Subject: RE: [Enum] Re: draft-ietf-enum-e164-dns-02.txt: IANA Consideratio ns

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2000 14:23:50 -0400

(typo corrected.)

At 09:28 AM 7/31/00 -0400, Michael Froomkin - U.Miami School of Law wrote:
>serious divisions; that said it the odds of ICANN collapsing in the short
>run seem small -- although bigger than they did six months ago. The first

That sweeping assessment, absent detailed listing of its basis, translates 
into a statement more of personal hope than meaningful analysis.

>half of point 5 is certainly true; I don't know if the second half
>necessarily follows.

My wording was not as careful as it should have been.

I meant that no new issues in IANA and DNS administration are raised.

To the extent that anyone *says they do not* know if that assessment is 
true -- and they wish to claim *or imply* that it is not -- they need to 
provide details which substantiate additional concern, besides the lack of 
their knowing the truth of the assessment.

>Point 2 is not quite correct.  There was a very substantial break about
>two years ago when ICANN took over IANA from USC.  There has been

And here my wording was careful.

In fact the administration has been continuous and stable.

The policy-level work has recently been erratic.  Different area of concern.

For those aware of the 15-year history, it is worth noting that the 
policy-level work has ALWAYS been erratic...

>instead of Jon Postel.  ICANN claims the authority to tell IANA what to
>do, although it has entered into an agreement with the IETF not to use
>(much of) that authority.  Not quite the same thing.

In fact, there IS an agreement with the IETF, but it is only with respect 
to those on-going administrative issues over which the IETF has authority.

My suspicion is that the intended reference, here, was to issues that have 
essentially never been an IETF matter.  My other suspicion is that the 
agreement to exclude/limit has not happened, so it would be
more than slightly helpful to see a reference to documentation that 
substantiates the claimed agreement.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 31 Jul 2000 15:02:53 -0400

Friends, please stay friends. Let's not have yet-another-mailinglist 
which turns into something which looks like "how do we 
fix/replace/change/xxxx ICANN".

Also, the IAB has already asked the wg to use .ARPA for these kind of 
architectual discussions. Before you talk with IAB about your 
concerns, you should read 
http://www.iab.org/iab/statement-on-infrastructure-domains.txt, i.e. 
"IAB Statement on Infrastructure Domain and Subdomains".

Now, we can of course in the wg go back to IAB to say either of:

(1) We don't belive that the E164 numbers is something which falls 
into the category of domains which you talk about in your statement

(2) We don't agree with the IAB on their conclusions, and rather see 
that infrastructural things should be in some other place in the DNS 
hierarchy.

Regarding these, I personally think only (2) is something that can be 
discussed, as I belive (1) is true for the E.164 numbers. This 
because my belief is that the E.164 number -- with the wide knowledge 
people have about E.164 all over the world -- will be really 
important and used in various applications all over the place. Just 
look at the interest in ENUM!

Regarding (2), I have not been able to find a single place in the DNS 
tree which can be as stable as .arpa. This from an operational 
perspective (widely distributed stable home for the NS for the E164 
RR, regardless of parent zone owner). All alternatives I have found 
are not at all as easy to create as e164.arpa. For example, one 
alternative would be to create a new TLD....how long time and how 
much discussions, with how many bodies do you think is needed for 
that to happen? Directly under ".int"? Well, should/can/want we 
really touch the discussions regarding policy/home for .int in this 
wg? Under "itu.int"? Is it really wise to have infrastructural issues 
under the same domain as an organization, what is the risk of failure 
when they add www1.itu.int to the same zone? Etc etc etc...

The answer to all of these questions is NO, and that e164.arpa is the 
best place we can place things at the moment, exactly as IAB has 
already said.

   paf