Several questions for DT-F
1. Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation. Can anyone provide either a general answer or specific scenarios where the two-party solution is better. 2. 1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted. 1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition. I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter. Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016. Do we want to keep it? Alan
Hi, On Thu, Apr 16, 2015 at 10:01:05PM -0400, Alan Greenberg wrote:
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
I cannot think of a reason why this should be enshrined. I can think if an excellent reason not to change that _now_, however: the relationship is there at the moment, and it's better to change as little as possible as a matter of prudence. See below.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Unless there is an operational definition of "increase robustness" (i.e. a proposal for how robustness is increased, and one that specifies the necessary and sufficient conditions for knowing what that increase is and to what extent it has happened), I think 1.c.1 is actively harmful. It continues to indulge the myth that NTIA is doing something that the IANA names community can't or won't do. If someone has an operationalized proposal, and can show that it is important, that's a different matter (though it raises the question of whether it's a good idea to undertake the transition when such improvements need to be made). Otherwise, the text increases the odds that we'll get a needlessly destabilizing change to the IANA arrangements at exactly the moment where we want to keep everything as stable as possible. After all, if we change IANA and take the NTIA away at the same time, then if something goes wrong afterwards we won't know whether it was the change to IANA or the loss of the NTIA that made the difference. Mill's methods teach us to change one thing at a time if we want to understand cause, and I can think of no better time than now to invoke that principle. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew Sullivan writes:
Hi,
On Thu, Apr 16, 2015 at 10:01:05PM -0400, Alan Greenberg wrote:
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
I cannot think of a reason why this should be enshrined. I can think if an excellent reason not to change that _now_, however: the relationship is there at the moment, and it's better to change as little as possible as a matter of prudence. See below.
The are my thoughts as well.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Unless there is an operational definition of "increase robustness" (i.e. a proposal for how robustness is increased, and one that specifies the necessary and sufficient conditions for knowing what that increase is and to what extent it has happened), I think 1.c.1 is actively harmful. It continues to indulge the myth that NTIA is doing something that the IANA names community can't or won't do.
Indeed!
If someone has an operationalized proposal, and can show that it is important, that's a different matter (though it raises the question of whether it's a good idea to undertake the transition when such improvements need to be made). Otherwise, the text increases the odds that we'll get a needlessly destabilizing change to the IANA arrangements at exactly the moment where we want to keep everything as stable as possible. After all, if we change IANA and take the NTIA away at the same time, then if something goes wrong afterwards we won't know whether it was the change to IANA or the loss of the NTIA that made the difference. Mill's methods teach us to change one thing at a time if we want to understand cause, and I can think of no better time than now to invoke that principle.
+1, jaap
Hi all, On 17 April 2015 at 14:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign. With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two. If there is not a line of business restriction placed on ICANN to prevent it also being the Root Zone Maintainer, there are two consequences: - pressure that could emerge over time, from whatever source, for ICANN to develop another portfolio of activity that would divert attention, resources, focus from its core activity - the concentration of the entire responsibility for operating the root in one entity. I do not believe ICANN or the IANA functions department within it have the skills and experience, the resources and the need, to deliver the RZM functions. I do not believe that them developing this capability is required by ICANN's core role. Even if I could be persuaded on that point, the notion that we should go from three different entities with three different webs of constituency, degrees of power, and expertise (ICANN, NTIA and Verisign) to ONE, is inevitably and totally a future threat to the security and stability of the root. It would be fundamentally irresponsible to allow such a situation to emerge, in my opinion. best, Jordan
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan _______________________________________________ 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 (mob) jordan@internetnz.net.nz Skype: jordancarter *A better world through a better Internet *
Dear Alan, Dear CWG colleagues: 1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified. In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator. 2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why? CW On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Christopher, How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F Dear Alan, Dear CWG colleagues: 1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified. In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator. 2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why? CW On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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 Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community! Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that! More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'. Regards CW On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Root Zone Manager = ICANN (presently) Root Zone Maintainer = Verisign (presently) Abbreviations can be ambiguous. I don't think this attempt to clarify usage for purposes of internal discussion is a sign of deeper or more widespread confusion regarding the roles themselves. Greg On Fri, Apr 17, 2015 at 11:35 AM, CW Lists <lists@christopherwilkinson.eu> wrote:
Dear Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community!
Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that!
More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'.
Regards
CW
On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Well technically that definition is valid assuming ICANN is the only "technical" source for root update and if verisign has no write privileges. The current situation is that the maintainer may as well manage (un-authoritatively) if he wants. Regards sent from Google nexus 4 kindly excuse brevity and typos. On 17 Apr 2015 16:53, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
Root Zone Manager = ICANN (presently) Root Zone Maintainer = Verisign (presently)
Abbreviations can be ambiguous. I don't think this attempt to clarify usage for purposes of internal discussion is a sign of deeper or more widespread confusion regarding the roles themselves.
Greg
On Fri, Apr 17, 2015 at 11:35 AM, CW Lists <lists@christopherwilkinson.eu> wrote:
Dear Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community!
Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that!
More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'.
Regards
CW
On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Good evening: In that case, I am clearly referring to the Root Zone Maintainer. Furthermore, it is not clever to try and hide a substantive issue behind such ambiguities. CW On 17 Apr 2015, at 17:52, Greg Shatan <gregshatanipc@gmail.com> wrote:
Root Zone Manager = ICANN (presently) Root Zone Maintainer = Verisign (presently)
Abbreviations can be ambiguous. I don't think this attempt to clarify usage for purposes of internal discussion is a sign of deeper or more widespread confusion regarding the roles themselves.
Greg
On Fri, Apr 17, 2015 at 11:35 AM, CW Lists <lists@christopherwilkinson.eu> wrote: Dear Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community!
Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that!
More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'.
Regards
CW
On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
You lost me there Christopher. I don't have a clue what you think I am doing as stated in your second sentence so I won't try to respond. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 3:35 PM To: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F Good evening: In that case, I am clearly referring to the Root Zone Maintainer. Furthermore, it is not clever to try and hide a substantive issue behind such ambiguities. CW On 17 Apr 2015, at 17:52, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: Root Zone Manager = ICANN (presently) Root Zone Maintainer = Verisign (presently) Abbreviations can be ambiguous. I don't think this attempt to clarify usage for purposes of internal discussion is a sign of deeper or more widespread confusion regarding the roles themselves. Greg On Fri, Apr 17, 2015 at 11:35 AM, CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> wrote: Dear Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community! Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that! More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'. Regards CW On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Chris, You didn't answer my question and it is difficult for me to respond to your comments until you do. When you used the acronym RZM did you mean Root Zone Manager or Root Zone Maintainer? As Greg pointed out, they are not the same organization. Chuck -----Original Message----- From: CW Lists [mailto:lists@christopherwilkinson.eu] Sent: Friday, April 17, 2015 11:36 AM To: Gomes, Chuck Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F Dear Chuck:
Root Zone Manager and Maintainer ...
For present purposes I do not recognise the difference. Someone, somewhere may be splitting hairs. If the (relative) cognoscenti are confused, imagine how this argument will travel later in public consultation and among the international community! Regarding the definition of RZM, I suggest that Verisign is better placed than I am to provide a reply. I imagine that we might be entering into another scholastic debate about the "Unit". I am not asking for that! More generally, for those of us brought up on the regulatory principle that critical infrastructure functions must not be under the control of the dominant operator, the NTIA arrangement with Verisign has always been rather shocking. The only saving grace being that the ICANN and NTIA contracts prevented abuse. Now that has to change, although I agree that change should be 'serial' and not 'parallel'. Regards CW On 17 Apr 2015, at 14:52, "Gomes, Chuck" <cgomes@verisign.com> wrote:
Christopher,
How do you define RZM? Root Zone Manager or Root Zone Maintainer? To avoid confusion in DT-M we used RZM for Root Zone Manager and Maintainer without an acronym. For consistency in DT-F I encourage us to do the same.
Chuck
-----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of CW Lists Sent: Friday, April 17, 2015 8:12 AM To: Alan Greenberg Cc: CWG IANA Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Hi, I won't bother arguing whether or not ICANN has the "skills and experience, the resources, and the need, to deliver the [Root Zone Maintainer] function" (hint: it isn't rocket science and ICANN already does). I will simply note that in many (most?) situations in which an operational infrastructure is considered important, there is a requirement for a "Two Person Rule" (http://en.wikipedia.org/wiki/Two-man_rule). For example, it would be cheaper, easier, and far simpler if there was a single person in nuclear missile silos able to launch the missiles, yet there is a requirement for two people with two keys to enable launch. Further, if you have two party controls (and you assume a base level of competence), it does not matter who performs the functions as long as they are different: the two parties provide checks to minimize the risk that either party has the ability to unilaterally either accidentally or maliciously "do the bad thing". It is true that it is not technically essential to have two party controls, nor is it the most efficient way of operating, however I personally believe it is appropriate in the context of the root zone. How that is actually implemented should be a topic for future discussion. Regards, -drc -----Original Message----- From: CW Lists <lists@christopherwilkinson.eu> Date: Friday, April 17, 2015 at 5:11 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Earlier, Jordan said: In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign. With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two. I believe this is not immediately true, though it may become so. It is my understanding that the Verisign Cooperative Agreement will stay in place for the time being, with amendments made to account for the ending of the IANA Functions Contract. I recognize that statements were made that the Cooperative Agreement/relationship would be the subject of a related, parallel transaction. However, it is my sense that this transition may well be "serial," rather than "parallel." Greg On Fri, Apr 17, 2015 at 10:44 AM, David Conrad <david.conrad@icann.org> wrote:
Hi,
I won't bother arguing whether or not ICANN has the "skills and experience, the resources, and the need, to deliver the [Root Zone Maintainer] function" (hint: it isn't rocket science and ICANN already does). I will simply note that in many (most?) situations in which an operational infrastructure is considered important, there is a requirement for a "Two Person Rule" (http://en.wikipedia.org/wiki/Two-man_rule). For example, it would be cheaper, easier, and far simpler if there was a single person in nuclear missile silos able to launch the missiles, yet there is a requirement for two people with two keys to enable launch.
Further, if you have two party controls (and you assume a base level of competence), it does not matter who performs the functions as long as they are different: the two parties provide checks to minimize the risk that either party has the ability to unilaterally either accidentally or maliciously "do the bad thing".
It is true that it is not technically essential to have two party controls, nor is it the most efficient way of operating, however I personally believe it is appropriate in the context of the root zone. How that is actually implemented should be a topic for future discussion.
Regards, -drc
-----Original Message----- From: CW Lists <lists@christopherwilkinson.eu> Date: Friday, April 17, 2015 at 5:11 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Hmmm, I thought this conversation was taking place in DT-F. now I see it is here, too. So this is what I wrote to DT-F on this topic: Let me make it clear why I am insisting on a better articulation of the purpose of the separation [between IANA and the RZ Maintainer]. I actually support the idea intuitively, but feel that unless we clearly state the purpose of the separation we are not providing clear instructions on how to do it, and we could easily fail to achieve our goals. As an example, there are people in the US who support the separation because they want a U.S. company under U.S. legal jurisdiction to have some control over what goes into the RZF, and to serve as a check should ICANN “escape” California. There may also be people who support the separation (as Jordan partially does below) because they don’t think ICANN or a legally separated IANA affiliate would have the operational capability to run the primary RZ as reliably as Verisign. In contrast, David Conrad has repeatedly suggested that the separation is a kind of two-factor authentication that can provide a means of preventing errors and abuses of power, both. Others also see it as a check on concentration of power. Those three rationales above point to completely different requirements for the type of separation we would ask for. Let me focus on David’s rationale, as I think it is the one that has the most support. If separation between RZM and IANA RZ editing is intended to provide two-factor authentication, then it implies a certain level of autonomy among the parties, does it not? RZM cannot be a passive recipient of IANA instructions that are automatically implemented – can they? Or is there some way to automate the exchange between IANA and VRSN that still allows some kind of additional error or security check or some way to filter out of policy abuses? --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, April 17, 2015 11:02 AM To: David Conrad Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Several questions for DT-F Earlier, Jordan said: In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign. With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two. I believe this is not immediately true, though it may become so. It is my understanding that the Verisign Cooperative Agreement will stay in place for the time being, with amendments made to account for the ending of the IANA Functions Contract. I recognize that statements were made that the Cooperative Agreement/relationship would be the subject of a related, parallel transaction. However, it is my sense that this transition may well be "serial," rather than "parallel." Greg On Fri, Apr 17, 2015 at 10:44 AM, David Conrad <david.conrad@icann.org<mailto:david.conrad@icann.org>> wrote: Hi, I won't bother arguing whether or not ICANN has the "skills and experience, the resources, and the need, to deliver the [Root Zone Maintainer] function" (hint: it isn't rocket science and ICANN already does). I will simply note that in many (most?) situations in which an operational infrastructure is considered important, there is a requirement for a "Two Person Rule" (http://en.wikipedia.org/wiki/Two-man_rule). For example, it would be cheaper, easier, and far simpler if there was a single person in nuclear missile silos able to launch the missiles, yet there is a requirement for two people with two keys to enable launch. Further, if you have two party controls (and you assume a base level of competence), it does not matter who performs the functions as long as they are different: the two parties provide checks to minimize the risk that either party has the ability to unilaterally either accidentally or maliciously "do the bad thing". It is true that it is not technically essential to have two party controls, nor is it the most efficient way of operating, however I personally believe it is appropriate in the context of the root zone. How that is actually implemented should be a topic for future discussion. Regards, -drc -----Original Message----- From: CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> Date: Friday, April 17, 2015 at 5:11 AM To: Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> Cc: CWG Mailing List <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Greg, You seem to have information that the rest of us do not have, or at least that I do not have. I have no idea what NTIA is going to do with the Cooperative Agreement. Where did your understanding come from? Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: Friday, April 17, 2015 11:02 AM To: David Conrad Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Several questions for DT-F Earlier, Jordan said: In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign. With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two. I believe this is not immediately true, though it may become so. It is my understanding that the Verisign Cooperative Agreement will stay in place for the time being, with amendments made to account for the ending of the IANA Functions Contract. I recognize that statements were made that the Cooperative Agreement/relationship would be the subject of a related, parallel transaction. However, it is my sense that this transition may well be "serial," rather than "parallel." Greg On Fri, Apr 17, 2015 at 10:44 AM, David Conrad <david.conrad@icann.org<mailto:david.conrad@icann.org>> wrote: Hi, I won't bother arguing whether or not ICANN has the "skills and experience, the resources, and the need, to deliver the [Root Zone Maintainer] function" (hint: it isn't rocket science and ICANN already does). I will simply note that in many (most?) situations in which an operational infrastructure is considered important, there is a requirement for a "Two Person Rule" (http://en.wikipedia.org/wiki/Two-man_rule). For example, it would be cheaper, easier, and far simpler if there was a single person in nuclear missile silos able to launch the missiles, yet there is a requirement for two people with two keys to enable launch. Further, if you have two party controls (and you assume a base level of competence), it does not matter who performs the functions as long as they are different: the two parties provide checks to minimize the risk that either party has the ability to unilaterally either accidentally or maliciously "do the bad thing". It is true that it is not technically essential to have two party controls, nor is it the most efficient way of operating, however I personally believe it is appropriate in the context of the root zone. How that is actually implemented should be a topic for future discussion. Regards, -drc -----Original Message----- From: CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> Date: Friday, April 17, 2015 at 5:11 AM To: Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> Cc: CWG Mailing List <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
Chuck, This goes back several weeks, so I'm trying to remember exactly how I got here. I'm not sure if it's information others do not have, or just information that is buried in the morass. I do remember that we had raised the question of whether it was in scope for us to deal with the Cooperative Agreement transition, and I recall getting various bits of information that added up to the point I made. We could always just ask NTIA what their current thinking is on the subject. Greg On Fri, Apr 17, 2015 at 1:38 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Greg,
You seem to have information that the rest of us do not have, or at least that I do not have. I have no idea what NTIA is going to do with the Cooperative Agreement. Where did your understanding come from?
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Greg Shatan *Sent:* Friday, April 17, 2015 11:02 AM *To:* David Conrad *Cc:* cwg-stewardship@icann.org
*Subject:* Re: [CWG-Stewardship] Several questions for DT-F
Earlier, Jordan said:
In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign.
With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two.
I believe this is not immediately true, though it may become so. It is my understanding that the Verisign Cooperative Agreement will stay in place for the time being, with amendments made to account for the ending of the IANA Functions Contract. I recognize that statements were made that the Cooperative Agreement/relationship would be the subject of a related, parallel transaction. However, it is my sense that this transition may well be "serial," rather than "parallel."
Greg
On Fri, Apr 17, 2015 at 10:44 AM, David Conrad <david.conrad@icann.org> wrote:
Hi,
I won't bother arguing whether or not ICANN has the "skills and experience, the resources, and the need, to deliver the [Root Zone Maintainer] function" (hint: it isn't rocket science and ICANN already does). I will simply note that in many (most?) situations in which an operational infrastructure is considered important, there is a requirement for a "Two Person Rule" (http://en.wikipedia.org/wiki/Two-man_rule). For example, it would be cheaper, easier, and far simpler if there was a single person in nuclear missile silos able to launch the missiles, yet there is a requirement for two people with two keys to enable launch.
Further, if you have two party controls (and you assume a base level of competence), it does not matter who performs the functions as long as they are different: the two parties provide checks to minimize the risk that either party has the ability to unilaterally either accidentally or maliciously "do the bad thing".
It is true that it is not technically essential to have two party controls, nor is it the most efficient way of operating, however I personally believe it is appropriate in the context of the root zone. How that is actually implemented should be a topic for future discussion.
Regards, -drc
-----Original Message----- From: CW Lists <lists@christopherwilkinson.eu> Date: Friday, April 17, 2015 at 5:11 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Several questions for DT-F
Dear Alan, Dear CWG colleagues:
1. I think that it is not technically essential to have separate IANA and RZM operators. It is visually preferable and in certain limiting cases more secure, provided that an appropriately independent RZM operator can be identified.
In any event, absent the NTIA contract, it would be entirely inappropriate for any Registry or Registrar with a corporate interest in the content of the Root Zone to become or remain RZM operator.
2. I agree with Alan's question. I have also been perplexed as to the motives for the explicit and implicit attacks on IANA performance in the CWG. If it not evidence-based, then Why?
CW
On 17 Apr 2015, at 04:01, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
1.
Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.
Can anyone provide either a general answer or specific scenarios where the two-party solution is better.
2.
1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.
1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.
I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.
Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.
Do we want to keep it?
Alan<DT-F_Rec-v07.pdf>_______________________________________________ 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
participants (10)
-
Alan Greenberg -
Andrew Sullivan -
CW Lists -
David Conrad -
Gomes, Chuck -
Greg Shatan -
Jaap Akkerhuis -
Jordan Carter -
Milton L Mueller -
Seun Ojedeji