[CWG-Stewardship] For your review - Draft Transition Plan V3.2
Gomes, Chuck
cgomes at verisign.com
Sun Apr 19 18:59:26 UTC 2015
Andrew,
Thanks for the very detailed review and analysis. Here are my reactions to two of your comments/suggestions.
Regarding your discussion about fundamental bylaws vs. contractual terms (III.A p 17ff), my understanding is that what we are proposing for public comment will be the legal separation approach, which will involve a contract so I don't think the functional separation approach is an option in what we are proposing even though it could be revived based on public comment. Also, I believe that fundamental bylaws may be proposed by the CCWG even if there is a contract so I don't think it is a matter of ' fundamental bylaws vs. contractual terms '.
Regarding your comments about expression of interest statements on page 66, I get your point but I admit to having concerns if someone serving on the review team was unwilling to submit a statement of interest. I am not opposed to people with conflicts of interest being involved as long as it is publicly known what those interests are. It seems problematic to me if any member of the review team did not declare his/her interests.
Chuck
-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Sunday, April 19, 2015 12:54 AM
To: cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] For your review - Draft Transition Plan V3.2
Dear colleagues,
I've read the plan v 3.2 through. I here include my comments. Page numbers are from the redlined version.
I hope these remarks are helpful. They are offered in the same spirit of frank collaboration that I've valued so far in the CWG Stewardship.
Thanks to all of you for the hard work so far.
GENERAL REMARKS
To begin with, it's really very difficult to comment coherently on this document with the rather large gaps, particularly in section III.
I know we ran out of time. It's nevertheless more than a little worrisome that we're looking at a document with some of its most central elements missing only a couple days before the document is supposed to be largely done. I think therefore we should be prepared for participants in this group to do additional heavy-duty reviews during public comment, and some of those reviews may reveal some pretty big issues. I make this remark not to cast blame, but to be explicit that we're rather shy of our goal and we're going to have to make up the deficiency somewhere.
Various places in the text have questions that are, I think, unresolved parts of CWG or DT deliberations. If these are to remain in the text for public comment, I suggest setting them off in a box (or something -- marginal note? whatever) as stuff left explicitly open for the review process.
Some of the more important annexes only really came available quite recently, and I barely had a chance to glance at some of them before our calls this week. Therefore in some cases this is my first serious look at them, so some of the annexes come in for more detailed comments than others in what follows. My silence on text should be taken to mean that I didn't see anything to comment on in this reading; I read it all pretty carefully (but I've doubtless missed things).
As a small but important issue, several of the section numbers in the document are wrong. I am pretty sure, given the way it shows up, that this is due to the vagaries of contemporary word-processor (yes,
"Word") section numbering. This is merely irritating to those already familiar with the developing text; but it's going to be awful during public comment, so it needs to get sorted before posting.
On a personal note, I'll have really limited time to devote to more iterations of the draft (and probably many of the CWG meetings) for roughly a month, due to other commitments. I'll work to keep up with things via the list.
BIG ISSUES
1. Section III.A has a serious ambiguity that has persisted through our discussions. I offer in the detailed remarks some ways to fix this, but not text, because it still seems to me conceptually troublesome.
2. Some places reach beyond the names community and implicate other communities. I make some suggestions in the detailed remarks about how to avoid these cases when I catch them (and it's appropriate).
3. Annex M item 2 actually appears to me to be a repudiation of NTIA's offer. See the detailed remarks.
Every one of these strikes me as a fatal flaw to the text as it stands, though I think each can be repaired. I do not believe the proposal should go out for comment at all with any of them unresolved.
DETAILED REMARKS
I.D, p. 6: I think "extensions, could designate parts…" would be better here. That is, if the IETF did this, it would be a failure.
If the IETF did this in name space already delegated by IANA, it would be a mistake by IETF. Similarly, if ICANN delegated something that was marked as special by the IETF, that would be a mistake by ICANN.
Co-ordination is of course important and we should call this out, but "may" suggests that normal operation could make this happen, and my point is that it had better never happen.
II.A.ii, p7 : Why the change to the description of Jon Postel's role?
This reads like rewritten history — I’ve never heard him called “the then head” or anything of the kind. This reads as though there was a well-defined IANA function that was apart from the individuals carrying it out. I've never read anywhere else people saying that. I don't think we should try to sanitize the early history to make it seem more orderly than it was.
II.A.ii, p7: "This document was not meant to be a policy document"
This language, previously fixed, has returned. It’s flat out false.
RFC 1591 was a policy document, it reads as one, and we should not claim it wasn’t (much less should impute intentions to someone who isn't alive any more to be asked about them). Indeed, Annex A (item c) lists 1591 as one of the policy documents! Also, to my knowledge there was never an attempt to revise 1591 (which would involve publishing a new RFC). Perhaps "supersede"?
II.B.i, p13 (probably broken numbering). "Root Zone file or database are affected". I don't know why adding the word "file" here helps -- it just serves to obscure meaning. I urge whoever has the pen at this point to resist the temptation to add detailed clarifications of this sort at such a late stage. In this particular case, it serves to confuse, because it suggests that there is some in-principle difference between the root zone database and the STD 13 presentation-format zone file. If there _is_ such a difference, we have an enormous problem. If there's not, then this sort of clarification adds nothing, and it should be reverted.
III.A p 17: "ICANN to continue as IANA Functions Operator for the Naming Related Services through the creation of a Post-Transition IANA (PTI)" cWe seem unable to decide clearly whether we're talking about a different organization or an internal department, but the current formulation is plainly wrong.
• The first recommendation should be that ICANN hive off its IANA operations to the PTI. That's _all_ IANA functions, for everything that ICANN currently does as IANA operator (names, number resources, protocol parameters). Either this is an internal department with rules around it from the fundamental bylaws, or else it's an affiliate of some kind; but all the IANA functions ICANN is doing move together.
• The second is the agreement between PTI and ICANN for the
service-level rules for IANA names functions. Either the rules are a contract or else they're fundamental bylaws. (In the second case, it's funny to call this an "agreement".)
Unstated in the above is that, depending on whether we have fundamental bylaws or an affiliate, there are either one or two options for other communities. ICANN can be indifferent to how to proceed on this, but the other communities may need to make a
decision:
• Continue the agreement with ICANN, who then undertake to have PTI do the work for those other communities. This is the only option available if PTI is a department of ICANN under some fundamental bylaw(s), but it remains available in case PTI is an affiliate.
• Undertake a new agreement with PTI, if PTI is a separate organisation.
III.A.vii nr. 4 p 23 (note: numbering is wrong. More magic section renumbering, I suspect) Couldn't this recommendation be that, at least at the time of transition, the principle holds? AFAIK nobody is suggesting changing this separation of roles now, and it could get changed in the future anyway by some policy change, so we don't have to pretend we're writing in concrete. (This remark also applies to the related bit in Annex M.)
Annex A.a, p31. I am unaware of any mechanism by which the IETF standardisation process would today result in an actual entry in the root zone. If it did, I think that would be _prima facie_ evidence that the special names entry was not a special name at all, but rather an entry in the root zone that should be processed through usual channels. In fact, were such an entry to occur I think there would be more than 20 of us lined up to try out elements of the IETF recall process. What _is_ true is that the IETF can standardise a name (or in principle, even, a label in every domain) such that it is excluded from the root namespace and therefore prohibited from appearing in any version of the root zone. How about this:
Policy for entries in the root zone are determined by ICANN policy
setting mechanisms (e.g. for ccTLDs and gTLDs). The IETF
standardisation process can create reservations from the global name
space so that certain names that otherwise would be valid in the DNS
root are disallowed.
Annex A.c and A.d, p32. There is no provision in RFC 6761 to alter the whois for names added to the special names registry. I don't believe there is any overlap at all here.
Annex A.e, p33. I think the overlap description here is wrong. I'd state it this way:
Historically, some policy for INT (that of international databases for
infrastructure use) was determined by the IETF. RFC 3172 recommended
that such uses move under ARPA, and the only then-extant use of INT
for such infrastructure (the IPv6 reverse mapping tree) was in fact
moved under ARPA; all subsequent IETF infrastructure uses have
been under ARPA. It is possible for an international treaty
organization to put infrastructure entries under INT, but such
entries would be in keeping with INT being used by international
treaty organizations. IETF maintains a registry of special-use domain names
according to rules in RFC 6761, and it could in principle create a
conflict with .INT eligibility policy.
Annex A.f, p33. Isn't a dependency here the IETF's creation of algorithm numbers for key types? (I don't care, but elsewhere there are overlaps that note the dependency on protocols or number resources, so this would be another such case.)
Annex D, p41. There's a question at the bottom of this page. If it's to remain in the final document, maybe it should be boxed off as a particular question for the community during public comment?
Otherwise, it looks like hangover from the drafting, or else a
needless rhetorical question for what follows. (BTW, earlier on
p41, "While the Periodic Review will normally be scheduled based on a regular 5 year rotation with other ICANN reviews. A Special Periodic Review may be also be initiated by community action:" should either be turned into a single sentence, or the "While" at the beginning should
go.)
In Annex D, p42, there's this:
• The relative performance of the IANA Functions pre- and
post-transition according to established service levels
Surely that's a one-time consideration? That is, I'd expect to see that in year 2 but not in year 7. I anyway don't see why it's not subsumed under bullet 1.
I observe that the review team composition is volunteering the IETF and RIRs to provide free work on this review team. Has anyone asked them whether they'd be willing to participate? Maybe these could be noted as "pending agreement" or something in the table? I'm particularly uneasy about it given the detailed appointment rules that follow. Historically, the IETF at least has been pretty sensitive to not appointing people to anything according to the receiving organisation's rules, and if these criteria persist then I suspect the IETF would bridle. (It occurs to me that other groups might react similarly. If they're making appointments as representatives, then the central procedure doesn't get to specify criteria, I suspect.)
On p 46, there is both the claim that the cross-community working group approach was "used successfully" in preparing this document, and that the PRT is going to take six months including the two 40 day public comments. Assuming a 30 day month, that leaves 100 days (including weekends) for the PRT to do its work, including whatever integration of public comment materials needs to be done, all the reading of the voluminous materials outlined elsewhere in the annex, and so on. I apologise for saying something perhaps indelicate; but, while I can perhaps believe nine months, I cannot believe six, given what I've seen of this CWG and other ICANN groups working on things.
That's not a criticism -- working in public takes time (IETF working groups are appallingly bad at meeting their milestones too. And have you ever seen a software development schedule? Please). At the same time, I note that the very next section in the annex actually lists three public comment periods, though I guess the first one can happen in parallel to appointment of the PRT.
In the dependencies section p47 there are some questions. Are these questions for the pubic? See the "box" suggestion earlier.
It's kind of strange that there's a list of periodic reviews on pp47-8 that doesn't name the PRT itself.
Annex E appears to be an attempt to specify the succession of an operator for all IANA functions, and not the names ones. That's probably unwise. I'd remove at least the stuff in step 2 on page 50 about non-names stuff, and replace it all with a sentence, "Other data held by IANA may also need to transition, and other communities will be affected. The details of those transitions are beyond the scope of this proposal, which relates to names only." Or something like that.
At the end (p 52) there are some outstanding questions. See earlier about boxing off. Note that there's considerably more than just "the website" involved in control over the domain name.
In Annex I (p 66) there is a requirement for an expression of interest statement from everyone including appointed liaisons. See a similar discussion in annex D: I think that the liaison-sending organization gets to send its own choice, and there's nothing the target organization can do. Put this another way: suppose that the IAB was asked to send such a liaison, and the appointed candidate refused to supply the requisite form. What would the CSC be able to do? Refuse the appointment? There are additional elements to the selection process that seem similarly problematic.
Annex J makes changes to an existing resolution process for all IANA users. I think this is _way_ beyond the remit of this CWG. I can say with a great deal of certainty that the protocol parameters community has an escalation procedure that is already working for it just fine.
I suggest _very strongly_ that phase 2 of this section be revised to limit it clearly to names issues only.
In Annex M, item 1.a: why is the "act as approver" approach a "very short term" solution? It seems like this is over-specifying.
Item 2.a, p78, put more frankly, says, "The access that the NTIA used to provide to expertise actually can -- 'surely'! -- be provided by other means, but anyway we think that someone needs to be Boss of Big Changes, but we don't know who and we don't really have a reason why."
I hope it is clear why I think that's a lousy recommendation. The NTIA says that it wants to move this function to the multi-stakeholder community because it believes that the multi-stakeholder community is grown up enough now to do this itself. This item says, in effect, that we disagree. Do we really want to say that?
Item 3.a, p79, suggests earlier publication of decisions. I'm not opposed to this, but I don't see what difference it makes either. If the decision is already made, earlier public knowledge makes no difference. If the decision is _not_ already made, then this sounds like the thin end of a wedge to make these kinds of changes -- whether they be renumbering a name server or redelegation of a domain -- subject to some sort of public comment or review period. These activities are mostly operational and involve two or three actors (today, plus NTIA, but they're officially not doing anything but stamping the change). I'm quite uncomfortable with the implications here, and I think the section should make it clear that this is a sunlight provision but not an opportunity for wider consultation. I think ii is considerably less problematic than i in this regard.
--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship
More information about the CWG-Stewardship
mailing list