Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 14 Aug 2000 09:10:26 -0500

>The problem here is the 'disconnect' between the client who lauches the
query,
>and the user who provisions the NAPTR RRs. Both have a way to ignore the
>numbering plan if they choose to, but neither can assume what the other
side may
>do. To make the NAPTR algorithm work, I would think that the burden should
be
>put on the shoulder of the user who provisions the RRs. In this way, the
client
>always starts with some numbering plan according to the digits received,
the
>user can consolidate the records for all numbering plans if he/she chooses
to do
>so.

You have nailed the crux of the problem for the existing ENUM document.  We
need to clearly define the behavior of the client upon receipt of NAPTR's
that have unrecognized components.  Which which unrecognized components are
"errors" and which are "extensions" need to be clearly identified to use
this mechanism in more interesting ways going forward.

The easiest resolution seems to be to indicate that E2U can only be used for
E164 numbers, and drop the "+".  The "+" without defined semantics is at
best useless and at worst a limitation on future extensibility.  Vague
references in email to using the "+" in the future to somehow distinguish
between address completion and ENUM resolution are not adequate.

Greg V.

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Saturday, August 12, 2000 10:50 AM
To: Vaudreuil, Greg M (Greg)
Cc: Richard Shockey; [email-masked]; Patrik Fältström; Manfredi,
Albert E; [email-masked]'; Scott Bradner; [email-masked]
Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt

Greg,

You have raised a number of good points. I have some additional comments in
between the lines below.

Cheers,

--Hong

"Vaudreuil, Greg M (Greg)" wrote:

> I am also concerned with the number of NAPTR records that may proliferate
if
> we require a separate service selector for each numbering plan.  In my
> previous example where a typical corporate node may have four numbering
plan
> entries, (164, corporate-wide private, local site extension, national) we
> need to consider that multiplied by say six services for 24 records! In
most
> cases, the resulting URL does not depend upon the input string, that is,
it
> does not matter what number or dialplan was used to find it.
>

The issue here is how fine-grained we want to differentiate the services
offered
by ENUM. In general, the numbering plan indicator provides more detailed
information than the corresponding service selector. What I have in mind is
the
following:
(1) For each numbering plan defined by ITU-T, say E.xxx, define exxx+digits
as
the numbering plan indicator and ExxxToU as the service selector;
(2) For each national numbering plan, define YY+digits as the numbering plan
indicator and YYtoU as the service selector. Here YY is the two letters for
each
country as defined by ISO 3166;
(3) For other corporate or private numbering plans, define a 'private'
numbering
plan indicator and use something like 'P2U' as the service selector; Note
here
'P2U' serves as a generic service selector for private number to URI
mapping.

(1) and (2) can be standardized easily, using the schemes already
established by
other standards bodies. For (3), we probably do not, and cannot, standardize
the
plan indicator for two reasons: first, it is 'private' anyway; second, there
are
two many of them.

Note that it is the numbering plan indicator, not the service selector, that
makes the NAPTR RRs different, i.e., the regexp part. If you can find a way
to
combine different numbering plans into a single regexp, consolidating
service
selectors is easy, just use the '+', e.g. 'mailto+E2U+US2U+P2U'.

>
> I would like to see E2U explicitly support other numbering plans.  This
can
> be done by noting that + is the dialplan separator.  If no dialplan is
> indicated, then the NAPTR applies to all numbering plans.  If a particular
> NATPR record is intended to be limited to only E164 numbers, than the E164
> dialplan indicator is explicitly indicated with e164+digits.
>
> If an unknown dialplan is indicated in the returned NAPTR record, the
record
> is ignored (No match is found).
>

Basically, you have suggested two things here:
(1) Overload or generalize the semantics of  'E2U' from 'E.164 to URI' to
'Telephone Number to URI'. This is a very good idea in that we do not need
to
worry about choosing different service selectors when using ENUM. If the WG
decides to go this route, then I suggest we use a different name instead,
such
as 'T2U' because 'E2U' suggests something for E.164. I don't use 'N2U' since
I
do not want to confuse that with existing URN service selectors such as
'N2I'.
(2) The default or 'ANY/ALL' construct for all numbering plans. This is also
a
very good idea for consolidating different NAPTR RRs when we don't care
which
numbering plan is used to reach those records. However, I see one problem:
it
assumes that the client knows a priori what the NAPTR RRs look like before
it
launches the query, i.e., the regexp in the NAPTR RR ignores the numbering
plan
indicator.
On the other hand, you can always write a regexp in such a way that it
ignores
anything upto the '+' (and including '+') in the input string to accomplish
the
same goal.
The problem here is the 'disconnect' between the client who lauches the
query,
and the user who provisions the NAPTR RRs. Both have a way to ignore the
numbering plan if they choose to, but neither can assume what the other side
may
do. To make the NAPTR algorithm work, I would think that the burden should
be
put on the shoulder of the user who provisions the RRs. In this way, the
client
always starts with some numbering plan according to the digits received, the
user can consolidate the records for all numbering plans if he/she chooses
to do
so.

>
> Note that this is completely compatable with the existing proposal.
Because
> only E164 is discussed, a default for all dialplans behaves as the current
> text.
>
> Greg V.
>
> -----Original Message-----
> From: Hong Liu [mailto:[email-masked]]
> Sent: Friday, August 11, 2000 10:51 PM
> To: Richard Shockey
> Cc: [email-masked]; Patrik Fältström; Manfredi, Albert E;
> [email-masked]'; Scott Bradner; [email-masked]
> Subject: Re: [Enum] Re: draft-ietf-enum-e164-dns-03.txt
>
> Richard, Patrik, and others,
>
> Thanks for the nice comments. I personally learned a lot from the email
> exchanges in the last few days. Assuming that we will leave '+' as it is
in
> the
> document, then I would like to add a note at the end of the ENUM
procedure,
> i.e. Section 2, as something like the following:
>
> "Note: The output of Step 2 above, i.e., an E.164 number without any
> characters
> but the leading '+' and digits, is the input string to the NAPTR
algorithm.
> The
> leading '+' is the E.164 numbering plan indicator, which SHALL be used in
> conjuction with the service selector E2U defined in Section 3.1.2 in all
> NAPTR
> resource records with a non-empty service field for E.164 to URI mapping.
>
> Other numbering plans MAY make use of the ENUM procedure defined above for
> telephone number to URI mapping with the following modifications:
> - Specification of an unique numbering plan indicator other than '+';
> - Specification of a service selector other than 'E2U';
> - Specification of the root domain name other than 'e164.arpa';
> However, these specifications are outside of the scope of this document.
It
> is
> envisioned that other numbering plan indicators and service selectors will
> be
> defined in a future document to accommodate multiple numbering plans using
> the
> same ENUM mechanism. "
>
> The language above is rough, as they are coming out of the top of my head.
> Please feel free to make modifications as you see fit.
>
> Not that I am stubborn, but I do feel that if we are to define
> 'numberplan+digits' as the generic structure for the input string to
NAPTR,
> it
> is better to change '+digits' to 'e164+digits' _now_ than later. I am more
> concerned about the massive number of NAPTR RRs to be populated in the DNS
> databases after this document becomes an RFC. As we have already seen, the
> input string format does dictate the regexp format in a NAPTR RR. Why is
it
> so
> difficult to change? Anyway, I will accept the consensus of the group.
>
> Richard Shockey wrote:
>
> > >If we are to adopt the 'numberplan+digits' as the generic structure for
> > >ENUM-like
> > >Application Unique String, then for E.164, I suggest we do it all the
> way,
> > >such as
> > >'e164+digits' as the input string to NAPTR. If we decide to use '+' as
it
> > >is, then
> > >I suggest that a paragraph be added in the document clarifying the
> > >semantics of
> > >'+' as a numbering plan indicator.
> >
> > Lets assume, for purposes of argument that '+' remains for the time
> > being.  Is there any language you'd like to suggest here... about the
> usage
> > of  '+'  ambiguous or unambiguous but leaving the door open for
> > enhancements in a future ID, which I'd hope you'd write? :-)
> >
>
> Sure, I will write an ID addressing extension issues for the next IETF
> meeting,
> with some other folks who are interested in this topic.
>
> Regards,
>
> --Hong
>
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/enum

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