Subject: [DNSOP] Thoughts on the top level name space

From: Steve Crocker <[email-masked]>
Date: Sun, 5 Jul 2015 04:26:54 -0700

This note is an attempt to describe how things work today and to bring some precision to the current discussion.  Except very mildly under the ISSUES section at the end, this note does not propose anything new.

This is quick draft.  There might be errors, missing pieces, assumptions, etc.  Please comment or fix.

ONE NAME SPACE

There’s really just one top level name space.  The top level of the domain name system (DNS) is *part* of this name space.  Names for other uses are also part of this space.  Names not intended to be used as top-level *domain* names (TLDs) leak into the public DNS, so it’s not really possible to keep these apart.

Informal vs Formal Allocation

ICANN allocates top level names via its formal processes.  IETF tends to recognize names that have developed use informally, although sometimes IETF will formally allocate a name prior to seeing the name in use.  These processes do not usually clash but have the potential for doing so.

EIGHT SUBSETS?

Here is an attempt to subdivide the entire name space into non-overlapping subsets and to show the pathways for a name to move from one subset to another.  The subsets are annotated with whether the subset falls into the IETF’s, ICANN’s or neither’s purview.

1. (Neither) Names that have not yet been used for anything.  This is an initial state for all names except two letter Latin letters.  Names in this subset may move to subsets 2, 4, 5, 6 or 7.  Examples:

	unusedname96456

2. (IETF) Names that have not been formally recognized but are being used privately or for applications that have not yet become standard.  Names in this subset may move to subset 4.  Examples:

	onion

3. (ICANN) Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future.  Names in this subset may move to subset 7 to become active ccTLDs.  Examples:

	xq

4. (IETF) Names the IETF has formally recognized as reserved for particular non-DNS uses.  Names in this subset are effectively permanent.  (“Effectively permanent” means they are expected to remain in this subset forever and there is no defined process for changing the status of names in this subset.)  Examples:

	example, local

5. (ICANN) Names ICANN has determined to be inappropriate to delegate.  Names in this subset are effectively permanent.  Examples:

	corp, home, mail

6. (ICANN) gTLDs, both Latin and IDN.  Names in this subset are expected to last indefinitely.  If they are taken out of service they move to subset 8.  Examples:

	net, info, xxx, xn--cg4bki

7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected to last indefinitely.  If they are taken out of service they move to subset 8.  Examples:

	jp, uk, na, xn--fzc2c9e2c

8. (ICANN) Previously used TLDs that have been taken out of service.  Names in this subset must remain out of service for a very long time, currently estimated at 50 years, to avoid unintended consequences.  Examples:

	cs

ISSUES

o ICANN speaks indistinctly about subset 5.

o Does the IETF have a process for moving a name from subset 2 to subset 4?

o A process for coordination between the IETF and ICANN regarding subsets 2, 4 and 5 would be helpful.

o Should there be some sort of operational penalty for leakage of names in subsets 2, 4, 5 and 8 into the public DNS, e.g. a slow response from DNS servers?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jul 2015 21:08:34 +0000

On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker"
<[email-masked] on behalf of [email-masked]> wrote:

>3. (ICANN) Two letter Latin characters that have not yet been assigned by
>the ISO 3166 maintenance agency but might be in the future.  Names in
>this subset may move to subset 7 to become active ccTLDs.  Examples:
>
>	xq

'pq' is a better example.  'xq' is classified as User Assigned, which
means it has been assigned for use by anyone for their own purposes.  'pq'
is (using Wikipedia's term) unassigned.

In recognition of this, though, I'd lump all of the alpha-2 codes
([A-Z][A-Z]) into category 3, and call it informally "being at the mercy
of the ISO 3166-1 Maintenance Agency."

>4. (IETF) Names the IETF has formally recognized as reserved for
>particular non-DNS uses.  Names in this subset are effectively permanent.
> (“Effectively permanent” means they are expected to remain in this
>subset forever and there is no defined process for changing the status of
>names in this subset.)  Examples:
>
>	example, local

(Left in for the discussion later in this message.)

>7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected
>to last indefinitely.  If they are taken out of service they move to
>subset 8.  Examples:
>

The quirk I have here is the IDN Fast Track
[https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and
trying to anticipate what names will be in that.   The Latin ccTLD codes I
can anticipate from category 3 above.  But the IDN ccTLD names aren't
distinguishable from other IDN names without consulting the Fast Track and
even so, well I'll put this under - I don't understand if a name coming
through the Fast Track might also be on a generic TLD track.

As far as I know, if the Fask Track the only source of IDN ccTLD names?

>8. (ICANN) Previously used TLDs that have been taken out of service.
>Names in this subset must remain out of service for a very long time,
>currently estimated at 50 years, to avoid unintended consequences.
>Examples:
>
>	cs

Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which
have been rescinded (NS records removed) are eligible to be reinstated if
needed for further testing.  "I've been told" means that I have never seen
this in print and thus have no citation to give.

>ISSUES
>
>o Should there be some sort of operational penalty for leakage of names
>in subsets 2, 4, 5 and 8 into the public DNS, e.g. a slow response from
>DNS servers?

For the e.g., no.  If just because that delaying an answer opens the time
a cache can be poisoned.  Others have mentioned this.

But there's a wider issue suggested by this specific suggestion.  What
reaction should name servers have upon seeing a name in a certain category?

Take category 4 - example and local.

When running a tutorial/demo, I would expect to be able to use "example."
as my TLD in live use of general purpose DNS software.  In that case,
example. should mean nothing special to the DNS.  However, in the universe
of registration, that as a TLD (application) is to be rejected.  (But the
name can be used 'down low' in the tree.)

I don't expect the same for "local."  When running the same tutorial/demo,
I may want to use the functionality of "local." while running a name
server on ::1 - using "local." in my name server configuration will cause
some confusion.

Are these categories "felt" in the DNS protocol layer or the registration
service above it?  Or in the resolution service?

 - - -

In thinking about this, I have a number of past influences, mostly coming
from DNSSEC development.

One is seeing the impact of dealing with "expedient operational short
cuts" that resulted in long-lasting architectural issues.  Round robin was
one (which I feel I keep harping about) that required DNSSEC validation to
be able know how to reset the order of the records for the digital
signature operation and then revert.  Then there are other oddities, like
CNAME processing's many quirks.  From this I always ask - will the change
be expected to be seen in name server code paths?  Or will anything
derived here be a registry accessed by applications inserting and/or
retrieving data from the system?

Another is the drive towards future proof-ness.  How can any improvement
drive towards a data-driven solution rather than a something that needs
more code paths?  Is the change compatible with current code paths, even
past code paths?

And, how much of this is about domain names and how much is about TLDs?
Isn't this all about TLDs as where name spaces are rooted?  (Or
sub-rooted?)

BTW, I've been trying to read back in time, as far back as RFC 799
"Internet Name Domains" and RFC 805.  If there are earlier discussions,
I'd like to know.  Some of the pre-1034 RFCs are close to today's
understanding, but Mill's 799 seems to have been passed by.  The purpose
of this is to determine what the intent of domain names were (originally),
whether applications have appropriately stuck to that, whether the DNS of
STD 13 is a subset of domain names or a superset of domain names, and how
host names of RFC 1123 applies to all of this.

In some sense, all of the problems are the use of host names in other
forms.  And in trying to put the horse in front of the cart, all of this
seems to date back to email (pre-SMTP even) and how to address a mailbox
somewhere.  The usual data structures I think of are URI, X.509, and email
headers and they are hostnames.  But Tor's onion isn't, I think.  This
makes me think less about the DNS rules for domain names as the place to
root all of this.  But I'm not sure.

To sum up, as much as the categorization is interesting, I'm not sure it
sets up the equation properly - as far as eventual impact on code.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 07 Jul 2015 11:42:26 +0200

Not taking a stand on this, but some more remarks on these thoughts.

 > is (using Wikipedia's term) unassigned.

Indeed. The complete user assigned set is:

	AA, QM-QZ, XA-XZ and ZZ

For the alpha 3-code the complete user assigned set is:

	AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ

so one could argue that the delegations for TLD xyz (and maybe xxx) is
a actually against the rules in ICANN's Application Guide Book.

 > of the ISO 3166-1 Maintenance Agency."

But given that they can be freely used, one could consider them as
candidates for non-TLD use in the name space.

 > > (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain in this

I would recommend to not use UK as an example in this discussion. If I
remember correctly, the use as a TLD stems from the time before the
iso alpha-2 codes got adopted as TLDs.

 > through the Fast Track might also be on a generic TLD track.

As far as I know, the Fast-Track IDN process uses the ISO standard to
see whether the requested name can be applied as ccTLD. so something like
Scandinavia will drop because because there is no ISO code for the corresponding country or (administrative) territory.

 > >currently estimated at 50 years, to avoid unintended consequences.

CS has been used twice by ISO 3166. It is now in the 50 year cool-off period.

 > this in print and thus have no citation to give.

And there are other cases; Official assigned by ISO but not used as
TLD (um comes  to mind).

	jaap

---

From: "Bill Woodcock" <[email-masked]>
Date: Tue, 7 Jul 2015 18:27:58 +0800

As I'm sure our resident bad-idea-fairy can relate in greater detail, .UM was a delegated ccTLD with SLD subdelegations and at least one user, before the administrative contact requested that the TLD delegation be rescinded or deactivated or whatever you want to call it. 

Just a little more colorful history of the shub-Internet. 
    
                -Bill

> On Jul 7, 2015, at 17:44, Jaap Akkerhuis <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Dr Eberhard Lisse <[email-masked]>
Date: Tue, 07 Jul 2015 11:32:51 +0100

-07-07 11:27, Bill Woodcock wrote:>
> As I'm sure our resident bad-idea-fairy can relate in greater detail,
.UM was a delegated ccTLD with SLD subdelegations and at least one user,
before the administrative contact requested that the TLD delegation be
rescinded or deactivated or whatever you want to call it.

---

From: Dr Eberhard Lisse <[email-masked]>
Date: Tue, 07 Jul 2015 11:43:57 +0100

Sorry for the empty previous post.

My recollection is somewhat different from the AC "requesting" the
revocation.  But then the then AC reads this list and can relate
himself if he wishes to do so.

And I was quite upset at the time because I wanted dibs on IMODI.UM
(just for the fun of it, not for squatting, actually with the
express proviso until and/or if Janssen or whoever holds the trade
mark now, wanted it :-)-O)

el

On 2015-07-07 11:27, Bill Woodcock wrote:
> 
> As I'm sure our resident bad-idea-fairy can relate in greater
> detail, .UM was a delegated ccTLD with SLD subdelegations and at
> least one user, before the administrative contact requested that
> the TLD delegation be rescinded or deactivated or whatever you
> want to call it.
> 
[...]

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 7 Jul 2015 23:00:41 +0000

Putting the focus on this part of Steve¹s original email for now:

>o Does the IETF have a process for moving a name from subset 2 to subset

Ideally, I would argue we may not need such a process. Beside
experimentation with strings like xx-Š, subset 2 should be empty or, at
least, not ground for consideration to move to subset 4. So, beside
grand-fathering a few strings, what is needed is a process that is less
ambiguous and simpler to evaluate than RFC6761 to reserve strings in
subset 4. Maybe something along the lines of IETF validates the technical
merits of the proposal and ICANN validates the suggested nameŠ That leads

>2, 4 and 5 would be helpful.

RFC6761 does not say anything about such a coordination process. We have
now learned a lot going through this round of 6761 candidates, so it is
time to work on 6761bis, with, among other things, this coordination
between ICANN and IETF on the agenda.

Alain.

---

From: Steve Crocker <[email-masked]>
Date: Tue, 7 Jul 2015 19:36:28 -0400

On Jul 6, 2015, at 5:08 PM, Edward Lewis <[email-masked]> wrote:

> is (using Wikipedia’s term) unassigned.

Thanks.  I didn’t check the tables before writing.  I was pretty sure xq wasn’t already assigned to a specific country or territory, but I didn’t think about a “1918” style designation of two letter codes.  Perhaps we need another subset to put these into.  It would be a “final” state in the sense that once a two letter code is put into that state, it can’t move to another state.  And the purview would be the ISO 3166-1 Maintenance Agency.

> of the ISO 3166-1 Maintenance Agency.”

Hmm… I understand your point, but I think it would feel odd to our audiences.  If the ISO 3166-1 Maintenance Agency were to tinker with established codes, e.g. DE, JP, CN, etc., all hell would break loose.

> through the Fast Track might also be on a generic TLD track.

I think this is a non-problem.  Strings beginning with “x n - -“ are in subset 1 until they are moved into either subset 7 (Active ccTLD) or subset 6 (Active gTLD).  It doesn’t matter whether they moved into the Active ccTLD subset because of the current FastTrack or some future process.

> As far as I know, if the Fask Track the only source of IDN ccTLD names?

I believe this is true at present.  There may be other processes in the future.
> this in print and thus have no citation to give.

Heh.  Good point.  Well, for other reasons I’ve been thinking we may need three additional subsets, and perhaps the experimental IDN TLDs would fit into one of these.  The three are:

o The two letter codes reserved by the ISO 3166-1 Maintenance Agency that will never be assigned to countries or territories, i.e. what you said above.  This subset would be carved out of subset 3 and be a final state.

o Names that have shown up in queries with some frequency but may subside in the future and hence may be available for assignment in the future.  They would arrive into this subset from subset 1 (or possibly subset 3), and either return to the subset they came from or progress to subset 5.  I would put the test IDNs into this subset.

o Names that have been permanently excluded from use by both the IETF and ICANN and hence fall into both subsets 4 and 5.  I think there’s value in keeping all of these subsets distinct from each other, it’s necessary to create a new subset for names that both groups have excluded.  This would be a final state, arrived at either from subset 4 or subset 5.

> service above it?  Or in the resolution service?

Interesting and informative.  Thanks.  This require splitting off a piece of subset 5 to create yet another subset.

> more code paths?  Is the change compatible with current code paths, even

I agree we don’t want to create unnecessary code paths.  I don’t have enough context to contribute to the rest of your comments here, but I’m sure others do.

Thanks,

Steve

---

From: Steve Crocker <[email-masked]>
Date: Tue, 7 Jul 2015 19:48:18 -0400

Thanks.  Minor comments in line below.

Steve

On Jul 7, 2015, at 5:42 AM, Jaap Akkerhuis <[email-masked]> wrote:

> a actually against the rules in ICANN’s Application Guide Book.

It’s my understanding that only the two character codes are included in the relationship between DNS top level names and ISO 3166-1.  Three letter codes aren’t included, so there’s no conflict.

> candidates for non-TLD use in the name space.

Hmm… Maybe.  Seems like a bad idea, though.

> iso alpha-2 codes got adopted as TLDs.

Well, I know there is controversy over some of the two letter codes, particularly UK, SU and EU, but it seems to me they are in full use and treated as ccTLDs.

> Scandinavia will drop because because there is no ISO code for the corresponding country or (administrative) territory.

This comment applies to whether a particular name is permitted to move from one subset to another.  I don’t think it’s necessary to include the rules for moving, just what subsets names can be in.
>> this in print and thus have no citation to give.

See my reply to Ed Lewis re a possible additional subset for names that have appeared at the root with some frequency but might subside

> And there are other cases; Official assigned by ISO but not used as

It seems to me that UM did appear in the root and then was taken out of service.  I doubt we’d want to see it assigned to another country or territory in the near future.  I’d put it in subset 8 unless it were brought back to life in the service of the same territory it had been used for before.

Steve

---

From: hellekin <[email-masked]>
Date: Tue, 07 Jul 2015 21:28:40 -0300

On 07/07/2015 08:00 PM, Alain Durand wrote:
> what is needed is a process that is less ambiguous and simpler to
> evaluate than RFC6761 to reserve strings in subset 4.

Can you please elaborate on "ambiguous and simpler"?

In my opinion, what we need is already there, and is called RFC6761.
Now I'm all ears for what needs to be done to enhance RFC6761 process.
But I don't think taking back technical control over a tiny subset of
global names from IETF can do any good.

I think RFC6761 section 5 is not ambiguous, but I've seen ambiguity in
how candidates answer the questions.  Maybe clarifying the scope of each
point is in order.

==
hk

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 07 Jul 2015 18:03:50 -0700

> It seems to me that UM did appear in the root and then was taken out of service.  I doubt we’d want to see it assigned to another country or territory in the near future.  I’d put it in subset 8 un…

The Dept. of Insular Affairs within the Dept. of the Interior may, or 
may not, allow its iso3166-1 code point allocation(s) to be repurposed.

My very minor point is that Insular Affairs, not we (either hat), make 
policy wrt the UM code point.

Eric

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 08 Jul 2015 09:53:56 +0200

Steve Crocker writes:

 > > a actually against the rules in ICANN�s Application Guide Book.
 > 
 > It's my understanding that only the two character codes are included in the relationship between DNS top level names and ISO 3166-1.  Three letter codes aren't included, so there's no conflict.

There is a relation between aplha-3 codes and gTLDS. In my reading of
Applicants Guide Book Section 2.2.1.4 point 1, apha-3 codes are
considered an off limits if listed in ISO 3166-3. (That's why google
retracted some applications because they collided with his rule).

Of course, the list above is "1918-like space" but still so it doesn't
matter that much;. However, one might want to be consistent in
threating 1918-like thingies.

	jaap

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 8 Jul 2015 15:57:24 +0800

> On Jul 7, 2015, at 6:43 PM, Dr Eberhard Lisse <[email-masked]> wrote:
> revocation.

I meant the Department of the Interior.  If I’m remembering correctly.

                                -Bill

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 08 Jul 2015 09:59:44 +0200

Steve Crocker writes:

 > > is (using Wikipedia�s term) unassigned.
 > 
 > Thanks.  I didn't check the tables before writing.  I was pretty sure
 > xq wasn't already assigned to a specific country or territory, but I
 > didn't think about a '1918' style designation of two letter codes.
 > Perhaps we need another subset to put these into. It would be a
 > 'final' state in the sense that once a two letter code is put into
 > that state, it can't move to another state. And the purview would be
 > the ISO 3166-1 Maintenance Agency.

FYI: There has been attempts to move from '1918' style space to allocated
space but in the cases I know, it has been refused. by the ISO 3166/MA.

	jaap

---

From: Dr Eberhard Lisse <[email-masked]>
Date: Wed, 08 Jul 2015 09:03:23 +0100

That corresponds to my recollection.

el

On 2015-07-08 08:57, Bill Woodcock wrote:
> 
>> On Jul 7, 2015, at 6:43 PM, Dr Eberhard Lisse <[email-masked]>
>> wrote: My recollection is somewhat different from the AC
>> "requesting" the revocation.
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
> 

- --

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 8 Jul 2015 07:36:33 -0400

Colleagues,

As we pursue this discussion, I think it would be helpful to focus on attributes that are visible and relevant from the perspective of DNS operators, with an eye towards guidance we might provide to them and applications developers.

For example, the distinction between gTLDs and ccTLDs is of great importance to ICANN and to participants in its decisions, but of less obvious relevance to an application developer or DNS operator who sees only "name that gets a positive response to a DNS query against the public root zone."

It seems to me, as a first cut, that the important thing to take into account here is that the production DNS root zone is dynamic-- just as any other chunk of the namespace. We're accustomed to thinking of the root zone as special, and indeed it's still far less dynamic than other areas of the namespace, for good reason-- but it's not static. Rules we try to derive today could change within foreseeable time. (Some of us are/were opposed to the decisions that resulted in this fact, but it remains a fact.)

It further seems to me that an attempt to list names that are currently in the public root zone or might someday be in the public root zone has a high risk of being simply backwards if the purpose is to identify names it's "safe" to use in other contexts because they won't collide with names in the public root zone.  Our current approach as documented in RFC 6761 comes at this question from the perspective that the IETF can declare whatever names it likes to be so "protected" by extending the standard with a new entry in the special use names registry, but takes no account of any possible distinctions between names currently in use at an arbitrary time for the DNS, names that will (or even might) be in use at a future time for the DNS, and any other categories. 

We might want to decide which, if any, of such distinctions are meaningful for the purposes of the IETF identifying "special use names".

best,
Suzanne

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Wed, 8 Jul 2015 15:06:03 +0000

Hi,

Thanks, Suzanne for your thoughtful contribution.

I posit that continued inaction on the question of "Does the .onion case 
fit the RFC6761 mechanism" actually weakens the reputation of the IETF, and
certainly that of DNSOP.

I acknowledge that it is important to have discussion and a wide range
of opinion expressed, such that an informed decision can be made.
We have seen plenty of discussion.

I beleve that it is time to make a decision.  People will then respond to
that in whatever manner best suits their objectives.

I encourage the relevant chairs of the working groups to push for a decision.

Regards,  Hugo Connery
________________________________________
From: DNSOP [[email-masked]] on behalf of Suzanne Woolf [[email-masked]]
Sent: Wednesday, 8 July 2015 13:36
To: Jaap Akkerhuis
Cc: Edward Lewis; Steve Crocker; [email-masked]
Subject: [DNSOP] perspective Re:  Thoughts on the top level name space

Colleagues,

best,
Suzanne

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jul 2015 09:55:49 -0700

<secretary-hat on>

> I encourage the relevant chairs of the working groups to push for a decision.

Just to be clear: the WG already did decide that. The WG document has been submitted to the IESG a few weeks ago. See the archives of this list, and <https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/history/>.

To see the (hopefully-up-to-date) list of WG documents, see <https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html>

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jul 2015 17:33:59 +0000

On 7/8/15, 7:36, "Suzanne Woolf" <[email-masked]> wrote:

>For example, the distinction between gTLDs and ccTLDs is of great
>importance to ICANN and to participants in its decisions, but of less
>obvious relevance to an application developer or DNS operator who sees
>only "name that gets a positive response to a DNS query against the
>public root zone."

It's not that the distinction between gTLDs and ccTLDs matters, I believe
that what matters first is whether this is an issue best handled in the
DNS protocol or in the operational conventions applied to placing names
into the root zone.  As much as I spend time trying to distinguish
characteristics of TLDs, I don't think any of that really matters in this
context, at least in the high level.

If a name is meant to be represented in the DNS, then delegate it, NS/DS
set and all.  If a name is not meant to be in the DNS, then we can 1)
simply reserve it from being delegated, 2) delegate it in a way that
shunts all queries to /dev/null or 3) alter code paths such that the name
is never spoken over port 53.

A clear definition that hasn't been made is what names are we talking
about.  Re-reading notes, it seems that all the use cases match, to date,
host names and there are specifications that bear that out.  Such as
pointing to RFC 1123's definition of a host name.  But the described use
of onion would break that assumption.  This lack of definition isn't a
show stopper but to be pedantic about it, no one has offered up why we
talk about "domain" names.  (RFC799 seems to be the origin, citing mail
domains, but that is in the context of mail servers.)

>It seems to me, as a first cut, that the important thing to take into
>account here is that the production DNS root zone is dynamic-- just as
>any other chunk of the namespace. We're accustomed to thinking of the
>root zone as special, and indeed it's still far less dynamic than other
>areas of the namespace, for good reason-- but it's not static. Rules we
>try to derive today could change within foreseeable time. (Some of us
>are/were opposed to the decisions that resulted in this fact, but it
>remains a fact.)

It's been dynamic for a decade, NS sets change and there has been activity
in ccTLDs and even some sporadic gTLD delegations, not to mention test
IDNs coming and going.  I sense the fear is more in the way other pieces
of software treat the root zone.  I recall a past version of a general
purpose, open-source name server that would refuse to load a zone as the
root unless explicitly informed the operator was sane.

The concern returns once again to what I see as a central question - is
this about the protocol or the operational convention of registering names
in the root zone?  If it is the former, we are tinkering with, perhaps,
the production of the root zone.  If it is the latter, we are tinkering
with the submission process.

>It further seems to me that an attempt to list names that are currently
>in the public root zone or might someday be in the public root zone has a
>high risk of being simply backwards if the purpose is to identify names
>it's "safe" to use in other contexts because they won't collide with
>names in the public root zone.  Our current approach as documented in RFC
>6761 comes at this question from the perspective that the IETF can
>declare whatever names it likes to be so "protected" by extending the
>standard with a new entry in the special use names registry, but takes no
>account of any possible distinctions between names currently in use at an
>arbitrary time for the DNS, names that will (or even might) be in use at
>a future time for the DNS, and any other categories.
>
>We might want to decide which, if any, of such distinctions are
>meaningful for the purposes of the IETF identifying "special use names".

"Special Use Domain Names"  The third word is central to this thread is
often omitted.  It is why we should have a definition of 'domain' names,
state whether this applied to the operation of the global public Internet
or is a matter of altering the standard, base, protocol.

One perspective I think needs to be addresses too is "what is the process"
for registering a name in the root zone registry?  What does it mean?

There is the ICANN process.  The process has been defined by a community
process akin to the IETF albeit with more structure to the community.
When I see words like "to ICANN and to participants in its decisions" I
cringe because that is giving credit to the wrong group when it comes to
many of the processes.  ICANN does implement what comes in from community
processes so there may be an appearance of the ICANN staff making
decisions.  But this is as much a function of what comes from the
community.  But this isn't what I want to impart.  (There have been
threads on whether it's as easy to participate in IETF or ICANN
communities.  I'll leave that as an open topic.)

There's been talk that the price of a TLD is high.  I am unable to
rationalize all of the price tag, but it covers a lot of work done by a
lot of people when it comes to clearing a name for registration and
delegation. I'm not going to try to justify the price here, but I do think
it's is instructive to keep in mind the work needed before a name is
delegated.

Is a name going to work?  Does it meet protocol limitations?  That's
pretty simple.

Is the name compatible with the existing set of code out there?  Are names
in use that would be disruptive?  For example, "local."  For this the IETF
list is important.

Is the name offensive?  This is something we don't talk about inside
engineering circles, it's highly subjective.  But what if some managed to
deploy a system using a top name what is, well, offensive.  Perhaps having
a thick skin makes one think it is okay, but still it might incite violent
reactions by others.

Does the name conflict with another use in a way that causes harm?  Could
someone, seeing it or copying it from hardcopy be fooled by the name?

Is it visually similar?  1 vs. i, Cyrillic 'a' vs. Latin 'a' and so on.

There are other reasons...but I'll skip to the last obvious one - will a
registry for the name work?  I raise this because this is a part of the
current process for gTLDs but is one that is not applicable to names that
are not meant to be registries.

I've been kicking the process around in my mind the past weeks.  I keep
thinking there's a easy way around all this work, but I don't think so
(except for the last one).  If it were, then the price of a new TLD need
not be so high.

But I keep coming to this, decidedly non-engineering, question:  What if
someone uses RFC 6761 to get an offensive name registered as a special-use
domain name?  What organization is going to bear the risk of dealing with
any potential fallout from the registration?  Well, maybe I'm wrong about
this - objections raised about operating something with an offensive name
more so than recognizing a name is offensive.  What if I have to have the
name in my code paths though?

I'm not against innovation and using (domain) names for things that will
not be in the DNS.  I am against altering code paths such that we restrict
the use the DNS protocol in other contexts or in the future.  I am against
putting the IETF in harms way if someone manages to "game the system" for
one purpose or another.

I do think an alt-TLD is needed, one that avoids the trouble some strings
might bring.  I do think that the IETF needs a process for determining
what names should not be activated (given NS sets in the root zone), or at
least provide recommendations for what should not be activated.

Perhaps IETF last call is what people feel is sufficient to judge whether
an idea has consensus.  In many ways, I'm not all that confident.  Last
calls are only heard by those that are subscribed to the lists.  (That's
behind my comment that I'm concerned by the not-engaged developer
population.)

---

From: Rubens Kuhl <[email-masked]>
Date: Wed, 8 Jul 2015 14:51:47 -0300

> Em 08/07/2015, à(s) 14:33:000, Edward Lewis <[email-masked]> escreveu:
> 

Actually, a better distinction would be between ISO-controlled allocation and ICANN-controlled allocation, not gTLDs and ccTLDs. For 2 ASCII letters, ISO is now considered authoritative in allocating pair of letters to countries and territories; ICANN's only decision is whether an organization represents that country in RFC-1591 terms. 
But when it comes to IDN ccTLDs, registries need to pick a 2-char IDN string, submit to ICANN which then decides whether that combination is to become a ccTLD or not; with IDNs there is actual decision on whether that string is to be allocated as a ccTLD. 

Rubens

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jul 2015 18:11:53 +0000

On 7/8/15, 13:51, "DNSOP on behalf of Rubens Kuhl" <[email-masked]
on behalf of [email-masked]> wrote:

>Actually, a better distinction would be between ISO-controlled allocation
>and ICANN-controlled allocation, not gTLDs and ccTLDs. For 2 ASCII
>letters, ISO is now considered authoritative in allocating pair of
>letters to countries and territories; ICANN's only decision is whether an
>organization represents that country in RFC-1591 terms.
>But when it comes to IDN ccTLDs, registries need to pick a 2-char IDN
>string, submit to ICANN which then decides whether that combination is to
>become a ccTLD or not; with IDNs there is actual decision on whether that
>string is to be allocated as a ccTLD.

Hmmm.  I'm confused in many ways about this reply.

My comment above is that, as far as the thread on the Special Use Domain
Name registry and any potential replacement of the process of making an
entry in it, it doesn't really matter how or why a name appears (or
doesn't) in the DNS to the software handling the names.

But beyond that, ISO, has, as one of its many functions, the job of
maintaining the ISO-3166-1 alpha-2 codes.  I did some web searching and
found this reference which might clear up "ICANN-controlled allocation" :
http://icannwiki.com/CcTLD

and, in particular: http://www.iana.org/help/eligible-tlds

As far as the "IDN ccTLDs, registries need to pick a 2-char IDN string" -
I believe that to be factually incorrect.  The Fast-Track process here:
https://www.icann.org/resources/pages/fast-track-2012-02-25-en has
details.  But there are plenty of examples of more than two character IDN
ccTLDs already, I think.

For example, Mongolia's which 'looks like' MOH :
https://www.iana.org/domains/root/db/xn--l1acc.html

There are many names that "are longer" scripts I don't understand enough
about to count "characters".  Like one of Sri Lanka's :
https://www.iana.org/domains/root/db/xn--xkc2al3hye2a.html

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Jul 2015 17:36:19 -0700

No.

At the time, the Administrative Contact as listed in the IANA Whois database was USC-ISI. They (IIRC, the Director of ISI) requested the TLD to be removed from the root zone.

Regards,
-drc

> On Jul 8, 2015, at 12:57 AM, Bill Woodcock <[email-masked]> wrote:
> 
>

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Jul 2015 17:44:47 -0700

Jaap,

> space but in the cases I know, it has been refused. by the ISO 3166/MA.

In the past, ISO-3166/MA maintained a color-coded "decoding table" that clearly identified the "user assigned" 2-letter ISO codes. However, for reasons that I'm sure made sense to someone, they stopped publishing the decoding table (http://www.iso.org/iso/iso-3166-1_decoding_table.html) it now is found on the Wikipedia page for "ISO 3166-1 Alpha-2" (https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table).  I haven't looked particularly closely but I've been unable to locate an official reference to "user assigned" codes any more (e.g., that term isn't in the glossary at http://www.iso.org/iso/country_codes_glossary.html).

Is there an official, ISO maintained, listing of ISO-3166 "user assigned" codes?

Thanks,
-drc

---

From: manning <[email-masked]>
Date: Wed, 8 Jul 2015 18:18:29 -0700

Hum…  The then director has no recollection of that and a request to ICANN to produce such a letter was denied.  All we have is an assertion that a request was made.
Neither Herb, nor Bob have any idea what happened.  In the interests of openness & transparency, one might expect less demure behaviors.  I would go into more detail,
but it is not WG related.  

….
back in Dec 2014, this exchange occurred:
————
> 
> I have been doing some research and can find no one here at ISI who remembers this communication and there is no written record of this exchange.   Would it be possible to get a copy from you?
> It does not appear to be available from the normal ICANN archives.

Thanks for your enquiry.

It is standard IANA practice that the details of the communications we have with directly involved parties are held in confidence. For requests relating to substantial changes of control for ccTLDs (e.g. delegations, transfers and retirement) a report is published after the conclusion of such requests that is a distillation of the relevant facts, but the underlying communications with the parties are not.

With kindest regards,

Kim Davies
Internet Assigned Numbers Authority
ICANN
———————

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 09 Jul 2015 10:50:38 +0200

David Conrad writes:

 > 
 > In the past, ISO-3166/MA maintained a color-coded "decoding table" that
 > clearly identified the "user assigned" 2-letter ISO codes. However, for
 > reasons that I'm sure made sense to someone, they stopped publishing the
 > decoding table (http://www.iso.org/iso/iso-3166-1_decoding_table.html)
 > it now is found on the Wikipedia page for "ISO 3166-1 Alpha-2"
 > (https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table). 

The official decoding table got lost when ISO revamped their website.
More people have complained about that (including me).

One can get something similar by going to
<https://www.iso.org/obp/ui/#home>, select the country codes in the
search box, and then do an empty search (just hit enter). That gets
you a complete a table (and you might want to set results per page on
maximum). Unfortunately, the User Assigned code are missing.

The last time I looked at the Wikipedia it was a bit out of date but I
just looked and someone seems to have updated it.
 
 > I haven't looked particularly closely but I've been unable to locate an
 > official reference to "user assigned" codes any more (e.g., that term
 > isn't in the glossary at
 > http://www.iso.org/iso/country_codes_glossary.html).
 > 

The standard itself is authoritative for definitions of
terms, to quote from ISO 3166-1:2013 Clause 8.1.3 says:

	8.1.3 User-assigned code elements

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

I just took a trip along memory by means of the WayBack Machine. It
shows me on olde ISO site[1] (from 2009, just picked a random year),
which has the definition in the glossary[2]. That has the same quote
as above (from ISO 3166-1:2006) and some explanatory text.

But yes, it would be nice to have it back on the current site (and the
codes in the database).

	jaap

[1] <http://web.archive.org/web/20090707104326/http://www.iso.org/iso/iso-3166-1_decoding_table>

[2] <http://web.archive.org/web/20081205170501/http://www.iso.org/iso/customizing_iso_3166-1.htm>

---

From: Alain Durand <[email-masked]>
Date: Thu, 9 Jul 2015 15:53:22 +0000

On 7/7/15, 8:28 PM, "DNSOP on behalf of hellekin" <[email-masked]

>Now I'm all ears for what needs to be done to enhance RFC6761 process.

Here is a short list:

- RFC6761 does not say anything wrt to coordination between IETF and ICANN
on this topic.
- RFC6761 talks about names, not TLDs. i.e. It could be use to reserve a
name under any existing TLD.
- RFC6761 does not say much about how to evaluate the merits of proposals.
That made the discussion
  on the current crop of candidates difficult.

I¹m sure there are more issues. It would be great to discuss this in
Prague.

Alain

---

From: hellekin <[email-masked]>
Date: Thu, 09 Jul 2015 13:50:33 -0300

On 07/08/2015 08:36 AM, Suzanne Woolf wrote:
> 
> It further seems to me that an attempt to list names that are
> currently in the public root zone or might someday be in the public
> root zone has a high risk of being simply backwards if the purpose
> is to identify names it's "safe" to use in other contexts because
> they won't collide with names in the public root zone.
>

I can see a distinction here between "names that are currently in the
public root zone", and "names that might someday be in the public root
zone".  Obviously, the former is a finite list of names in operation,
and can serve as a reference to avoid name conflicts with non-DNS
namespaces: they already exist, so they should be considered solid.
Besides, if I understood well, there's a procedure to send
decommissioned domains to a 50-year-purgatory before they return to the
"unused" set.  On the other hand, this latter set of unused, potential
domain names is the complementary of the former in the superset of all
domain names: making it special as such would determine the future of
the namespace, which seems to go against the idea of letting reality
unfold and adapt to it.  So I'd recommend a clear distinction is made
between "existing domain names in the public root", and the rest of the
set, kept as undetermined and irrelevant to daily operations.

> Our current
> approach as documented in RFC 6761 comes at this question from the
> perspective that the IETF can declare whatever names it likes to be
> so "protected" by extending the standard with a new entry in the
> special use names registry, but takes no account of any possible
> distinctions between names currently in use at an arbitrary time
> for the DNS, names that will (or even might) be in use at a future
> time for the DNS, and any other categories.
>

I'm not sure I understand what you mean by "currently in use at an
arbitrary time for the DNS": it sounds to me as an equivalent to "the
superset of all possible domain names" that I evoked earlier; if a
domain is in use now, it's part of the set of "existing domain names in
the public root", otherwise it's undetermined.  Or do you mean there
should be a preemptive complete assignation of the domain namespace?  I
don't think it's possible to predict an ordered way of revealing the
namespace until its exhaustion: it sounds mechanistic.  Maybe you're
suggesting that some names should be reserved for future use?  In that
case I fear arbitrariness may be the rule.  What example categories
would you think of?

> meaningful for the purposes of the IETF identifying "special use

For the sake of avoiding name conflicts, the distinction above is
necessary ("existing", i.e., registered by IANA, or not).

Regards,

==
hk

---

From: hellekin <[email-masked]>
Date: Thu, 09 Jul 2015 14:45:30 -0300

On 07/08/2015 02:33 PM, Edward Lewis wrote:
> 
> But I keep coming to this, decidedly non-engineering, question:  What 
> if someone uses RFC 6761 to get an offensive name registered as a
> special-use domain name?
>

TL;DR: you cannot avoid subjectivity, you have to embrace it.

Your entire post is very interesting and thoughtful, Edward, but I
wanted to follow-up on my response to Suzanne and focus on your mention
of subjectivity and engineering.

There's no way we cut subjectivity out of the process, because decisions
are made by humans, on objective criteria (e.g., my previous response:
"registered or not"), and on subjective criteria (e.g., your examples of
visual similarity, offensiveness, and more generally meaning--in the
previous conversations regarding P2PNames usability issues came up
between, e.g., .onion, and .onion.alt)

When "domain" names are meant to be used primarily by humans, coming
from various backgrounds, cultures, languages, avoiding offensiveness
certainly is an impossible challenge to meet--if the dirty word does not
exist in a language you know, it might still make people smile or frown
in another culture.  It's mostly a matter of perspective, and that is
irreducibly subjective.

I think it's quite important indeed to keep in mind that humans will
judge whether an application is valid or not, and no, that's probably
not an engineering question.  But it can be established that
applications matching a visually-similar, confusing, or otherwise
threatening name can be rejected on security considerations; similarly,
a name obviously offensive to humanity, life, or the values promoted by
the Internet culture of planetary cooperation should be discouraged.

This is certainly a mind-blowing perspective to an engineer, and a
seemingly intractable issue to put skin on dead cold technology, but in
the end humans create, and humans decide what technology should do or
not.  In order to avoid the inevitable conflict of the limits of
morality and ethics (e.g., who decides that .fsck is not available),
this ultimate consideration should be left to the community, and not to
arbitrary rules: if it's easy to find an objection to an illustrative
.con special-use wannabe for its (English) meaning and its proximity to
.com, it's less easy to grasp its dirty meaning in French; this example
could certainly be rejected on the ground that it may confuse users
(especially as typing n instead of m on many keyboards is an easy
mistake) and pose a security risk; but rejecting it, or another similar
example, on the grounds it can be taken as an insult or refer to usually
intimate parts of someone is a cultural and moral call that should not
be written but tacit.

So, to summarize, when considering Special-Use Domain Names candidates*,
I'm for:

- - rejecting based on current use in DNS (to avoid name conflicts)
- - rejecting based on proximity of an existing name when it can lead to
  confusion and pose a security risk
- - recommending rejection when the word is threatening or contrary to
  cooperative and humanistic values (e.g., UNDHR)
- - suggesting rejection when the word can be considered offensive

* I guess IANA could tell better about how that fits their own process
for TLDs.

> 
> Last calls are only heard by those that are subscribed to the lists.
>
*** Should IETF use social media to expand their reach? (@ietf? @dnsopwg
?)

==
hk

---

From: hellekin <[email-masked]>
Date: Thu, 09 Jul 2015 15:44:20 -0300

On 07/09/2015 12:53 PM, Alain Durand wrote:

I don't think I can make it to Prague,

> - RFC6761 does not say anything wrt to coordination between IETF and I
CANN

How did the RFC6761 reservations happen?  Clarifying this process should
be helpful to determine this coordination.

> - RFC6761 talks about names, not TLDs. i.e. It could be use to reserve
> a name under any existing TLD.

Granted, this should be clarified as in: a new, inexistent TLD and/or
sub-domains within this TLD.

I must say I can't decide if there's a use-case for IETF to declare a
sub-domain special under an existing TLD that is already delegated by
IANA.  My brains explodes and shows "MESS" warnings.

> - RFC6761 does not say much about how to evaluate the merits of 
> proposals. That made the discussion on the current crop of
> candidates difficult.
>

I would not expect an amended RFC6761 to go much beyond what's already
in section 5.  Using quantitative criteria is prone to error and
imprecision and could well prevent a legitimate technology from growing:
we already know that .alt will not solve the issue of
globally-operative-name-spaces that are not suited for DNS (which is why
I proposed an informational RFC for P2PNames).  Nevertheless this global
uniqueness of names could become a criterium, since the alternative
would be covered by .alt.

> I'm sure there are more issues.
> 

- - RFC6761 does not clearly define the scope of each point in section 5.

Judging from the variety of responses to the first point about "Users"
and the overlap with "Application Software" on the one hand, and between
"Application Software" and "Name Resolution APIs and Libraries" on the
other hand, this should be clarified.  The fact that the current .onion
draft needs to mention "Applications (including proxies)" is symptomatic
.

- From my reading:
  1. Users are humans-in-front-of-Application-Software
  2. Application Software is a program-used-by-Users-or-other-programs
  3. Name Resolution APIs and Libraries are specialized parts of a
system that are concerned exclusively with *DNS* resolution, that can
run inside of an Application Software (library) or independently from it
(API).
  4. to .7 are self-explanatory.

Regards,

==
hk

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Jul 2015 08:52:10 -0400

> - RFC6761 does not say anything wrt to coordination between IETF and ICANN

Or with regard to co-ordination between anyone else and the IETF.
This is part of why I say the IETF retains the ability to take some
names out of the DNS protocol or otherwise to alter the DNS namespace.
I attempted to make some distinctions about this a few weeks ago, and
Steve Crocker has posted some other distinctions (some of which are,
as near as I can tell, just administrative matters for one policy
authority for a DNS zone).  Ed Lewis told me he didn't understand the
distinctions I was trying to make.  I'm not sure whether they're helpful.

> name under any existing TLD.

Yes, and in fact that happens.  Example, for instance, is reserved
underneath com, net, and org.

> - RFC6761 does not say much about how to evaluate the merits of proposals.

I don't think that's true at all.  It has the various criteria.  If
you can't explain how you meet the various criteria, then there's a
problem.  I think onion does, and others seem to too, so it's
proceeded accordingly.  The real blocker for onion for well over a
year was its link to other names where the argument for special
treatment was harder.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Fri, 10 Jul 2015 07:46:08 -0700

Andrew,

> Or with regard to co-ordination between anyone else and the IETF.

True, but the IETF hasn't entered into an MoU with anyone else on this particular topic.

> names out of the DNS protocol or otherwise to alter the DNS namespace.

I don't think there is any argument about this. The question is really about the criteria, constraints, and how coordination will be done since the implication of the special names registry is that it pushes the "single root" of the namespace up one level.

> problem.

Wrong actor. Alain said 'evaluate' (which I take to mean how does the IETF/IESG/community interpret the input provided related to the criteria in 6761), not 'explain' (which I take to mean how does the requester attempt to describe how they meet the criteria).

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Jul 2015 16:33:36 +0000

A re-ordering of the previous message happens here:

On 7/9/15, 13:45, "DNSOP on behalf of hellekin" <[email-masked] on
behalf of [email-masked]> wrote:

> *** Should IETF use social media to expand their reach? (@ietf?
>@dnsopwg?)

Oddly enough, ICANN does this, an in fact the ICANN staff includes a
Communications Team whose job is to engage as many peoples as possible
(and my peoples I an stretching that beyond cultures to, umm,
classifications like government workers, etc., i.e., non-cultural
divides).  This is also why ICANN makes a point of holding meetings and
events in places where the IETF is reluctant to go.

There's a double point here.  One, yes, this is a necessary component that
the IETF has not taken on as a role.  And two, the IETF doesn't employ a
communications team trained and equipped to do this.  I'm not saying the
IETF is deficient, I mean "it is what it is."

>* I guess IANA could tell better about how that fits their own process

The first I don't completely understand, if it's in the DNS, then the ship
has sailed.  I'm missing that point.

The other categories are fine.  It's the implementation that has me
concerned.

In another thread, you'd asked about " [less] ambiguous and simpler" (I
inserted less because I think you meant to include that) in a critique
about RFC 6761.  You'd also mentioned that, and I can't find the quote so
forgive me for paraphrasing your thought, that it wasn't what RFC 6761
asked that was a problem, it was the answers submitted - with the problem
being "ambiguity."

Unless I have mis-paraphrased you, and recognizing John Levine's comment
that the IETF is better at technology than processes, RFC 6761('s
potential replacement) could do with a lot more determinism.  RFC 6761 has
it's heart in the right direction, recognizing there's a difference
between impacts on code paths in applications, in DNS servers, DNS
resolution, and registration activity.  (I don't get the first item on
6761's list, do humans know the name to be special, but that's another
matter unimportant here.)  What RFC 6761 doesn't do well enough is give
any guidance of how to evaluate the responses.

There are only 6 sets of successful justifications in the registry
representing, if I counted right, 31 domain names, in 9 TLDs [net has
example.net], representing just 5 TLDs [local].  Looking the Users:
responses, all are "free to use" with the exception of the justification
of example as meaning "only for documentation."  (Most documentation of
DNS configurations comes from running it through a server, so...I mention
to this to mean I really don't get the "Users:" consideration section of
the RFC 6761 application.)

Throw in that 5 of the successful justifications are in the same RFC that
defines the registry, the 6th is in the next (numerical) RFC and by the
same authors.  Section 5 does give guidance on what to put in the
justifications but there's no guidance of what is important or necessary
to gain approval.  That's not a lot to go on, given that there aren't many
criteria listed anywhere.  And that there's no expectation that the review
of the application will be taken on by outside-the-IETF interested parties.

The IETF often uses refers to deciding something with the appropriate
expertise involved.  By that metric, I see the process described in RFC
6761 not being sufficient, it doesn't ensure that the appropriate experts
are involved.  Yes, the IETF has expertise when it comes to whether a name
is special in engineering - and I think that is missing from RFC 6761 -
especially having deterministic criteria defined.  One thing I'll mention
in the sense of being "blue sky" - there are IAB liaisons to ICANN board
that could be a means for coordination, perhaps there is a way for an
"expert review" to happen.

BTW, stumbled across in preparing this message, perhaps of interest:
https://datatracker.ietf.org/liaison/1351/

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>
>iQJ8BAEBCgBmBQJVnrMyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
>ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
>ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9JokP/jIYL2mtSgh2UPx5mogX+f9H
>HR55z/bzX81pB1RUXyTXXRghVHHCmIPz+luKBkeA9+USAuQ/h3qQsrTpLtWHTo18
>PgPl0nsG90IUDVtlx9Q0tIPR1zYtLIsLLEpqCY+GKdp7y7llAHhh7ASJkpC1nOSl
>DXiPjG3TX2WLGglfLd8o9bDbm2DF/CEAOmalFZjh+FsOuKaT6m07CtdFsdasIeAN
>f/qie61Hzny36kDxmTWmhhXW9we/B6PURScAEcpusukJXlT3ViBeozgVQCnvSr2L
>mfHvFAmWY32yk6Oe8Ss5fN8D6r1hlSlkiatofzPY/A659T/fUBAIVuA7luA17lQI
>jD9hH6mm0W0djJKLjRnKzmcM6/37kH7sdrX1vei13jovwc6IwjFptiTu31s8QUwV
>Tm9v6E3xm4pJJlwJ03BKCLQg8vpJbrllS/U/E3mRpsip02hljvmem6fRZJolu3LG
>Vw8Ocs7nN20ibiZt1iepPJXYfW3wMGFR8QBNoI4BMjSWJcuqIefMx4N9+Eute9jQ
>Jnb0iTRT1xCV8B/dr/OoXB4mJVtiu/zbAOHlTn/wqFVr4ZZYTdeRvgCgmXkXql3a
>o8LhHL98zzC9OkyKloNiRLI7QeMHCyHDamp0vvD3OwOX7yJK16s1LFwJk0DglzOI
>oEw/EV2ELKtxfleyZXek
>=R5oG
>-----END PGP SIGNATURE-----
>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 11 Jul 2015 09:12:26 +1000

In message <[email-masked]>, David Conrad
 writes:
> I don't think there is any argument about this. The question is really
> about the criteria, constraints, and how coordination will be done since
> the implication of the special names registry is that it pushes the
> "single root" of the namespace up one level.
>
> proposals.
> Wrong actor. Alain said 'evaluate' (which I take to mean how does the
> IETF/IESG/community interpret the input provided related to the criteria
> in 6761), not 'explain' (which I take to mean how does the requester
> attempt to describe how they meet the criteria).

It's like the judge said "I know porn when I see it."  Something are
just subjective.  This is why you have working groups not check lists
for evaluating.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Sat, 11 Jul 2015 09:22:45 -0700

Mark,

> It's like the judge said "I know porn when I see it."

Potter Stewart's 1964 expression was thrown out in 1973 in favor of a more objective standard (see the "Miller Test").

> Something are just subjective.

Extreme corner cases may require subjective analysis. I believe the vast majority of "special use" cases can be determined objectively, perhaps with an appeals mechanism for the odd corner cases where the objective analysis isn't clear cut.

> This is why you have working groups not check lists for evaluating.

RFC 6761 specifies an IETF "Standards Action" or "IESG Approval", not a working group decision.

Regards
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sun, 12 Jul 2015 08:52:26 +1000

In message <[email-masked]>, David Conrad
 writes:
> Potter Stewart's 1964 expression was thrown out in 1973 in favor of a
> more objective standard (see the "Miller Test").
>
> Extreme corner cases may require subjective analysis. I believe the vast
> majority of "special use" cases can be determined objectively, perhaps
> with an appeals mechanism for the odd corner cases where the objective
> analysis isn't clear cut.
>

That why we have groups of people look at the request. Not a
individual working off a checklist.  Attempting to get this sort
of assignment down to a simple checklist / objective measurements
will not work.

---

From: David Conrad <[email-masked]>
Date: Sun, 12 Jul 2015 14:17:31 -0700

Mark,

> of assignment down to a simple checklist / objective measurements

Because?

In large part, I believe a simply set of criteria/objective measurements can be established that will allow the majority of proposed special name cases to be resolved with no contention. I would agree that there will always be borderline cases that need human intervention, but even then, there needs to be _some_ criteria by which the humans can judge.

Regards,
-drc