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

[Gomes, Chuck]

Andrew,

I want to thank you for the extensive and constructive efforts you have contributed to the CWG.  They have been very valuable.

Because I was one who strongly supported improved SLEs at transition, I want to communicate that I am comfortable with your " suggested text about SLEs at ¶133".  In my comments submitted on Friday to v.3 of the proposal I expressed some concern about the softest of the word 'can' and would like to see a stronger commitment to improving the SLEs after transition but I accept the approach of deferring changes until after the transition.

Regarding your comments on the diagram in Annex D I have to confess that I do not understand your point regarding the number of customers.  Who would the fourth customer be if we changed 'three' to 'four"?  Would your concern be resolved if we didn't use the word 'customer'?

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Sunday, June 07, 2015 12:13 AM
To: cwg-stewardship at icann.org
Subject: Re: [CWG-Stewardship] Transition Proposal v.3 -- Edits due on Sunday at 23:59 UTC

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
_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship