Subject: [Enum] draft-ietf-enum-rqmts-01.txt: Section 3.5

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:19:01 -0400

Anne,

I have a number of questions regarding Section 3.5 of
draft-ietf-enum-rqmts-01.txt.

In the first paragraph,

"The protocol SHOULD also provide the ability to support corporate
numbering plan or competitive directory service  providers under
separate root domains.  It SHOULD NOT require an  additional centralized
administrator beyond that required for the
existing telephone number system."

The first sentence is a good one, but I am not sure how it relates to
"e164.arpa" being the only root domain discussed on the ENUM list so
far. Are we going to allow other root domains besides e164.arpa? I just
want to know whether this is what ENUM WG has in mind.

The second sentence is a bit too restricted to me, maybe I did not
understand it correctly. It seems to me that it implies that the
administration of E.164 numbers for both PSTN and ENUM be ONE entity,
which may not be what we want in the long run. I agree it is important
to keep the numbering space consistent across the two networks, however,
synchronization of changes may be achieved through other means instead
of requiring a single administrator.

In addition, it seems that these two requirements are not quite
consistent with each other, unless we assume the same administrator for
multiple root domains.

In the second paragraph,

"...In any case, the subscriber or enterprise is the ultimate authority
for service provisioning."

I guess this is confusing, given what is being done in PSTN today, at
least for individual subscribers. Do you mean "service provisioning" as
"self service provisioning", say through the web page? Will the change
be propagated in the ENUM hierarchy right away ("fast" update) or just
be logged into the system, which will be put into the system by the
administrator later on?

Thanks for the clarification,

--Hong

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:44:57 -0700

>want to know whether this is what ENUM WG has in mind.

What has been talked about in the corridors is the ability for 
individual companies in their private resolution use a different top 
domain for the resolution than E164.ARPA. The same algorithms.

   paf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 24 Jul 2000 08:25:17 -0500

>want to know whether this is what ENUM WG has in mind.

Well companies have private _dialing_ plans for their endpoints and the 
ENUM scheme can accommodate those through the use of a separate resolution 
servers such as e164.bigco.com.  We can assume that proxies and gateways 
will have sufficient intelligence to distinguish between internal dialing 
and external e164 connections.

There may be a need for a separate ID on this subject in the future.

>of requiring a single administrator.

Yes I agree this is a touch unclear but the intent is that from the Country 
Code NS delegation multiple and competitive resolution service providers 
can exist. This does _not_ change or alter the actual e164 plan in any way.

>"self service provisioning", say through the web page?

Yes ..though there is going to be some tricky AAA to deal with here.

>Will the change

Changes to RR's should be propagated as soon as possible given the nature 
of DNS itself ..earlier messages from Randy I think made this clear. That 
said we do need to engage in some operational testing of the environment.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Hong Liu <[email-masked]>
Date: Tue, 25 Jul 2000 20:38:37 -0400

Hi, Richard,

Thanks for the clarification. I still have some concerns. Please see my
comments below.

--Hong

> and external e164 connections.

I assume what you said is the ENUM can also be used for private numbering
plans. If that is case, then the requirements on 3.18 should be either removed
or reworded:

"3.18    E.164 Numbers

   The system is not responsible for returning information on private
   numbering plans and non-E.164 numbers.  The system is responsible
   for returning information on 1-800 and other legitimate E.164
   numbers. "

I think the problem here is whether ENUM should be restricted to be used as a
public resolution service only or can also be used as an enterprise solution.
Technically, it should be the same in terms of populating the RRs for the phone
numbers within an enterprise. Either way, I think we need to clarify that.

On the other hand, if we do allow other root domains than e164.arpa, then we
need to make that clear in draft-ietf-enum-e164-dns-02.txt that e.164.arpa is
used as A root, not THE root for ENUM.

> can exist. This does _not_ change or alter the actual e164 plan in any way.

I would suggest that we either remove the second sentence or reword it as
something like "How that is accomplished is a national matter and is outside of
the scope of ENUM." I know that I am punting the issue since there are problems
that need to be addressed here if multiple roots are allowed.

I am curious about how domain names are being administered today. Do we have a
single administrator for, say the .com domain, or multiple administrators? If
the answer is the latter, then how that is being done may help to shed light on
the problem we are facing in ENUM. I would appreciate if someone can answer my
question here.

> Yes ..though there is going to be some tricky AAA to deal with here.

I see. If that is the intent, then I would suggest that the text be changed to
something like "In any case, the subscriber or enterprise is the ultimate
authority for any changes regarding the RRs of their numbers. The system MAY
provide means for a subscriber or enterprise to modify the RRs of their numbers
by themselves, with appropriate security mechanisms."

The intent here is to be more specific about service provisioning since moving
a subtree from one service provider to another may involved more than just
changing the values in the parent RRs. Please see my separate response to
Patrik's email.

> said we do need to engage in some operational testing of the environment.

I am not arguing against the capability of DNS to propagate changes, as was
addressed in Randy's email. The issue I would like to raise here is whether the
changes a subscriber made is a change request, which will be logged and then
executed by the service provider in a well-defined later time or the changes
are written into the DNS zone file immediately. In PSTN, we use the former. I
just don't know which one will be used for ENUM.