[CWG-Stewardship] For your review - Draft Transition Plan V2.1 and DT Status Overview

[Andrew Sullivan]

Dear colleagues,

On Wed, Mar 11, 2015 at 07:07:41PM +0000, Marika Konings wrote:
> Dear All,
> 
> As discussed during yesterday's meeting, please find attached version 2.1 of the draft transition proposal which includes:
> 

I've read this document.  Here are some comments.

In I.A, the customers of the root zone change management function
include ccTLD and gTLD registries, and the INT registry. According to
the classification on http://www.iana.org/domains/root/db, however,
INT is just a species of "sponsored" TLD. (As you know from my
previous postings, I disagree with this interpretation, but let's
leave it for the moment). Instead of "INT", then, should this be
"sponsors of sponsored TLDs"?

In any case, I think the IAB needs to be added as another relevant
customer, _for the root zone_, because of arpa.  That is, the IANAPLAN
submission includes the arpa zone operation under the protocol
parameters registry, but I.A (and actually, I.B too) are talking about
the registry of the _root_ zone, in which the various TLDs are
registrants.  So the delegated authorities of every TLD are the
registrants (all the customers), and that includes the IAB for arpa.
(I hope this makes sense.  It's a little hard to understand because
the arpa zone is also served by the root zone, but you can see the
difference if you query for an SOA record for arpa.  Since there is
one, there are two zones.)  This should be extended to I.B (you can
check by doing whois -h whois.iana.org arpa) but, rather to my
embarrassment, I just don't know whether anyone has thought about I.G
or I.H.  I'll ask.

In I.F, why are the customers various registries?  The root zone KSK
is the trust anchor for the entire DNSSEC system.  The customers are
"all validating systems on the Internet".  I'm also not sure why IP
addresses are relevant to this.

Section II really depends on the reader knowing and understanding the
difference between a gTLD and a ccTLD, and also on understanding the
difference between a ccTLD and an IDN ccTLD.  I suggest that, before
II.A, that be inserted.  Here is some suggested text, but it can
probably use some sprucing up:

    The names in the root zone are by and large top-level domains.
    With very few exceptions, they fall into two borad categories:
    generic TLDs (gTLDs) and country-code TLDs (ccTLDs).  The majority
    of ccTLDs are two-letter TLDs; they are created in conformance
    with the ISO 3166 two-letter country code list.  There is also a
    growing number of ccTLDs that are associated with countries, but
    that write the name of the country as an Internationalized Domain
    Names for Applications (RFC 5890) U-label/A-label pair.  With the
    exceptions of INT and ARPA, the remaining TLDs are all treated as
    gTLDs for the purposes of administration.  This distinction is
    necessary to keep in mind in what follows.

In II.A.1, there is a claim that RFC 1591 "was not meant to be a
policy document".  I'm not sure I agree with that statement.  When
nerds like me talk about "policy", we mean it in the narrow sense of
"here are the rules for what happens right now."  There are DNS
validation policies, for instance, that determine whether you validate
DNSSEC responses or not, and what you do in case of failure.  Just
about every top-level registry these days has a registration policy
that says, "If you don't have two different name servers, we won't
publish your name in the DNS."  And so on.  These are technical
policies.  And we in the technical community cheerfully use the word
"policy" that way, to distinguish those rules (which are variable from
operator to operator) from protocol rules (which have to be the same
everywhere or things don't work).  RFC 1591 (or anyway, the relevant
parts) read exactly like that kind of "policy" to me.  What it
probably was not intended to be is a public policy or social policy or
something like that.  It certainly did not intend to be holy writ.

Which brings me to the other perhaps touchy issue in this section.
It's not true that there was no process for updating RFC 1591.  The
RFC series since practically forever -- certainly since the days of
1591 -- had a way to update _anything_, and that was to issue a new
RFC that said, "This one updates that one."  I think this is not a
problem, because I think the IETF and IAB pretty clearly decided many
years ago that this entire issue was sent somewhere else.  But it
could have been -- and in principle, still could be -- updated if
someone desperately wanted to do that and could get consensus.  It's
sort of too bad, really, that nobody went back and obsoleted RFC 1591,
or at least published an update saying where the policy documents had
moved to, because that would make this all much clearer.

In II.B.2 and II.B.3, there's this:

    The NTIA is currently responsible for providing this
    oversight. There is no description regarding how the individuals
    who perform these functions are selected, removed or replaced.

Should that say "no description in the agreement" or something like
that?  Surely there is, somewhere, such a description, because the
NTIA employees are all civil servants, so the relevant US civil
service regulations do contain such a description.  

In the same sections, the text answers the question of jurisdiction,
but not the "legal basis" part.  It should probably just say.  I guess
saying, "There's an agreement between ICANN and USG," would be enough,
yes?

I hope these comments are helpful.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com