[CWG-Stewardship] Some comments on CWG v2

Avri Doria avri at acm.org
Thu Jun 4 05:28:23 UTC 2015 

Hi,

Some comments.

Overall reads fairly well, though the font changes can be distracting.

- Last sentence of para 96 - seems to just end.  At the very least it
needs punctuation, but I think perhaps a bit more. 

- Why is 96 all italics?

- in Para 102, it might be worth explaining what the public comment
tools does.

- in Para 104, bullet 3, do we still have an issue on whether the CSC is
part of ICANN or independent?  I notice that the footnote referring to
CSC still says 'could'

- In Para 107, does everyone know what "ring fence" means?  While it may
have become a bingo word in this crowd, I am not sure that everyone will
understand it.

- in 108,
> an “affiliate” of ICANN if PTI is a California public benefit
> corporation without owners. 

      is the 'if PTI', superfluous at this point?


- in 117, I had requested that words 'or evaluations' be removed since
evaluation of the implementation of policies should be in order for the IFR.

- in 118   it discusses 'every 5 years'.  I thought we had developed a
wording earlier to the effect of 'no less that every 5 years' so that
the periodicity could be changed if warranted. This also give some
response to those who asked for it more frequently.  I believe one of
the CCWG issues is the need for flexibility to arrange a reasonable
schedule for the multiplicity of reviews.  If changed this would need to
be reflected in 119 and appendix F as well.

- in 119  should probably also mention that the IFR clock restarts after
a SIFR.  One thought, would we want to require the same two stage cycle
after an SIFR we have at transition (and especially after a SCWG) of
first a 2 year review and then back to the 5 year cycle?

- in 123 how about something like:

Following the triggers defined above, the naming Support Organizations
would be responsible for reviewing the  outcome of the CSC process (as
defined in annex G), and the IANA Problem Resolution Process (as defined
in Annex J) and for determining whether an Special IFR was necessary.
After consideration, including a comment period, the Special IFR could
be triggered by a supermajority vote of each of the ccNSO and GNSO
Councils according to their normal procedures for determining
supermajority. The Special IFR would follow the same multistakeholder
cross community composition and process structure as the periodic IANA
Function Review. ....

(note, I only did this because the action item said "paragraph 123 (note
action item for Avri)" Being of weak memory I looked at 123 trying to
figure out what I was supposed to change.  It was only after making a
change and reading on that I realized it was 125 I was supposed to work
on.  Having reworked this text, I am submitting it for consideration. We
did talk about this and there was concern that the gNSO and ccNSO did
not include enough of the multistakeholder community among their
membership.  While I argue that this may or may not be the case, it
seemed reasonable to require a comment period.)

- in 125 (my action item)  how about something like:

An IFR may determine that Separation process is necessary. In making
this determination, the IFR is not responsible for recommending a type
of separation. If the IFR determines that a Separation Process is
necessary, it will recommend the creation of the Separation
Cross-Community Working Group (SCWG). This recommendation would need to
be approved by a supermajority of each of the GNSO and the ccNSO
Councils, according to their normal procedures for determining
supermajority, and would need to be approved by the ICANN Board after a
public comment period. A determination by the ICANN Board to not approve
a SCWG that had been supported by a supermajority of the ccNSO and GNSO
Councils would need to follow the same supermajority thresholds and
consultation procedures as ICANN Board rejection of a PDP recommendation
that is supported by a GNSO supermajority.

And then change 144 to deal with the issue, something like:

There would be no prescribed action for the Separation Process.  It
would be empowered to make a recommendation ranging from “no action
required” to the initiation of an RFP and the recommendation for a new
IFO. It could also determine that a different form of reorganization of
the IANA function was necessary, such as divestiture of the PTI.  In the
case of a recommendation for any action, ICANN is expected to cover all
costs related to the costs of transition and ongoing operation costs
related to the possible selection of a new operator or other change.
Moreover, in bearing such costs, it is to be required of ICANN that it
does not raise costs for operators (and indirectly for registrants) in
order to do so.

this would also require a modification to L, which is discussed below.

- going back to 143 last sentence:  in order to disambiguate, how about
something like:

Both the recommendation to initiate the Separation Process and the
outcomes of a Separation Process would need to be approved by the ICANN
Board and would be subject to all escalations and appeals mechanisms.

- on Page 128 point ii) Includes a representative of the IETF on a
standing committee.  Have they given permission for this inclusion
considering the work it might take to carry out this obligation?

- in para 169 , have we decided to just leave .int status quo in
perpetuity? This is also reflect ina later appendix.

- 173 describes the CSC as multistakeholder.  Seems inappropriate.

- page 33 table.  In the first row, do only 53 % support legal
separation? only 53 support creating a PTI?  or only 53% support PTI
being an public benefit affiliate?  these table are repeated in an
appendix with the same ambiguity about what the number mean.

- page 35 indicates the PTI budget is ready for implementation.  Is this
actually the case?  I had not gathered that from our meetings.

- page 36  - the following sentence is confusing.  What are we leaving
to the ICG?

> At this stage, considering possible interest and modifications
> pending from the other operational communities,
> the CWG-Stewardship leaves it to the ICG to determine establishing PTI.


- page 37 again indicates that the CSC is a multistakeholder entity.  I
think this is inappropriate.  If we are going to be bold enough to
create something that is intentionally not multistakeholder we should be
straightforward about it and our reasons for ignoring the mandate for a
fully multistakeholder solution.

- page 42 indicates that  a list of members and particpants can be found
on the wiki page.  Might be worth listing the url.

- 44 meting should be meeting

- 43/44  While it is a very good description of the design team process
it does not include the process by which we moved from the Contract Co.
to the PTI.  Does not include the discussion in Istanbul of multiple
configurations being whittled down to two and then later to one.  Might
be worth including something on this since the first recommendation made
such a hit with the world.  And it might be worth descriing that
journey.  I know this section is incomplete. But with one day left, I
figure I would mention it.

- page 47  Should 3a mention the pending Framework of Interpretation.

- page 48. re 5. should the possiblity of post transition work on .int
be mentioned?

- 253  says "a Special Review may be also be initiated by community action."

     should it be a Special IANA function Review may also be ...


- page 62, table.  Why did we change 1 RySG and 1 gTLD Registry to 3
RySG?  the extra seat in for the RySG was only for the SCWG and not for
the IFR.  The decision in the IFR was to give the ccNSO an extra seat,
not the RySG.

Also I thought we want to allow for a non GNSO Registry to have a
possible seat.  If this is added, then we do need a paragraph similar to
273 saying that the RySG gets to do the picking after consultation with
existing gTLD groupings from outside the RySG.

- 275 should mention the acronym IFRT after the use of IANA Function
Review Team so that the first instance of IFRT in 277 is understood.

- 285 last sentence should be changed to:

  Subsequent reviews will be scheduled to commence
 at five year intervals from the date of the
  previous  IANA Function Review.


- 332 If the CSC is part of the ICANN, why is the IFO providing the
secretariat?  I thought that when this was discussed we had moved away
from a IFO secretariat. Perhaps I misunderstood.

- 369.  I thought this was where the rySG got its 3rd seat based on the
compromise concerning geographic distribution. 


- 372  Contains bracketed text.  While a compromise concerning geo
distribution was agreed in the CWG plenary meeting, it was rejected in
the DT.  This needs to be resolved.

- 374  similar to changes in 125/144 we should add a first bullet to 374
that says: Decide on the remedy needed to resolve the issue(s) which
caused initiation of the SCWG.

The other bullets should then be condition on decing to do an RFP.  For
example, something like:

  * ›Decide on the remedy needed to resolve the issue(s) which caused
    initiation of the SCWG.

  * If the decison is to do an RPF
      o  Developing RFP Guidelines and Requirements for the performance
        of the IANA Naming Functions;
      o ›  Soliciting participation in the RFP Process;
      o ›  Reviewing responses to the RFP
      o ›  Selecting the entity that will perform the IANA Naming
        Functions; and
      o ›  Managing any other Separation Process.

  * If a different process such as PTI divestiture is to be recommended,
    develop recommendations for  that process.



- 378  First sentence: Replace 'Special IFR could be triggered' with
'SCWG could be initiated'

- 378  Remove Bullet one, it is redundant of the last bullet : 

- 378  in last bullet: Replace 'Creation of' with 'Approval by'

- page 87 Appendix M  - Does this need a mention of the escrow fund
being proposed for IANA continuity?

Will review terms sheet at some other point.  I did notice that it has a
lot of unresolved comments.

That is about it for this pass.

avri


















---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

More information about the CWG-Stewardship mailing list