Re: [CWG-Stewardship] For your review - version V3.3
Hi Marika, The first bullet in Section III.A says: ICANN, through an affiliate controlled by ICANN, to continue as the IANA
Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says: A contract would be entered between PTI and ICANN, which would give PTI the
rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
- Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
- Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. - Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
*Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.*
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
I prefer the existing text, unchanged. CW On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing). Greg Shatan On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote:
I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA
Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI
the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
- Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
- Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. - Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
*Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.*
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals. In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group. Greg On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote:
I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA
Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI
the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
- Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
- Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. - Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org
wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
*Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.*
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion. Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate. Martin From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3 I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals. In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group. Greg On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing). Greg Shatan On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> wrote: I prefer the existing text, unchanged. CW On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu<mailto:bnkuerbi@syr.edu>> wrote: Hi Marika, The first bullet in Section III.A says: ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI). Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says: A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator. I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest: * Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions. This would be followed by the existing bullets: * Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. * Changes proposed to root zone environment and relationship with root zone maintainer. -- Brenden On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document. Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible. Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly. You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC. For your convenience I’ve attached a redline and clean version both in Word as well as pdf. Thanks again for all your feedback! Marika _______________________________________________ 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
Hi Martin, On Tue, Apr 21, 2015 at 5:32 PM, Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
I am not sure Greg is implying what you stated above. The CWG proposal is indeed moving IANA to PTI which includes everything related to the other 2 communities (perhaps except existing MOUs which ofcourse is not yet clear)
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
This was exactly what i had earlier suggested; If our proposal is going to affect the other communities in the manner we are proposing, i think it saves us a lot of time by flagging the respective communities to know their thoughts before our public comment. Instead of submitting and then having ICG come back to us....and as a matter of fact, it think it will be an act of "courtesy" if that is done. (again i know CRISP formerly indicated that they are open to receive such interaction, i expect same with IETF as well) Regards
Martin
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Greg Shatan *Sent:* 21 April 2015 17:14 *To:* CW Lists *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote:
I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
- Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
- Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. - Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
*Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.*
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
On Tue, Apr 21, 2015 at 04:32:40PM +0000, Martin Boyle wrote:
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
I believe here are two completely different things here. 1. The IANA functions -- all of them -- move from inside ICANN to the affiliate. This is how ICANN performs the IANA functions. The agreements with other parties can remain between ICANN and those other parties, but that does not affect the "how ICANN gets IANA done." 2. The names IANA function gets all the accountability rules and so on we've been talking about. That's the "names community proposal". This part really is names-only. If follows from these two premises, however, that ICANN needs also to undertake some sort of agreement with PTI about how the other communities' needs get satisfied. Presumably, if the other communities maintain an agreement with ICANN, then ICANN concludes an agreement with PTI that says, "You implement that." The details of how that is worked out, however, are not our problem and we don't need to have an opinion about it reflected in this document, I think. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, By George, I think you've got it. Greg On Tue, Apr 21, 2015 at 1:23 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Apr 21, 2015 at 04:32:40PM +0000, Martin Boyle wrote:
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
I believe here are two completely different things here.
1. The IANA functions -- all of them -- move from inside ICANN to the affiliate. This is how ICANN performs the IANA functions. The agreements with other parties can remain between ICANN and those other parties, but that does not affect the "how ICANN gets IANA done."
2. The names IANA function gets all the accountability rules and so on we've been talking about. That's the "names community proposal". This part really is names-only.
If follows from these two premises, however, that ICANN needs also to undertake some sort of agreement with PTI about how the other communities' needs get satisfied. Presumably, if the other communities maintain an agreement with ICANN, then ICANN concludes an agreement with PTI that says, "You implement that." The details of how that is worked out, however, are not our problem and we don't need to have an opinion about it reflected in this document, I think.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, Sounds right to me as well. I think any incidental compatibility issues that may spring up become an issue for the ICG, as long as we remain careful to not include any extra work or participation by the other operational communities in any of the PTI mechanisms. avri On 21-Apr-15 13:36, Greg Shatan wrote:
Andrew,
By George, I think you've got it.
Greg
On Tue, Apr 21, 2015 at 1:23 PM, Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Tue, Apr 21, 2015 at 04:32:40PM +0000, Martin Boyle wrote: > I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion. >
I believe here are two completely different things here.
1. The IANA functions -- all of them -- move from inside ICANN to the affiliate. This is how ICANN performs the IANA functions. The agreements with other parties can remain between ICANN and those other parties, but that does not affect the "how ICANN gets IANA done."
2. The names IANA function gets all the accountability rules and so on we've been talking about. That's the "names community proposal". This part really is names-only.
If follows from these two premises, however, that ICANN needs also to undertake some sort of agreement with PTI about how the other communities' needs get satisfied. Presumably, if the other communities maintain an agreement with ICANN, then ICANN concludes an agreement with PTI that says, "You implement that." The details of how that is worked out, however, are not our problem and we don't need to have an opinion about it reflected in this document, I think.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> _______________________________________________ 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
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct. Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do. --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3 I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion. Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate. Martin From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3 I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals. In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group. Greg On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing). Greg Shatan On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> wrote: I prefer the existing text, unchanged. CW On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu<mailto:bnkuerbi@syr.edu>> wrote: Hi Marika, The first bullet in Section III.A says: ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI). Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says: A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator. I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest: * Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions. This would be followed by the existing bullets: * Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. * Changes proposed to root zone environment and relationship with root zone maintainer. -- Brenden On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document. Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible. Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly. You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC. For your convenience I’ve attached a redline and clean version both in Word as well as pdf. Thanks again for all your feedback! Marika _______________________________________________ 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
Milton, I don't think these sorts of exaggerated statements are helpful. Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions. Regards, -drc From: Milton L Mueller <mueller@syr.edu> Date: Tuesday, April 21, 2015 at 11:32 AM To: 'Martin Boyle' <Martin.Boyle@nominet.org.uk> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3
Martin I also think Andrew¹s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the ³design flaw² that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I¹m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton¹s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN¹s affiliate.
Martin
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 Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com> > wrote:
In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu> > wrote:
I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu <mailto:bnkuerbi@syr.edu> > wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
* Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
* Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. * Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org <mailto:marika.konings@icann.org> > wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we¹ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we¹ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I¹ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship <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 <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
David I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that? By "control" I meant that IANA's management were all hired by ICANN and accountable to ICANN's board and dependent on ICANN's budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes. It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was "controlled" by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It's only 'control' over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN. ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that's important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic. NTIA oversight mitigated that somewhat, but that is going away. I know that ICANN employees don't like to be reminded of ICANN's design flaws, but I don't think that gives you license to dismiss reasonable statements as exaggerated or unhelpful. --MM From: David Conrad [mailto:david.conrad@icann.org] Sent: Tuesday, April 21, 2015 2:55 PM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: Re: [CWG-Stewardship] For your review - version V3.3 Milton, I don't think these sorts of exaggerated statements are helpful. Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community - IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions. Regards, -drc From: Milton L Mueller <mueller@syr.edu<mailto:mueller@syr.edu>> Date: Tuesday, April 21, 2015 at 11:32 AM To: 'Martin Boyle' <Martin.Boyle@nominet.org.uk<mailto:Martin.Boyle@nominet.org.uk>> Cc: CWG Mailing List <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] For your review - version V3.3 Martin I also think Andrew's clear distinction between IANA and names-related IANA functions was correct. Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the "design flaw" that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do. --MM From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3 I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I'm not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton's assertion. Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN's affiliate. Martin From:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3 I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals. In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group. Greg On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing). Greg Shatan On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu>> wrote: I prefer the existing text, unchanged. CW On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu<mailto:bnkuerbi@syr.edu>> wrote: Hi Marika, The first bullet in Section III.A says: ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI). Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says: A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator. I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest: ? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions. This would be followed by the existing bullets: ? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. ? Changes proposed to root zone environment and relationship with root zone maintainer. -- Brenden On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we've also reorganised the annexes to match the flow of the document. Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible. Also, note that we've incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly. You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC. For your convenience I've attached a redline and clean version both in Word as well as pdf. Thanks again for all your feedback! Marika _______________________________________________ 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
Milton,
I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances.
The fact that the IANA functions are performed by ICANN employees does not imply that the names community, a subset of the ICANN community, controls the operation of the IANA functions or drives its priorities.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was ³controlled² by the protocols community simply because maintaining protocol registries accounts for a lot of the work.
I question your knowledge of how the IANA functions are actually implemented, how the priorities of the staff who perform those functions are set, and thus, the credibility of your assertions of who controls or operates IANA. In terms of staff resources committed and activities undertaken by IANA staff, the protocol parameter community was (and presumably still is) more "in control" than the other communities of what IANA staff does. More staff are required to perform that function than the others, and the protocol parameter function is the only function that has Service Level Agreements that defines what IANA staff must do. The budget for the IANA functions is not set based upon who is paying for those functions, nor are the activities undertaken determined by a particular community.
The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended;
In my mind, the fact that that the PSO went away does not mean the IETF and the protocol parameter community ceased being an ICANN stakeholder.
It¹s only control¹ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
You appear to have a fundamental misunderstanding of how ICANN provides the IANA functions. IANA staff must meet the demands of _all_ the communities they serve. No one of those communities "controls" the operation of IANA, nor does that community "operate" IANA. The mechanisms by which the performance of the IANA functions is "controlled" is not based on who pays or who votes on the ICANN board. That is simply not how ICANN has implemented the IANA functions. It is controlled primarily by the agreements, e.g., RFC 2860 (despite your attempts to minimize it), the ASO-MOU, the IANA Functions contract, etc., ICANN has entered into to perform those functions. One (1) of those agreements will be going away with the transition this fact does not invalidate the other agreements or the requirements on ICANN they impose. Regards, -drc
Hi, On Tue, Apr 21, 2015 at 07:27:14PM +0000, Milton L Mueller wrote:
for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member.
I don't think it's exactly true that the protocols community stopped participating in ICANN as a stakeholder. What is true is that we have a slightly lightweight, and less formal, relationship than some of the officially-sanctioned SOs and ACs. But the IETF appoints a liaison to the ICANN board, appoints a liaison to the RSSAC, contributes two experts to the technical experts group, and appoints a member of the Nomcom. I know you're aware of this, and I understand the distinction you were trying to draw; I just didn't want the significant participation to be overlooked by those who may be less aware of it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Hi, Financial control is not the only kind of control. One form of control that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this. Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged. One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions. And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation. In some sense this may seem an irrelevant issue, after all there are no protocol actions pending at the moment, and I know I should not worry about things that might happen but which are not currently happening. I do, however, think that we have a hole in our solution at the moment. Who makes these decisions? Is it the PTI? I assume that up until now, this has been an ICANN management decision. Or does the IETF have technical oversight over the IANA operations vis a vis architecture, protocol and operational guidelines? I think we need to know the answers to these questions. avri On 21-Apr-15 15:27, Milton L Mueller wrote:
David
I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that?
By “control” I meant that IANA’s management were all hired by ICANN and accountable to ICANN’s board and dependent on ICANN’s budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was “controlled” by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It’s only ‘control’ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that’s important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic.
NTIA oversight mitigated that somewhat, but that is going away.
I know that ICANN employees don’t like to be reminded of ICANN’s design flaws, but I don’t think that gives you license to dismiss reasonable statements as exaggerated or unhelpful.
--MM
*From:*David Conrad [mailto:david.conrad@icann.org] *Sent:* Tuesday, April 21, 2015 2:55 PM *To:* Milton L Mueller *Cc:* 'cwg-stewardship@icann.org' *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
Milton,
I don't think these sorts of exaggerated statements are helpful.
Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community — IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions.
Regards,
-drc
*From: *Milton L Mueller <mueller@syr.edu <mailto:mueller@syr.edu>> *Date: *Tuesday, April 21, 2015 at 11:32 AM *To: *'Martin Boyle' <Martin.Boyle@nominet.org.uk <mailto:Martin.Boyle@nominet.org.uk>> *Cc: *CWG Mailing List <cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org>> *Subject: *Re: [CWG-Stewardship] For your review - version V3.3
Martin
I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _/not/_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org>[mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Martin Boyle *Sent:* Tuesday, April 21, 2015 12:33 PM *To:* Greg Shatan; Alissa Cooper *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org>[mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Greg Shatan *Sent:* 21 April 2015 17:14 *To:* CW Lists *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote:
In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote:
I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu <mailto:bnkuerbi@syr.edu>> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services.
? Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org <mailto:marika.konings@icann.org>> wrote:
Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
_Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible._
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Avri, I believe there is a misunderstanding in your comments. ICANN does NOT control the funds available to any protocol innovation. They don’t even control the funds for protocols developed in an IETF context. They DO (currently) provide the funding for the IANA to maintain registries specified by the IETF. Clearly IEEE and ITU and (…long list of other SDO’s…) do not depend on ICANN to fund their protocol work. And an IETF WG -could- select a different registry operator for the registry of “FOO” parameters, not selecting the IANA. So the protocol “control” is very, very weak indeed. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 21April2015Tuesday, at 19:17, Avri Doria <avri@acm.org> wrote:
Hi,
Financial control is not the only kind of control. One form of control that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this. Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged.
One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions.
And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation.
In some sense this may seem an irrelevant issue, after all there are no protocol actions pending at the moment, and I know I should not worry about things that might happen but which are not currently happening. I do, however, think that we have a hole in our solution at the moment. Who makes these decisions? Is it the PTI? I assume that up until now, this has been an ICANN management decision. Or does the IETF have technical oversight over the IANA operations vis a vis architecture, protocol and operational guidelines?
I think we need to know the answers to these questions.
avri
On 21-Apr-15 15:27, Milton L Mueller wrote:
David I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that?
By “control” I meant that IANA’s management were all hired by ICANN and accountable to ICANN’s board and dependent on ICANN’s budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was “controlled” by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It’s only ‘control’ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that’s important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic. NTIA oversight mitigated that somewhat, but that is going away.
I know that ICANN employees don’t like to be reminded of ICANN’s design flaws, but I don’t think that gives you license to dismiss reasonable statements as exaggerated or unhelpful.
--MM
From: David Conrad [mailto:david.conrad@icann.org] Sent: Tuesday, April 21, 2015 2:55 PM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: Re: [CWG-Stewardship] For your review - version V3.3
Milton,
I don't think these sorts of exaggerated statements are helpful.
Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community — IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions.
Regards, -drc
From: Milton L Mueller <mueller@syr.edu> Date: Tuesday, April 21, 2015 at 11:32 AM To: 'Martin Boyle' <Martin.Boyle@nominet.org.uk> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote: I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. ? Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
This email has been checked for viruses by Avast antivirus software. www.avast.com
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, What i mean was expenses to deploy any protocol or operational changes within any of the support systems or structures IANA needs to do its work., which can be due to IETF protocol work. I assumed that IANA did not fund the IETF or anyone to develop protocols. And yes, I know the IETF can take it protocols and move away anytime it wants. avri On 21-Apr-15 23:55, manning bill wrote:
Avri, I believe there is a misunderstanding in your comments. ICANN does NOT control the funds available to any protocol innovation. They don’t even control the funds for protocols developed in an IETF context. They DO (currently) provide the funding for the IANA to maintain registries specified by the IETF. Clearly IEEE and ITU and (…long list of other SDO’s…) do not depend on ICANN to fund their protocol work. And an IETF WG -could- select a different registry operator for the registry of “FOO” parameters, not selecting the IANA. So the protocol “control” is very, very weak indeed.
/bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102
On 21April2015Tuesday, at 19:17, Avri Doria <avri@acm.org> wrote:
Hi,
Financial control is not the only kind of control. One form of control that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this. Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged.
One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions.
And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation.
In some sense this may seem an irrelevant issue, after all there are no protocol actions pending at the moment, and I know I should not worry about things that might happen but which are not currently happening. I do, however, think that we have a hole in our solution at the moment. Who makes these decisions? Is it the PTI? I assume that up until now, this has been an ICANN management decision. Or does the IETF have technical oversight over the IANA operations vis a vis architecture, protocol and operational guidelines?
I think we need to know the answers to these questions.
avri
On 21-Apr-15 15:27, Milton L Mueller wrote:
David I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that?
By “control” I meant that IANA’s management were all hired by ICANN and accountable to ICANN’s board and dependent on ICANN’s budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was “controlled” by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It’s only ‘control’ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that’s important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic. NTIA oversight mitigated that somewhat, but that is going away.
I know that ICANN employees don’t like to be reminded of ICANN’s design flaws, but I don’t think that gives you license to dismiss reasonable statements as exaggerated or unhelpful.
--MM
From: David Conrad [mailto:david.conrad@icann.org] Sent: Tuesday, April 21, 2015 2:55 PM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: Re: [CWG-Stewardship] For your review - version V3.3
Milton,
I don't think these sorts of exaggerated statements are helpful.
Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community — IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions.
Regards, -drc
From: Milton L Mueller <mueller@syr.edu> Date: Tuesday, April 21, 2015 at 11:32 AM To: 'Martin Boyle' <Martin.Boyle@nominet.org.uk> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote: I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. ? Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
This email has been checked for viruses by Avast antivirus software. www.avast.com
_______________________________________________ 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
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
On Apr 21, 2015, at 7:17 PM, Avri Doria <avri@acm.org> wrote:
Hi,
Financial control is not the only kind of control. One form of control that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this. Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged.
One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions.
Avri, I too am confused by your comment. The main job of IANA with respect to protocols is to publish the protocol parameters developed by the IETF. They make no decisions about the protocols or their adoption. In the particular area of the root, IANA functions as the single registrar for the root. Evolutions in the technology for DNS can affect the IANA operation, and thus there’s a practical question of when the IANA operation implements whatever is necessary to support the changes. The changes that I can recall are: o the addition of IPv6 records to the root for those servers that have IPv6 addresses, with the name servers for the root being a particular case that was dealt with separately, o the insertion of IDNs into the root zone, and o the support DNSSEC including signing the root and acceptance of DS records from TLD operators and publishing them in the root. If these are the sorts of things you’re referring to, I fully agree this is vital. It is also vital that the decisions related to these changes be managed by people who understand the technical issues. These are policy decisions in the sense that some value judgments are needed, but they are qualitatively different from the value judgments involved in, say, delegation or redelegation, and should not be lumped into the same basket. Steve
And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation.
In some sense this may seem an irrelevant issue, after all there are no protocol actions pending at the moment, and I know I should not worry about things that might happen but which are not currently happening. I do, however, think that we have a hole in our solution at the moment. Who makes these decisions? Is it the PTI? I assume that up until now, this has been an ICANN management decision. Or does the IETF have technical oversight over the IANA operations vis a vis architecture, protocol and operational guidelines?
I think we need to know the answers to these questions.
avri
On 21-Apr-15 15:27, Milton L Mueller wrote:
David I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that?
By “control” I meant that IANA’s management were all hired by ICANN and accountable to ICANN’s board and dependent on ICANN’s budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was “controlled” by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It’s only ‘control’ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that’s important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic. NTIA oversight mitigated that somewhat, but that is going away.
I know that ICANN employees don’t like to be reminded of ICANN’s design flaws, but I don’t think that gives you license to dismiss reasonable statements as exaggerated or unhelpful.
--MM
From: David Conrad [mailto:david.conrad@icann.org] Sent: Tuesday, April 21, 2015 2:55 PM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: Re: [CWG-Stewardship] For your review - version V3.3
Milton,
I don't think these sorts of exaggerated statements are helpful.
Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community — IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions.
Regards, -drc
From: Milton L Mueller <mueller@syr.edu> Date: Tuesday, April 21, 2015 at 11:32 AM To: 'Martin Boyle' <Martin.Boyle@nominet.org.uk> Cc: CWG Mailing List <cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] For your review - version V3.3
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
From:cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote: I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. ? Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
This email has been checked for viruses by Avast antivirus software. www.avast.com
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, Steve. Yes it is those things you enumerated that I was referring to. Thanks for helping me become clear. And I am not lumping them in with any policy decisions currently being made. In fact that is the crux of my question: where will these decisions be made? The PTI Board? If so we should make sure it is reflected in the list. avri On 22-Apr-15 00:40, Steve Crocker wrote:
On Apr 21, 2015, at 7:17 PM, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:
Hi,
Financial control is not the only kind of control. One form of control that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this. Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged.
One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions.
Avri,
I too am confused by your comment. The main job of IANA with respect to protocols is to publish the protocol parameters developed by the IETF. They make no decisions about the protocols or their adoption.
In the particular area of the root, IANA functions as the single registrar for the root. Evolutions in the technology for DNS can affect the IANA operation, and thus there’s a practical question of when the IANA operation implements whatever is necessary to support the changes. The changes that I can recall are:
o the addition of IPv6 records to the root for those servers that have IPv6 addresses, with the name servers for the root being a particular case that was dealt with separately,
o the insertion of IDNs into the root zone, and
o the support DNSSEC including signing the root and acceptance of DS records from TLD operators and publishing them in the root.
If these are the sorts of things you’re referring to, I fully agree this is vital. It is also vital that the decisions related to these changes be managed by people who understand the technical issues. These are policy decisions in the sense that some value judgments are needed, but they are qualitatively different from the value judgments involved in, say, delegation or redelegation, and should not be lumped into the same basket.
Steve
And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation.
In some sense this may seem an irrelevant issue, after all there are no protocol actions pending at the moment, and I know I should not worry about things that might happen but which are not currently happening. I do, however, think that we have a hole in our solution at the moment. Who makes these decisions? Is it the PTI? I assume that up until now, this has been an ICANN management decision. Or does the IETF have technical oversight over the IANA operations vis a vis architecture, protocol and operational guidelines?
I think we need to know the answers to these questions.
avri
On 21-Apr-15 15:27, Milton L Mueller wrote:
David I think you are missing my point. I simply call attention to the fact that IANA is inside of and its staff are employees of an organization (ICANN) that is overwhelmingly driven by names community priorities and finances. Do you seriously dispute that?
By “control” I meant that IANA’s management were all hired by ICANN and accountable to ICANN’s board and dependent on ICANN’s budget. I do not of course, mean that ICANN tries to control IETF processes or numbering processes.
It is wildly inaccurate, and undermines the credibility of your comment, to suggest that IANA was “controlled” by the protocols community simply because maintaining protocol registries accounts for a lot of the work. The protocols community stopped participating in ICANN as a stakeholder more than a decade ago, when the PSO was ended; it contributes no money to ICANN and has no voting board member. It’s only ‘control’ over IANA is an MoU of unclear legal status which gives it the right to walk away from it and find another registry should it want to. That gives IETF a lot of control over who it uses for IANA, but very little control over the IANA that resides inside ICANN.
ICANN as an organization is financed primarily by the names community (more than 95% of its revenues) and probably more than 95% of what it does is about names policy and naming-related issues. And that’s important, because as long as the management and accountability of the IANA functions for ALL operational communities are lodged inside an entity so dominated by ONE community there is an asymmetry in the institutional architecture that is problematic. NTIA oversight mitigated that somewhat, but that is going away.
I know that ICANN employees don’t like to be reminded of ICANN’s design flaws, but I don’t think that gives you license to dismiss reasonable statements as exaggerated or unhelpful.
--MM
*From:* David Conrad [mailto:david.conrad@icann.org] *Sent:* Tuesday, April 21, 2015 2:55 PM *To:* Milton L Mueller *Cc:* 'cwg-stewardship@icann.org' *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
Milton,
I don't think these sorts of exaggerated statements are helpful.
Historically, in terms of workload and policy setting, IANA was "controlled" far more by the protocol parameter community than the names operational community (which is, of course, a subset of the ICANN community). And it is certainly not the case that the IANA functions were "operated" by the names operational community — IANA staff were not related to that community at all. I don't believe that has changed all that much since I ran the IANA functions.
Regards, -drc
*From: *Milton L Mueller <mueller@syr.edu <mailto:mueller@syr.edu>> *Date: *Tuesday, April 21, 2015 at 11:32 AM *To: *'Martin Boyle' <Martin.Boyle@nominet.org.uk <mailto:Martin.Boyle@nominet.org.uk>> *Cc: *CWG Mailing List <cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org>> *Subject: *Re: [CWG-Stewardship] For your review - version V3.3
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _/not/_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Martin Boyle *Sent:* Tuesday, April 21, 2015 12:33 PM *To:* Greg Shatan; Alissa Cooper *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Greg Shatan *Sent:* 21 April 2015 17:14 *To:* CW Lists *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com <mailto:gregshatanipc@gmail.com>> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>> wrote: I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu <mailto:bnkuerbi@syr.edu>> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
? Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
? Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. ? Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org <mailto:marika.konings@icann.org>> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
_Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible._
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
------------------------------------------------------------------------ Avast logo <http://www.avast.com/>
This email has been checked for viruses by Avast antivirus software. www.avast.com <http://www.avast.com/>
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Avri, Thanks for the clarification.
And I am not lumping them in with any policy decisions currently being made. In fact that is the crux of my question: where will these decisions be made? The PTI Board? If so we should make sure it is reflected in the list.
This is one of the things I've been a bit wound up about. I've called it "architectural changes to the root system". Currently,my view is that that decision is made by NTIA, using processes known only to them (but which, from empirical evidence would appear to include consultation with technical experts at NIST and elsewhere). I had thought a logical place would be the CSC via the creation of an ad hoc, technically knowledgable committee, but I gather my assumptions of the role of the CSC were in error. Personally, I don't care too much who makes the decision, just that the decision is made by folks who understand the issues and the process by which the decision is made is open, transparent, accountable, and well documented (and makes sense, of course). Regards, -drc
This issue (who makes decisions about or approves "architectural changes to the root system" in the absence of the NTIA) bears further review. The CSC doesn't seem like the right place at all. The PTI Board makes some sense, but only if we are not keeping it minimalist. Could the NTIA role simply disappear (as we propose to happen with the authorization/validation function)? Greg On Wed, Apr 22, 2015 at 1:14 AM, David Conrad <david.conrad@icann.org> wrote:
Avri,
Thanks for the clarification.
And I am not lumping them in with any policy decisions currently being made. In fact that is the crux of my question: where will these decisions be made? The PTI Board? If so we should make sure it is reflected in the list.
This is one of the things I've been a bit wound up about. I've called it "architectural changes to the root system".
Currently,my view is that that decision is made by NTIA, using processes known only to them (but which, from empirical evidence would appear to include consultation with technical experts at NIST and elsewhere). I had thought a logical place would be the CSC via the creation of an ad hoc, technically knowledgable committee, but I gather my assumptions of the role of the CSC were in error. Personally, I don't care too much who makes the decision, just that the decision is made by folks who understand the issues and the process by which the decision is made is open, transparent, accountable, and well documented (and makes sense, of course).
Regards, -drc
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Greg, A number of us in DT-C were concerned about the CSC having a role in this and we ended with two alternative wordings: 1. “In the event a change in IANA services is anticipated, the CSC is authorised to establish an ad hoc committee of technical and other experts to oversee the changes, in accordance with a defined process.” or 2. “The CSC, in consultation with registry operators, is authorised to discuss with the IANA ways to enhance the provision of IANA’s operational services to meet changing technological environments; as a means to address performance issues; or other unforeseen circumstances. In the event it is agreed that a material change in IANA functions services or operations would be beneficial, the CSC reserves the right to call for a community consultation and independent validation, to be convened by IANA, on the proposed change. Any recommended change must be approved by the ccNSO and RySG.” As you will see, neither gives sole responsibility to the CSC. Both appear in annex G, both look to a wider engagement in discussions. As others, I am not convinced that final decisions should be taken by the PTI, unless it was simply to adopt recommendations approved by the directly impacted stakeholders and that had received good buy-in during the consultation process. Actual accountability needs to be somewhere and that would appear to me to be through the parent of the PTI – ie via the ICANN Board – given the model we are working on. There are a number of groups whose agreement (as directly impacted) would be vital: IETF, IAB, ccNSO, RySG, and I’m sure many others, not just the two referenced! So CSC could initiate a process, PTI needs to be happy that due process has been followed and the decision has got good buy-in, but accountability – and therefore final decision – would need to be at the ICANN Board level and subject to the various accountability processes over them (including review). Martin From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 22 April 2015 07:16 To: David Conrad Cc: Avri Doria; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3 This issue (who makes decisions about or approves "architectural changes to the root system" in the absence of the NTIA) bears further review. The CSC doesn't seem like the right place at all. The PTI Board makes some sense, but only if we are not keeping it minimalist. Could the NTIA role simply disappear (as we propose to happen with the authorization/validation function)? Greg On Wed, Apr 22, 2015 at 1:14 AM, David Conrad <david.conrad@icann.org<mailto:david.conrad@icann.org>> wrote: Avri, Thanks for the clarification. And I am not lumping them in with any policy decisions currently being made. In fact that is the crux of my question: where will these decisions be made? The PTI Board? If so we should make sure it is reflected in the list. This is one of the things I've been a bit wound up about. I've called it "architectural changes to the root system". Currently,my view is that that decision is made by NTIA, using processes known only to them (but which, from empirical evidence would appear to include consultation with technical experts at NIST and elsewhere). I had thought a logical place would be the CSC via the creation of an ad hoc, technically knowledgable committee, but I gather my assumptions of the role of the CSC were in error. Personally, I don't care too much who makes the decision, just that the decision is made by folks who understand the issues and the process by which the decision is made is open, transparent, accountable, and well documented (and makes sense, of course). Regards, -drc _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, DT-F also discussed this and the resulting recommendation appears in Annex N, p. 74, of version 3.3. We suggested that the important thing for now was less to specify anything in detail than to make sure we provide for future paths to getting the necessary work done in the absence of NTIA. I believe the resources and expertise will be available, but we need to make sure they can be mobilized as needed. Personally I think the DT-C view as described here makes sense. I don't have an opinion yet on the specific alternatives proposed, although I do think it's important not to over-specify, since by definition we're talking about mechanisms for solving problems we don't have yet. best, Suzanne On Apr 22, 2015, at 4:14 AM, Martin Boyle <Martin.Boyle@nominet.org.uk> wrote:
Greg,
A number of us in DT-C were concerned about the CSC having a role in this and we ended with two alternative wordings:
1. “In the event a change in IANA services is anticipated, the CSC is authorised to establish an ad hoc committee of technical and other experts to oversee the changes, in accordance with a defined process.” or 2. “The CSC, in consultation with registry operators, is authorised to discuss with the IANA ways to enhance the provision of IANA’s operational services to meet changing technological environments; as a means to address performance issues; or other unforeseen circumstances. In the event it is agreed that a material change in IANA functions services or operations would be beneficial, the CSC reserves the right to call for a community consultation and independent validation, to be convened by IANA, on the proposed change. Any recommended change must be approved by the ccNSO and RySG.”
As you will see, neither gives sole responsibility to the CSC. Both appear in annex G, both look to a wider engagement in discussions.
As others, I am not convinced that final decisions should be taken by the PTI, unless it was simply to adopt recommendations approved by the directly impacted stakeholders and that had received good buy-in during the consultation process. Actual accountability needs to be somewhere and that would appear to me to be through the parent of the PTI – ie via the ICANN Board – given the model we are working on. There are a number of groups whose agreement (as directly impacted) would be vital: IETF, IAB, ccNSO, RySG, and I’m sure many others, not just the two referenced!
So CSC could initiate a process, PTI needs to be happy that due process has been followed and the decision has got good buy-in, but accountability – and therefore final decision – would need to be at the ICANN Board level and subject to the various accountability processes over them (including review).
Martin
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 22 April 2015 07:16 To: David Conrad Cc: Avri Doria; cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
This issue (who makes decisions about or approves "architectural changes to the root system" in the absence of the NTIA) bears further review. The CSC doesn't seem like the right place at all. The PTI Board makes some sense, but only if we are not keeping it minimalist. Could the NTIA role simply disappear (as we propose to happen with the authorization/validation function)?
Greg
On Wed, Apr 22, 2015 at 1:14 AM, David Conrad <david.conrad@icann.org> wrote: Avri,
Thanks for the clarification.
And I am not lumping them in with any policy decisions currently being made. In fact that is the crux of my question: where will these decisions be made? The PTI Board? If so we should make sure it is reflected in the list.
This is one of the things I've been a bit wound up about. I've called it "architectural changes to the root system".
Currently,my view is that that decision is made by NTIA, using processes known only to them (but which, from empirical evidence would appear to include consultation with technical experts at NIST and elsewhere). I had thought a logical place would be the CSC via the creation of an ad hoc, technically knowledgable committee, but I gather my assumptions of the role of the CSC were in error. Personally, I don't care too much who makes the decision, just that the decision is made by folks who understand the issues and the process by which the decision is made is open, transparent, accountable, and well documented (and makes sense, of course).
Regards, -drc
_______________________________________________ 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
On Wed, Apr 22, 2015 at 02:16:23AM -0400, Greg Shatan wrote:
This issue (who makes decisions about or approves "architectural changes to the root system" in the absence of the NTIA) bears further review. The CSC doesn't seem like the right place at all. The PTI Board makes some sense, but only if we are not keeping it minimalist. Could the NTIA role simply disappear (as we propose to happen with the authorization/validation function)?
Why isn't this the names community within ICANN? That's where the policy resides, I thought? A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew's questions/suggestion seem very good to me. With regard to the GNSO though, to date it hasn't really dealt with policy regarding the root. I think that may need to change going forward, not only for issues like this one but also to allow it to serve as an escalation body for the CSC as currently proposed. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, April 22, 2015 6:55 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3 On Wed, Apr 22, 2015 at 02:16:23AM -0400, Greg Shatan wrote:
This issue (who makes decisions about or approves "architectural changes to the root system" in the absence of the NTIA) bears further review. The CSC doesn't seem like the right place at all. The PTI Board makes some sense, but only if we are not keeping it minimalist. Could the NTIA role simply disappear (as we propose to happen with the authorization/validation function)?
Why isn't this the names community within ICANN? That's where the policy resides, I thought? A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
On Wed, Apr 22, 2015 at 01:50:22PM +0000, Gomes, Chuck wrote:
Andrew's questions/suggestion seem very good to me. With regard to the GNSO though, to date it hasn't really dealt with policy regarding the root.
I think what you mean is that the GNSO hasn't been involved in the policies around technology to be used with the root zone, right? That is, I guess the GNSO was involved in the development of the Applicant Guide Book for the new gTLDs, and that entire process was, assuredly, about the policy for what went in the root. But the decision around (say) DNSSEC was different. I confess I am made slightly nervous about some of this, because it's pretty clear that a significant number of participants in the SOs and ACs are not exactly proficient in details of technical operations. In my experience, such a lack of relevant experience never seems to disqualify anyone from having an opinion about how the technology should be operated, and I worry about that being a problem here. Perhaps that suggests that ICANN will need to develop a technical advisory track of some kind (or maybe the SSAC will become more important). I nevertheless think that the policy part needs to live inside of ICANN, despite any misgivings I might have about how well technical policy may be done at first. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
That is correct Andrew. The guidebook kicks in before a delegation ever gets to the IANA processes. To my knowledge the GNSO has never developed any policies that relate directly to IANA services. Chuck -----Original Message----- From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Wednesday, April 22, 2015 10:55 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3 On Wed, Apr 22, 2015 at 01:50:22PM +0000, Gomes, Chuck wrote:
Andrew's questions/suggestion seem very good to me. With regard to the GNSO though, to date it hasn't really dealt with policy regarding the root.
I think what you mean is that the GNSO hasn't been involved in the policies around technology to be used with the root zone, right? That is, I guess the GNSO was involved in the development of the Applicant Guide Book for the new gTLDs, and that entire process was, assuredly, about the policy for what went in the root. But the decision around (say) DNSSEC was different. I confess I am made slightly nervous about some of this, because it's pretty clear that a significant number of participants in the SOs and ACs are not exactly proficient in details of technical operations. In my experience, such a lack of relevant experience never seems to disqualify anyone from having an opinion about how the technology should be operated, and I worry about that being a problem here. Perhaps that suggests that ICANN will need to develop a technical advisory track of some kind (or maybe the SSAC will become more important). I nevertheless think that the policy part needs to live inside of ICANN, despite any misgivings I might have about how well technical policy may be done at first. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, I think I must be misunderstanding what you're saying, because my current interpretation of this message makes it sound like the Internet is one big LAN, and I can't imagine you believe that. More below. On Tue, Apr 21, 2015 at 10:17:10PM -0400, Avri Doria wrote:
that the protocol operational community has is that they define all of the directories held by IANA and can change those with protocol actions. The transition does not change this.
Yes.
Nor am I recommending we tackle this particular problem at the moment. But I want to make sure it is flagged.
What is the "problem", exactly?
One of the long term issue we have is that the IETF is also the one that controls the DNS protocols, DNSSEC, and any new protocl elements that may be created in the future. The degree to which IANA adopts future protocols and protocols elements is a decsion that is somehwat orphaed at the moment. Who makes those decisions.
I don't see what issue there is here. The IETF makes protocols. Suppose it invents a new protocol. Suppose that the name policy community thinks it's a stupid or useless protocol. In that case, that community won't implement the new protocol and won't use it. This is not a theoretical exercise: we have more than one worked example. For instance, in perhaps the most obvious case, IETF developed in a WG (a previous one named CRISP, having nothing to do with IANA transition) the IRIS protocol. This was supposed to be a WHOIS replacement and was carefully designed to meet the requirements that came "over the wall" from ICANN. It was a complete failure: virtually nobody implemented it and the one registry that did either has since shut it down (or is in the process of doing so). IETF has no cops or army. It makes protocols and they are either voluntarily deployed, or they're not. I don't see why the case of the names community is somehow extra special.
And this is where the financial comes back in, because as the sole financial source, ICANN does control the funds available to any protocol innovation.
Really? I had not observed ICANN's close involvement in the development of DANE, SIP, XMPP, and so on, let alone its significant contributions to ALTO or OpenFlow. It sounds like you have a centralized, managers-of-the-Net picture of how all this works, and I don't think that's how the Internet actually functions. (I also don't believe that's what you think really happens, so I'm pretty sure I must be misunderstanding you.) A -- Andrew Sullivan ajs@anvilwalrusden.com
and so the numbers and protocols proposals should not dictate to the names OC what to do. Right? and in like vein, the names OC proposal should not dictate to the numbers or protocols OCs. Right? regarding names - not all names are created equal or are run under the same sets of rules. I, for one, find that the management of .INT question to be flawed in a number of respects… the actual DT never met, the chair formulated a “Fact Sheet” and then made a recommendation that was carried forward. Further discussion has revolved around the process point of the GAC & cc/gTLD constituents acting as proxy (although without a mandate, either expressed or implied from the affected parties) to decide the fate of the .INT registry. The ONLY open/transparent option is to ask the .INT registrants what they would like to see done going forward. manning bmanning@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 21April2015Tuesday, at 11:32, Milton L Mueller <mueller@syr.edu> wrote:
Martin I also think Andrew’s clear distinction between IANA and names-related IANA functions was correct.
Because IANA is currently controlled and operated by the names operational community (ICANN), there is no way for a names proposal to _not_ touch on numbers or protocol parameters in some way. That is the “design flaw” that makes the names part of this hard. The legal separation makes this issue less of a problem but will require some coordination and adjustment by the other OCs. But that is not a big deal; the numbers proposal already required some adjustment and coordination by the protocols community. There is no way to avoid these interdependencies. But adjustments to facilitate compatibility are not the same as one OC telling another what to do.
--MM
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Martin Boyle Sent: Tuesday, April 21, 2015 12:33 PM To: Greg Shatan; Alissa Cooper Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I think that Greg is right, that we were not mandated in the CWG to look at numbers or protocol parameters. While that might sit uneasily, I’m not sure I really know about the flow of funding or the accountability/stewardship role in the light of Milton’s assertion.
Specifically asking CRISP & IANAPLAN for views as to where they would see their relationship lying (given the ring-fencing of the IANA functions operator into a subsidiary in ICANN) would seem to me to be appropriate. They could, after all, contract/sign an MoU with either ICANN or ICANN’s affiliate.
Martin
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Greg Shatan Sent: 21 April 2015 17:14 To: CW Lists Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] For your review - version V3.3
I agree with Alissa that this needs to be clarified. Some of the lack of clarity is due to concern about having a proposal that goes beyond naming functions. This has resulted in some odd phrasings and odd proposals.
In my view, splitting the IANA personnel and assets so this is a "names-only" proposal is unrealistic and unnecessary. Because we are within ICANN, we have a different relationship to the IANA Functions group. We should make it clear that the whole ball of wax would move to PTI, and put that out for public comment. We should flag this specifically for the CRISP and IANAPLAN group.
Greg
On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan <gregshatanipc@gmail.com> wrote: In this instance, I agree with Christopher. I believe both statements are accurate (though the first is less than mellifluous in its phrasing).
Greg Shatan
On Tue, Apr 21, 2015 at 11:36 AM, CW Lists <lists@christopherwilkinson.eu> wrote: I prefer the existing text, unchanged.
CW
On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi@syr.edu> wrote:
Hi Marika,
The first bullet in Section III.A says:
ICANN, through an affiliate controlled by ICANN, to continue as the IANA Functions Operator for the Naming Related Services through the creation of a separate legal entity, Post-Transition IANA (PTI).
Section III.A.i.a, which is text provided by Sidley in consultation with the CWG, says:
A contract would be entered between PTI and ICANN, which would give PTI the rights and obligations as the IANA Functions Operator.
I believe the latter statement is correct, and the prior bullet is inconsistent with it (or at least very unclear). Perhaps Sidley could provide more accurate text for the bullet in Section III.A, or I would suggest:
• Creation of a legally separated affiliate, Post-Transition IANA (PTI), to provide the IANA functions.
This would be followed by the existing bullets:
• Establishment of service level agreement between ICANN and PTI, the IANA Functions Operator for the Naming Related Services. • Changes proposed to root zone environment and relationship with root zone maintainer.
-- Brenden
On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings <marika.konings@icann.org> wrote: Dear All,
Please find attached an updated draft which now incorporates, amongst others, a summary for section III, DT X, information from the legal memo, updates as a result of comments received and proposed text for section IIIB. Note that we’ve also reorganised the annexes to match the flow of the document.
Please note that that there a number of comments that have been flagged that need further consideration by the different DTs. We would like to encourage the leads of the DTs to pick up on the items that have been flagged for review and provide feedback on those items to the CWG mailing list as soon as possible.
Also, note that we’ve incorporated those edits and/or comments that we considered corrections and/or clarifications of existing content as well as responses to some of the Sidley comments. If you do not agree with those responses or updates or are of the view that these are more than corrections and/or clarifications, please flag those accordingly.
You are encouraged to flag any items that you think warrant CWG consideration by Tuesday 20 April at 16.00 UTC at the latest. Other minor edits and/or clarifications can be submitted until Tuesday 20 April 23.59 UTC.
For your convenience I’ve attached a redline and clean version both in Word as well as pdf.
Thanks again for all your feedback!
Marika
_______________________________________________ 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
Hi, On 21-Apr-15 15:24, manning wrote:
The ONLY open/transparent option is to ask the .INT registrants what they would like to see done going forward.
This makes sense. I think this has been suggested before. I certainly have a great deal of trouble suggesting a transition plan that cements the .int status quo as the solution for ever. Even if we do not do this now at the last minute when we put it aside earlier, I believe we must have a way for the .int registrants to have some say in their long term future post transition. avri --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
participants (14)
-
Andrew Sullivan -
Avri Doria -
Brenden Kuerbis -
CW Lists -
David Conrad -
Gomes, Chuck -
Greg Shatan -
manning -
manning bill -
Martin Boyle -
Milton L Mueller -
Seun Ojedeji -
Steve Crocker -
Suzanne Woolf