Subject: [Enum] Impl.Issues: 5 - Treatment of Non-final loop in ENUM query

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 4 Nov 2003 12:06:25 +0000

Hi folks,
  (if you thought that issue 4 was obscure, this one's worse :).
Another (pure implementation) issue with non-final NAPTR processing
came up when (due to misconfiguration) we had a referential loop
in a pair of non-final NAPTRs.

A Client may detect a loop in an ENUM querie (e.g. there's a non-final
NAPTR within 5.4.3.2.1.e164.arpa that points to domain a.example.com.,
and within a.example.com there's a non-final NAPTR that points "back"
to 5.4.3.2.1.e164.arpa.).

Q: If 5.4.3.2.1.e164.arpa contains some NAPTRs that are as-yet unprocessed
when the initial "reference" is followed, then should the Client "return"
to the "referencing" domain to process the remaining NAPTRs, or should it
abort and give up on the whole query?

Background: This one can get a bit more involved. The client may continue
in the domain a.example.com looking for as-yet unprocessed NAPTRs, or might
instead discard all remaining NAPTRs in that domain and "return" to the
5.4.3.2.1.e164.arpa. domain and look there. Where there are three non-finals
in different domains, the Client has the choice to abort the whole non-final
"recursion" and return to the original domain, or just go "one domain up"
and continue with processing the domain that included the non-final that
had the "bad" non-final.

In our Client, we choose to continue with the domain that includes the
"bad" non-final rather than either aborting the whole query or returning
to the initial "top of the stack" domain.

Although we (obviously) think that this is the way to go, I'd appreciate
any opinions on whether or not this is the best approach.

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum