[CWG-Stewardship] RZERC Charter for CWG review

Alan Greenberg alan.greenberg at mcgill.ca
Wed May 11 00:39:59 UTC 2016


At 10/05/2016 06:48 PM, Andrew Sullivan wrote:
>On Mon, May 09, 2016 at 05:12:58PM +0000, Mueller, Milton L wrote:
> >
> > The CWG represented only the names community, its proposal 
> emerged out of the names community, and it only had authority to 
> make proposals relevant to the names community. If you are talking 
> about RZERC you are talking about names-related changes.
> >
>
>I think Milton is quite correct.  Bluntly, if _today_ the NTIA decided
>to tell ICANN not to do something that the IETF specified under
>ICANN's IANA agreement, I am quite sure that the IETF would use the
>same 6 month notice period it would use after the transition.

I have no doubt about that, and I would support it.

But that is not the question on the table as I understand it. It is 
purely about how that new function is carried out and not IF to carry 
it out. It might require minimal operational changes and this is a 
non-issue. Or it might require substantial software development or 
have major security issues that needed to be considered.

My understanding of the overall issue is the following:

- Currently the NTIA passes judgement on pretty much every decision 
that IANA makes related to the RZ and all of its operational 
procedures (including those related to the non-names communities).

- The transition was required to specify how the NTIA would be 
replaced post-transition. The critical day-to-day issue was of course 
approval of changes to the RZ, but also operational changes and the 
systems they use.

- DT-F was charged with considering this, and the outcome was that 
day-to-day decision would be handled internal to the IANA group and 
that substantive changes to the RZ Architecture would need to jump 
through extra hoops to ensure that all aspects were considered before 
making changes. Additionally, significant operational changes (with 
an eye to major systems and/or automation changes) would similarly 
need to have such external review. In my mind, presuming the other 
operational communities did not invent their own replacement of the 
NTIA authorization function, this group would address issues related 
to them as well.

- The Group now called the RZERC (regardless of whether that is an 
appropriate name or not) was designated as the wise people to perform 
or oversee the review, and the ICANN Board was identified as the 
entity to give the "official" blessing. That blessing is effectively 
a rubber stamp unless there is reason to suspect the RZERC has not 
properly done its job.


If this group and the ICANN Board are not responsible for overseeing 
operation changes related to the non-names registries, there are 
several options that I can think of. Perhaps there are more.

1. IANA (PTI in this incarnation) is left to its own devices and they 
can take whatever operational actions they want with no external 
approval. They could of course consult the RZERC if they chose, but 
are under no obligation to do so. Whether this is acceptable to the 
NTIA, I have no idea.

2. Each of the other communities could set up their own consultative 
group and authorizer (which could be the group itself). IANA would 
involve RZERC if the issue is names related, the new group(s) if the 
issue relates to other registries, or both (or all three) if applicable.

3. The other communities could use the RZERC (to not re-invent the 
wise-people-group) and it would forward its recommendation to the 
numbers/parameters-designated approver.

I have no particular stake in which path is chosen, although I have a 
long enough history in systems design and operation that my 
preference is not option 1. We are talking about things that can 
break the Internet if not done properly, and I no matter how good the 
folks in IANA are, I think that major changes in process or systems 
should be vetted by a group that has a very strong cross-area 
perspective and can give such plans an unbiased and fresh review.

2 seems overkill based on the number of times this group is likely to 
be invoked and the likely overlap among the groups.

Alan




More information about the CWG-Stewardship mailing list