From cgomes at verisign.com Sun Mar 15 16:25:06 2015 From: cgomes at verisign.com (Gomes, Chuck) Date: Sun, 15 Mar 2015 16:25:06 +0000 Subject: [Cwg-rfp1-2a-2b] FW: [CWG-Stewardship] For your review - Draft Transition Plan V2.1 and DT Status Overview In-Reply-To: <20150313120029.GB16982@mx1.yitter.info> References: <20150313120029.GB16982@mx1.yitter.info> Message-ID: <6DCFB66DEEF3CF4D98FA55BCC43F152E4953E6B2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> If the rest of you are like me, you probably haven't focused on proposal sections RFP 1 & 2 in months but I think those of us who proposed text for those sections toward the end of last year should consider Andrew's suggestions and respond to them. Please provide your thoughts regarding each of his suggestion below so that we can respond to Andrew and also make recommendations to the full CWG regarding any edits to Sections 1 & 2. Chuck -----Original Message----- From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Andrew Sullivan Sent: Friday, March 13, 2015 8:00 AM To: cwg-stewardship at icann.org Subject: Re: [CWG-Stewardship] For your review - Draft Transition Plan V2.1 and DT Status Overview 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 _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship at icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship