headers
Richard Shockey | 3 Nov 2003 20:42
Picon

FINAL Agenda for ENUM WG IETF 58 Minneapolis


TUESDAY, November 11, 2003
0800-1800 IETF Registration - Ballroom Foyer, 3rd Floor
0800-0900 Continental Breakfast - Ballroom Foyer, 3rd Floor

1130-1300
Break 1300-1400 Afternoon Sessions I
APP ldapbis LDAP (v3) Revsion WG
INT send Securing Neighbor Discovery WG
OPS dnsop Domain Name System Operations
WG OPS ipcdn IP over Cable Data Network WG
RTG pim Protocol Independent Multicast WG
SEC enroll Credential and Provisioning BOF
TSV enum Telephone Number Mapping WG

IETF 58 Minneapolis Telephone Number Mapping (ENUM) WG  Agenda

Chair(s):
Patrik Faltstrom <paf <at> cisco.com>
Richard Shockey <rich.shockey <at> neustar.biz>

Transport Area Advisor:
Allison Mankin  <mankin <at> psg.com>

Mailing Lists:
General Discussion:enum <at> ietf.org
To Subscribe: enum-request <at> ietf.org
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 12:06
Picon

Impl.Issues: 1 - Case Sensitivity

Hi Folks,
   here's an issue we've come across when looking at ENUM domain 
content "out there".
Some NAPTRs use lower case for the flag field value; some use upper 
case - (e.g. 'U' or 'u')
Some NAPTRs use lower case for the ENUMservice tokens; some use upper 
case - (e.g. 'SIP' or 'sip')

In our clients we treat both of these strings as case-insensitive 
(i.e. we do a tolower before
comparing them). This is also done in a couple of the Clients where 
I've scanned their source.

Thus...

Q:  It looks like most clients are designed to treat the flags and 
service fields as case-insensitive.

Does anyone object to this (i.e. does anyone have a burning desire to 
have the flag and
services field entries treated as case-sensitive)?

all the best,
   Lawrence
--

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:lwc <at> roke.co.uk>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 12:18
Picon

Impl.Issues: 2 - Reservation of E2U

Hi Folks,
   here's an issue we've come across when looking at ENUM domain 
content "out there".
Some NAPTRs use the soon-to-be obsolescent (2916) syntax, whilst 
others use the syntax defined in 2916bis -
(i.e. the E2U is at the rightmost or leftmost end of hte services field).

As one should be 'liberal in what one accepts' (and both forms are 
"out there"), it is
appropriate to process both forms. However, I think that this does 
mean that there should
NOT be a valid ENUMservice with the token 'E2U' (or 'e2u' or 'e2U' or 'E2u').

[For those old enough, this is a shade of the JANET vs. 822 domain 
ordering issue]

Does anyone have a burning desire to allow such an ENUMservice token, 
or instead can we ask
IESG and/or IANA to reserve this token (or these tokens, if case 
sensitivity is required)?

all the best,
   Lawrence
--

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:lwc <at> roke.co.uk>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 12:32
Picon

Impl.Issues: 3 - service field in Non-final NAPTRs

Hi folks,
  there don't seem to be any non-final NAPTRs "out there" yet and I'm not
sure what should be the solution, so this is a pair of straight questions:

Q: MUST a Client ignore the content of the service field in a non-final
NAPTR (i.e. one with an empty flags field)?

Q: MUST a Registrant NOT populate a non-final NAPTR with a non-empty services
field?

Background: We were unclear over whether or not a non-final NAPTR acted
regardless of DDDS application, or instead it could include a non-empty
services field, including E2U and, potentially, ENUMservice token(s).
In the latter case, one could treat the non-final NAPTR as being DDDS
Application specific and possibly even have more than one non-final NAPTR
with each one being tied to a different application (e.g. one for E2U,
one for D2U, one for ...). Furthermore, one could traverse the non-final
if and only if the specified ENUMservice was supported by the Client.

In effect, the intent of the Registrant would be "for contact info for
the h323 ENUMservice within ENUM, look here" or "for contacts for the
sip ENUMservice, look there".

Against that, the Registrant might have decided to leave the services
field of a non-final NAPTR blank, or the Client may choose to ignore
the service field content in this case, so the Client has to be able
to handle the other case (I guess as a "catch-all").

At present, we ignore the services field in our Clients, but I'm
interested in the group's opinions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 12:46
Picon

Impl.Issues: 4 - treatment of ORDER in NAPTRs with non-supported ENUMservices

Hi folks,
   this one's pretty obscure, but it's tied to the way that Clients
select from several possible contact choices. We have seen a few
domains within which NAPTRs with different ORDER field values exist,
and it's not always completely clear how to react (i.e there are corner
cases like this).

The ENUM Client can select which of a set of NAPTRs that share the same
("winning") ORDER field value based on its capabilities; thus, if it
doesn't handle the ENUMservice h323, then even though this appears in
a NAPTR with the best priority/preference, the Client can discard it
and go on to the next best, and so on.

However...
Q: If the Client discards a NAPTR as it specifies an un-supported ENUMservice,
then should the Client re-evaluate the "winning" ORDER field value after
discarding the NAPTR containing the un-supported ENUMservice?

Background: This came up as a corner case when we were testing non-final
NAPTR processing - the "referred" domain had NAPTRs with a new "winning"
Order field value, but none of the NAPTRs in that domain were supported,
so should a Client "return" to try with lower preference/priority NAPTRs,
or just give up, as it had hit one with a new "winning" Order value?

Opinions gratefully received - at present, our client only considers the
Order field value within a single RRset, so if no NAPTRs give useful
results in a "recursive" call, it returns and continues with any unprocessed
NAPTRs in the "referring" domain (i.e. the one with the non-final NAPTR).

all the best,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 13:06
Picon

Impl.Issues: 5 - Treatment of Non-final loop in ENUM query

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 14:47
Picon

Impl.Issues: 6 - detection of Non-final loop in ENUM query

Hi folks,
   here's another choice that Clients have to make when dealing with non-finals.

Q: Is is necessary to keep a full "domain traversed" list for each 
ENUM query, or
    is it sufficient to just keep a "recursion count", detecting a 
loop by the count
    expiring?
    Q: If the latter is OK, then how many non-final domain traversals 
is reasonable
       for a query?

Our Client currently sets a recurstion limit of 5, so that, if non-final
references are encountered within an ENUM query, when the references are more
than 4 deep it classifies this as a loop and continues where it left off
(see issue 5 for the related question :).

Can anyone think of a case where one might reasonably expect any deeper
nesting, or where immediate loop detection is required?

all the best,
   Lawrence
--

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:lwc <at> roke.co.uk>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
Permalink | Reply | 0 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 15:46
Picon

Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority

Hi folks,
   We have seen domains with more than one NAPTR with the same 
priority/preference
field value "out there"; this shouldn't happen, but as we prefer to be liberal,
how should a Client react?

Again, this is a pure implementation issue; there doesn't seem to be 
anywhere in
2916bis or in 340x where this is explicitly barred, even though the 
WG discussions
have suggested that it's a bad idea.

Some of the affected domains are "published" via DNS servers that 
return responses
in a fixed RRset pattern; examining the NAPTRs themselves, it looks 
like some folk
assume that an "in order" processing is expected.

Now...of course this is risky activity, as there's no guarantee of 
ordering, and
a simple change of DNS server (or version) can remove the option of 
fixed delivery
order, causing some strange results (i.e. Clients calling what were 
assumed to be
lower contacts).
In short, the simple answer is: "don't do it", but whilst there are 
some out there
that do...

We chose to treat NAPTRs with identical order and preference/priority
(Continue reading)

Permalink | Reply | 2 comments |
headers
Conroy, Lawrence (SMTP | 4 Nov 2003 16:00
Picon

Impl.Issues: 8 - Evaluation order for NAPTR with multiple ENUservices

Hi folks,
   one more issue; the only NAPTRs we've seen with more than one ENUMservice in
them are ones tied to mobile phones, but it's a general 
implementation issue, so...

Q:  If a NAPTR contains more than one ENUMservice, should these ENUMservices be
evaluated from left to right, or from right to left?

Background:  This matters, as the Registrant may populate NAPTRs in 
which they intend
to specify that they prefer to receive an SMS, and only if this can't 
be done to receive
a voice call. If these two ENUMservices are tied to the same URL (and 
have adjacent
preferences) then a single NAPTR may be "published" holding both ENUMservices.

However, should this be:
  'E2U+sms:tel+voice:tel' '!^.*$!tel:44-767-123-4567'
or instead:
  'E2U+voice:tel+sms:tel' '!^.*$!tel:44-767-123-4567'

Our Client chooses left-to-right evaluation order for NAPTRs with 
multiple ENUMservices.

If anyone can think of a good reason to process right to left, please holler.

all the best,
   Lawrence
--

-- 
-----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Reid | 4 Nov 2003 16:56

Re: Impl.Issues: 7 - Order of evaluation of NAPTRs with equal preference/priority

>>>>> "lwc" == Conroy, Lawrence (SMTP) <lwc <at> roke.co.uk> writes:

    lwc> Hi folks, We have seen domains with more than one NAPTR with
    lwc> the same priority/preference field value "out there"; this
    lwc> shouldn't happen, but as we prefer to be liberal, how should
    lwc> a Client react?

Well there doesn't seem to be anything which prohibits NAPTRs for some
name having identical priority/preference values and it wouldn't be
reasonable to do so IMO. So in these cases, the client should
figuratively toss a coin to make the decision, just like when mail
software finds there's 2 or more equal preference MX records for some
domain.

    lwc> Now...of course this is risky activity, as there's no
    lwc> guarantee of ordering, and a simple change of DNS server (or
    lwc> version) can remove the option of fixed delivery order,
    lwc> causing some strange results (i.e. Clients calling what were
    lwc> assumed to be lower contacts).  In short, the simple answer is:
    lwc> "don't do it", but whilst there are some out there that  do...

I must be missing something. If the NAPTRs are equal, whoever is
publishing them doesn't care which URI clients go to after they do a
lookup. Therefore the client shouldn't need to be given rules to make
it behave deterministically for these cases. 

A rule which says "select equal NAPTRs in the order they appear in the
DNS response" is meaningless. [Though in practice this is what mail
software tends to do when MX records are equal.] The reason for that
is there could be a resolving name server between the client and the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane