[CWG-Stewardship] RZERC Charter for CWG review

[Mueller, Milton L]

Alan
We seem to be talking past each other. 

Andrew and I are just saying that the proposed RZERC is about the names root. If you look at the original charter for DT-F it was explicitly about the relationship between ICANN, IANA and the RZM - nothing more. RZERC can and will include people from protocols and numbers if you like, but its remit is major architectural changes in the names root. So the RZERC will ensure that the PTI, RZM and Root server operators don't do anything that "breaks the Internet" or messes up the other IFOs.  

If the IFOs for numbers and protocols do something that "breaks the Internet" then the numbers and protocols communities have all the authority they need to fire their IFO or, what is more likely, they have the oversight and credible threat to prevent that from happening in the first place. 

I don't see what else needs to be done.

> -----Original Message-----
> 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
>