Subject: RE: [Enum] Tier II roll out

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 21 Feb 2001 10:21:04 -0500

> -----Original Message-----
> From: David R. Conrad [mailto:[email-masked]]

> >>However, the point I was trying to make was countering Christian's 
> >>assertion that the IETF shouldn't be establishing domains.  
> The IETF is 
> >>in the business of specifying protocols of which the use of 
> in-addr.arpa 
> >>for associating names with addresses is one.  If this is, 
> as you say, 
> >>protected from antitrust concerns by the USG's magic wand, 
> then it would 
> >>appear to follow that e164.arpa would be protected as well.
> >Except that we're creating de novo, an entirely
> >new infrastructure and marketplace, with a really
> >substantial scale and significance that Christian
> >points out.
> 
> This is one view.  Another view is that we are simply mapping 
> an existing 
> infrastructure into the DNS.

Seems to me that this is somewhat more unique a situation than you make it
to be here, though. I'm sure I don't have the jargon right, but:

The DNS is typically listing domains that individual corporate entities
organize, control, and maintain ... independently. This enum is very
different. Here, the DNS is being made to collapse a large multinational,
highly regulated database into the structure usually assigned to a single
corporate entity.

It doesn't surprise me that people get antsy about ensuring the integrity of
this e.164 database, even when it sits in this different, somewhat
unregulated and freewheeling database (let alone the possibility that it
might be assigned also to domains other than .arpa!).

I'm not familar with the details of what this animated discussion has been
covering, but it does seem clear that enum is new ground for the DNS.

Bert
[email-masked]

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

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 21 Feb 2001 17:48:38 -0800

Albert,

At 10:21 AM 2/21/2001 -0500, Manfredi, Albert E wrote:
>This enum is very

No it is not.  Why do you think this?

>covering, but it does seem clear that enum is new ground for the DNS.

In as much as it has brought the IETF into direct ... um... contact with 
the ITU in new and interesting ways, yes it is new ground.  However, the 
technology is not particularly new.

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 22 Feb 2001 12:19:51 -0800

Albert,

At 10:21 AM 2/22/2001 -0500, Manfredi, Albert E wrote:
>No one other than Boeing would give a hoot if someone screws around
>with this domain.

Well, not quite true -- I imagine Lockheed Martin would be really happy if 
(say) special-projects.boeing.com got redirected to a LM server (which is, 
of course, possible with the current DNS system), but I know what you 
meant... :-)

>The information in the e164.arpa database is instead controlled by multiple
>organizations from many countries,

There are a couple of proposals on how to move forward with deploying e.164 
identifiers into the DNS.  One proposal is to have a singly rooted tree 
with top level control of that tree vested in the international body that 
administers the e.164 identifier space (the ITU).  Delegation of the 
sub-trees would correspond to delegations within the e.164 identifier 
space, e.g., 4.4.e164.arpa would be delegated in whatever way the UK body 
responsible for delegating the telephone country code sees fit.

Another proposal is that there would be multiple e.164 identifier trees in 
the DNS, with the administrators of those trees competing against each 
other.  That is, e164.org would compete against 
e164.mytelephonenumbersinthedns.com which would compete against 
telephone.af (etc).  Each of these organizations would presumably be 
required to (somehow) insure the delegation of numbers in the telephony 
system matches what they are delegating in their DNS e164 trees.  "ENUM 
clients" (that is, DNS clients that know what to do with the results of 
NAPTR queries) would be able to query these multiple trees and (somehow) 
resolve conflicts.

In the first model, your assertion isn't correct.  Or rather, the situation 
is not significantly different that is currently the case with the existing 
PSTN numbering scheme.  In the second model, the potential exists for the 
situation you describe.  I simply don't believe the second model will 
scale/work if you make the assumption that a telephone number lookup 
3.0.0.6.1.8.3.0.5.6.1.e164.org should give you the same answer as a 
telephone number lookup in 3.0.0.6.1.8.3.0.5.6.1.telephone.af.  Others feel 
differently.

Rgds,
-drc