Re: [DNSOP] on private use TLDS: .interNAL -> .LAN

[Paul Marks]

On Sat, Jan 27, 2024 at 8:33 PM Paul Wouters  wrote:
>
> LAN implies local area network. So an organization with multiple locations 
> would have a LAN at each location, but the .LAN would be their collection of 
> LANs? I think that would lead to confusion.
>
> Paul

There are non-commercial .coms and non-organizational .orgs; is the
spectre of non-local .lans sufficiently confusing to merit a 2.6x
longer TLD, even for non-English speakers?

"dot lan" might imply Local Area Network to you, but it *could* imply
inter-nal, if we chose to define it that way.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS: .interNAL -> .LAN

[John Levine]

According to Paul Wouters  :
>
>> On Jan 27, 2024, at 16:42, Paul Marks  wrote:
>> 
>>  pick .lan
>> instead?  It seems that a lot of people are already using this abbreviation 
>> on their internal
>networks, which happen to be local in
>> area.
>
>LAN implies local area network. So an organization with multiple locations 
>would have a LAN at each
>location, but the .LAN would be their collection of LANs? I think that would 
>lead to confusion.

It's also the name of a group of airlines in South America.  I was surprised 
none of them applied
for a vanity TLD.

The name .INTERNAL is fine.  Let's argue about something else.

R's,
John


-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS: .interNAL -> .LAN

[Paul Wouters]

> On Jan 27, 2024, at 16:42, Paul Marks  wrote:
> 
>  pick .lan
> instead?  It seems that a lot of people are already using this abbreviation 
> on their internal networks, which happen to be local in
> area.

LAN implies local area network. So an organization with multiple locations 
would have a LAN at each location, but the .LAN would be their collection of 
LANs? I think that would lead to confusion.

Paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS: .interNAL -> .LAN

[Paul Marks]

I recently sent this idea to ICANN, but I'm curious if DNSOP finds it
interesting.

There is currently a proposal to reserve .internal for private use.  I
think this word is bureaucratically and semantically the right choice,
but 8 characters is too many to type.

So let's take .internal and define an abbreviation.  Unfortunately
.int is already taken, but what if we read right-to-left and pick .lan
instead?  It seems that a lot of people are already using this
abbreviation on their internal networks, which happen to be local in
area.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[David Conrad]

[Sorry for the slow response — US holidays and a resolution not to look at my 
computer over said holidays got in the way]

Doug,

On Nov 27, 2019, at 8:39 PM, Doug Barton  wrote:
> I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
> expressed that we should stay out of ISO's sandbox.

No one is suggesting we get into their sandbox.

> Whatever the rules are today, they can change, and poaching their stuff for 
> our purposes is bad form (and yes, I feel that poaching is what is being 
> proposed, in spite of the arguments to the contrary).

I’m confused. ISO 3166 says a set of codes are intended for user defined 
purposes. What is being proposed is using those codes for user defined 
purposes. How can this be construed as poaching?

> ICANN has already said that it's not going to ever delegate CORP, HOME, or 
> MAIL.

No, ICANN has not said that.

Regards,
-drc
(Speaking for myself, not any organization I may be affiliated with)




signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Brian Dickson]

On Thu, Nov 28, 2019 at 2:52 PM Doug Barton  wrote:

> On 11/28/19 2:20 PM, Joe Abley wrote:
>
> > - has the advice to anchor a private namespace in a registered domain in
> > the private namespace really been received and judged to be
> > insufficient?
>
> Yes.
>
> > Or has it just not been received? Could such advice be
> > delivered in a more effective way?
>
> The market has rejected this advice. I could bore you with examples and
> reasoning, but I have never worked with a client in an enterprise larger
> than a taco stand that didn't have at least one private domains set up.
>
>
I don't think anyone doubts that you have tons of experience with lots of
customers.

However, there are very important differences between anecdotes and proper
statistical studies.

There are any number of reasons for why those might differ in meaningful
ways.
There could be populations which, for whatever reason, don't overlap with
your set of clients, with different characteristics.
There could be an inherent selection bias, in how your clients choose you
or how you find your clients.
Certainly, the size of your client set, is not very likely to be anywhere
near large enough to be statistically significant, compared to the number
of domain registrants worldwide (hundreds of millions).

What folks are trying to say is, in order to build rough consensus, which
is how the IETF works, it helps to have something (anything) to support
your assertions, preferably something that can be easily confirmed
([citation needed]).

And, does the use case you are concerned with, actually need to be at the
TLD level? Would something like "internal.zz" not be just as suitable,
assuming you concur with the ".zz" usability? (Substitute arpa for zz if
you prefer.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Brian Dickson]

On Thu, Nov 28, 2019 at 2:52 PM Doug Barton  wrote:

> On 11/28/19 2:20 PM, Joe Abley wrote:
>
> > - does the growth in observed query traffic for names with non-existant
> > top-level labels really support the idea that squatting on arbitrary
> > undelegated TLDs is on the rise? Is it possible there are other effects?
> > Have we normalised the observed growth against other known causes of
> > growth? If this phenomenon is actually becoming less common, does it
> > need a solution beyond "wait"?
>
> In my experience the practice is so ubiquitous that while these
> questions are good in the abstract, spending time on them would be a
> waste of effort. That said, ICANN's name collision work is relevant
> here, and I encourage anyone with interest in the topic to review that
> at length. It was really well done, and well documented to boot.
>
>
As many of the participants in dnsop were actively involved in reviewing
that work, I disagree.
I think the consensus was, and still is, that the work (done by a third
party under contract) was not particularly well done.

My view of that work is that the parameters given to the third party were
myopic, and the methodology was flawed.
The focus was specifically only on a hard-coded list of prospective new
TLDs, and cannot be generalized.

The follow-up proposal for "tasting" new TLDs was equally flawed, and IMHO
did not adequately address a number of major concerns.

Also, as a general comment, I think you are using too many pronouns or
phrases that are ambiguous or not well defined, in this discussion.
E.g. elsewhere you reference market "demand", but not for a demand for
what. Similarly, "the practice" above isn't clear here.

I think one of the reasons Joe raises study, is that there has been no
analysis of data for top-level queries (possible TLDs),
other than those included in the aforementioned report. That would mean no
study has been done on e.g. ".internal" as a TLD string.
The more general question has to do, not with queries for the big three
non-delegated domains identified in the report,
but for other non-delegated top-level labels: are there distinguishable
sets of popular such labels; has the size of the set of
labels been changing, and is it increasing or decreasing; and what is the
trend and proportional volume on those labels.

This is the kind of information that, at a minimum, should be included in a
proposal for a new "private" non-delegated TLD-like label,
i.e. to justify the choice of label(s), and demonstrate non-collision risk
related to using said label(s).

This is the strength of Roy's proposal; there is solid documentation from
the ISO that says these are really private use things. They can be used
today, even if there is a very small chance that the ISO might change that
at some point.

My opinion on the private use TLDs issue is that it makes sense to move
forward in two directions simultaneously: Roy's proposal; and what you
appear to want (one or more private labels reserved by ICANN based on
coordination between the IETF and ICANN).

The market can choose, and you are free to advocate for your preferred
option, but I don't see any legitimate reason to oppose Roy's proposal if
you can get what you want via your proposal. Suggesting that only one
can/should be used is a straw man, and/or bikeshedding.

I know my intention is to use Roy's scheme, in future work within the IETF,
and that based on what Roy and Jaap have documented, I don't think there is
even a need to wait for publication of an RFC to be safe in using one or
more of these labels.

Those of us not interested in pursuing the ICANN direction can avoid any
delays. I fully encourage you to pursue your approach, but do want to
politely caution you to have reasonable expectations on the speed and
likelihood of success.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Jaap Akkerhuis]

 Doug Barton writes:

 > I don't doubt Jaap.

Thank you.

 > What I doubt is that any organization as political 
 > as ISO (or ICANN) will hold preferences stable in the absence of a 
 > controlling policy.

Here are some more facts from the trivia corner.

The ISO was started from 1947. The first edition of the 3166 standard
is from 1974 and defined the User assigned codes as:

The series of letters AA, XA to XZ, and ZZ, and the series AAA to AAZ, 
XAA
to XZZ and ZZA to ZZZ respectively, are available for private use, and 
for
provisional codes which should be recorded as soon as possible by the
maintenance agency. An existing alpha-1 code which is in agreement with
the first letter of the alpha-2 code may be used for an appropriate time
to be fixed by the agency.

The second edition (1981) said:

The series of letters AA, OM 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 for individual use.

so it did add the ranges starting with a Q. 

The later editions are all defining the same name space (with sometimes
different wording).

A similar exercise can be done for ICANN en TLD name space but I
leave that up to the reader(s).

However, I cannot help noticing that for years I hear from various
ICANN stakeholders that ICANN should start to use alpha-2 codes as
well. Most recently in the meetings of the GNSO newgtld working
group, subgroup wt-5. The motivation is that then Volkswagen can
have its TLD ".vw" and the Bank of America (why not bank of Albania?)
".ba".

jaap

PS. [Apparently proponents of ba for a bank don't realize that it
is assigned to Bosnia and Herzegovina].

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/28/19 4:24 PM, Joe Abley wrote:

On Nov 28, 2019, at 19:07, Doug Barton  wrote:


Can you please explain why ICANN's work on name collision and the ongoing 
onslaught of queries at the root for un-delegated TLDs are not sufficient 
evidence?


If it's not obvious from the questions I asked, then perhaps not.


What I'm looking for are specific areas in which the existing volume of 
evidence is lacking. We already have a lot of data which addresses the 
questions you raised. What is it about the existing data which is 
inadequate? What data do you want to see collected instead?



And if not, how do you propose that we study it?


By avoiding words like "onslaught" and building substantiated
conclusions from data.


Thank you for defining "study." What I'm looking for is a specific plan. 
If you don't have one in mind, or can't be bothered to create one, then 
this feels like another example of "We have to study the problem more" 
as an excuse not to take action. (I would be very happy to be proven 
wrong though.)


Doug

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/28/19 5:15 PM, John R Levine wrote:

On Thu, 28 Nov 2019, Doug Barton wrote:

I don't see how relying on ISO's advice is poaching.  They say:


You, like Ted, are ignoring the fact that ISO can choose to change 
those rules.


The user assigned codes are part of the published ISO 3166 standard.  If 
that's not stable enough, neither is any ccTLD.  What if they decided to 
swap .US and .SU?  Jaap assured us they're not going to change, and he 
should know.


I don't doubt Jaap. What I doubt is that any organization as political 
as ISO (or ICANN) will hold preferences stable in the absence of a 
controlling policy.


Ok, so if you think there is a risk here, then it should be mitigated 
by working together with ICANN ...


The politics about this at ICANN are hopeless.  There are still six 
applications for corp, home, and mail who would object loudly if ICANN 
said they were permanently unavailable and who torpedoed Lyman Chapin's 
proposal to add them to the 6761 list.  Fighting that is not a good use 
of anyone's time.


Given the time that's passed this landscape may have changed. But if it 
has not for CORP, HOME, and MAIL; why not open the discussion about 
whatever strings we decide are useful instead?


Doug

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[John R Levine]

I do think the semantic meaning of the label is worth thinking about, 
and I am wary of particular scripts or languages being chosen 
arbitrarily. ...


Part of Roy's pitch was that the reserved two letter codes like .ZZ are 
equally meaningless in most languages.


- has the advice to anchor a private namespace in a registered domain in 
the private namespace really been received and judged to be 
insufficient? Or has it just not been received? Could such advice be 
delivered in a more effective way?


How long have wee been telling people to anchor their private namespace on 
a registered name?  It's on the order of a decade, I believe, and it's 
clear that for whatever reason people want something that's easy to type.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[John R Levine]

On Thu, 28 Nov 2019, Doug Barton wrote:

I don't see how relying on ISO's advice is poaching.  They say:


You, like Ted, are ignoring the fact that ISO can choose to change those 
rules.


The user assigned codes are part of the published ISO 3166 standard.  If 
that's not stable enough, neither is any ccTLD.  What if they decided to 
swap .US and .SU?  Jaap assured us they're not going to change, and he 
should know.



ICANN has already said that it's not going to ever delegate CORP, HOME,
or MAIL.


They said indefinitely defer which is not the same thing at all. 


Ok, so if you think there is a risk here, then it should be mitigated by 
working together with ICANN ...


The politics about this at ICANN are hopeless.  There are still six 
applications for corp, home, and mail who would object loudly if ICANN 
said they were permanently unavailable and who torpedoed Lyman Chapin's 
proposal to add them to the 6761 list.  Fighting that is not a good use of 
anyone's time.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Joe Abley]

On Nov 28, 2019, at 19:07, Doug Barton  wrote:

> Can you please explain why ICANN's work on name collision and the ongoing 
> onslaught of queries at the root for un-delegated TLDs are not sufficient 
> evidence?

If it's not obvious from the questions I asked, then perhaps not.

> And if not, how do you propose that we study it?

By avoiding words like "onslaught" and building substantiated
conclusions from data.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Doug Barton]

Can you please explain why ICANN's work on name collision and the 
ongoing onslaught of queries at the root for un-delegated TLDs are not 
sufficient evidence?


And if not, how do you propose that we study it?

Doug


On 11/28/19 3:58 PM, Joe Abley wrote:

Hi Doug,

I appreciate the response and I don't doubt your experience, but I do 
think there is some value in a more robust study around some of these 
questions. Really the prevalence of no-doubt well-informed but largely 
unsubstantiated opinions (to the level of detail that I was trying to 
infer) is what I am arguing we need to do better than.



Joe


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Joe Abley]

Hi Doug,

I appreciate the response and I don't doubt your experience, but I do think 
there is some value in a more robust study around some of these questions. 
Really the prevalence of no-doubt well-informed but largely unsubstantiated 
opinions (to the level of detail that I was trying to infer) is what I am 
arguing we need to do better than.

Joe

> On Thursday, Nov 28, 2019 at 17:52, Doug Barton  (mailto:do...@dougbarton.us)> wrote:
> On 11/28/19 2:20 PM, Joe Abley wrote:
> > Hi Doug,
> >
> > I am not suggesting that you are wrong in your final paragraph, and I am
> > not philosophically opposed to reserving a label in the root zone for
> > private use, somehow analogously to RFC1918, but I think it's worth
> > challenging how obvious this really is. (Yours is just a convenient hook
> > to hang this reply to; it's not really directed just at you.)
>
> No worries, but thanks for clarifying. :) (And thanks for your well
> thought out questions as well.)
>
> > I do think the semantic meaning of the label is worth thinking about,
> > and I am wary of particular scripts or languages being chosen
> > arbitrarily. I realise "internal" and "private" are sensible labels to
> > use for this kind of thing if you are English-speaking and used to
> > reading Latin script; I don't know that it's reasonable not to care that
> > they might not be sensible in other contexts. This to me is a much more
> > important conversation than bikeshedding about what regulatory agency
> > has said what about what.
>
> heh, it's funny you mention that. I actually considered raising that in
> my first post, but decided to get over the hump of "let's do this"
> first. I agree that we need to consider this issue. I think the obvious
> choice would be to pick a word that has meaning in private space but no
> value in public, then document several language's worth of it, along
> with guidance not to delegate other translations of the word. This would
> also solve the issue raised previously that "sometimes you need more
> than one."
>
> > It's also perhaps worth mentioning that the mechanics of how to
> > provision (or not provision) such a name with regard to DNSSEC
> > validation by various elements of the wider ecosystem have been a matter
> > of some debate in other venues. I doubt that dnsop is immune to that. I
> > won't fulfill that expectation by saying more in this message. :-)
>
> Agreed, but having names documented for this purpose will make the
> DNSSEC bits easier, not harder.
>
> > So, on the subject of how obvious it is that we need to reserve a
> > top-level label for private namespaces,
> >
> > - has the advice to anchor a private namespace in a registered domain in
> > the private namespace really been received and judged to be
> > insufficient?
>
> Yes.
>
> > Or has it just not been received? Could such advice be
> > delivered in a more effective way?
>
> The market has rejected this advice. I could bore you with examples and
> reasoning, but I have never worked with a client in an enterprise larger
> than a taco stand that didn't have at least one private domains set up.
>
> It's fair to ask the question of do we need it, and it's also fair to
> document answers to most/all of the questions you've raised as part of
> the process. But given how things are in the real world, this is
> something that needs to happen.
>
> > - does the growth in observed query traffic for names with non-existant
> > top-level labels really support the idea that squatting on arbitrary
> > undelegated TLDs is on the rise? Is it possible there are other effects?
> > Have we normalised the observed growth against other known causes of
> > growth? If this phenomenon is actually becoming less common, does it
> > need a solution beyond "wait"?
>
> In my experience the practice is so ubiquitous that while these
> questions are good in the abstract, spending time on them would be a
> waste of effort. That said, ICANN's name collision work is relevant
> here, and I encourage anyone with interest in the topic to review that
> at length. It was really well done, and well documented to boot.
>
> > - what are the possible negative effects of providing a TLD label for
> > use in private namespaces? We know that in the addressing realm, RFC
> > 1918 and similar private-use addresses lead to collisions during M,
> > interconnections, etc. Perhaps these are reasonable trade-offs for
> > addresses. Is the same true for names?
>
> This is a good question to address, although the collision risk for
> non-common names in a private TLD is lower than the risk of collisions
> of integers. Two orgs using PRIV might each have a www, but if one of
> them has a naming convention of host-rack-floor.priv for their data
> centers, that's not likely to collide.
>
> That said, the commonly chosen names already have a non-trivial risk for
> collisions. The marginal risk of codifying a set of examples is in the
> noise.
>
> > - does promoting a single anchor for private 

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/28/19 2:42 PM, Roy Arends wrote:



On 28 Nov 2019, at 22:30, Doug Barton  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/28/19 2:20 PM, Joe Abley wrote:

Hi Doug,

I am not suggesting that you are wrong in your final paragraph, and I am 
not philosophically opposed to reserving a label in the root zone for 
private use, somehow analogously to RFC1918, but I think it's worth 
challenging how obvious this really is. (Yours is just a convenient hook 
to hang this reply to; it's not really directed just at you.)


No worries, but thanks for clarifying.  :) (And thanks for your well 
thought out questions as well.)


I do think the semantic meaning of the label is worth thinking about, 
and I am wary of particular scripts or languages being chosen 
arbitrarily. I realise "internal" and "private" are sensible labels to 
use for this kind of thing if you are English-speaking and used to 
reading Latin script; I don't know that it's reasonable not to care that 
they might not be sensible in other contexts. This to me is a much more 
important conversation than bikeshedding about what regulatory agency 
has said what about what.


heh, it's funny you mention that. I actually considered raising that in 
my first post, but decided to get over the hump of "let's do this" 
first. I agree that we need to consider this issue. I think the obvious 
choice would be to pick a word that has meaning in private space but no 
value in public, then document several language's worth of it, along 
with guidance not to delegate other translations of the word. This would 
also solve the issue raised previously that "sometimes you need more 
than one."


It's also perhaps worth mentioning that the mechanics of how to 
provision (or not provision) such a name with regard to DNSSEC 
validation by various elements of the wider ecosystem have been a matter 
of some debate in other venues. I doubt that dnsop is immune to that. I 
won't fulfill that expectation by saying more in this message. :-)


Agreed, but having names documented for this purpose will make the 
DNSSEC bits easier, not harder.


So, on the subject of how obvious it is that we need to reserve a 
top-level label for private namespaces,


- has the advice to anchor a private namespace in a registered domain in 
the private namespace really been received and judged to be 
insufficient?


Yes.

Or has it just not been received? Could such advice be 
delivered in a more effective way?


The market has rejected this advice. I could bore you with examples and 
reasoning, but I have never worked with a client in an enterprise larger 
than a taco stand that didn't have at least one private domains set up.


It's fair to ask the question of do we need it, and it's also fair to 
document answers to most/all of the questions you've raised as part of 
the process. But given how things are in the real world, this is 
something that needs to happen.


- does the growth in observed query traffic for names with non-existant 
top-level labels really support the idea that squatting on arbitrary 
undelegated TLDs is on the rise? Is it possible there are other effects? 
Have we normalised the observed growth against other known causes of 
growth? If this phenomenon is actually becoming less common, does it 
need a solution beyond "wait"?


In my experience the practice is so ubiquitous that while these 
questions are good in the abstract, spending time on them would be a 
waste of effort. That said, ICANN's name collision work is relevant 
here, and I encourage anyone with interest in the topic to review that 
at length. It was really well done, and well documented to boot.


- what are the possible negative effects of providing a TLD label for 
use in private namespaces? We know that in the addressing realm, RFC 
1918 and similar private-use addresses lead to collisions during M, 
interconnections, etc. Perhaps these are reasonable trade-offs for 
addresses. Is the same true for names?


This is a good question to address, although the collision risk for 
non-common names in a private TLD is lower than the risk of collisions 
of integers. Two orgs using PRIV might each have a www, but if one of 
them has a naming convention of host-rack-floor.priv for their data 
centers, that's not likely to collide.


That said, the commonly chosen names already have a non-trivial risk for 
collisions. The marginal risk of codifying a set of examples is in the 
noise.


- does promoting a single anchor for private namespaces concentrate 
traffic that leaks from those internal contexts to the Internet's DNS? 
If the leakage of queries that are intended to be private represents a 
security concern, does the concentration of targets for that traffic on 
the Internet make the security concern worse?


I don't see how we could make this worse. If you look at ICANN's name 
collision work, the results are already concentrated in CORP, HOME, and 
MAIL, which is why they were indefinitely-but-maybe-not-forever taken 
out of the new gTLD program.


For the record, I don't personally see any enormous harm from 
standardising 

Re: [DNSOP] on private use TLDS

[Roy Arends]

> On 28 Nov 2019, at 22:30, Doug Barton  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.

> 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. A change to 
categories would force many active users of the standard such as ICAO, IATA, 
WIPO, UNLOCODE, UNICODE, Worldbank, Interpol, CABforum, and even the IETF and 
ISO itself to rename internally used strings. From their own ISO-3166 standard: 
"the ISO 3166/MA shall endeavour to maintain stability in the list of code 
elements.” 

As an example, say the ISO-3166 TC46 decides to reassign the X* range to 
countries, all the worlds financial services have to rewrite, re-map and 
re-issue monetary units and bonds, since ISO4217 makes use of ISO3166. (Take 
the CFA francs for instance, mapped to XAF and XOF, where XA and XO are used as 
intended since ISO4217 (the user of the ISO3166 standard) can allocated X* as 
they see fit). 

I have many examples of standard bodies using ISO3166 User Assigned ranges for 
private use.

> And if they do, we would have no recourse.

Why 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. 

> 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. 

Roy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Joe Abley]

Hi Doug,

I am not suggesting that you are wrong in your final paragraph, and I am not 
philosophically opposed to reserving a label in the root zone for private use, 
somehow analogously to RFC1918, but I think it's worth challenging how obvious 
this really is. (Yours is just a convenient hook to hang this reply to; it's 
not really directed just at you.)

I do think the semantic meaning of the label is worth thinking about, and I am 
wary of particular scripts or languages being chosen arbitrarily. I realise 
"internal" and "private" are sensible labels to use for this kind of thing if 
you are English-speaking and used to reading Latin script; I don't know that 
it's reasonable not to care that they might not be sensible in other contexts. 
This to me is a much more important conversation than bikeshedding about what 
regulatory agency has said what about what.

It's also perhaps worth mentioning that the mechanics of how to provision (or 
not provision) such a name with regard to DNSSEC validation by various elements 
of the wider ecosystem have been a matter of some debate in other venues. I 
doubt that dnsop is immune to that. I won't fulfil that epectation by saying 
more in this message. :-)

So, on the subject of how obvious it is that we need to reserve a top-level 
label for private namespaces,

- has the advice to anchor a private namespace in a registered domain in the 
private namespace really been received and judged to be insufficient? Or has it 
just not been received? Could such advice be delivered in a more effective way?

- does the growth in observed query traffic for names with non-existant 
top-level labels really support the idea that squatting on arbitrary 
undelegated TLDs is on the rise? Is it possible there are other effects? Have 
we normalised the observed growth against other known causes of growth? If this 
phenomenon is actually becoming less common, does it need a solution beyond 
"wait"?

- what are the possible negative effects of providing a TLD label for use in 
private namespaces? We know that in the addressing realm, RFC 1918 and similar 
private-use addresses lead to collisions during M, interconnections, etc. 
Perhaps these are reasonable trade-offs for addresses. Is the same true for 
names?

- does promoting a single anchor for private namespaces concentrate traffic 
that leaks from those internal contexts to the Internet's DNS? If the leakage 
of queries that are intended to be private represents a security concern, does 
the concentration of targets for that traffic on the Internet make the security 
concern worse?

For the record, I don't personally see any enormous harm from standardising 
something like Warren's ".internal" (or Roy's ".zzz", to make it clear that I'm 
not talking about the specific label). But I do think questions like the ones I 
mentioned are worth putting some effort into answering.

Perhaps I've missed some elegant and robust analysis, but to date all I've seen 
is "nobody likes the advice to register MYCO.COM (http://MYCO.COM) and use 
that, so obviously we need to do something". If that's really where we are, it 
seems like it would be comforting to be able to say so more convincingly.

Joe

> On Thursday, Nov 28, 2019 at 16:38, Doug Barton  (mailto:do...@dougbarton.us)> wrote:
> On 11/28/19 8:55 AM, John Levine wrote:
> > In article <71ad677a-8c88-8916-fe02-7d0d8ae93...@dougbarton.us> you write:
> > > I agree with Matt, Bill Woodcock, Steve Crocker, and others that have
> > > expressed that we should stay out of ISO's sandbox. Whatever the rules
> > > are today, they can change, and poaching their stuff for our purposes is
> > > bad form (and yes, I feel that poaching is what is being proposed, in
> > > spite of the arguments to the contrary).
> >
> > I don't see how relying on ISO's advice is poaching. They say:
>
> You, like Ted, are ignoring the fact that ISO can choose to change those
> rules.
>
> > > ICANN has already said that it's not going to ever delegate CORP, HOME,
> > > or MAIL.
> >
> > They said indefinitely defer which is not the same thing at all.
>
> Ok, so if you think there is a risk here, then it should be mitigated by
> working together with ICANN on a draft that codifies that they will
> never be delegated. Since there is apparently a need for additional such
> names (like INTERNAL) then they should be included.
>
> Other than some sort of gratuitous "we hate ICANN so we don't want to
> work with them" thing, it's not at all clear to me why we wouldn't want
> to lock the necessary resources down in cooperation with the only other
> entity that has anything to say about what happens in the root zone.
>
> > The IETF has already decided to stay out of the home/corp/mail
> > argument
>
> The IETF can change its mind too. :)
>
> Seriously, there is obviously a need to have private-use TLDs that we
> can guarantee will never be part of the public root zone. So let's make
> that happen, in a way that we can be sure 

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/28/19 8:55 AM, John Levine wrote:

In article <71ad677a-8c88-8916-fe02-7d0d8ae93...@dougbarton.us> you write:

I agree with Matt, Bill Woodcock, Steve Crocker, and others that have
expressed that we should stay out of ISO's sandbox. Whatever the rules
are today, they can change, and poaching their stuff for our purposes is
bad form (and yes, I feel that poaching is what is being proposed, in
spite of the arguments to the contrary).


I don't see how relying on ISO's advice is poaching.  They say:


You, like Ted, are ignoring the fact that ISO can choose to change those 
rules.



ICANN has already said that it's not going to ever delegate CORP, HOME,
or MAIL.


They said indefinitely defer which is not the same thing at all. 


Ok, so if you think there is a risk here, then it should be mitigated by 
working together with ICANN on a draft that codifies that they will 
never be delegated. Since there is apparently a need for additional such 
names (like INTERNAL) then they should be included.


Other than some sort of gratuitous "we hate ICANN so we don't want to 
work with them" thing, it's not at all clear to me why we wouldn't want 
to lock the necessary resources down in cooperation with the only other 
entity that has anything to say about what happens in the root zone.



The IETF has already decided to stay out of the home/corp/mail
argument


The IETF can change its mind too.  :)

Seriously, there is obviously a need to have private-use TLDs that we 
can guarantee will never be part of the public root zone. So let's make 
that happen, in a way that we can be sure will never be pulled out from 
under us.


Doug

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Doug Barton]

The IETF and ICANN share a sandbox on many topics, including the root 
zone. (But of course you already knew that.) And if you don't think 
ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read 
the reference I provided. Or, if you did read it, and still have 
concerns, that is that much more reason to work with them on a draft 
that memorializes it.


Meanwhile, as many others have pointed out, and your side of the 
argument continues to ignore, ISO can choose to change those rules. And 
if they do, we would have no recourse. OTOH, we do have a means of 
working with ICANN to codify certain TLDs for private use. Given those 
facts alone I'm frankly astonished that anyone would argue for any other 
course of action.


Doug


On 11/28/19 4:15 AM, Ted Lemon wrote:

So let me get this straight: you want us to stay out of ISO’s sandbox by 
jumping right in to ICANN’s? ICANN has not promised never to delegate those 
domains, whereas ISO effectively has, so your reasoning doesn’t make sense.


On Nov 27, 2019, at 23:39, Doug Barton  wrote:

On 11/26/19 9:16 AM, Matthew Pounsett wrote:

On Tue, 26 Nov 2019 at 05:19, Roy Arends mailto:r...@dnss.ec>> 
wrote:
“ZZ” was used in my presentation as an example. Since this
bikeshedding is siphoning attention from the important part of the
discussion, I’ll try to re-focus on the question here:
"Is it safe to use ISO3166-1 Alpha-2 code elements from the User
Assigned range as top level domains for my own private use?"
Thanks for the context, Roy.  Speaking as someone who was not at the IETF meeting this week, I 
found the earlier thread confusing.  But, it looks like the assumed context of bringing up 
"what can we use this for" as "can we assign this string in an RFC?" was 
correct.
It seems like reassignment of anything in the User Assigned range is unlikely, 
however that is the purview of the iSO 3166 maintenance agency, and not the IETF.  
However unlikely it is, we cannot be absolutely certain they will never reassign 
those, and so we should not include them in any standard (note the lower-case) 
published by the IETF.  Even if the IETF is just cut & pasting their current 
advice, I think it's unwise.
I'm also persuaded by Bill's argument that the IETF has already stated that ISO 
3166 has control over that bit of the namespace, and trying to take back part 
of it is confusing, bad form, and risky.
Even though they're not specifically proposed, only mentioned in passing, I'd 
also like to point out that the referenced potential uses of things like XH 
instead of home.arpa. is even more risky, because that fixes that string for a 
specific use, even if it's private.  Using XH as an example, if that had been 
chosen it would run the risk of colliding with some legitimate use of XH 
already being used by a User... if that user then also needed to interoperate 
with Homenet technologies they'd be hosed.
I think, instead of an RFC, what you really want is a Best Current Practices 
document, outside of the IETF, that is simply a redirect to the current ISO 
3166 document.  Instead of DNSOP, I'd suggest you have a chat with one or more  
of the BCOP efforts at the NOGs.


I agree with Matt, Bill Woodcock, Steve Crocker, and others that have expressed 
that we should stay out of ISO's sandbox. Whatever the rules are today, they 
can change, and poaching their stuff for our purposes is bad form (and yes, I 
feel that poaching is what is being proposed, in spite of the arguments to the 
contrary).

ICANN has already said that it's not going to ever delegate CORP, HOME, or 
MAIL. 
(https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf
 Section 3.2) IMO it would be useful for the IETF, with ICANN's cooperation, to 
codify that (if it hasn't been done already). I also think INTERNAL as a 
private-use TLD is a good idea, and should be included in the same doc. It's 
also useful to mention the distinction between using something temporarily for 
testing, and building infrastructure around it. If someone wants to put 
together a document like that I would be happy to offer support, review, and/or 
contributions if so desired.

So what's the harm? Aside from the PR issues related to poaching ISO 3166 stuff, I have 
personally been involved a few times in unwinding the giant mess created when clients 
decided that they were going to use a string as an internal TLD, and then subsequently it 
got delegated publicly. This creates serious problems, is difficult to debug, and 
expensive to fix. The advice we've given folks for decades is, "Don't take it upon 
yourself to grab something that doesn't belong to you and build your network on it." 
In my view, that's what is being recommended here; and having seen the damage it causes 
first hand, I cannot support the proposal.

Doug

--
Since I haven't been involved in the group for a while here is a mini-resume 
for those that don't know me, offered with no small amount 

Re: [DNSOP] on private use TLDS

[Paul Vixie]

On Thursday, 28 November 2019 12:15:23 UTC Ted Lemon wrote:
> So let me get this straight: you want us to stay out of ISO’s sandbox by
> jumping right in to ICANN’s? ICANN has not promised never to delegate those
> domains, whereas ISO effectively has, so your reasoning doesn’t make sense.

ISO has other constituencies beyond IANA, and while they have promised not to 
"delegate" certain names, their private-use rules allow those names to be used 
by someone other than IANA.

IANA can be instructed by IETF to never delegate certain TLDs (like .ZZZ).

noting, i would prefer stronger mnemonic naming for this, like .PRIVATE

-- 
Paul


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[John Levine]

In article <71ad677a-8c88-8916-fe02-7d0d8ae93...@dougbarton.us> you write:
>I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
>expressed that we should stay out of ISO's sandbox. Whatever the rules 
>are today, they can change, and poaching their stuff for our purposes is 
>bad form (and yes, I feel that poaching is what is being proposed, in 
>spite of the arguments to the contrary).

I don't see how relying on ISO's advice is poaching.  They say:

  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.

That note tells me they're like RFC 1918 IP addresses, use them in your
organization but be aware that other organizations will use them differently.


>ICANN has already said that it's not going to ever delegate CORP, HOME, 
>or MAIL. 

They said indefinitely defer which is not the same thing at all.  If
the facts change, e.g., the number of root queries for one of them
drops significantly, I'm sure they'll revisit them.  

The IETF has already decided to stay out of the home/corp/mail
argument, reasonably concluding that RFC 6761 are for names that are
technically special which these are not.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Ted Lemon]

So let me get this straight: you want us to stay out of ISO’s sandbox by 
jumping right in to ICANN’s? ICANN has not promised never to delegate those 
domains, whereas ISO effectively has, so your reasoning doesn’t make sense. 

> On Nov 27, 2019, at 23:39, Doug Barton  wrote:
> 
> On 11/26/19 9:16 AM, Matthew Pounsett wrote:
>> On Tue, 26 Nov 2019 at 05:19, Roy Arends > > wrote:
>>“ZZ” was used in my presentation as an example. Since this
>>bikeshedding is siphoning attention from the important part of the
>>discussion, I’ll try to re-focus on the question here:
>>"Is it safe to use ISO3166-1 Alpha-2 code elements from the User
>>Assigned range as top level domains for my own private use?"
>> Thanks for the context, Roy.  Speaking as someone who was not at the IETF 
>> meeting this week, I found the earlier thread confusing.  But, it looks like 
>> the assumed context of bringing up "what can we use this for" as "can we 
>> assign this string in an RFC?" was correct.
>> It seems like reassignment of anything in the User Assigned range is 
>> unlikely, however that is the purview of the iSO 3166 maintenance agency, 
>> and not the IETF.  However unlikely it is, we cannot be absolutely certain 
>> they will never reassign those, and so we should not include them in any 
>> standard (note the lower-case) published by the IETF.  Even if the IETF is 
>> just cut & pasting their current advice, I think it's unwise.
>> I'm also persuaded by Bill's argument that the IETF has already stated that 
>> ISO 3166 has control over that bit of the namespace, and trying to take back 
>> part of it is confusing, bad form, and risky.
>> Even though they're not specifically proposed, only mentioned in passing, 
>> I'd also like to point out that the referenced potential uses of things like 
>> XH instead of home.arpa. is even more risky, because that fixes that string 
>> for a specific use, even if it's private.  Using XH as an example, if that 
>> had been chosen it would run the risk of colliding with some legitimate use 
>> of XH already being used by a User... if that user then also needed to 
>> interoperate with Homenet technologies they'd be hosed.
>> I think, instead of an RFC, what you really want is a Best Current Practices 
>> document, outside of the IETF, that is simply a redirect to the current ISO 
>> 3166 document.  Instead of DNSOP, I'd suggest you have a chat with one or 
>> more  of the BCOP efforts at the NOGs.
> 
> I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
> expressed that we should stay out of ISO's sandbox. Whatever the rules are 
> today, they can change, and poaching their stuff for our purposes is bad form 
> (and yes, I feel that poaching is what is being proposed, in spite of the 
> arguments to the contrary).
> 
> ICANN has already said that it's not going to ever delegate CORP, HOME, or 
> MAIL. 
> (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf
>  Section 3.2) IMO it would be useful for the IETF, with ICANN's cooperation, 
> to codify that (if it hasn't been done already). I also think INTERNAL as a 
> private-use TLD is a good idea, and should be included in the same doc. It's 
> also useful to mention the distinction between using something temporarily 
> for testing, and building infrastructure around it. If someone wants to put 
> together a document like that I would be happy to offer support, review, 
> and/or contributions if so desired.
> 
> So what's the harm? Aside from the PR issues related to poaching ISO 3166 
> stuff, I have personally been involved a few times in unwinding the giant 
> mess created when clients decided that they were going to use a string as an 
> internal TLD, and then subsequently it got delegated publicly. This creates 
> serious problems, is difficult to debug, and expensive to fix. The advice 
> we've given folks for decades is, "Don't take it upon yourself to grab 
> something that doesn't belong to you and build your network on it." In my 
> view, that's what is being recommended here; and having seen the damage it 
> causes first hand, I cannot support the proposal.
> 
> Doug
> 
> -- 
> Since I haven't been involved in the group for a while here is a mini-resume 
> for those that don't know me, offered with no small amount of embarrassment:
> DNS and domain name work for 25 years, 20+ of doing it for a living
> Formerly a regular IETF participant
> Former GM of the IANA
> Former consultant in the DNS/DHCP/IPAM and domain name spaces
> Currently managing the domain name portfolio for a Fortune 100 corporation
> 
> That said, all views are my own, and are worth exactly what you paid for 
> them.  :)
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] on private use TLDS

[Doug Barton]

On 11/26/19 9:16 AM, Matthew Pounsett wrote:



On Tue, 26 Nov 2019 at 05:19, Roy Arends > wrote:


“ZZ” was used in my presentation as an example. Since this
bikeshedding is siphoning attention from the important part of the
discussion, I’ll try to re-focus on the question here:

"Is it safe to use ISO3166-1 Alpha-2 code elements from the User
Assigned range as top level domains for my own private use?"


Thanks for the context, Roy.  Speaking as someone who was not at the 
IETF meeting this week, I found the earlier thread confusing.  But, it 
looks like the assumed context of bringing up "what can we use this for" 
as "can we assign this string in an RFC?" was correct.


It seems like reassignment of anything in the User Assigned range is 
unlikely, however that is the purview of the iSO 3166 maintenance 
agency, and not the IETF.  However unlikely it is, we cannot be 
absolutely certain they will never reassign those, and so we should not 
include them in any standard (note the lower-case) published by the 
IETF.  Even if the IETF is just cut & pasting their current advice, I 
think it's unwise.


I'm also persuaded by Bill's argument that the IETF has already stated 
that ISO 3166 has control over that bit of the namespace, and trying to 
take back part of it is confusing, bad form, and risky.


Even though they're not specifically proposed, only mentioned in 
passing, I'd also like to point out that the referenced potential uses 
of things like XH instead of home.arpa. is even more risky, because that 
fixes that string for a specific use, even if it's private.  Using XH as 
an example, if that had been chosen it would run the risk of colliding 
with some legitimate use of XH already being used by a User... if that 
user then also needed to interoperate with Homenet technologies they'd 
be hosed.


I think, instead of an RFC, what you really want is a Best Current 
Practices document, outside of the IETF, that is simply a redirect to 
the current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a 
chat with one or more  of the BCOP efforts at the NOGs.


I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
expressed that we should stay out of ISO's sandbox. Whatever the rules 
are today, they can change, and poaching their stuff for our purposes is 
bad form (and yes, I feel that poaching is what is being proposed, in 
spite of the arguments to the contrary).


ICANN has already said that it's not going to ever delegate CORP, HOME, 
or MAIL. 
(https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf 
Section 3.2) IMO it would be useful for the IETF, with ICANN's 
cooperation, to codify that (if it hasn't been done already). I also 
think INTERNAL as a private-use TLD is a good idea, and should be 
included in the same doc. It's also useful to mention the distinction 
between using something temporarily for testing, and building 
infrastructure around it. If someone wants to put together a document 
like that I would be happy to offer support, review, and/or 
contributions if so desired.


So what's the harm? Aside from the PR issues related to poaching ISO 
3166 stuff, I have personally been involved a few times in unwinding the 
giant mess created when clients decided that they were going to use a 
string as an internal TLD, and then subsequently it got delegated 
publicly. This creates serious problems, is difficult to debug, and 
expensive to fix. The advice we've given folks for decades is, "Don't 
take it upon yourself to grab something that doesn't belong to you and 
build your network on it." In my view, that's what is being recommended 
here; and having seen the damage it causes first hand, I cannot support 
the proposal.


Doug

--
Since I haven't been involved in the group for a while here is a 
mini-resume for those that don't know me, offered with no small amount 
of embarrassment:

DNS and domain name work for 25 years, 20+ of doing it for a living
Formerly a regular IETF participant
Former GM of the IANA
Former consultant in the DNS/DHCP/IPAM and domain name spaces
Currently managing the domain name portfolio for a Fortune 100 corporation

That said, all views are my own, and are worth exactly what you paid for 
them.  :)


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Matthew Pounsett]

On Tue, 26 Nov 2019 at 05:19, Roy Arends  wrote:

> “ZZ” was used in my presentation as an example. Since this bikeshedding is
> siphoning attention from the important part of the discussion, I’ll try to
> re-focus on the question here:
>
> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned
> range as top level domains for my own private use?"
>

Thanks for the context, Roy.  Speaking as someone who was not at the IETF
meeting this week, I found the earlier thread confusing.  But, it looks
like the assumed context of bringing up "what can we use this for" as "can
we assign this string in an RFC?" was correct.

It seems like reassignment of anything in the User Assigned range is
unlikely, however that is the purview of the iSO 3166 maintenance agency,
and not the IETF.  However unlikely it is, we cannot be absolutely certain
they will never reassign those, and so we should not include them in any
standard (note the lower-case) published by the IETF.  Even if the IETF is
just cut & pasting their current advice, I think it's unwise.

I'm also persuaded by Bill's argument that the IETF has already stated that
ISO 3166 has control over that bit of the namespace, and trying to take
back part of it is confusing, bad form, and risky.

Even though they're not specifically proposed, only mentioned in passing,
I'd also like to point out that the referenced potential uses of things
like XH instead of home.arpa. is even more risky, because that fixes that
string for a specific use, even if it's private.  Using XH as an example,
if that had been chosen it would run the risk of colliding with some
legitimate use of XH already being used by a User.. if that user then also
needed to interoperate with Homenet technologies they'd be hosed.

I think, instead of an RFC, what you really want is a Best Current
Practices document, outside of the IETF, that is simply a redirect to the
current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a chat
with one or more  of the BCOP efforts at the NOGs.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[David Conrad]

On Nov 26, 2019, at 12:52 PM, Ted Lemon  wrote:
> It might be worth clarifying what the actual scope of this proposal is.  I 
> think that the idea is to say “look, if you want to use a private name, these 
> names are known to be safe.”   It’s not to say “the IETF hereby declares that 
> the following names are safe,” but rather “the IETF is reporting that these 
> names have been declared safe by this other SDO.”
> 
> The point of making this recommendation is that we know that people will have 
> reasons to privately use domains that have not been allocated to them out of 
> the global namespace, and we’ve seen the problems that such private 
> allocations cause when they are done in an unsafe manner.  The advice here is 
> on how to avoid making that mistake.   It’s not a TLD allocation by IETF: 
> those TLDs are already effectively allocated.
> 
> Is that about right?

Exactly (at least from my perspective).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Ted Lemon]

 It might be worth clarifying what the actual scope of this proposal is.  I 
think that the idea is to say “look, if you want to use a private name, these 
names are known to be safe.”   It’s not to say “the IETF hereby declares that 
the following names are safe,” but rather “the IETF is reporting that these 
names have been declared safe by this other SDO.”

The point of making this recommendation is that we know that people will have 
reasons to privately use domains that have not been allocated to them out of 
the global namespace, and we’ve seen the problems that such private allocations 
cause when they are done in an unsafe manner.  The advice here is on how to 
avoid making that mistake.   It’s not a TLD allocation by IETF: those TLDs are 
already effectively allocated.

Is that about right?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Bill Woodcock]

> On Nov 26, 2019, at 11:46 AM, Jim Reid  wrote:
>> On 26 Nov 2019, at 10:18, Roy Arends  wrote:
>> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned 
>> range as top level domains for my own private use?"
>> It is my understanding that the ISO3166 Maintenance Agency can not re-assign 
>> codes from the User Assigned range. This needs an action from ISO TC46.
> 
> It would be prudent to assume that there is a possibility, no matter how 
> remote, that codes from the User Assigned range could get re-assigned one 
> day. Whoever made the current policy could well change it.

I think that once a range has been delegated, it’s just imprudent and counter 
to good sense to make any assertions whatsoever about what the delegate will do 
with it.  If two-letter TLDs are delegated to ISO3166, then just say so.  Say 
that whether or not end-users can use any of them for private purposes is at 
the discretion of ISO3166, and make no further assertions about it, since, as 
Jim points out, things can always change, and then you have misinformation 
floating about.

This doesn’t seem like a complicated principle to me, and I’m having a really 
hard time seeing what benefit could ever come from violating it.

If you delegate, you delegate.  If you don’t delegate, you don’t delegate.  
Mixing the two is chaos.  The whole point of delegation is to scale without 
chaos.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] on private use TLDS

[Jim Reid]

> On 26 Nov 2019, at 10:18, Roy Arends  wrote:
> 
> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned 
> range as top level domains for my own private use?"
> 
> ...
> It is my understanding that the ISO3166 Maintenance Agency can not re-assign 
> codes from the User Assigned range. This needs an action from ISO TC46. 

It would be prudent to assume that there is a possibility, no matter how 
remote, that codes from the User Assigned range could get re-assigned one day. 
Whoever made the current policy could well change it.*

So if your idea goes forward, I think there needs to be some text which 
explains this. ie User Assigned 3166 codes *might* be OK for private use today; 
that list of code points is subject to change even if that's highly unlikely; 
plan accordingly just in case your private use two-letter code gets repurposed.

* I read documents in the late 90s, albeit not from SDOs, telling companies to 
anchor their internal name space under .corp because it was impossible for that 
TLD to ever exist in the public Internet. This was before ICANN was formed.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] on private use TLDS

[Roy Arends]

“ZZ” was used in my presentation as an example. Since this bikeshedding is 
siphoning attention from the important part of the discussion, I’ll try to 
re-focus on the question here:

"Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned range 
as top level domains for my own private use?"

1) RFC1591: Selection of 3166 was made with knowledge that ISO has a procedure 
for determining which entities should be and should not be on that list.
(Note of the word “entities” and “procedure”)

2) From the ISO 3166-1 Alpha-2 standard, on the construction of an alpha-2 
code: "42 alpha-2 code elements are not used in the ISO 3166. Users sometimes 
need to extend or alter the use of country code elements for special purposes.” 

It is my understanding that the ISO3166 Maintenance Agency can not re-assign 
codes from the User Assigned range. This needs an action from ISO TC46. 

3) Jaap Akkerhuis writes:

> Shane Kerr writes:
> 
>> 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).
> 
> Yes, that is a perfectly legit use. 

For those who are not aware, Jaap is a member of the ISO-3166 Maintenance 
Agency and a Category C liaison for ICANN to TC46/WG2 [1].  Therefore it is 
likely that he knows these things. Note that the IETF has its own liaison to 
ISO-TC46 (John Klensin) [2]. Conversely, I (Roy Arends) make no representation 
for ICANN.

4) The XN— ACE prefix for internationalized domains was chosen by IANA, because 
"The use of ISO 3166-1 user-assigned elements removes the possibility that the 
code will duplicate a present or future ccTLD code.” [3]

5) ISO, ICAO, IATA, WIPO, UNLOCODE, UNICODE, Worldbank, Interpol, CABforum, and 
the IETF  make use of these User Assigned codes as intended by ISO3166. These 
codes have been assigned for different purposes that only have meaning in the 
local context of their organization and their constituencies.

6) It is highly unlikely that any of the 42 codes will ever appear in the root 
zone (especially following Postel’s Law: Be conservative in what you do), as we 
follow RFC1591. 

When a private space name is chosen, the 42 top-level labels are safe to use, 
as it is highly unlikely to collide with any top-level domain now or in the 
future. 

Please see the presentation during DNSOP at IETF106 here: 
https://youtu.be/yUO1J9s8BdE?t=5042

Follow the slides here:
https://datatracker.ietf.org/meeting/106/materials/slides-106-dnsop-sessa-draft-arends-private-use-tld

Warmly,

Roy Arends
Not representing ICANN.

[1] https://www.iso.org/organization/567449.html
[2] https://ietf.org/about/liaisons/
[3] https://psg.com/~randy/lists/iesg/2003/msg01081.html
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop