- CWG-Stewardship - lists.icann.org

Re: [CWG-Stewardship] Principles - revised version 10 December
by kurt＠kjpritz.com Dec. 10, 2014

Dec. 10, 2014

1 0

Principles - revised version 10 December
by Martin Boyle Dec. 10, 2014

Dec. 10, 2014

Dear all, My apologies for the delay in circulating a new version of the principles text for our discussion tomorrow. As requested, I have tidied up the text. In doing so: 1. I have ignored comments more related to implementation and use of the principles. These are obviously important and need to be reflected through into the development of the proposal but are not in themselves principles. 2. I have made minor and what appear to be mainly uncontroversial edits (including removing the two legacy footnotes!). 3. There was a comment about the need to do an analysis of capture mechanisms associated with c.iv. I have tried to add wording, although I am not sure that the addition is needed as again it is more an issue of implementation based on the principles, rather than a principle per se. I'd welcome thoughts. 4. I have asked Kurt Pritz for proposed wording for gTLDs on contract requirements in g.ii. 5. There are three outstanding major issues. a. The text in f.ii and the policy authority text for ccTLDs: I have tried to correct the flow of the paragraph from the chapeau text. I have also highlighted the proposed addition to take care of GAC-members' concerns about third-party involvement in decisions affecting ccTLDs. Otherwise the text is substantially as agreed in Frankfurt. b. Two additions proposed by Avri - f.vi and i. - have been marked as deleted. Neither was supported and both had calls for deletion. c. There have been calls for deletion of the final paragraph in section h and no support for retention. I have marked it as deleted. I hope that this helps us identify a way forward to complete this document. Thanks Martin Boyle

1 0

Re: [CWG-Stewardship] Contract, Co. and the root zone publisher
by Alan Greenberg Dec. 10, 2014

Dec. 10, 2014

If we have no control over who performs the RXM function, we are not in control over the Cooperative agreement with the RZM. It is that Cooperative Agreement which presumably specifies who the RZM is to take instructions from and it is that CA (which we are not in control of but NTIA is) that must be altered to ensure that any new assignment of the IANA function is honoured. Alan At 09/12/2014 11:23 PM, Greg Shatan wrote: >Alan, > >Why do you say it is up to the NTIA? Our >charter says it's up to us. I don't believe >we're adding a new complexity. I think we are >recognizing that we overlooked an existing complexity that was on our plate. > >Greg > >Gregory S. Shatan Ã¯ Abelman Frayne & Schwab > >666 Third Avenue Ã¯ New York, NY 10017-5621 > >Direct 212-885-9253 | Main 212-949-9022 > >Fax 212-949-9190 | Cell 917-816-6428 > ><mailto:gsshatan@lawabel.com>gsshatan(a)lawabel.com > >ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc(a)gmail.com > >www.lawabel.com > >On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >We need to specify that for the IANA transition >to be effective, there must be a requirement >that the Root zone maintainer accept change >instructions from the assigned IANA functions >operator. It is up to NTIA to arrange its (or >perhaps our at some point) contract with the RZM >to make sure that this happens. Why add new >complexity to our already difficult task? > >Alan > > >At 09/12/2014 11:02 PM, Jordan Carter wrote: >>All >> >>I agree with Mathieu's basic concern but would basically put it like this: >> >>ContractCo has no teeth in assigning the IANA >>functions contract to anyone unless it can also >>direct the Root zone maintainer to accept >>change instructions from the assigned IANA functions operator. >> >>Without the ability to do both those things, >>then the first power is imaginary. >> >>For example, imagine if Contract Co had a >>contract with ICANN to perform the IANA >>functions, and ICANN as IANA functions operator had a contract with the RZM. >> >>If ContractCo issued the contract for IANA >>functions to a different entity, ICANN could still control the root. >> >>So it appears to me that we aren't solving >>post-NTIA problems if we aren't dealing with RZM as well as IANA functions. >> >>Interested in other views and perspectives on this. >> >>cheers, >>Jordan >> >> >>On 9 December 2014 at 03:48, Milton L Mueller >><<mailto:mueller@syr.edu>mueller(a)syr.edu> wrote: >>I agree with you Greg that this is in scope; >>you are also correct to point out that the NTIA >>language (ârelated and parallelâ) makes it >>rather ambiguous regarding our role relative to >>NTIAâs role in effecting this change. >> >>My take on it is that NTIA will actually take >>responsibility for modifying or ending the >>Verisign Cooperative Agreement once we have a >>complete proposal, but that our proposal really >>does need to be based on a clear understanding >>of what we want to happen to the RZM functions. >>This message should be more detailed but I donât have time for more now. >> >> >>From: Greg Shatan [ mailto:gregshatanipc@gmail.com] >>Sent: Monday, December 8, 2014 3:14 AM >>To: Milton L Mueller >>Cc: >><mailto:Mathieu.Weill@afnic.fr>Mathieu.Weill(a)afnic.fr; >><mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >>Subject: Re: [CWG-Stewardship] Contract, Co. and the root zone publisher >> >>I agree that this is another important reason >>for Contract Co. -- to contract with the RZM. >>However, I'm not sure I agree that issues >>relating to the Cooperative Agreement are part >>of a "Step 2" that is not within the scope of this CWG. >>The Q&A issued along with the NTIA's initial >>press release on the IANA transition said that >>there a "related and parallel" transition of >>the NTIA's responsibilities relating to the Verisign cooperative agreement. >> >><http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-r…>http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-r… >> >> >>A "parallel" transition seems inconsistent with >>a "Step 2" approach (which would be more of a "serial" transition). >>In our CWG's Charter, in the section entitled >>"Scope," there is the following paragraph (emphasis added): >>In respect of Function 2. (âPerform >>Administrative Functions Associated With Root >>Zone Managementâ), this process currently >>involves distinct roles performed by three >>different entities through two separate legal >>agreements: the Contractor as the IANA >>Functions Operator, NTIA as the Administrator, >>and VeriSign (âor any successor entity as >>designated by the U.S. Department of >>Commerceâ) as the Root Zone Maintainer. The >>accountability function currently performed by >>NTIA regarding the RZM role, as well as the >>discussion of the RZM management administrative >>interface currently used by NTIA are within the >>scope of the CWG. The issue of who performs the >>Root Zone Maintainer (RZM) role is not in scope >>for the CWG and should be dealt with in a >>subsequent effort as needed. Additionally, >>issues related to naming policy e.g. >>delegation, redelegation or revocation of >>ccTLDs, RAA related policy issues etc. are not within the scope of the CWG. >> >>If I read this correctly, "the accountability >>function ... regarding the RZM role" is within >>our scope. This means that our proposal does >>have to provide for a transition of the NTIA's >>role relating to the RZM function. It stands >>to reason that, if the NTIA is no longer in >>this role, that the NTIA should no longer be a >>party to the Cooperative Agreement, since the >>Cooperative Agreement is a key part of the >>NTIA's accountability function. This also >>seems to call for a "parallel" transition (like >>the NTIA Q&A) of the NTIA's responsibilities >>relating to the Verisign cooperative agreement to be included in our proposal. >>Perhaps someone from the drafting team can shed >>some light on the genesis and meaning of this >>paragraph in our Charter. The only reference I >>can find to this paragraph on the DT wiki is a >>line from the Call #3 Meeting Notes and Action Items: >>Language on Root Zone Maintaining process: >>re-focus on role of NTIA in Root Zone >>maintainer process. Action: Avri and Chuck to >>propose language to the group. Group aware of Chuckâs role and no objection. >> >>I think we need to get some real clarity on >>this point very soon, so that our Proposal does >>not fail to deal with part of our mandate. >>Greg >>Gregory S. Shatan Ã¯ Abelman Frayne & Schwab >>666 Third Avenue Ã¯ New York, NY 10017-5621 >>Direct <tel:212-885-9253>212-885-9253 | Main <tel:212-949-9022>212-949-9022 >>Fax <tel:212-949-9190>212-949-9190 | Cell <tel:917-816-6428>917-816-6428 >> >><mailto:gsshatan@lawabel.com>gsshatan(a)lawabel.com >>ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc(a)gmail.com >> >>www.lawabel.com >> >>On Sun, Dec 7, 2014 at 11:11 AM, Milton L >>Mueller <<mailto:mueller@syr.edu>mueller(a)syr.edu> wrote: >> >>Mathieu >>You are correct to suggest that the status of >>Verisign as RZM is still a bit of a loose end >>in the transition process. However, the >>scenario you propose isn't a problem with this >>plan; if it could happen under a new regime, >>too if we are not careful. There would be >>nothing preventing Verisign from refusing to >>implement IANA change requests from ICANN, for example. >>So this is not an argument against any >>particular plan, it is simply identifying a >>problem that the NTIA has to take care of after the transition. >>Currently, Verisign is bound to modify the root >>zone changes approved by the NTIA through a >>Cooperative Agreement with the Commerce >>Department. Ultimately, that agreement has to >>go away to complete the IANA transition. If >>Verisign continues to be the Root Zone File >>implementer, the cooperative agreement has to >>go away otherwise the NTIA will still be in >>control of the root. However, for practical >>reasons the NTIA has chosen to make that "step >>2" after they get an agreeable IANA transition >>plan. My guess is that once we have an >>acceptable plan, then the NTIA-Verisign >>cooperative agreement will be modified and the >>new IANA contractor will work out an agreement >>with whoever the RZF implementer turns out to be. >>This is another reason why we MUST have a >>Contract Co.!!!! How are you going to have >>authority over RZF change implementation >>without a legally binding, readily enforceable contract? >>One thing that may put your mind at ease: >>Verisign does not want to be in control of root >>zone file modifications. That would make it >>liable for antitrust challenges or make it >>subject to liability for other things that >>might happen related to RZF changes. It is a >>private, commercial company, and putting a >>private company in charge of a critical >>resource used by its competitors is not a >>position a company residing in a jurisdiction >>with strong antitrust laws wants to be in. The >>current arrangement makes Verisign the operator >>but someone else has the responsibility for the changes. >> > -----Original Message----- >> > From: >> <mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org >> [mailto:<mailto:cwg-stewardship->cwg-stewardship- >> > <mailto:bounces@icann.org>bounces(a)icann.org] On Behalf Of Mathieu Weill >> > Sent: Sunday, December 7, 2014 7:41 AM >> > To: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >> > Subject: [CWG-Stewardship] Contract, Co. and the root zone publisher >> > >> > Dear Colleagues, >> > >> > Having now read carefully the proposal document, I have a significant >> > concern to share with all Members and >> Participants. I feel like we are missing >> > an important part of the puzzle. >> > >> > I apologize for raising this concern so >> late, and I hope this concern will be >> > easily dismissed if I have missed something. >> > >> > Here is the scenario that raised my concern. >> > >> > The CWG suggests to create Contract, Co. as the contracting party for the >> > IANA contract in the future. Consider the >> scenario where Contract, Co., upon >> > instruction from the MRT after a fierce >> debate, contracts with someone else >> > than Icann, following an RFP. >> > >> > Consider now that, due to external >> considerations, the root zone publisher >> > (currently, Verisign) indicates that it does >> not intend accepting requests from >> > the new IANA operator. We would be facing a deadlock, threatening the >> > ability to maintain the root zone in a secure and stable manner. >> > >> > Am I missing something here ? Unless I am, I believe we would need to >> > expand our investigations to be able to address this scenario, by : >> > - analyzing the root zone publisher >> function, especially by what mechanisms >> > it is bound to publish IANA-approved changes to to the root zone. >> > - investigating options in our transition >> proposal, through which to ensure >> > that the root zone publisher remains committed to publish changes in the >> > root when, and only when, they are approved by the IANA Operator. >> > >> > Many thanks in advance for your replies >> regarding both the validity of this >> > scenario as well as potential ways to address that risk. >> > >> > -- >> > ***************************** >> > Mathieu WEILL >> > AFNIC - directeur gÃ©nÃ©ral >> > TÃ©l: 01 39 30 83 06 >> > <mailto:mathieu.weill@afnic.fr>mathieu.weill(a)afnic.fr >> > ***************************** >> > ATTENTION : L'Afnic a dÃ©mÃ©nagÃ© le 31 mars 2014 ! >> > Notre nouvelle adresse est : >> > Afnic - Immeuble Le Stephenson - 1, rue Stephenson - 78180 Montigny-le- >> > Bretonneux >> > >> > _______________________________________________ >> > CWG-Stewardship mailing list >> > <mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >> > https://mm.icann.org/mailman/listinfo/cwg-stewardship >>_______________________________________________ >>CWG-Stewardship mailing list >><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >>https://mm.icann.org/mailman/listinfo/cwg-stewardship >> >>_______________________________________________ >>CWG-Stewardship mailing list >><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >>https://mm.icann.org/mailman/listinfo/cwg-stewardship >> >> >> >> >>-- >>Jordan Carter >> >>Chief Executive >>InternetNZ >> >>04 495 2118 (office) | <tel:%2B64%2021%20442%20649>+64 21 442 649 (mob) >><mailto:jordan@internetnz.net.nz>jordan(a)internetnz.net.nz >>Skype: jordancarter >> >>To promote the Internet's benefits and uses, and protect its potential. >> >>_______________________________________________ >>CWG-Stewardship mailing list >><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >>https://mm.icann.org/mailman/listinfo/cwg-stewardship > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship >

5 5

CWG - Public Comment summary for Tuesday December 10th
by Bernard Turcotte Dec. 10, 2014

Dec. 10, 2014

All, 1 submission yesterday, Monday, December 9th from Richard Hill - A number of very specific wording suggestions for the proposal. Many relating to applicable laws, one saying the CWG recommends accepting the ITU recommendation regarding .int, some regarding intellectual property and closing with section C suggesting the addition of a few paragraphs noting that A PERSON is unsatisfied with the Charter of the CWG regarding participants because it is not truly open. B.

1 0

Proposed Agenda for Thursday 11 December call (11:00 UTC)
by Grace Abuhamad Dec. 10, 2014

Dec. 10, 2014

Dear all, Below is the proposed agenda for the Thursday 11 December call (11:00 UTC). With regard to Item #2, and related to the outreach and tracking that we have been doing for the Proposal (see Wiki here <https://community.icann.org/display/gnsocwgdtstwrdshp/Outreach+Tracking+CWG -Stewardship> ), there will be an opportunity on the call this week to report briefly on process outreach and engagement efforts of the Members to date. Primarily, the Chairs envision this to be done by the Members since Members have additional responsibilities of outreach and engagement with their communities. This reporting may give the group a sense and understanding of the efforts to date. Proposed Agenda -- Thursday 11 December call (11:00 UTC) 1. Welcome & Roll Call 2. Status Update 3. Outreach & Engagement Reporting from Members 4. Key Questions & Issues (identified during Webinars) 5. Processing of Public Comments 6. Work Plan Going Forward 7. Principles 8. Review of Action Items 9. AOB Best, Grace

3 2

Re: [CWG-Stewardship] Contract, Co. and the root zone publisher
by Alan Greenberg Dec. 10, 2014

Dec. 10, 2014

We need to specify that for the IANA transition to be effective, there must be a requirement that the Root zone maintainer accept change instructions from the assigned IANA functions operator. It is up to NTIA to arrange its (or perhaps our at some point) contract with the RZM to make sure that this happens. Why add new complexity to our already difficult task? Alan At 09/12/2014 11:02 PM, Jordan Carter wrote: >All > >I agree with Mathieu's basic concern but would basically put it like this: > >ContractCo has no teeth in assigning the IANA >functions contract to anyone unless it can also >direct the Root zone maintainer to accept change >instructions from the assigned IANA functions operator. > >Without the ability to do both those things, >then the first power is imaginary. > >For example, imagine if Contract Co had a >contract with ICANN to perform the IANA >functions, and ICANN as IANA functions operator had a contract with the RZM. > >If ContractCo issued the contract for IANA >functions to a different entity, ICANN could still control the root. > >So it appears to me that we aren't solving >post-NTIA problems if we aren't dealing with RZM as well as IANA functions. > >Interested in other views and perspectives on this. > >cheers, >Jordan > > >On 9 December 2014 at 03:48, Milton L Mueller ><<mailto:mueller@syr.edu>mueller(a)syr.edu> wrote: >I agree with you Greg that this is in scope; you >are also correct to point out that the NTIA >language (related and parallel) makes it >rather ambiguous regarding our role relative to >NTIAs role in effecting this change. > >My take on it is that NTIA will actually take >responsibility for modifying or ending the >Verisign Cooperative Agreement once we have a >complete proposal, but that our proposal really >does need to be based on a clear understanding >of what we want to happen to the RZM functions. >This message should be more detailed but I dont have time for more now. > > >From: Greg Shatan [mailto:gregshatanipc@gmail.com] >Sent: Monday, December 8, 2014 3:14 AM >To: Milton L Mueller >Cc: ><mailto:Mathieu.Weill@afnic.fr>Mathieu.Weill(a)afnic.fr; ><mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org >Subject: Re: [CWG-Stewardship] Contract, Co. and the root zone publisher > >I agree that this is another important reason >for Contract Co. -- to contract with the RZM. >However, I'm not sure I agree that issues >relating to the Cooperative Agreement are part >of a "Step 2" that is not within the scope of this CWG. >The Q&A issued along with the NTIA's initial >press release on the IANA transition said that >there a "related and parallel" transition of the >NTIA's responsibilities relating to the Verisign cooperative agreement. > ><http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-r…>http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-r… > >A "parallel" transition seems inconsistent with >a "Step 2" approach (which would be more of a "serial" transition). > >In our CWG's Charter, in the section entitled >"Scope," there is the following paragraph (emphasis added): >In respect of Function 2. (Perform >Administrative Functions Associated With Root >Zone Management), this process currently >involves distinct roles performed by three >different entities through two separate legal >agreements: the Contractor as the IANA Functions >Operator, NTIA as the Administrator, and >VeriSign (or any successor entity as designated >by the U.S. Department of Commerce) as the Root >Zone Maintainer. The accountability function >currently performed by NTIA regarding the RZM >role, as well as the discussion of the RZM >management administrative interface currently >used by NTIA are within the scope of the CWG. >The issue of who performs the Root Zone >Maintainer (RZM) role is not in scope for the >CWG and should be dealt with in a subsequent >effort as needed. Additionally, issues related >to naming policy e.g. delegation, redelegation >or revocation of ccTLDs, RAA related policy >issues etc. are not within the scope of the CWG. > >If I read this correctly, "the accountability >function ... regarding the RZM role" is within >our scope. This means that our proposal does >have to provide for a transition of the NTIA's >role relating to the RZM function. It stands to >reason that, if the NTIA is no longer in this >role, that the NTIA should no longer be a party >to the Cooperative Agreement, since the >Cooperative Agreement is a key part of the >NTIA's accountability function. This also seems >to call for a "parallel" transition (like the >NTIA Q&A) of the NTIA's responsibilities >relating to the Verisign cooperative agreement to be included in our proposal. >Perhaps someone from the drafting team can shed >some light on the genesis and meaning of this >paragraph in our Charter. The only reference I >can find to this paragraph on the DT wiki is a >line from the Call #3 Meeting Notes and Action Items: >Language on Root Zone Maintaining process: >re-focus on role of NTIA in Root Zone maintainer >process. Action: Avri and Chuck to propose >language to the group. Group aware of Chucks role and no objection. > >I think we need to get some real clarity on this >point very soon, so that our Proposal does not >fail to deal with part of our mandate. >Greg > >Gregory S. Shatan ï Abelman Frayne & Schwab >666 Third Avenue ï New York, NY 10017-5621 >Direct 212-885-9253 | Main 212-949-9022 >Fax 212-949-9190 | Cell 917-816-6428 > ><mailto:gsshatan@lawabel.com>gsshatan(a)lawabel.com >ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc(a)gmail.com > >www.lawabel.com > >On Sun, Dec 7, 2014 at 11:11 AM, Milton L >Mueller <<mailto:mueller@syr.edu>mueller(a)syr.edu> wrote: > >Mathieu >You are correct to suggest that the status of >Verisign as RZM is still a bit of a loose end in >the transition process. However, the scenario >you propose isn't a problem with this plan; if >it could happen under a new regime, too if we >are not careful. There would be nothing >preventing Verisign from refusing to implement >IANA change requests from ICANN, for example. >So this is not an argument against any >particular plan, it is simply identifying a >problem that the NTIA has to take care of after the transition. >Currently, Verisign is bound to modify the root >zone changes approved by the NTIA through a >Cooperative Agreement with the Commerce >Department. Ultimately, that agreement has to go >away to complete the IANA transition. If >Verisign continues to be the Root Zone File >implementer, the cooperative agreement has to go >away otherwise the NTIA will still be in control >of the root. However, for practical reasons the >NTIA has chosen to make that "step 2" after they >get an agreeable IANA transition plan. My guess >is that once we have an acceptable plan, then >the NTIA-Verisign cooperative agreement will be >modified and the new IANA contractor will work >out an agreement with whoever the RZF implementer turns out to be. >This is another reason why we MUST have a >Contract Co.!!!! How are you going to have >authority over RZF change implementation without >a legally binding, readily enforceable contract? >One thing that may put your mind at ease: >Verisign does not want to be in control of root >zone file modifications. That would make it >liable for antitrust challenges or make it >subject to liability for other things that might >happen related to RZF changes. It is a private, >commercial company, and putting a private >company in charge of a critical resource used by >its competitors is not a position a company >residing in a jurisdiction with strong antitrust >laws wants to be in. The current arrangement >makes Verisign the operator but someone else has >the responsibility for the changes. > > > -----Original Message----- > > From: > <mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces(a)icann.org > [mailto:<mailto:cwg-stewardship->cwg-stewardship- > > <mailto:bounces@icann.org>bounces(a)icann.org] On Behalf Of Mathieu Weill > > Sent: Sunday, December 7, 2014 7:41 AM > > To: <mailto:cwg-stewardship@icann.org>cwg-stewardship(a)icann.org > > Subject: [CWG-Stewardship] Contract, Co. and the root zone publisher > > > > Dear Colleagues, > > > > Having now read carefully the proposal document, I have a significant > > concern to share with all Members and > Participants. I feel like we are missing > > an important part of the puzzle. > > > > I apologize for raising this concern so late, > and I hope this concern will be > > easily dismissed if I have missed something. > > > > Here is the scenario that raised my concern. > > > > The CWG suggests to create Contract, Co. as the contracting party for the > > IANA contract in the future. Consider the > scenario where Contract, Co., upon > > instruction from the MRT after a fierce > debate, contracts with someone else > > than Icann, following an RFP. > > > > Consider now that, due to external considerations, the root zone publisher > > (currently, Verisign) indicates that it does > not intend accepting requests from > > the new IANA operator. We would be facing a deadlock, threatening the > > ability to maintain the root zone in a secure and stable manner. > > > > Am I missing something here ? Unless I am, I believe we would need to > > expand our investigations to be able to address this scenario, by : > > - analyzing the root zone publisher function, > especially by what mechanisms > > it is bound to publish IANA-approved changes to to the root zone. > > - investigating options in our transition > proposal, through which to ensure > > that the root zone publisher remains committed to publish changes in the > > root when, and only when, they are approved by the IANA Operator. > > > > Many thanks in advance for your replies > regarding both the validity of this > > scenario as well as potential ways to address that risk. > > > > -- > > ***************************** > > Mathieu WEILL > > AFNIC - directeur général > > Tél: 01 39 30 83 06 > > <mailto:mathieu.weill@afnic.fr>mathieu.weill(a)afnic.fr > > ***************************** > > ATTENTION : L'Afnic a déménagé le 31 mars 2014 ! > > Notre nouvelle adresse est : > > Afnic - Immeuble Le Stephenson - 1, rue Stephenson - 78180 Montigny-le- > > Bretonneux > > > > _______________________________________________ > > CWG-Stewardship mailing list > > <mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org > > https://mm.icann.org/mailman/listinfo/cwg-stewardship >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship > > >_______________________________________________ >CWG-Stewardship mailing list ><mailto:CWG-Stewardship@icann.org>CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship > > > > >-- >Jordan Carter > >Chief Executive >InternetNZ > >04 495 2118 (office) | +64 21 442 649 (mob) ><mailto:jordan@internetnz.net.nz>jordan(a)internetnz.net.nz >Skype: jordancarter > >To promote the Internet's benefits and uses, and protect its potential. > >_______________________________________________ >CWG-Stewardship mailing list >CWG-Stewardship(a)icann.org >https://mm.icann.org/mailman/listinfo/cwg-stewardship

2 1

Contract, Co. and the root zone publisher
by Mathieu Weill Dec. 10, 2014

Dec. 10, 2014

Dear Colleagues, Having now read carefully the proposal document, I have a significant concern to share with all Members and Participants. I feel like we are missing an important part of the puzzle. I apologize for raising this concern so late, and I hope this concern will be easily dismissed if I have missed something. Here is the scenario that raised my concern. The CWG suggests to create Contract, Co. as the contracting party for the IANA contract in the future. Consider the scenario where Contract, Co., upon instruction from the MRT after a fierce debate, contracts with someone else than Icann, following an RFP. Consider now that, due to external considerations, the root zone publisher (currently, Verisign) indicates that it does not intend accepting requests from the new IANA operator. We would be facing a deadlock, threatening the ability to maintain the root zone in a secure and stable manner. Am I missing something here ? Unless I am, I believe we would need to expand our investigations to be able to address this scenario, by : - analyzing the root zone publisher function, especially by what mechanisms it is bound to publish IANA-approved changes to to the root zone. - investigating options in our transition proposal, through which to ensure that the root zone publisher remains committed to publish changes in the root when, and only when, they are approved by the IANA Operator. Many thanks in advance for your replies regarding both the validity of this scenario as well as potential ways to address that risk. -- ***************************** Mathieu WEILL AFNIC - directeur général Tél: 01 39 30 83 06 mathieu.weill(a)afnic.fr ***************************** ATTENTION : L'Afnic a déménagé le 31 mars 2014 ! Notre nouvelle adresse est : Afnic - Immeuble Le Stephenson - 1, rue Stephenson - 78180 Montigny-le-Bretonneux

4 6

Re: [CWG-Stewardship] Principles
by Alan Greenberg Dec. 9, 2014

Dec. 9, 2014

The last version of the Principles that I can find, under Separability, says: >h. Separability: any proposal must ensure the ability: > i. To separate the IANA Functions from the current operator if > warranted and in line with agreed processes; and > > ii. To convene a process for selecting a new Operator. > >Separability should persist through any future transfer of the IANA >Functions. (Note the current NTIA contract requires such separation). To the best of my knowledge, the current contract makes reference to the execution of the IANA function being separate from ICANN Policy development. There is no reference to separability as defined in h.i. Alan

1 0

Reminder: Outreach Tracking for RFP5
by Grace Abuhamad Dec. 9, 2014

Dec. 9, 2014

Dear all, We've received information from ccNSO, GAC, and RySG. That was included in the draft proposal and on the Wiki. If you have any additional information you'd like to share with the group, please do so and we will include in future proposals. Best, Grace From: Grace Abuhamad <grace.abuhamad(a)icann.org> Date: Tuesday, November 25, 2014 11:18 AM To: <cwg-stewardship(a)icann.org> Cc: RFP5 <cwg-rfp5(a)icann.org> Subject: Outreach Tracking for RFP5 Dear all, On behalf of the RFP5 subgroup, we'd like to start collecting information about the consultations within communities that have taken place to date. This is in order to validate the NTIA requirements and principles. Please reply with an outline of your community consultations to date and/or a description of your outreach efforts to date. We will compile this information and provide it to the RFP5 subgroup for review. Best, Grace

4 4

CWG - Public Comment summary for Wednesday December 9th
by Bernard Turcotte Dec. 9, 2014

Dec. 9, 2014

No new submissions yesterday December 8th. B.

1 0