Re: [CWG-Stewardship] RZERC Charter for CWG review
Milton, you raise an interesting issue, although perhaps not the one you thought you were raising. It is one we missed during the initial review of this charter. Among other things, the name of the group is incorrect. Although it is responsible for overseeing the architecture of the Root Zone, it is also responsible for significant operational changes in regard to all IANA functions (something that was omitted from earlier versions of the charter, which also led to the incorrect name). This is in line with the NTIA approval function it partially replaces (lesser changes no longer needing approval at all) and with the CWG report. IANA Functions Evolution Review Committee is probably a more apt name, even though it is a weak-sounding acronym - IFERC. You are correct regarding the RZM, although I think the generic conflict statement covers the issue, given that the people on the group are not likely to be overwhelmed by the RZM delegate. Alan At 08/05/2016 11:37 AM, Mueller, Milton L wrote:
Two important observations I would make:
1. It is clear that whoever drafted the RZERC charter has reverted to the legacy mindset of a single IANA Functions Operator for names, numbers and protocols. The composition of the group, for example, does not distinguish between the IFO for names and the IFO for protocols and numbers. Let me remind everyone that the Root Zone (RZ) that ICANN will contract for management of and which this RZERC will consider is a NAMES function only. Therefore it is unclear to me why ASO is included on this body and the management of numbers ârootâ has very little if any connection to the architecture and operation of the RZM.
2. Another issue that seems to be overlooked is that going forward, RZM will be a paid contractor of ICANN, therefore the incumbent RZM might be considered to have a conflict of interest in RZERC consultations with ICANN about the RZM contract terms and conditions. On the other hand, we certainly do want the incumbent RZM to be a part of this committee because of the operational knowledge it would bring to bear. So their role should be circumscribed appropriately; e.g., the incumbent RZM contractor should not chair the committee and any definition of âconsensusâ should not allow an incumbent RZM to block recommendations pertaining to its own role or contract.
A not-so important but funny observation: Seunâs modifications referred to âexpenses incurred in the curse of carrying out their servicesâ
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Sunday, May 8, 2016 2:14 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] RZERC Charter for CWG review
Dear all, Kindly find attached a document that contains my comments, and proposed edits. Regards
On Wed, May 4, 2016 at 12:17 AM, Seun Ojedeji <<mailto:seun.ojedeji@gmail.com>seun.ojedeji@gmail.com> wrote: Thanks, that's helpful (especially the funding part) Regards Sent from my LG G4 Kindly excuse brevity and typos On 3 May 2016 11:53 p.m., "Alan Greenberg" <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@mcgill.ca> wrote: At 03/05/2016 06:21 PM, Seun Ojedeji wrote:
Content-Type: multipart/alternative; boundary="047d7b67048f2cc5610531f78803" X-Microsoft-Exchange-Diagnostics:
1;SN1PR0301MB2030;9:yXSxQKq/XJtXcx74HQ6pcWbqx+b5hJebhZjStOfe2vcCaFJ13kuGboEAYxZedfvpfqoQkW2my/77y/UqGl8n/BZrde2MO+2rOPKk/tzSDPSclTyxHy+8MwGyIS5oWnPtJXGBJ+eJUMHEFVAZUN4McvB0XW/SRKMbIhIxtENblbs= Dear Co-Chairs/all, Looking at the acronym "RZERC" makes me feel I probably may have been lagging behind with happenings within the CWG. ;-) Just a few clarification question/comments: - What is RZERC(I assume it's an acronym) as the charter does not seem to include description.
It stands for the Root Zone Evolution Review Committee
- I did a quick find on the ICG proposal and don't see reference to "RZERC", what part of the ICG (to be specific CWG) proposal is this implementing?
The name is new. The committee is described in paragraph 155 of the CWG proposal. 1155 of the ICG proposal I think.
- I note that review of charter every 5 years is indicated, but there seem to be no room to modify the charter in situations requiring urgent need.
The 5 years is a mandatory review.
- There is no process of replacing members indicated.
There is similarly no process for formally naming them. It is up to the appointing body (they all come from somewhere specific).
- What part of the ICANN(or perhaps it's going to be applicable to PTI ) bylaw recognises the formation of the RZERC
ICANN. The RZERC advises the ICANN Board and can act as an advisor to other groups as necessary (such as IANA itself)
- Is the RZERC a new ICANN AC?
It is an advisory committee, but not an Advisory Committee in the sense of the ACs defined in the Bylaws. The Board has the responsibility of approving substantive changes in the RZ architecture and operation. The RZERC is a resource it uses to do the analysis.
- Who funds the activities of the RZERC?
To the extent that it needs funds, ICANN.
- Renumeration of the group is not explicitly indicated in the charter; is this a volunteer group or a paid group?
They are paid double what I am paid and tripple what you are paid.
- What will be the connection between RZERC and PTI board (since they will be more closer to IANA than ICANN board post-transition) since it seem this group reports/works with ICANN board?
No connection. The PTI Board oversees the physical operation of PTI. The ICANN Board, replacing NTIA, is responsible for RZ issues as per the previously mentioned section of the CWG/ICG reports. Alan
Regards Sent from my LG G4 Kindly excuse brevity and typos On 3 May 2016 6:20 p.m., "Lise Fuhr" <<mailto:Fuhr@etno.eu>Fuhr@etno.eu> wrote: Dear CWG,
Attached is the RZERC charter for your review. We would like to receive your comments at 17 May at the latest 23.59 utc (2 week review period). We furthermore plan to have a CWG call at the 12 may where the RZERC Charter will be discussed.
Best regards, Jonathan and Lise _______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Microsoft-Exchange-Diagnostics:
1;SN1PR0301MB2030;9:yXSxQKq/XJtXcx74HQ6pcWbqx+b5hJebhZjStOfe2vcCaFJ13kuGboEAYxZedfvpfqoQkW2my/77y/UqGl8n/BZrde2MO+2rOPKk/tzSDPSclTyxHy+8MwGyIS5oWnPtJXGBJ+eJUMHEFVAZUN4McvB0XW/SRKMbIhIxtENblbs= _______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: <http://www.fuoye.edu.ng>http://www.fuoye.edu.ng Mobile: +2348035233535 alt email:<http://goog_1872880453> <mailto:seun.ojedeji@fuoye.edu.ng>seun.ojedeji@fuoye.edu.ng Bringing another down does not take you up - think about your action!
On Sun, May 08, 2016 at 01:32:57PM -0400, Alan Greenberg wrote:
Although it is responsible for overseeing the architecture of the Root Zone, it is also responsible for significant operational changes in regard to all IANA functions
I'm not sure I agree. The justification for this committee is at ¶154 ff in the CWG proposal (https://community.icann.org/pages/viewpage.action?pageId=53779816), but the text is not perfectly clear. It recommends that "a replacement of this approval function be put in place for significant architectural and operational changes." The antecedent of "this" is apparently in the prior paragraph (153), which includes changes to the root zone "environment" (with DNSSEC as an example) "as well as many classes of changes to IANA Functions Operator processes (including what may be published)". That's the only example given, however, and it's hard to know what to make of this claim. I well recall the discussion about how DNSSEC was implemented. I'm having a hard time imagining the kind of operational change where, if an operational community wanted it, the Board would be in a position to say no. For the OC in question would surely terminate and take their IANA function elsewhere in that case, no? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
At 08/05/2016 02:15 PM, Andrew Sullivan wrote:
On Sun, May 08, 2016 at 01:32:57PM -0400, Alan Greenberg wrote:
Although it is responsible for overseeing the architecture of the Root Zone, it is also responsible for significant operational changes in regard to all IANA functions
I'm not sure I agree. The justification for this committee is at ¶154 ff in the CWG proposal (<https://community.icann.org/pages/viewpage.action?pageId=53779816>https://community.icann.org/pages/viewpage.action?pageId=53779816), but the text is not perfectly clear. It recommends that "a replacement of this approval function be put in place for significant architectural and operational changes." The antecedent of "this" is apparently in the prior paragraph (153), which includes changes to the root zone "environment" (with DNSSEC as an example) "as well as many classes of changes to IANA Functions Operator processes (including what may be published)". That's the only example given, however, and it's hard to know what to make of this claim.
I well recall the discussion about how DNSSEC was implemented. I'm having a hard time imagining the kind of operational change where, if an operational community wanted it, the Board would be in a position to say no. For the OC in question would surely terminate and take their IANA function elsewhere in that case, no?
Best regards,
A -- Andrew Sullivan <https://mm.icann.org/mailman/listinfo/cwg-stewardship>ajs at anvilwalrusden.com
I don't think it is issue of the Board saying no. The ICANN Board was put in that position because it was felt (within DT-F) that SOME entity had to have the Go/NoGo stamp, and the ICANN Board was as good or better than any other proposals at the time. The real issue is that whatever the proposal is, it has been vetted by people/groups that are the experts on the issue. Currently NTIA passes judgement on pretty much EVERYTHING that IANA does, including details of what is on a report. The new authorization function (committee + Board) was to replace that, but only for the more substantive issues. Alan
On Sun, May 08, 2016 at 02:34:50PM -0400, Alan Greenberg wrote:
Currently NTIA passes judgement on pretty much EVERYTHING that IANA does, including details of what is on a report.
Yes,
The new authorization function (committee + Board) was to replace that, but only for the more substantive issues.
I guess I can imagine that there would be a new kind of number resource, for instance, that got an IANA registry; and I can imagine this group perhaps having something to say about that. But fundamentally, are you suggesting that if the IETF published a standards-track RFC that said to IANA, "Create this new kind of registry," then the Board would be in a position to say, "No"? If so, then I think we have a very different idea of how IANA functions. A -- Andrew Sullivan ajs@anvilwalrusden.com
At 08/05/2016 07:09 PM, Andrew Sullivan wrote:
On Sun, May 08, 2016 at 02:34:50PM -0400, Alan Greenberg wrote:
Currently NTIA passes judgement on pretty much EVERYTHING that IANA does, including details of what is on a report.
Yes,
The new authorization function (committee + Board) was to replace that, but only for the more substantive issues.
I guess I can imagine that there would be a new kind of number resource, for instance, that got an IANA registry; and I can imagine this group perhaps having something to say about that. But fundamentally, are you suggesting that if the IETF published a standards-track RFC that said to IANA, "Create this new kind of registry," then the Board would be in a position to say, "No"? If so, then I think we have a very different idea of how IANA functions.
A
The existence of a new number resource would not be an issue that this group would look at - that is clearly an IETF issue. The plans on how to do it (it might require some complex systems, for instance, depending on how the new resource is distributed and to whom, or the level of security to be associated with access to the registry) would be the question. In the past, automation processes have been something that NTIA definitely was involved in. Alan
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg Currently NTIA passes judgement on pretty much EVERYTHING that IANA does, including details of what is on a report. The new authorization function (committee + Board) was to replace that, but only for the more substantive issues. MM: Again we seem to have fundamental differences in our conception of this committee. I never viewed it as a replacement for _all_ of NTIA's authority over IANA, and I don't think many of us did see it that way. The real "replacement" for NTIA's stewardship is threefold: in numbers, ir is the NRO, which contracts for the numbers functions; in protocols, it is the IETF, which contracts for protocols functions; and in names, it is basically the empowered community, which can take the names IANA functions away from ICANN if it jumps through six flaming hoops and wins a game of Twister. MM: We created the committee because someone said, "suppose there is a need to make a major change in RZ operations comparable to DNSSEC. Where does the authority to do that lie?" We discovered that, absent NTIA, there was no clear institutional locus for initiating or approving those kinds of changes. So we created this committee for that very limited purpose. It was never conceived as a replacement for ALL of NTIA's roles.
I have not sure that there was ever any intention for this committee to have an approval function. I thought it was a group of experts to provide input to possible technical and architectural changes to IANA functions. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Sunday, May 08, 2016 10:01 PM To: Alan Greenberg; Andrew Sullivan; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] RZERC Charter for CWG review From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg Currently NTIA passes judgement on pretty much EVERYTHING that IANA does, including details of what is on a report. The new authorization function (committee + Board) was to replace that, but only for the more substantive issues. MM: Again we seem to have fundamental differences in our conception of this committee. I never viewed it as a replacement for _all_ of NTIA's authority over IANA, and I don't think many of us did see it that way. The real "replacement" for NTIA's stewardship is threefold: in numbers, ir is the NRO, which contracts for the numbers functions; in protocols, it is the IETF, which contracts for protocols functions; and in names, it is basically the empowered community, which can take the names IANA functions away from ICANN if it jumps through six flaming hoops and wins a game of Twister. MM: We created the committee because someone said, "suppose there is a need to make a major change in RZ operations comparable to DNSSEC. Where does the authority to do that lie?" We discovered that, absent NTIA, there was no clear institutional locus for initiating or approving those kinds of changes. So we created this committee for that very limited purpose. It was never conceived as a replacement for ALL of NTIA's roles.
Good evening: Before we get too much involved with the details of RZERC, may I say that I am not convinced that we need another committee or a charter about the Root Zone atall. There are two significant issues in this context that were identified twenty years ago and remain germane: 1. It is no longer appropriate for Verisign to hold control over the primary root server. As long as we could rely on the benign common sense of NTIA, that anomaly has been accepted, but things have now changed. Should Verisign be asked to choose between holding the .com Registry and holding the primary root server, I have little doubt as to which way they would go. 2. The geographical distribution of the other Root Servers is no longer consistent with the contemporary topology of the Internet. Granted that the proliferation of mirror servers has alleviated some of the technical constraints. However, the gains from rebalancing the situation far outweigh any conceivable losses. Do something about this soon. These issues can be resolved within existing structures and competences. We do not need RZ*** to do so. CW On 08 May 2016, at 20:15, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Sun, May 08, 2016 at 01:32:57PM -0400, Alan Greenberg wrote:
Although it is responsible for overseeing the architecture of the Root Zone, it is also responsible for significant operational changes in regard to all IANA functions
I'm not sure I agree. The justification for this committee is at ¶154 ff in the CWG proposal (https://community.icann.org/pages/viewpage.action?pageId=53779816), but the text is not perfectly clear. It recommends that "a replacement of this approval function be put in place for significant architectural and operational changes." The antecedent of "this" is apparently in the prior paragraph (153), which includes changes to the root zone "environment" (with DNSSEC as an example) "as well as many classes of changes to IANA Functions Operator processes (including what may be published)". That's the only example given, however, and it's hard to know what to make of this claim.
I well recall the discussion about how DNSSEC was implemented. I'm having a hard time imagining the kind of operational change where, if an operational community wanted it, the Board would be in a position to say no. For the OC in question would surely terminate and take their IANA function elsewhere in that case, no?
Best regards,
A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, On Sun, May 08, 2016 at 08:46:22PM +0200, Christopher Wilkinson wrote:
Before we get too much involved with the details of RZERC, may I say that I am not convinced that we need another committee or a charter about the Root Zone atall.
You may say that, of course, but it doesn't matter whether we need such a committee. The CWG report definitely identifies it as something and asks that it be implemented. That's therefore what we need to implement. The time to argue about what ought to be implemented is over. Now is the time to implement the reports. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
-----Original Message----- 1. It is no longer appropriate for Verisign to hold control over the primary root server. As long as we could rely on the benign common sense of
Outside the scope of the CWG proposal. Talk to ICANN corporate about who they contract with.
2. The geographical distribution of the other Root Servers is no longer consistent with the contemporary topology of the Internet. Granted that the
Outside the scope of the CWG proposal. Suggest you gird up for WS2.
-----Original Message----- I well recall the discussion about how DNSSEC was implemented. I'm having a hard time imagining the kind of operational change where, if an operational community wanted it, the Board would be in a position to say no. For the OC in question would surely terminate and take their IANA function elsewhere in that case, no?
Andrew has hit the nail on the head. Any major reconfiguration of IANA functions outside of names would not be the responsibility of an ICANN/names community based committee. It would involve contractual agreements among three autonomous communities, of which names would be only one. ICANN and the names community DO need a committee like this to consider major operational changes in the management of the names root zone. Since the names root is one of the most demanding and high-stakes IANA functions, it is best to let this committee focus on that. And in fact, all of the references and examples we used when calling for the creation of this committee were based on NAMES. No one ever suggested that it would have the authority to reconfigure all the IANA functions. I am not even sure what such a configuration would consist of. Anything I can imagine would involve IETF-level changes in standards - not something we want ICANN involved in. I am deeply surprised that such a proposition can even be taken seriously at this stage of the game. Let's please amend the proposal to make it clear that this committee is all about names.
Best regards,
A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
participants (5)
-
Alan Greenberg -
Andrew Sullivan -
Christopher Wilkinson -
Gomes, Chuck -
Mueller, Milton L