Subject: [DNSOP] On .ZZ

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 21 Nov 2019 15:18:55 +0800

Setting the basic issue aside (I'm still a bit torn) I agree with
Warren that it would need a string that has a meaning.

.ZZ would remind me of long beards and loud motorcycles for the rest
of my life.. https://de.wikipedia.org/wiki/ZZ_Top

best,
Alex

---

From: Jared Mauch <[email-masked]>
Date: Thu, 21 Nov 2019 02:21:25 -0500

.ZZ makes as much sense as anything else to be honest, virtually anything is going to conflict with some acronym or name out there.

- Jared

> On Nov 21, 2019, at 2:18 AM, Alexander Mayrhofer <[email-masked]> wrote:
> 
> ..ZZ would remind me of long beards and loud motorcycles for the rest
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Nov 2019 15:26:44 +0800

> On Nov 21, 2019, at 15:18, Alexander Mayrhofer <[email-masked]> wrote:
> 
> 

English speaking people can’t even agree on how to pronounce this name......

Having an undelegated .zz is also not guaranteed to be free of security issues, for example if ICANN delegates .zzz there will be interesting typo attacks possible in this weird private space.

Finally, I agree. People want something semantic and more pronounceable.

Paul

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 21 Nov 2019 08:55:24 +0100

> Having an undelegated .zz is also not guaranteed to be free of security issues, for example if ICANN delegates .zzz there will be interesting typo attacks possible in this weird private space.

The code zzz is also private space

 > Finally, I agree. People want something semantic and more pronounceable.

In what language? Furtherore, there are a sle of codes to choose
from. Currently the principle choice is wether one wants to use
these 'User Assigned' ISO codes.

	jaap

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 21 Nov 2019 08:57:41 +0100

On 11/21/19 8:26 AM, Paul Wouters wrote:
> for example if ICANN delegates .zzz there will be interesting typo attacks possible in this weird private space

In this respect .zz is at least better than .xx which was among the
suggestions.

> Finally, I agree. People want something semantic and more pronounceable.

I don't think it's possible to satisfy completely all potential use
cases with a single name.  Desire for being short was also stated by
multiple people.  For semantic and pronounceable options we already have
myDomain.com - which has additional benefits like being able to work
globally.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Nov 2019 16:18:03 +0800

On Thu, Nov 21, 2019 at 3:57 PM Vladimír Čunát <[email-masked]>
wrote:

> > for example if ICANN delegates .zzz there will be interesting typo
> attacks possible in this weird private space
>
> multiple people.

The draft specifically disclaims the semantic/pronounceable aspect.

IMHO, there is *no* reason not to advance both .zz and .internal:

   - .zz (for general non-human use cases, like automatically generating
   locally scoped, globally unique names, a use case I have for
   resolver/forwarder identity)
   - .internal (for humans)

Or basically, for the pronounceable use case, keep that separate and do in
another place, don't really care where/how (e.g. .internal.arpa or
.local.arpa or whatever).

If the delegation is to AS112, I think the typo attacks become a
diminishing issue. Not sure, though.

Brian

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Thu, 21 Nov 2019 10:28:31 +0200

I agree with Jaap (about the principle).

I think it is safe to assume that there will not be a ccTLD
corresponding to an alpha-2 code element that does not form part of
3161-1 ie is available as 'User Assigned'.

I personally find an alpha-3 code element, ie .ZZZ, less confusing to
the casual user than an alpha-2 one, ie .ZZ, but, perhaps unfortunately
(in this context) the User Assigned alpha-3s are open for business (eg.
.XYZ and .XXX come to mind).  So anything there, even .ZZZ is a
possibility.  Only the ones which are possible (ie correspond to an
actual country name in the Standard) under 3611-1 are (somewhat)
protected, apparently

So using alpha-2 seems the only option and .ZZ does make sense.

Could Paul's valid point be solved by 'reserving' .ZZ[A-Z] as well?

el

On 21/11/2019 9:55 am, Jaap Akkerhuis wrote:
>  > > ..ZZ would remind me of long beards and loud motorcycles for the
>  > > rest of my life..  https://de.wikipedia.org/wiki/ZZ_Top
>  >
>  > Having an undelegated .zz is also not guaranteed to be free of
>  > security issues, for example if ICANN delegates .zzz there will be
>  > interesting typo attacks possible in this weird private space.
>  >
> 
> from.  Currently the principle choice is wether one wants to use these
> 'User Assigned' ISO codes.
> 
> 	jaap

-- 
Dr. Eberhard W. Lisse          / Obstetrician & Gynaecologist (Saar)
[email-masked]            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421                  /
Bachbrecht, Namibia     ;____/

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 21 Nov 2019 07:25:47 -0800

> On Nov 21, 2019, at 12:18 AM, Brian Dickson <[email-masked]> wrote:
> IMHO, there is *no* reason not to advance .zz

For the record, I think it’s a really bad idea to start re-purposing the ISO user-assigned codes.  Just as bad an idea as if they started re-purposing 1918 space.

                                -Bill

---

From: Shane Kerr <[email-masked]>
Date: Fri, 22 Nov 2019 09:20:42 +0100

Bill and all,

> For the record, I think it’s a really bad idea to start re-purposing the ISO user-assigned codes.  Just as bad an idea as if they started re-purposing 1918 space.

Hm... this is an interesting point.

I just checked the ISO 3166 glossary:

https://www.iso.org/glossary-for-iso-3166.html

And it says:

"User-assigned codes - If users need code elements to represent country 
names not included in ISO 3166-1, the series of letters AA, QM to QZ, XA 
to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and 
ZZA to ZZZ respectively, and the series of numbers 900 to 999 are available.
NOTE: Please be advised that the above series of codes are not 
universal, those code elements are not compatible between different 
entities."

So the intention of the ISO at least is that these codes are used by 
users. (I'm not sure what the scary warning means.) Certainly I have 
made heavy use of .Q* and .X* in my own testing, with the assumption 
that these would never be assigned (and yes, there is .TEST but 
sometimes you need more than one one TLD).

Cheers,

--
Shane

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 22 Nov 2019 00:26:35 -0800

> On Nov 22, 2019, at 12:20 AM, Shane Kerr <[email-masked]> wrote:
> "User-assigned codes - If users need code elements to represent country names not included in ISO 3166-1, the series of letters AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers 900 to 999 are available.
> NOTE: Please be advised that the above series of codes are not universal, those code elements are not compatible between different entities."
> 
> So the intention of the ISO at least is that these codes are used by users. (I'm not sure what the scary warning means.) Certainly I have made heavy use of .Q* and .X* in my own testing, with the assumption that these would never be assigned (and yes, there is .TEST but sometimes you need more than one one TLD).

Right.  And in fact, “unassigned” ISO codes _do_ get used, for places like Kosovo, that are in a state of disputed or partially-recognized countryhood, and ranges that are reserved for user use really should be left for that use, because they do in fact get used by users, so any centrally-coordinated use will run afoul of that.

Again, this is an argument from principle rather than an argument based on the specific case at hand.  I just think that we have a well-established precedent that all two-letter TLDs are derived from ISO 3166 Alpha-2, and it’s bad form to cross back over and start poaching in their territory.

                                -Bill

---

From: "Erwin Lansing" <[email-masked]>
Date: Fri, 22 Nov 2019 09:46:13 +0100

> -----Original Message-----
> From: DNSOP <[email-masked]> On Behalf Of Bill Woodcock
> Sent: Friday, November 22, 2019 9:27
> To: Shane Kerr <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DNSOP] On .ZZ
> 
> 
> 

Beware of assumptions. I would never have imagined in my wildest dreams for St. Maarten to be assigned SX.
> 
> Right.  And in fact, “unassigned” ISO codes _do_ get used, for places
> like Kosovo, that are in a state of disputed or partially-recognized
> countryhood, and ranges that are reserved for user use really should
> be left for that use, because they do in fact get used by users, so any
> centrally-coordinated use will run afoul of that.
> 
> Again, this is an argument from principle rather than an argument
> based on the specific case at hand.  I just think that we have a well-
> established precedent that all two-letter TLDs are derived from ISO 3166
> Alpha-2, and it’s bad form to cross back over and start poaching in
> their territory.
> 
Agreed. There is a well-established process for assigning country codes. While it might seem a sensible assumption that no country would be assigned these specific cases, it would open up potential conflicts and create a dilemma for newly established countries to either not be able to get the preferred ISO3166 country code or have  different country code and TLD. As far as I know, this is also current ICANN policy.

Erwin

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Nov 2019 09:32:44 +0000

On Friday, 22 November 2019 08:26:35 UTC Bill Woodcock wrote:
> ...
> 
> Again, this is an argument from principle rather than an argument based on
> the specific case at hand.  I just think that we have a well-established
> precedent that all two-letter TLDs are derived from ISO 3166 Alpha-2, and
> it’s bad form to cross back over and start poaching in their territory.

+1.

-- 
Paul

---

From: "Nishal Goburdhan" <[email-masked]>
Date: Fri, 22 Nov 2019 11:34:28 +0200

On 22 Nov 2019, at 10:26, Bill Woodcock wrote:

> based on the specific case at hand.  I just think that we have a 
> well-established precedent that all two-letter TLDs are derived from 
> ISO 3166 Alpha-2, and it’s bad form to cross back over and start 
> poaching in their territory.

^^ this.

—n.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 22 Nov 2019 10:51:58 +0100

> universal, those code elements are not compatible between different 

The glossary is not authoritative, but it is a reformulation of a
note to Section 8.1.3 in the standard (ISO 3166:1,Third edition,
2013-11-05):

       "NOTE Users are advised that the above series of codes are
	not universals, those code elements are not compatible
	between different entities."

 > users. (I'm not sure what the scary warning means.)

It means what it says. In the context of the stamdard, these are
not garanteed to be unique. The 3166/MA get sometimes requests to
reserve/allocate/assign codes from these blocks to make them unique
and always says no. (There used to be a note somewhere asking to
send the secretary of the 3166/MA information which User Assigned
Code was used and for what, but hardly anybody ever did and when
they did, users expected their particular code to be unique. Therefore
the MA dropped the note and does not keep a record of the User
Assigned Codes).

 > Certainly I have 

Yes, that is the ia perfect legit use use. (Trivia tidbit: The
rumour is that in Argentinia these codes are used to brand mark
cows).

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 22 Nov 2019 11:00:41 +0100

Bill Woodcock writes:

 > Again, this is an argument from principle rather than an argument based 
 > on the specific case at hand.  I just think that we have a
 > well-established precedent that all two-letter TLDs are derived from ISO
 > 3166 Alpha-2, and it's bad form to cross back over and start 

Nope, it ain't. That part of the so 3166 name space is speially set
aside by the standard for private use.

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 22 Nov 2019 11:09:01 +0100

Erwin Lansing writes:

 >
 > Beware of assumptions. I would never have imagined in my wildest
 > dreams for St. Maarten to be assigned SX.

It was on request of Dutch Sint Maarten. The argued that they where know for the
airport code for the well-known Princess Juliana International Airport  But that
is nir really related to the origonal proposal

	jaap

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Fri, 22 Nov 2019 12:16:31 +0200

Bill,

ISO has new draft out as part of their regular maintenance cycle which
states

	[...]  In addition exactly 42 alpha-2 code elements are not used in
	the ISO 3166, AA, QM to QZ, XA to XZ, ZZ. This rule may change in
	the future.  [...]

and then references this

	If users need code elements to represent country names not included
	in this part of ISO 3166, the series of letters AA, QM to QZ, XA to
	XZ, and ZZ [...] are available.

I read that to mean that a .ZZ (or rather any of the 42 possibles) would
be safe to use in our context.

If the rule were to change I would however speculate that the wishes of
the government concerned might prevail over the wishes of ICANN.

Whether this all is safe enough to write a standard, I don't know.

el

On 22/11/2019 10:26, Bill Woodcock wrote:
>> "User-assigned codes - If users need code elements to represent
>> country names not included in ISO 3166-1, the series of letters AA,
>> QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ,
>> XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers
>> 900 to 999 are available.  NOTE: Please be advised that the above
>> series of codes are not universal, those code elements are not
>> compatible between different entities."
>>
>> users.  (I'm not sure what the scary warning means.)  Certainly I
>> have made heavy use of .Q* and .X* in my own testing, with the
>> assumption that these would never be assigned (and yes, there is
>> .TEST but sometimes you need more than one one TLD).
> 
> be left for that use, because they do in fact get used by users, so
> any centrally-coordinated use will run afoul of that.
> 

-- 
Dr. Eberhard W. Lisse   \         /      Obstetrician & Gynaecologist 
[email-masked]             / *      | Telephone: +264 81 124 6733 (cell)
PO Box 8421              \      /
Bachbrecht 10007, Namibia ;____/

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 22 Nov 2019 08:15:54 -0500

> be safe to use in our context.

I read that to mean they are reserved for private use, and as mentioned
above, any centralized/standardized use is going to conflict with that.
 This is a bit like IANA trying to assign a bit of RFC1918 space to
something specific and global.

I'm surprised this thread has such legs.  I would have thought this would
wind up when home. and home.arpa were mentioned way up thread.

---

From: Roy Arends <[email-masked]>
Date: Fri, 22 Nov 2019 13:57:37 +0000

> On 22 Nov 2019, at 16:26, Bill Woodcock <[email-masked]> wrote:
> 
> 
> 

The ISO 3166 Maintenance Agency is not able to assign any code from the User Assigned range. The are used by users of the ISO3166 standards, such as UNLOCODE, WIPO, ICAO, IATA, Worldbank, Interpol, CAB/Forum, UNICODE. Even IETF and other ISO standards are using the User Assigned range exactly as intended.

> I just think that we have a well-established precedent that all two-letter TLDs are derived from ISO 3166 Alpha-2, and it’s bad form to cross back over and start poaching in their territory.

And this proposal is following that precedent to the letter. Two-letter codes are derived from ISO 3166 Alpha-2, and that standard says that ZZ is intended for Users, and is out of scope for the 3166 Maintenance Agency. It needs an ISO TC46 action to re-classify the User Assigned range, which has not happened in the 45 years that this standard is used.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 22 Nov 2019 13:59:55 +0000

> Right.  And in fact, “unassigned” ISO codes _do_ get used, for places like Kosovo, that are in a state of disputed or partially-recognized countryhood, and ranges that are reserved for user use rea…

The ISO 3166 Maintenance Agency is not able to assign any code from the User Assigned range. That is why organisations such as UNLOCODE, WIPO, ICAO, IATA, Worldbank, Interpol, CAB/Forum, UNICODE use these User Assigned codes when they’re using ISO3166. Even IETF and other ISO standards are using the User Assigned range exactly as intended.

> I just think that we have a well-established precedent that all two-letter TLDs are derived from ISO 3166 Alpha-2, and it’s bad form to cross back over and start poaching in their territory.

And this proposal is following that precedent to the letter. Two-letter codes are derived from ISO 3166 Alpha-2, and that standard says that ZZ is intended for Users, and is out of scope for the 3166 Maintenance Agency. It needs an ISO TC46 action to re-classify the User Assigned range, which has not happened in the 45 years that this standard is used. ZZ is not assigned. We’re not asking for ZZ to be delegated. ZZ will not be delegated because ZZ is on the user assigned list. I don’t know how to make it more clear than that.

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 22 Nov 2019 14:00:09 +0000

> On 22 Nov 2019, at 21:15, Matthew Pounsett <[email-masked]> wrote:
> 
> I read that to mean they are reserved for private use, and as mentioned above, any centralized/standardized use is going to conflict with that.

No.

No one is suggesting centralised use! The opposite. You can use it locally because there is no centralised use.

>   This is a bit like IANA trying to assign a bit of RFC1918 space to something specific and global.

No. Not at all. There is no ask here of IANA. ZZ is not to be delegated. At All. No one is re-assigning anything.

Using your analogy, there should not be an RFC1918 because it “standardizes” that 10/0 (etc) can be used for private internets.

> I'm surprised this thread has such legs.  I would have thought this would wind up when home. and home.arpa were mentioned way up thread.  

I’m surprised that this thread contains so much mis-information.

Roy

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 22 Nov 2019 09:16:43 -0500

> because there is no centralised use.

Standardized use isn't the same as globally reachable.  If you say "this
thing can be used for purpose X in any network" what happens when it's
already in use for purpose Y in someone's network, and they need X to work?

>
> Using your analogy, there should not be an RFC1918 because it
> “standardizes” that 10/0 (etc) can be used for private internets.
>
> > I'm surprised this thread has such legs.  I would have thought this
> would wind up when home. and home.arpa were mentioned way up thread.
>

It would probably help if the thread had started with the intended use.

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 22 Nov 2019 07:15:09 -0800

Eberhard:

The principle I’m trying to articulate is that our relationship to ISO 3166 is that of a standards body which has delegated to it.  

ISO 3166, in turn, specifies that this code is (for now, and at their authority) to be used by USERS for their purposes. 

It’s my assertion that it’s bad form for us, having placed ourselves in the standards body role on one side of ISO, to now also claim that we, the same people, are also  “users”  Standing on the other side of ISO.  

That seems to me to not be in the spirit of a good-faith delegation.  

If we want to start individually specifying the meaning or use of two-letter TLDs, it’s my assertion that We should first un-delegate that role from ISO, and take direct control of the task, not attempt to stand on both sides of them. And I think the harm of doing so would vastly outweigh any benefit. Therefore I think this shouldn’t be done. Either we delegate authority to them, or we don’t. No splitting the baby. 
    
                -Bill

> On Nov 22, 2019, at 02:17, Dr Eberhard W Lisse <[email-masked]> wrote:
> 
> Bill,
>

---

From: Steve Crocker <[email-masked]>
Date: Fri, 22 Nov 2019 10:21:35 -0500

I too find myself puzzled about trying to assign ZZ for this role.  I
strongly prefer we stay far away from using two letter codes for anything
other than ISO 3166 assignment of country codes for ccTLDs.  (I even think
we made a mistake in allowing two letter codes in Cyrillic and
Greek.)  Postel's dictum of being conservative comes in here.  Even if
using ZZ is *supposed* to work according to the rules, it seems unnecessary
and a bit risky.

What's the attraction of using a two letter code instead of something
longer?  And speaking of longer, I think it ought to be four characters or
more to aid in stamping out the whatever remaining code still thinks top
level domains are only two or three characters.

Steve

On Fri, Nov 22, 2019 at 10:15 AM Bill Woodcock <[email-masked]> wrote:

> Eberhard:
>
> The principle I’m trying to articulate is that our relationship to ISO
> 3166 is that of a standards body which has delegated to it.
>
> ISO 3166, in turn, specifies that this code is (for now, and at their
> authority) to be used by USERS for their purposes.
>
> It’s my assertion that it’s bad form for us, having placed ourselves in
> the standards body role on one side of ISO, to now also claim that we, the
> same people, are also  “users”  Standing on the other side of ISO.
>
> If we want to start individually specifying the meaning or use of
> two-letter TLDs, it’s my assertion that We should first un-delegate that
> role from ISO, and take direct control of the task, not attempt to stand on
> both sides of them. And I think the harm of doing so would vastly outweigh
> any benefit. Therefore I think this shouldn’t be done. Either we delegate
> authority to them, or we don’t. No splitting the baby.
>
>                 -Bill
>
>

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 22 Nov 2019 07:23:04 -0800

Man, sorry for the weird random capitalization, y’all.  Autocorrect has a mind of its own. 

Also, what Matt said: perhaps we could approach consensus if those in favor of the proposal would articulate their thoughts on why specifying a two-letter is the best solution to (this, any) problem, the rest of us might be able to see why you feel your case is compelling. 
    
                -Bill

> On Nov 22, 2019, at 07:15, Bill Woodcock <[email-masked]> wrote:
> 
> Eberhard:
>

---

From: David Conrad <[email-masked]>
Date: Fri, 22 Nov 2019 19:33:21 +0100

This whole discussion confuses me.

As Roy and Jaap have pointed out, ISO 3166 has indicated the user defined codes won’t be allocated.  They are for private use. Just as RFC 1918 has designated 10/8 for private use.

To me, this means any of the user defined ISO codes are fair game for internal use (that is, between consenting adults), regardless of context, including use in the DNS.

My interpretation of this is that since ISO 3166/MA won’t be assigning those codes and it is wildly unlikely ccTLD policy will change such that IANA could delegate any of those codes, it makes the use of those 2-letter domains for private use wildly unlikely to result in a collision with public use (that is, delegation) since the domains can’t be delegated.

The advantages of this are:

1) no change in IANA policy
2) no need to rerun the fun of the RFC 6761 “discussions"
3) no need to do an ICANN PDP or some other undoubtedly painful process to reserve a string
4) no need for interminable arguments about language (“internal doesn’t mean anything in Klingon!”)
5) people can paint their bike shed any one of 42 colors

I don’t understand why one would need to pick ZZ (or any other user defined code) to mean by convention anything.  It doesn’t hurt anything, I just don’t see the point.

I would turn the question around:

Why not simply have an RFC that declares the user defined ISO 3166 codes as the RFC 1918-space equivalent for the DNS and be done with it?  If people _really_ want to continue the bike shedding on a particular string, they still can, but the folks who want a string (or strings) that they can use for internal purposes without fear of it being delegated in some future round of new gTLDs can just get on with their lives.

Confusedly,
-drc

P.S. Yes, I know people can use those 2 letter codes now, but having it explicitly stated in an RFC comforts some folks

> On Nov 22, 2019, at 4:23 PM, Bill Woodcock <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Nov 2019 13:45:30 -0500

> Why not simply have an RFC that declares the user defined ISO 3166 codes as the RFC 1918-space equivalent for the DNS and be done with it?  If people _really_ want to continue the bike shedding on…

I agree completely.   The RFC that declares this should advise potential users of these TLDs to use a random number to choose one of the available names, so that the likelihood of a collision is at least somewhat lessened in case of a future merger.  Locking it to .ZZ or suggesting that people to pick based on preference creates a higher likelihood of such collisions.

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Fri, 22 Nov 2019 22:23:33 +0200

There is a small chance that ISO might change this in the future, but as
long as there are some excluded/user assigned ISO code elements left I
too think letting the user assign the pseudo TLD(s) makes sense.

Even though I like the .ZZ idea :-)-O

el

On 2019-11-22 20:45 , Ted Lemon wrote:
>> I don’t understand why one would need to pick ZZ (or any other user
>> defined code) to mean by convention anything.  It doesn’t hurt
>> anything, I just don’t see the point.
>>
>> Why not simply have an RFC that declares the user defined ISO 3166
>> codes as the RFC 1918-space equivalent for the DNS and be done with
>> it?  If people _really_ want to continue the bike shedding on a
>> particular string, they still can, but the folks who want a string
>> (or strings) that they can use for internal purposes without fear of
>> it being delegated in some future round of new gTLDs can just get on
>> with their lives.
>
> I agree completely.  The RFC that declares this should advise
> potential users of these TLDs to use a random number to choose one of
> the available names, so that the likelihood of a collision is at least
> somewhat lessened in case of a future merger.  Locking it to .ZZ or
> suggesting that people to pick based on preference creates a higher
> likelihood of such collisions.

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 24 Nov 2019 14:38:59 -0500

I can not speak for all DNSOP chairs, but this chair would prefer to not
repeat all those "fun" RFC6761 discussions,
as Mr. Conrad mentioned.

If the working group is missing a "fun" type of discussion, I am sure the
chairs can come up something suitably
entertaining.

Tim