Subject: [Enum] uniqueness - new recap, old issues - now what?

From: Andy Gallant <[email-masked]>
Date: Fri, 23 Feb 2001 08:46:34 -0600

After a very busy week at the Inbox, this is one way
to sort out some of the uniqueness issues.  Disclaimers 
apply: I'm just thinking out loud here, and terms are
intended to be illustrative.

Category 1:  Uniqueness alternatives.

  -  ENUM: E.164 --> e164.arpa (complete uniqueness
     exactly as in RFC 2916 and supported by RFC 3026);

  -  ENUM: E.164 --> [TBD.foo] (complete uniqueness as in 
     RFC 2916 (and RFC 3026) but into some other domain);

  -  Multiple ENUM-like images of E.164 numbers in multiple
     domains in DNS; or

  -  Multiple E.164s.

Discussion threads would be easier to follow if the points
being debated were clarified according to their scope.  For
example, there is clearly a significant difference between
opposing e164.arpa and opposing a (the?) unique ENUM image
of E.164 numbers in DNS.

Finally, in my opinion, debating what appears to be
multiple E.164s (as in recent messages mentioning
going around Administrations or using TPC.INT) is
out of scope for ENUM discussions.  The starting
points, again in my opinion, are the existing E.164
and DNS, and the objective is ENUM-enabled access
to competitive services (roughly speaking).

-Andy Gallant

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

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 23 Feb 2001 08:58:45 -0800

Sorry for not being active on this list, but I found out that I was 
for some reason unsubscribed months ago...weird. I thought it was a 
bit quiet :-)

Now, I agree fully with Andy's request, and I have a question for 
people which argue for some of these alternatives:

>Category 1:  Uniqueness alternatives.

The scenario is that an enduser A, which has an E.164 number A-E goes 
to some entity and have that registered in DNS under some E.164 root, 
and let's call that root A-root.

Enduser B, which has an E.164 number B-E goes to some other entity 
and have his number registered under B-root.

C is going to call A and B in order.

Questions:

(a) What domainname do C use when trying to look up ENUM information 
for A-E and B-E?

(b) How do C know that those are the domainnames to use?

(c) How do we ensure that if A-E exists under A-root and also under 
B-root, that they are the same, or that this situation is not allowed?

(d) If you need the syncronization I claim one need (depending on 
answer of (c)), what is the difference between this and a situation 
where you have only one zone, which multiple parties can enter 
information into?

>to competitive services (roughly speaking).

(e) Given the answers to the questions above, what more precisely is 
it people which argue for multiple roots want to compete about? I.e. 
what is the competition about? Endusers should be able to choose who 
they talk to when asking for a number to be registered in DNS or 
entities which want to run services which doesn't belive that the 
"parent" in the DNS tree (A-root and B-root) and created, or created 
with the wrong policy, and they because of this belive they have to 
do an endrun around the process around the definition of the root?

     Patrik