ietf
[Top] [All Lists]

Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

2015-07-26 13:24:03
On 26 Jul 2015, at 17:36, John C Klensin wrote:

Given that ICANN, and a number of ICANN-related entities
(notably some ccTLDs and regional ccTLD organizations) continue
to cite 1591, "rendered obsolete" may be a little strong even
though some of its comments are certainly OBE at this point.
And ICANN did publish an update to 1591 in the form of something
called ICP-1 [1].  It didn't say much and, IIR, was not
well-received and has sort of vanished from everyone's radar.  I
would suppose that the "update" for 1591 is the combination of
the ccTLD fast track procedure and the Applicant Handbook, with
1591 and/or ICP-1 still applying to 3166-1-based ccTLDs and
redelegations.

If we are having this discussion, which I do not think we should have here, I 
would be more careful with wording and separate the issues with various 
different PDPs inside the ICANN Community (most notably ccNSO and gNSO driven 
ones) and whatever work ICANN staff and Board run processes create. And not 
only say "ICANN" (although the use of the word "ICANN" definitely show 
correctly that one of the larger issues that not even people active in ICANN 
can separate the processes from each other -- and sometimes they can, but they 
deliberately mix them up).

Now, I agree ICP-1 is not very good, but I am still of the view that IETF could 
very well update RFC 1591 according to what the IETF view has changed during 
the years. If nothing else as a historical document, and it would also have 
made the handoff to the ICANN be much easier than what it has been now.

If nothing else, we see on this discussion how entangled the IETF process and 
view is with the ICANN process and view, and I still think it would have been 
better if IETF would have created a box in the namespace within which ICANN 
could play. Similarly to what the RIRs are allowed to do within the IPv4/IPv6 
address spaces.

Too late?

   Patrik

Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>