Re: [DNSOP] on private use TLDS

[Doug Barton <[e-mail]>]

On 11/28/19 2:42 PM, Roy Arends wrote:
> 
>> On 28 Nov 2019, at 22:30, Doug Barton <[e-mail]> wrote:
>>
>> And if you don't think ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read the reference I provided.
> 
>  From section 3.2: "The deferral is not guaranteed to be forever”. That doesn’t read like a promise to not delegate HOME, CORP, and MAIL.

Yes, Paul Hoffman confirmed your reading of the text, and I've already 
conceded that this isn't a guarantee. Which is all the more reason to 
work with ICANN to solidify it.

>> Meanwhile, as many others have pointed out, and your side of the argument continues to ignore, ISO can choose to change those rules.
> 
> It is not that simple. While it is in ISO’s remit to change a category from User Assigned to another category, it is extremely improbable.

What I find really interesting about this is that folks on your side of 
the argument want us to believe that ICANN is free to change their mind, 
but ISO is not.

> The IANA has not blindly surrendered to ISO-3166. There are differences in the list of ccTLDs and ISO’s officially assigned code elements.

Examples please? I know when I was in charge of that we were pretty 
strict about it.  :)  And yes, I'm aware of the fact that ICANN uses 
"exceptionally reserved" code elements like AC and EU (I worked on the 
IANA Report for the latter), but ICANN's use is consistent with their 
definitions.

>> OTOH, we do have a means of working with ICANN to codify certain TLDs for private use.
> 
> This is false. If you are referring to RFC 6761, then I suggest to read it again. Focus on the “special use” part of the text. While the result of reserving (say) “.private” has the desired effect (nxdomain forever), this is not the intent of RFC6761.

I'm referring to the fact that the IETF and ICANN have a unique 
relationship in regards to the stewardship of the root zone, and that we 
should utilize that relationship, in cooperation with them, to codify 
domains for this use case. Is your argument that this is a thing that 
cannot be done? Just because 6761 documented one aspect of the 
non-public TLD situation doesn't mean that we can't create a new 
document that codifies others.

In fact, that's exactly what you're asking us to do, it's just that for 
some reason you don't want to involve ICANN in the process, you want to 
do it by laying claim to things that don't belong to us.

Doug