[CWG-Stewardship] For your review - Draft Transition Plan V3.2

[Andrew Sullivan]

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