Re: [CWG-Stewardship] Contract, Co. and the root zone publisher
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@lawabel.com
ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc@gmail.com
www.lawabel.com
On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@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@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@afnic.fr; <mailto:cwg-stewardship@icann.org>cwg-stewardship@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.
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@lawabel.com ICANN-related: <mailto:gregshatanipc@gmail.com>gregshatanipc@gmail.com
www.lawabel.com
On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <<mailto:mueller@syr.edu>mueller@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@icann.org [mailto:<mailto:cwg-stewardship->cwg-stewardship- <mailto:bounces@icann.org>bounces@icann.org] On Behalf Of Mathieu Weill Sent: Sunday, December 7, 2014 7:41 AM To: <mailto:cwg-stewardship@icann.org>cwg-stewardship@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@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@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@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Alan: The NTIA says that there should be a "parallel" transition of the NTIA's responsibilities relating to the RZM function. That doesn't sound like they want to hold onto the CA one second longer than they want to hold onto the IANA Functions Contract. I think this is squarely 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 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>* On Tue, Dec 9, 2014 at 11:38 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
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 <http://??> *| Main* 212-949-9022 <http://??>
*Fax* 212-949-9190 <http://??> *|* *Cell *917-816-6428 <http://??>
*gsshatan@lawabel.com <gsshatan@lawabel.com> *
*ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> *
* www.lawabel.com <http://www.lawabel.com/> * On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <alan.greenberg@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 <mueller@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 <gregshatanipc@gmail.com>] Sent: Monday, December 8, 2014 3:14 AM To: Milton L Mueller Cc: Mathieu.Weill@afnic.fr; cwg-stewardship@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-ro... 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 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428
gsshatan@lawabel.com ICANN-related: gregshatanipc@gmail.com
www.lawabel.com On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <mueller@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: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship- bounces@icann.org] On Behalf Of Mathieu Weill Sent: Sunday, December 7, 2014 7:41 AM To: cwg-stewardship@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 > mathieu.weill@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 > CWG-Stewardship@icann.org > https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Jordan Carter
Chief Executive InternetNZ
04 495 2118 (office) | +64 21 442 649 <%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz Skype: jordancarter
To promote the Internet's benefits and uses, and protect its potential.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Dear Colleagues, Many thanks for your feedbacks and elaborating on this idea. Reading everyone's contributions, it seems to me there are three outlined options so far : a) status quo (RZM contracts with NTIA) b) Contract Co. contracts with RZM c) IANA Operator contracts with RZM I would suggest we go back to our principles to assess the merits of these options. For instance, option c may present better perspectives in terms of service performance overall (IANA Operator is fully accountable for performance and can adjust any interface issue with its contractor, the RZM), but it may be less desirable to some in terms of as separability as well as checks and balances (if the RZM contract includes provisions to double check). Happy to elaborate if you think it valuable. Best Mathieu Le 10/12/2014 05:53, Greg Shatan a écrit :
Alan:
The NTIA says that there should be a "parallel" transition of the NTIA's responsibilities relating to the RZM function. That doesn't sound like they want to hold onto the CA one second longer than they want to hold onto the IANA Functions Contract.
I think this is squarely 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
*/gsshatan@lawabel.com <mailto:gsshatan@lawabel.com>/*
*ICANN-related: gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com> *
*/www.lawabel.com <http://www.lawabel.com/>/*
On Tue, Dec 9, 2014 at 11:38 PM, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@mcgill.ca>> wrote:
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 <http://??> *| Main* 212-949-9022 <http://??>
*Fax* 212-949-9190 <http://??> *|* *Cell *917-816-6428 <http://??>
*/gsshatan@lawabel.com <mailto:gsshatan@lawabel.com> /* *ICANN-related: gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com> * */www.lawabel.com <http://www.lawabel.com/> /* On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <alan.greenberg@mcgill.ca <mailto:alan.greenberg@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 <mueller@syr.edu <mailto:mueller@syr.edu>> wrote:
I agree with you Greg that this is in scope; you are also correct to point out that the NTIA language (âEURoerelated and parallelâEUR ) makes it rather ambiguous regarding our role relative to NTIAâEUR^(TM)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âEUR^(TM)t have time for more now.
From: Greg Shatan [ mailto:gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>] Sent: Monday, December 8, 2014 3:14 AM To: Milton L Mueller Cc: Mathieu.Weill@afnic.fr <mailto:Mathieu.Weill@afnic.fr>; cwg-stewardship@icann.org <mailto:cwg-stewardship@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-ro...
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. (âEURoePerform Administrative Functions Associated With Root Zone ManagementâEUR ), 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 (âEUR~or any successor entity as designated by the U.S. Department of CommerceâEUR ) 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âEUR^(TM)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 212-885-9253 <tel:212-885-9253> | Main 212-949-9022 <tel:212-949-9022> Fax 212-949-9190 <tel:212-949-9190> | Cell 917-816-6428 <tel:917-816-6428>
gsshatan@lawabel.com <mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>
www.lawabel.com <http://www.lawabel.com/> On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <mueller@syr.edu <mailto:mueller@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: cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship- <mailto:cwg-stewardship-> > bounces@icann.org <mailto:bounces@icann.org>] On Behalf Of Mathieu Weill > Sent: Sunday, December 7, 2014 7:41 AM > To: cwg-stewardship@icann.org <mailto:cwg-stewardship@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 > mathieu.weill@afnic.fr <mailto:mathieu.weill@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 > CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> > https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Jordan Carter
Chief Executive InternetNZ
04 495 2118 (office) | +64 21 442 649 <tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter
To promote the Internet's benefits and uses, and protect its potential.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ***************************** Mathieu WEILL AFNIC - directeur général Tél: 01 39 30 83 06 mathieu.weill@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
Good to put the options out like this, Mathieu. I think we can eliminate Option a) There are cases to be made for either b) or c) and I would like us to think carefully about both of them using criteria of optimizing operational efficiency and accountability, and not jump to one conclusion or the other based on ancillary political calculations (such as, how does this affect ICANN?). I try to describe them as objectively as possible without expressing an opinion at this point. Option b) means that the MRT and CSC would have more authority over the whole picture, they could instruct Contract Co. to select a specific RZM as well as a specific IANA functions operator as distinct decisions. Of course, the Contract Co. could decide to award both functions to the same entity but that would have to be a positive decision it made. Option c) means that the MRT and CSC are trusting their chosen IANA functions contractor to make the choice itself. They are delegating responsibility for RZM to the contracted IANA operator, which would make the decision whether the functions were integrated or outsourced. Obviously option c) makes the choice of an IANA functions contractor more important and stickier. But it is also easier from a transactions cost perspective in that the IANA contractor would take responsibility for coordination or operating the RZM and the MRT wouldn’t have to worry about it. --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Mathieu Weill Sent: Wednesday, December 10, 2014 2:37 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Contract, Co. and the root zone publisher Dear Colleagues, Many thanks for your feedbacks and elaborating on this idea. Reading everyone's contributions, it seems to me there are three outlined options so far : a) status quo (RZM contracts with NTIA) b) Contract Co. contracts with RZM c) IANA Operator contracts with RZM I would suggest we go back to our principles to assess the merits of these options. For instance, option c may present better perspectives in terms of service performance overall (IANA Operator is fully accountable for performance and can adjust any interface issue with its contractor, the RZM), but it may be less desirable to some in terms of as separability as well as checks and balances (if the RZM contract includes provisions to double check). Happy to elaborate if you think it valuable. Best Mathieu Le 10/12/2014 05:53, Greg Shatan a écrit : Alan: The NTIA says that there should be a "parallel" transition of the NTIA's responsibilities relating to the RZM function. That doesn't sound like they want to hold onto the CA one second longer than they want to hold onto the IANA Functions Contract. I think this is squarely 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 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Tue, Dec 9, 2014 at 11:38 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> wrote: 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<http://??> | Main 212-949-9022<http://??> Fax 212-949-9190<http://??> | Cell 917-816-6428<http://??> gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@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 <mueller@syr.edu<mailto:mueller@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: Mathieu.Weill@afnic.fr<mailto:Mathieu.Weill@afnic.fr>; cwg-stewardship@icann.org<mailto:cwg-stewardship@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-ro... 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 212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022> Fax 212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428> gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <mueller@syr.edu<mailto:mueller@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: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-<mailto:cwg-stewardship-> bounces@icann.org<mailto:bounces@icann.org>] On Behalf Of Mathieu Weill Sent: Sunday, December 7, 2014 7:41 AM To: cwg-stewardship@icann.org<mailto:cwg-stewardship@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 mathieu.weill@afnic.fr<mailto:mathieu.weill@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 CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- Jordan Carter Chief Executive InternetNZ 04 495 2118 (office) | +64 21 442 649<tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter To promote the Internet's benefits and uses, and protect its potential. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ***************************** Mathieu WEILL AFNIC - directeur général Tél: 01 39 30 83 06 mathieu.weill@afnic.fr<mailto:mathieu.weill@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
Milton, I think the transaction costs remain the same for both options. In Option B, Contract Co incurs the transaction (contracting, negotiation, monitoring) costs and the IANA Operator indemnifies Contract Co for the costs. In Option C, IANA Operator directly incurs the transaction costs. Overall, the transaction costs for the institutional arrangement remain the same, at least from an economics perspective. How transaction costs may increase? The transaction costs may quite possibly be higher for Option C, as the RZM will need to be re-contracted every time the IANA Operator changes, thus increasing the frequency of the contract (thereby increasing the negotiation, contracting costs). In contrast, in Option B, the RZM operator need not change every time the IANA Operator changes. How the transaction costs may reduce? The overall transaction costs can only be lower in Option C if the RZM function is completely subsumed by the IANA Operator thereby removing the need for a Cooperative Agreement. . Adding to the pros and cons listed by you: *"b) Contract Co. contracts with RZM"* Option B would: 1) Make Contract Co and MRT even more bulkier/attractive/politicised (not too much though in my opinion). *"c) IANA Operator contracts with RZM"* Option C would: 1) Increase frequency of RZM re-contracting: Option C will require the RZM to be re-contracted by the new IANA Operator each time the IANA Operator is changed after a RFP. 2) Invite the possibility that the IANA Operator subsumes the RZM function (by self-contracting) unless precluded by the IANA Contract. 3) Require Work Stream 1 in CCWG-Accountability to recommend a accountability structure for managing the Cooperative Agreement with the RZM. However, since accountability for IANA and RZM fall in the domain of this CWG, we could also recommend the accountability structure for Option C in our proposal. On Wed, Dec 10, 2014 at 5:52 PM, Milton L Mueller <mueller@syr.edu> wrote:
But it is also easier from a transactions cost perspective in that the IANA contractor would take responsibility for coordination or operating the RZM and the MRT wouldn’t have to worry about it.
--MM
I have some agreement with both of you. Our plan needs to have a coherent conception of what the relationship is between the IANA contractor and the RZM, but it is up to the NTIA to implement any modifications to the Cooperative Agreement and its relationship with VeriSign From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: Tuesday, December 9, 2014 11:54 PM To: Alan Greenberg Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Contract, Co. and the root zone publisher Alan: The NTIA says that there should be a "parallel" transition of the NTIA's responsibilities relating to the RZM function. That doesn't sound like they want to hold onto the CA one second longer than they want to hold onto the IANA Functions Contract. I think this is squarely 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 gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Tue, Dec 9, 2014 at 11:38 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> wrote: 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<http://??> | Main 212-949-9022<http://??> Fax 212-949-9190<http://??> | Cell 917-816-6428<http://??> gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@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 <mueller@syr.edu<mailto:mueller@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: Mathieu.Weill@afnic.fr<mailto:Mathieu.Weill@afnic.fr>; cwg-stewardship@icann.org<mailto:cwg-stewardship@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-ro... 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 212-885-9253<tel:212-885-9253> | Main 212-949-9022<tel:212-949-9022> Fax 212-949-9190<tel:212-949-9190> | Cell 917-816-6428<tel:917-816-6428> gsshatan@lawabel.com<mailto:gsshatan@lawabel.com> ICANN-related: gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com> www.lawabel.com<http://www.lawabel.com/> On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <mueller@syr.edu<mailto:mueller@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: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-<mailto:cwg-stewardship-> bounces@icann.org<mailto:bounces@icann.org>] On Behalf Of Mathieu Weill Sent: Sunday, December 7, 2014 7:41 AM To: cwg-stewardship@icann.org<mailto:cwg-stewardship@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 mathieu.weill@afnic.fr<mailto:mathieu.weill@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 CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- Jordan Carter Chief Executive InternetNZ 04 495 2118 (office) | +64 21 442 649<tel:%2B64%2021%20442%20649> (mob) jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter To promote the Internet's benefits and uses, and protect its potential. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
participants (5)
-
Alan Greenberg -
Greg Shatan -
Guru Acharya -
Mathieu Weill -
Milton L Mueller