[CWG-Stewardship] Transition Proposal v.3 -- Edits due on Sunday at 23:59 UTC

[Andrew Sullivan]

Hi,

On Fri, Jun 05, 2015 at 04:07:05AM +0000, Grace Abuhamad wrote:
> 
> Attached is the updated proposal. This version includes the edits listed
> below. Your comments are requested and welcome until Sunday 23:59 UTC.

I've read the last version.  Thanks to the staff and all the
contributors for all the work.  I think this is pretty close to ready to
ship.

I have a few little comments.  They're below.  I should note that I've
been reading given what I take to be the views of the CWG (so there
may well be parts of the document that I don't agree with, but that I
nevertheless think should be in the document because I think it
reflects the view of the group.  I remain somewhat worried about a
tendency to try to do too much, and a little nervous about what PTI
means for the overall IANA system, but I think we've already explored
that pretty well).

I am (pleasantly) surprised at the inclusion of my suggested text
about SLEs at ¶133.  I expect this is controversial given the
discussion on the list (my impression is that many more people would
like to make the changes immediately).  I didn't see any responses to
that suggestion on the list, so I want to make sure people are ok with
it.  As I've argued before, I think this is the most prudent approach,
and I think giving 6 months gets us the improvements in a timely way
while yet reducing the number of things that have to get done at the
time of transition.

Given ¶133, ¶199's "Service Levels" bullet could be altered slightly
to say, "Because the current recommendation is to maintain the
existing SLAs as SLEs at the time of transition, there is no time
necessary to implement this.  The proposal requires new SLEs at the
end of six months, and it is anticipated that the work for
implementation should be included in staff time estimates over that
period.  More generally on this section, the comment I sent last week
still seems to me to be true: a few of these tasks are pretty close to
things that either ICANN or others have already done, and it'd be
really good to get some concrete estimates of how long tasks will
take.  That's what the ICG asked for.  (If I actually knew how to make
those estimates, I would offer text.  But I think these things are
mostly outside my own experience.)

On the diagram in Annex D, there are three customers of PTI.  This is
a little unfortunate, since three is sort of a magic number in this
discussion and it is not at all clear that the other communities are
going to deal directly with PTI.  This could be easily solved by
changing the number of customers to some number other than three (I
suggest four, so that it's clear).  I do note that every other
collection of people on the diagram is also three, so I suspect this
is just a standard design trope.  But I think it is slightly
problematic here.

The purpose of ¶341 (Annex G) is not totally obvious to me (I probably
don't understand the intricacies of the organizations in ICANN), but
it looks slightly problematic because it appears that it would allow
the ccNSO or GNSO (or both) to control access of various TLDs
(including gov, edu, mil, arpa, and int) to the CSC.  That could be
controversial.  Maybe I'm just misreading it?  If so, perhaps a
clarifying sentence along the following lines: "This provision is
intended to ensure orderly formal arrangements, and is not intended to
imply those other registries are subordinate to either the ccNSO or
the GNSO."  Also, there's a mistake in this ¶ -- "either…and".

In ¶406 (Annex L), I think the removal of "naming" has indeed expanded
the scope.  I think I'd restore it.  I realise now I've also always
been uncomfortable with the "currently" in the text, since of course
PTI doesn't actually exist yet.  How about this:

    The entity prevailing in the RFP would carry out the role
    currently performed by PTI for the IANA naming Functions. ICANN
    would remain the contracting party for the performance of the IANA
    naming Functions and would enter into a contract, including a
    statement of work, with this entity. If PTI is selected to
    continue performance of the IANA Functions, it would remain an
    affiliate of ICANN (unless a structural change was a condition of
    the bid proposal or of the selection). Otherwise, the new entity
    would be a subcontractor for the performance of the IANA
    Functions.  It should be noted that this does not address the way
    that non-naming IANA functions would be provided; depending on the
    arrangements with other communities, it is possible that those
    functions would move in concert with the naming functions; it is
    equally possible that they would not.

I note that this suggests a tension with the first principle in Annex
M (it's the "integrity" claim there that is problematic.)  Many people
(in all communities) are trying to avoid talking about these
separation cases, however, so maybe we can just whistle a tune and
look the other way.

In Annex S, the preamble/disclaimer should probably get another
sentence: "Because it is a sample, this term sheet may not be fully
consistent with the body of the proposal.  The reader should not treat
such inconsistencies as significant; the rest of the proposal should
be regarded as the authoritative version."  Or something like this.

I hope these comments are useful.  I appreciate the work everyone's
done on this.  I will certainly not make Tuesday's call, because I
have an all-day dayjob meeting.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com