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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Sat, 12 Aug 2000 08:13:52 -0500

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.

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).

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

---

From: Hong Liu <[email-masked]>
Date: Sat, 12 Aug 2000 11:50:28 -0400

Greg,

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

Cheers,

--Hong

> 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'.

> 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.