WP2 Issues from last night's call
I’ve attached a revised deck trying to lay out our conclusions from last night. 1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2. Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
I think this deals with chapeau issue elegantly. Paul -- Dr Paul Twomey Managing Director Argo P@cific US Cell: +1 310 279 2366 Aust M: +61 416 238 501 www.argopacific.com On 11/4/15 2:13 AM, Burr, Becky wrote:
I’ve attached a revised deck trying to lay out our conclusions from last night.
1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2.
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 03/11/2015 15:13, Burr, Becky wrote:
I’ve attached a revised deck trying to lay out our conclusions from last night.
Becky, I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously. Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded. Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission. If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission". Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²? J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote:
I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrgAF-9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
On 03/11/2015 16:54, Burr, Becky wrote:
I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²?
I think "in service of its Mission" is useful and important clarifying language. I suppose I could reluctantly accept its removal, in the interests of consensus, if that enabled us to finally put this issue to bed and we could finally freeze this text. But I feel that every time I make a concession in this area, others come back with a yet more radical and unacceptable additional demand. I'm not interested in being salami-sliced any further by my own concessions. It's time for the IPC to show that they are interested in reaching agreement. If they are not, we should revert to the original language that was overwhelmingly supported through the previous two public comment periods, and the IPC can be invited to add a formal dissenting comment. Malcolm.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote:
I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrgAF-9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
So, if we drop the competing lead ins (each of which elicits strong objections from one perspective or another) the text will read: "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet’s unique identifiers, or the content that such services carry or provide. ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.” Can we agree to this approach? Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer On 11/3/15, 12:10 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 16:54, Burr, Becky wrote:
I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²?
I think "in service of its Mission" is useful and important clarifying language.
I suppose I could reluctantly accept its removal, in the interests of consensus, if that enabled us to finally put this issue to bed and we could finally freeze this text. But I feel that every time I make a concession in this area, others come back with a yet more radical and unacceptable additional demand. I'm not interested in being salami-sliced any further by my own concessions.
It's time for the IPC to show that they are interested in reaching agreement. If they are not, we should revert to the original language that was overwhelmingly supported through the previous two public comment periods, and the IPC can be invited to add a formal dissenting comment.
Malcolm.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote:
I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et
_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W
DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrgAF -9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=Tpd2d9uemW87XIz_1HH4kpzAMFU1bANWL20yeB8rwvY&s=4Cs8W93kGiTXhBQK_H rE5iztStj__unZ2i_HULwv3P8&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
This works for me. Keith
On Nov 3, 2015, at 12:19 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
So, if we drop the competing lead ins (each of which elicits strong objections from one perspective or another) the text will read:
"ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet’s unique identifiers, or the content that such services carry or provide. ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.”
Can we agree to this approach?
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 12:10 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 16:54, Burr, Becky wrote: I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²?
I think "in service of its Mission" is useful and important clarifying language.
I suppose I could reluctantly accept its removal, in the interests of consensus, if that enabled us to finally put this issue to bed and we could finally freeze this text. But I feel that every time I make a concession in this area, others come back with a yet more radical and unacceptable additional demand. I'm not interested in being salami-sliced any further by my own concessions.
It's time for the IPC to show that they are interested in reaching agreement. If they are not, we should revert to the original language that was overwhelmingly supported through the previous two public comment periods, and the IPC can be invited to add a formal dissenting comment.
Malcolm.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote: I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et
_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W
DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrgAF -9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=Tpd2d9uemW87XIz_1HH4kpzAMFU1bANWL20yeB8rwvY&s=4Cs8W93kGiTXhBQK_H rE5iztStj__unZ2i_HULwv3P8&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Becky Thanks for yr kind efforts. Pls kindly clarify the objective of the qualifier" if reasonably appropriate" which part of the text the qualifier points to A) to achieve the mission B) to any other parts??? I believe obligation to achieve mission does not require any qualifier as the language is watered down by the two consecutive qualifiers( reasonably and appropriate) We need to be careful on test. Regards Kavouss " Sent from my iPhone
On 3 Nov 2015, at 18:17, Burr, Becky <Becky.Burr@neustar.biz> wrote:
So, if we drop the competing lead ins (each of which elicits strong objections from one perspective or another) the text will read:
"ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet’s unique identifiers, or the content that such services carry or provide. ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.”
Can we agree to this approach?
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 12:10 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 16:54, Burr, Becky wrote: I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²?
I think "in service of its Mission" is useful and important clarifying language.
I suppose I could reluctantly accept its removal, in the interests of consensus, if that enabled us to finally put this issue to bed and we could finally freeze this text. But I feel that every time I make a concession in this area, others come back with a yet more radical and unacceptable additional demand. I'm not interested in being salami-sliced any further by my own concessions.
It's time for the IPC to show that they are interested in reaching agreement. If they are not, we should revert to the original language that was overwhelmingly supported through the previous two public comment periods, and the IPC can be invited to add a formal dissenting comment.
Malcolm.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote: I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et
_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W
DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrgAF -9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=Tpd2d9uemW87XIz_1HH4kpzAMFU1bANWL20yeB8rwvY&s=4Cs8W93kGiTXhBQK_H rE5iztStj__unZ2i_HULwv3P8&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Kavouss, I know that you have objected to this language before, but it has received strong support in two public comment rounds (subject to the contract enforcement question). I tried to address your concerns about the language regarding ICANN’s power to act. The notion that ICANN’s actions must be appropriate to achieve its Mission does not strike me as unusual or over-limiting. I hope that we can now agree to move forward. Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer On 11/3/15, 2:40 PM, "Kavouss Arasteh" <kavouss.arasteh@gmail.com> wrote:
Dear Becky Thanks for yr kind efforts. Pls kindly clarify the objective of the qualifier" if reasonably appropriate" which part of the text the qualifier points to A) to achieve the mission B) to any other parts??? I believe obligation to achieve mission does not require any qualifier as the language is watered down by the two consecutive qualifiers( reasonably and appropriate) We need to be careful on test. Regards Kavouss "
Sent from my iPhone
On 3 Nov 2015, at 18:17, Burr, Becky <Becky.Burr@neustar.biz> wrote:
So, if we drop the competing lead ins (each of which elicits strong objections from one perspective or another) the text will read:
"ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet’s unique identifiers, or the content that such services carry or provide. ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.”
Can we agree to this approach?
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 12:10 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 16:54, Burr, Becky wrote: I understand the concern Malcolm, which is why I sent it out with both alternatives. What if we had neither ³in service of its mission² or ³notwithstanding its mission²?
I think "in service of its Mission" is useful and important clarifying language.
I suppose I could reluctantly accept its removal, in the interests of consensus, if that enabled us to finally put this issue to bed and we could finally freeze this text. But I feel that every time I make a concession in this area, others come back with a yet more radical and unacceptable additional demand. I'm not interested in being salami-sliced any further by my own concessions.
It's time for the IPC to show that they are interested in reaching agreement. If they are not, we should revert to the original language that was overwhelmingly supported through the previous two public comment periods, and the IPC can be invited to add a formal dissenting comment.
Malcolm.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
On 11/3/15, 11:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:
On 03/11/2015 15:13, Burr, Becky wrote: I¹ve attached a revised deck trying to lay out our conclusions from last night.
Becky,
I regret I wasn't aware of a meeting last night. Moreover, this message just arrived, and crossed with my reply to your message to Andrew immediately previously.
Regarding the chapeau, if your proposed resolution works for the IAB (as I suspect it will), then I am content, and my previous message of a few moments ago can be disregarded.
Regarding the "contracting" issue, I can accept adding the preliminary language "In service of its Mission". I cannot accept Greg's alternative suggestion "Notwithstanding the foregoing"; that would mean that the following statement completely supercedes and overrides the statement of there being a limited Mission.
If you need any further explanation of why the purple "notwithstanding the foregoing" is a non-starter, I can provide voluminous references to responses to public comment, and a comparison with the ISPCP statement issued in Dublin. I hope this will not be necessary, and that we can all agree on "In service of the Mission".
Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx .n et
_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYah OP 8W
DDkMr4k&m=JqsC5Zjvz5DIE0mKPzICaDfFgTw-Pj7kA_tmTjXLykk&s=F2P5dcS88CIyrg AF -9 N3nMq_NXhs_W3qUUCmMroUkuU&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |
https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et
_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W
DDkMr4k&m=Tpd2d9uemW87XIz_1HH4kpzAMFU1bANWL20yeB8rwvY&s=4Cs8W93kGiTXhBQK _H rE5iztStj__unZ2i_HULwv3P8&e=
London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ
Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIFaQ&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=R7jvecg1FpKMMJVhGKo afk9DaP1XymgB5bgvdBpC3nY&s=ZvtLNsKbi0wu_cjZGAo_WMSVWtBWNqOv8WO04iC1fPo&e=
Becky, all, I'm sorry, but I have some concerns with the text as it has evolved for (new 1) the names part of the mission statement. Not having been on today's call, this might have been covered. However, the new wording does seem to me to extend the role of ICANN for ccTLDs. For ccTLDs the ICANN policy role is limited to root-zone issues and those that can be directly linked to security, stability and resilience of the DNS. The new wording appears to me to broaden the coverage. First bullet: "reasonably necessary to facilitate openness, interoperability [and/or] security...": I'm not sure I know what reasonably necessary means, but in association with the qualities, it could easily be interpreted as harmonising on specific requirements. Could we think of some wording that limits the potential for mission creep? How about, "For which coordinated resolution is appropriate and necessary to facilitate resilience, security and/or stability."? Second bullet: I have significant concerns about the word "designed." Could we replace the bullet with, "That are developed through a bottom-up, consensus-based multi-stakeholder process and that are necessary to ensure the stable and secure operation of the Internet's unique names system."? Martin From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: 03 November 2015 15:14 To: Accountability Community; Andrew Sullivan; iab@iab.org Subject: [CCWG-ACCT] WP2 Issues from last night's call I've attached a revised deck trying to lay out our conclusions from last night. 1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2. Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
Confused Martin – none of the language re names has changed for months Martin, other than changing "Domain names (forming a system referred to as "DNS”)” to "names in the root zone of the Domain Name System (“DNS”). Otherwise the language remains exactly the same. J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer From: Martin Boyle <Martin.Boyle@nominet.uk<mailto:Martin.Boyle@nominet.uk>> Date: Tuesday, November 3, 2015 at 12:35 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>> Subject: RE: WP2 Issues from last night's call Becky, all, I’m sorry, but I have some concerns with the text as it has evolved for (new 1) the names part of the mission statement. Not having been on today’s call, this might have been covered. However, the new wording does seem to me to extend the role of ICANN for ccTLDs. For ccTLDs the ICANN policy role is limited to root-zone issues and those that can be directly linked to security, stability and resilience of the DNS. The new wording appears to me to broaden the coverage. First bullet: “reasonably necessary to facilitate openness, interoperability [and/or] security…”: I’m not sure I know what reasonably necessary means, but in association with the qualities, it could easily be interpreted as harmonising on specific requirements. Could we think of some wording that limits the potential for mission creep? How about, “For which coordinated resolution is appropriate and necessary to facilitate resilience, security and/or stability.”? Second bullet: I have significant concerns about the word “designed.” Could we replace the bullet with, “That are developed through a bottom-up, consensus-based multi-stakeholder process and that are necessary to ensure the stable and secure operation of the Internet’s unique names system.”? Martin From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: 03 November 2015 15:14 To: Accountability Community; Andrew Sullivan; iab@iab.org<mailto:iab@iab.org> Subject: [CCWG-ACCT] WP2 Issues from last night's call I’ve attached a revised deck trying to lay out our conclusions from last night. 1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2. Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
Becky Thank you for reply But the qualifiers are subject to whose judgement? ICANN? OR the Community. If these two composed qualifier are an option for ICANN to decide how reasonably appropriate achieve the mission's objhectives, If they do not avcheive those objectives reasonably appropriate they could claim that it was neither reasonable nor appropriate to do so. Whether the text was or was not subject to public comments , I do not care. It is wrong at this stage You put the acheivement of the mission subject to judgement of ICANN as being reasonably appropriate to acheive or not. Please read the text carefully or consult other lawyers Kavouss 2015-11-03 21:56 GMT+01:00 Burr, Becky <Becky.Burr@neustar.biz>:
Confused Martin – none of the language re names has changed for months Martin, other than changing "Domain names (forming a system referred to as "DNS”)” to "names in the root zone of the Domain Name System (“DNS”). Otherwise the language remains exactly the same.
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
From: Martin Boyle <Martin.Boyle@nominet.uk> Date: Tuesday, November 3, 2015 at 12:35 PM To: Becky Burr <becky.burr@neustar.biz>, Accountability Community < accountability-cross-community@icann.org>, Andrew Sullivan < ajs@anvilwalrusden.com>, "iab@iab.org" <iab@iab.org> Subject: RE: WP2 Issues from last night's call
Becky, all,
I’m sorry, but I have some concerns with the text as it has evolved for (new 1) the names part of the mission statement. Not having been on today’s call, this might have been covered. However, the new wording does seem to me to extend the role of ICANN for ccTLDs.
For ccTLDs the ICANN policy role is limited to root-zone issues and those that can be directly linked to security, stability and resilience of the DNS. The new wording appears to me to broaden the coverage.
First bullet: “reasonably necessary to facilitate openness, interoperability [and/or] security…”: I’m not sure I know what reasonably necessary means, but in association with the qualities, it could easily be interpreted as harmonising on specific requirements. Could we think of some wording that limits the potential for mission creep? How about, “For which coordinated resolution is appropriate and necessary to facilitate resilience, security and/or stability.”?
Second bullet: I have significant concerns about the word “designed.” Could we replace the bullet with, “That are developed through a bottom-up, consensus-based multi-stakeholder process and that are necessary to ensure the stable and secure operation of the Internet’s unique names system.”?
Martin
*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Burr, Becky *Sent:* 03 November 2015 15:14 *To:* Accountability Community; Andrew Sullivan; iab@iab.org *Subject:* [CCWG-ACCT] WP2 Issues from last night's call
I’ve attached a revised deck trying to lay out our conclusions from last night.
1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document
2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document
3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2
4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2.
Becky
J. Beckwith Burr
Deputy General Counsel & Chief Privacy Officer
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
[Dropping IAB from this, because it's peripheral to that other part of the discussion.] On Tue, Nov 03, 2015 at 10:30:02PM +0100, Kavouss Arasteh wrote:
But the qualifiers are subject to whose judgement? ICANN? OR the Community.
My impression of the other accountability improvements was that they were supposed to make sure that ICANN's judgement reflects the community's judgement. So, assuming they work, I think the community can be trusted to make the judgement and lead ICANN to the right decision that way. That, at least, is how I understand the text. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Becky, Ah sorry: I see now. My mistake. I had gone back to the original mission and I think I must have missed a lot of the discussion that led to the CCWG Proposed Text which seems to me to widen ICANN's mission with respect to ccTLDs. (I'm sure such terminology is quite appropriate for regulation in the gTLD space.) So it is already ground that has been lost for the mission statement. My apologies for having raised this too late. I'll just note that some wording ("of the DNS") has not been transferred across from the CCWG Proposed Text to the Text as Modified and regret the loss of terms like "appropriately related" and "these technical functions" that recognise limitations to ICANN's role supported in the scope defined by the ccNSO-related bylaws. Martin From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: 03 November 2015 20:57 To: Martin Boyle; Accountability Community; Andrew Sullivan; iab@iab.org Subject: Re: WP2 Issues from last night's call Confused Martin - none of the language re names has changed for months Martin, other than changing "Domain names (forming a system referred to as "DNS")" to "names in the root zone of the Domain Name System ("DNS"). Otherwise the language remains exactly the same. J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer From: Martin Boyle <Martin.Boyle@nominet.uk<mailto:Martin.Boyle@nominet.uk>> Date: Tuesday, November 3, 2015 at 12:35 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>> Subject: RE: WP2 Issues from last night's call Becky, all, I'm sorry, but I have some concerns with the text as it has evolved for (new 1) the names part of the mission statement. Not having been on today's call, this might have been covered. However, the new wording does seem to me to extend the role of ICANN for ccTLDs. For ccTLDs the ICANN policy role is limited to root-zone issues and those that can be directly linked to security, stability and resilience of the DNS. The new wording appears to me to broaden the coverage. First bullet: "reasonably necessary to facilitate openness, interoperability [and/or] security...": I'm not sure I know what reasonably necessary means, but in association with the qualities, it could easily be interpreted as harmonising on specific requirements. Could we think of some wording that limits the potential for mission creep? How about, "For which coordinated resolution is appropriate and necessary to facilitate resilience, security and/or stability."? Second bullet: I have significant concerns about the word "designed." Could we replace the bullet with, "That are developed through a bottom-up, consensus-based multi-stakeholder process and that are necessary to ensure the stable and secure operation of the Internet's unique names system."? Martin From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: 03 November 2015 15:14 To: Accountability Community; Andrew Sullivan; iab@iab.org<mailto:iab@iab.org> Subject: [CCWG-ACCT] WP2 Issues from last night's call I've attached a revised deck trying to lay out our conclusions from last night. 1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2. Becky J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
Hi, On Tue, Nov 03, 2015 at 03:13:49PM +0000, Burr, Becky wrote:
I’ve attached a revised deck trying to lay out our conclusions from last night.
Thanks for this work. As a tiny friendly amendment, I'd suggest adjusting "…unique identifier systems as described …" to "…unique identifier systems in the ways described …". This change will avoid any question of whether ICANN has responsibility for all unique identifier systems (it plainly doesn't -- email addresses, twitter handles, and ethernet MAC addresses are all such systems, none of which are ICANN's problem). I'm not super worked up about this, but I suggest it because it protects ICANN from people who want to find problems for ICANN to solve. For item 4, I think this would work pretty well: 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force. This allows for co-ordination not strictly through the MoU (as in the TZ database), and highlights the collaboration. Note that it's "protocol ports and parameters" -- no "numbers", since not all the registries are numeric. So, putting that all together, I think this is what we'd get: The Mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems in the ways described below. Specifically, ICANN: 1. Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS"). In this role, ICANN’s Mission is to coordinate the development and implementation of policies: • For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability: • That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems. 2. Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by root server operators]. 3. Coordinates the allocation and assignment at the top-most level of Internet Protocol ("IP") and Autonomous System ("AS") numbers. ICANN’s Mission is described in the ASO MoU between ICANN and RIRs. 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force. I'm pretty confident this would find support among the IAB. I've done some quick consultation and people seem to be reasonably comfortable. Again, I haven't done a formal consensus call, and doing so would take some time. I will if that will make people comfortable, but it'll probably be more useful if it happens after the text is pretty well completely settled. I think this text achieves our collective goal of an accurate, easily-understood mission statement that gives due weight to ICANN's important role without overstating it or exposing ICANN to the dangers a too-broad mission would entail. I appreciate so much the spirit of collaboration and co-operation here. I think it's just another sign that, when it comes to getting this sort of thing done, there really is nothing that beats open processes and collaboration among multiple stakeholders. Thanks, and special thanks to Becky who I know has been on the pointy end of much of this discussion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Is there a reason why we need "Internet protocol development organizations, such as" ? Why can't it just say: 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force. -----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Tuesday, November 3, 2015 11:39 PM To: Burr, Becky Cc: iab@iab.org; Accountability Community Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call Hi, On Tue, Nov 03, 2015 at 03:13:49PM +0000, Burr, Becky wrote:
I’ve attached a revised deck trying to lay out our conclusions from last night.
Thanks for this work. As a tiny friendly amendment, I'd suggest adjusting "…unique identifier systems as described …" to "…unique identifier systems in the ways described …". This change will avoid any question of whether ICANN has responsibility for all unique identifier systems (it plainly doesn't -- email addresses, twitter handles, and ethernet MAC addresses are all such systems, none of which are ICANN's problem). I'm not super worked up about this, but I suggest it because it protects ICANN from people who want to find problems for ICANN to solve. For item 4, I think this would work pretty well: 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force. This allows for co-ordination not strictly through the MoU (as in the TZ database), and highlights the collaboration. Note that it's "protocol ports and parameters" -- no "numbers", since not all the registries are numeric. So, putting that all together, I think this is what we'd get: The Mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems in the ways described below. Specifically, ICANN: 1. Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS"). In this role, ICANN’s Mission is to coordinate the development and implementation of policies: • For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability: • That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems. 2. Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by root server operators]. 3. Coordinates the allocation and assignment at the top-most level of Internet Protocol ("IP") and Autonomous System ("AS") numbers. ICANN’s Mission is described in the ASO MoU between ICANN and RIRs. 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force. I'm pretty confident this would find support among the IAB. I've done some quick consultation and people seem to be reasonably comfortable. Again, I haven't done a formal consensus call, and doing so would take some time. I will if that will make people comfortable, but it'll probably be more useful if it happens after the text is pretty well completely settled. I think this text achieves our collective goal of an accurate, easily-understood mission statement that gives due weight to ICANN's important role without overstating it or exposing ICANN to the dangers a too-broad mission would entail. I appreciate so much the spirit of collaboration and co-operation here. I think it's just another sign that, when it comes to getting this sort of thing done, there really is nothing that beats open processes and collaboration among multiple stakeholders. Thanks, and special thanks to Becky who I know has been on the pointy end of much of this discussion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Wed, Nov 04, 2015 at 01:12:19PM +0000, Chartier, Mike S wrote:
Is there a reason why we need "Internet protocol development organizations, such as" ?
Why can't it just say:
4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force.
I don't _think_ that would be a problem for me or for the IAB, but I am sensitive that some apparently believe the IAB is trying to tell ICANN what its mission is. We're not, but I don't want to give anyone such an impression. The Time Zone database is one slight wrinkle here. TZDB isn't really an IETF product, and though ICANN's IANA function is used to perform the updates and the IESG now appoints the relevant experts (see RFC 6557), the database isn't really an IETF work product. On the other hand, RFC 6557 does say The time zone community has requested that the IETF adopt the ongoing maintenance of the Time Zone Database. The time zone community would like the IETF to maintain it in a consistent fashion to its administration of the Internet protocol parameters and values. So maybe saying "requested by the IETF" would be ok there anyway. Also, under its agreements with ICANN the IETF could stop using ICANN as its IANA operator, or could choose another operator for some registries (as it did for ENUM). If the IETF decided to move all functions, then the removal of "such as" would make the clause false; I'm anxious not to set up a sitation where a fundamental bylaw could be impossible for ICANN to satisfy because of the actions of another party (such as the IETF). By leaving the "such as" in, there is a set of possible protocol parameter sources, a member of which is the IETF; the actual set could be empty at any one time without a problem. So those are a couple reasons for the language; but my initial reaction is that it ought to be ok to remove the "such as". I have not asked anyone on the IAB, so I don't know whether they'd have a different opinion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Thanks very much for the explanation. I not sure I see how "If the IETF decided to move all functions, then the removal of "such as" would make the clause false"? The statement says ICANN provides those services "requested by" IETF, doesn't that leave the decision to IETF? -----Original Message----- From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] Sent: Wednesday, November 4, 2015 8:52 AM To: Chartier, Mike S Cc: Burr, Becky; iab@iab.org; Accountability Community Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call On Wed, Nov 04, 2015 at 01:12:19PM +0000, Chartier, Mike S wrote:
Is there a reason why we need "Internet protocol development organizations, such as" ?
Why can't it just say:
4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force.
I don't _think_ that would be a problem for me or for the IAB, but I am sensitive that some apparently believe the IAB is trying to tell ICANN what its mission is. We're not, but I don't want to give anyone such an impression. The Time Zone database is one slight wrinkle here. TZDB isn't really an IETF product, and though ICANN's IANA function is used to perform the updates and the IESG now appoints the relevant experts (see RFC 6557), the database isn't really an IETF work product. On the other hand, RFC 6557 does say The time zone community has requested that the IETF adopt the ongoing maintenance of the Time Zone Database. The time zone community would like the IETF to maintain it in a consistent fashion to its administration of the Internet protocol parameters and values. So maybe saying "requested by the IETF" would be ok there anyway. Also, under its agreements with ICANN the IETF could stop using ICANN as its IANA operator, or could choose another operator for some registries (as it did for ENUM). If the IETF decided to move all functions, then the removal of "such as" would make the clause false; I'm anxious not to set up a sitation where a fundamental bylaw could be impossible for ICANN to satisfy because of the actions of another party (such as the IETF). By leaving the "such as" in, there is a set of possible protocol parameter sources, a member of which is the IETF; the actual set could be empty at any one time without a problem. So those are a couple reasons for the language; but my initial reaction is that it ought to be ok to remove the "such as". I have not asked anyone on the IAB, so I don't know whether they'd have a different opinion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Hi, On Wed, Nov 04, 2015 at 02:22:25PM +0000, Chartier, Mike S wrote:
Thanks very much for the explanation. I not sure I see how "If the IETF decided to move all functions, then the removal of "such as" would make the clause false"? The statement says ICANN provides those services "requested by" IETF, doesn't that leave the decision to IETF?
Yeah, "would" was probably too strong. Probably more like, "I worry that someone would believe that…." The reason, indeed, that we picked the "requested by" language (it wasn't mine, but one of my IAB colleagues) was exactly to defuse that sort of problem. I'm really trying to be careful not to overstep. But I can't currently think of a reason that "such as" is really required. (Note that it's about 23:30 on the Wednesday of an IETF week, so what I can or cannot think at this moment may be even a poorer guide to good ideas than usual.) A -- Andrew Sullivan ajs@anvilwalrusden.com
Because the IETF may could be replaced, conceivably. el On 2015-11-04 15:12, Chartier, Mike S wrote:
Is there a reason why we need "Internet protocol development organizations, such as" ?
Why can't it just say:
4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force.
[...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/
Or as Andrew rightl stated, the IETF may / could replace ICANN, coneivably. el On 2015-11-04 15:54, Dr Eberhard W Lisse wrote:
Because the IETF may could be replaced, conceivably.
el
On 2015-11-04 15:12, Chartier, Mike S wrote:
Is there a reason why we need "Internet protocol development organizations, such as" ?
Why can't it just say:
4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force.
[...]
-- Dr. Eberhard W. Lisse 4-5, St Annes Walk <Directors@omadhina.net> Alderney, Guernsey, GY9 3JZ Omadhina Internet Services Ltd British Channel Islands
Hi, On Wed, Nov 04, 2015 at 01:12:19PM +0000, Chartier, Mike S wrote:
4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force.
Today we polled the IAB, and its consensus is that either the above text or the previous text (with "such as") is acceptable to it. This does not mean the IAB is unwilling to consider or discuss other text, and I think there are some obvious adjustments that we'd be perfectly happy to see. But either of the versions we've been discussing (assuming the rest of the mission is consistent with it) will work for the IAB. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content". What is the status of the two sections where "Where feasible and appropriate" had been deleted in the August proposal? Alan At 03/11/2015 10:13 AM, Burr, Becky wrote:
I've attached a revised deck trying to lay out our conclusions from last night.
1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2.
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 04/11/2015 14:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
Alan, If you read the clause carefully, you will see that it does not say that ICANN cannot regulate Internet content; that's just a loose paraphrasing some people have been using in conversation. Instead, it says that ICANN "shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide." So the target of that exclusion is not "content" but "services" and "the content that such services carry or provide". This neatly avoids the question of whether domain names are content, because even if they are, they are still outside the reach of that exclusion. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
Malcolm, can you explain how domain name registration is not a "service that uses the Internet's unique identifiers"? Steve Metalitz From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 04, 2015 10:59 AM To: Alan Greenberg; Burr, Becky; Accountability Community; Andrew Sullivan; iab@iab.org Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call On 04/11/2015 14:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
Alan, If you read the clause carefully, you will see that it does not say that ICANN cannot regulate Internet content; that's just a loose paraphrasing some people have been using in conversation. Instead, it says that ICANN "shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide." So the target of that exclusion is not "content" but "services" and "the content that such services carry or provide". This neatly avoids the question of whether domain names are content, because even if they are, they are still outside the reach of that exclusion. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/<http://publicaffairs.linx.net/> London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://mm.icann.org/mailman/listinfo/accountability-cross-community>
Guys, read specification 1 to the RAA. J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer From: <Metalitz>, Steven Metalitz <met@msk.com<mailto:met@msk.com>> Date: Wednesday, November 4, 2015 at 11:03 AM To: 'Malcolm Hutty' <malcolm@linx.net<mailto:malcolm@linx.net>>, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>> Subject: RE: [CCWG-ACCT] WP2 Issues from last night's call Malcolm, can you explain how domain name registration is not a “service that uses the Internet’s unique identifiers”? Steve Metalitz From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 04, 2015 10:59 AM To: Alan Greenberg; Burr, Becky; Accountability Community; Andrew Sullivan; iab@iab.org<mailto:iab@iab.org> Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call On 04/11/2015 14:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
Alan, If you read the clause carefully, you will see that it does not say that ICANN cannot regulate Internet content; that's just a loose paraphrasing some people have been using in conversation. Instead, it says that ICANN "shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide." So the target of that exclusion is not "content" but "services" and "the content that such services carry or provide". This neatly avoids the question of whether domain names are content, because even if they are, they are still outside the reach of that exclusion. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net_&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=A8DtJCyVMLau-WRON7AQ_czu4FzwQSRY5CwKB3_lfYQ&e=> London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=iCNwcPAMpoUQGaoDRWeh9IT72SUScm3T-i7MFMaS454&e=>
For some reason the Consensus/Temporary Policy Spec is Spec 4 in the RAA. Note that Section 1.2 outlines the topics that are fair game for consensus policies, which includes “resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names) Section 1.3 gives specific examples (without limitation), including "reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration)" CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION 1. Consensus Policies. 1.1. "Consensus Policies" are those policies established (1) pursuant to the procedure set forth inICANN's Bylaws and due process, and (2) covering those topics listed in Section 1.2 of this document. The Consensus Policy development process and procedure set forth in ICANN's Bylaws may be revised from time to time in accordance with the process set forth therein. 1.2. Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including registrars. Consensus Policies shall relate to one or more of the following: 1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet, Registrar Services, Registry Services, or the Domain Name System ("DNS"); 1.2.2. functional and performance specifications for the provision of Registrar Services; 1.2.3. registrar policies reasonably necessary to implement Consensus Policies relating to a gTLD registry; 1.2.4. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); or 1.2.5. restrictions on cross-ownership of registry operators and registrars or Resellers and regulations and restrictions with respect to registrar and registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or Reseller are affiliated. 1.3. Such categories of issues referred to in Section 1.2 shall include, without limitation: 1.3.1. principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars; 1.3.3. reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); 1.3.4. maintenance of and access to accurate and up-to-date information concerning Registered Names and name servers; 1.3.5. procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility among continuing registrars of the Registered Names sponsored in aTLD by a registrar losing accreditation; and 1.3.6. the transfer of registration data upon a change in registrar sponsoring one or more Registered Names. 1.4. In addition to the other limitations on Consensus Policies, they shall not: 1.4.1. prescribe or limit the price of Registrar Services; 1.4.2. modify the limitations on Temporary Policies (defined below) or Consensus Policies; 1.4.3. modify the provisions in the Registrar Accreditation Agreement regarding terms or conditions for the renewal, termination or amendment of the Registrar Accreditation Agreement or fees paid by Registrar to ICANN; or 1.4.4. modify ICANN's obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and to not single out Registrar for disparate treatment unless justified by substantial and reasonable cause, and exercise its responsibilities in an open and transparent manner. 2. Temporary Policies. Registrar shall comply with and implement all specifications or policies established by the ICANN Board of Directors (the "Board") on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet ("Temporary Policies"). 2.1. Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Policy, the Board shall state the period of time for which the Temporary Policy is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws. 2.1.1. ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the Temporary Policy and why the Board believes such Temporary Policy should receive the consensus support of Internet stakeholders. 2.1.2. If the period of time for which the Temporary Policy is adopted exceeds 90 days, the Board shall reaffirm its temporary adoption every 90 days for a total period not to exceed one year, in order to maintain such Temporary Policy in effect until such time as it becomes aConsensus Policy. If the one year period expires or, if during such one year period, the Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board, Registrar shall no longer be required to comply with or implement such Temporary Policy. 3. Notice and Conflicts. Registrar shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such policy or specification, taking into account any urgency involved. In the event of a conflict between Registrar Services and Consensus Policies or any Temporary Policy, the Consensus Polices or Temporary Policy shall control, but only with respect to subject matter in conflict. For the avoidance of doubt,Consensus Policies that meet the requirements of this Specification may supplement or supersede provisions of the agreements between Registrar and ICANN, but only to the extent that suchConsensus Policies relate to the matters set forth in Section 1.2 and 1.3 of this Specification. J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer From: <Metalitz>, Steven Metalitz <met@msk.com<mailto:met@msk.com>> Date: Wednesday, November 4, 2015 at 11:03 AM To: 'Malcolm Hutty' <malcolm@linx.net<mailto:malcolm@linx.net>>, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>> Subject: RE: [CCWG-ACCT] WP2 Issues from last night's call Malcolm, can you explain how domain name registration is not a “service that uses the Internet’s unique identifiers”? Steve Metalitz From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 04, 2015 10:59 AM To: Alan Greenberg; Burr, Becky; Accountability Community; Andrew Sullivan; iab@iab.org<mailto:iab@iab.org> Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call On 04/11/2015 14:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
Alan, If you read the clause carefully, you will see that it does not say that ICANN cannot regulate Internet content; that's just a loose paraphrasing some people have been using in conversation. Instead, it says that ICANN "shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide." So the target of that exclusion is not "content" but "services" and "the content that such services carry or provide". This neatly avoids the question of whether domain names are content, because even if they are, they are still outside the reach of that exclusion. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net_&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=A8DtJCyVMLau-WRON7AQ_czu4FzwQSRY5CwKB3_lfYQ&e=> London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=iCNwcPAMpoUQGaoDRWeh9IT72SUScm3T-i7MFMaS454&e=>
Becky and all - I've just been granted participant access to this thread but have been following this issue for some time. I'm still confused as to how Spec 1 clarifies the "regulation" language. If spec 1 says ICANN can do something by way of consensus policy making, does that trump what the bylaws say ICANN can do? Bylaws trump, don't they? Bradley Silver Chief Intellectual Property Counsel | Time Warner Inc. One Time Warner Center New York, NY 10019-8016 | P: 212 484 8869 | F: 212 658 9293 [cid:image003.png@01D11709.11250B80] From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: Wednesday, November 04, 2015 11:33 AM To: Metalitz, Steven; 'Malcolm Hutty'; Alan Greenberg; Accountability Community; Andrew Sullivan; iab@iab.org Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call For some reason the Consensus/Temporary Policy Spec is Spec 4 in the RAA. Note that Section 1.2 outlines the topics that are fair game for consensus policies, which includes "resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names) Section 1.3 gives specific examples (without limitation), including "reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration)" CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION 1. Consensus Policies. 1.1. "Consensus Policies" are those policies established (1) pursuant to the procedure set forth inICANN's Bylaws and due process, and (2) covering those topics listed in Section 1.2 of this document. The Consensus Policy development process and procedure set forth in ICANN's Bylaws may be revised from time to time in accordance with the process set forth therein. 1.2. Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including registrars. Consensus Policies shall relate to one or more of the following: 1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet, Registrar Services, Registry Services, or the Domain Name System ("DNS"); 1.2.2. functional and performance specifications for the provision of Registrar Services; 1.2.3. registrar policies reasonably necessary to implement Consensus Policies relating to a gTLD registry; 1.2.4. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); or 1.2.5. restrictions on cross-ownership of registry operators and registrars or Resellers and regulations and restrictions with respect to registrar and registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or Reseller are affiliated. 1.3. Such categories of issues referred to in Section 1.2 shall include, without limitation: 1.3.1. principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars; 1.3.3. reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); 1.3.4. maintenance of and access to accurate and up-to-date information concerning Registered Names and name servers; 1.3.5. procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility among continuing registrars of the Registered Names sponsored in aTLD by a registrar losing accreditation; and 1.3.6. the transfer of registration data upon a change in registrar sponsoring one or more Registered Names. 1.4. In addition to the other limitations on Consensus Policies, they shall not: 1.4.1. prescribe or limit the price of Registrar Services; 1.4.2. modify the limitations on Temporary Policies (defined below) or Consensus Policies; 1.4.3. modify the provisions in the Registrar Accreditation Agreement regarding terms or conditions for the renewal, termination or amendment of the Registrar Accreditation Agreement or fees paid by Registrar to ICANN; or 1.4.4. modify ICANN's obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and to not single out Registrar for disparate treatment unless justified by substantial and reasonable cause, and exercise its responsibilities in an open and transparent manner. 2. Temporary Policies. Registrar shall comply with and implement all specifications or policies established by the ICANN Board of Directors (the "Board") on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet ("Temporary Policies"). 2.1. Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Policy, the Board shall state the period of time for which the Temporary Policy is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws. 2.1.1. ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the Temporary Policy and why the Board believes such Temporary Policy should receive the consensus support of Internet stakeholders. 2.1.2. If the period of time for which the Temporary Policy is adopted exceeds 90 days, the Board shall reaffirm its temporary adoption every 90 days for a total period not to exceed one year, in order to maintain such Temporary Policy in effect until such time as it becomes aConsensus Policy. If the one year period expires or, if during such one year period, the Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board, Registrar shall no longer be required to comply with or implement such Temporary Policy. 3. Notice and Conflicts. Registrar shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such policy or specification, taking into account any urgency involved. In the event of a conflict between Registrar Services and Consensus Policies or any Temporary Policy, the Consensus Polices or Temporary Policy shall control, but only with respect to subject matter in conflict. For the avoidance of doubt,Consensus Policies that meet the requirements of this Specification may supplement or supersede provisions of the agreements between Registrar and ICANN, but only to the extent that suchConsensus Policies relate to the matters set forth in Section 1.2 and 1.3 of this Specification. J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer From: <Metalitz>, Steven Metalitz <met@msk.com<mailto:met@msk.com>> Date: Wednesday, November 4, 2015 at 11:03 AM To: 'Malcolm Hutty' <malcolm@linx.net<mailto:malcolm@linx.net>>, Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Andrew Sullivan <ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>>, "iab@iab.org<mailto:iab@iab.org>" <iab@iab.org<mailto:iab@iab.org>> Subject: RE: [CCWG-ACCT] WP2 Issues from last night's call Malcolm, can you explain how domain name registration is not a "service that uses the Internet's unique identifiers"? Steve Metalitz From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 04, 2015 10:59 AM To: Alan Greenberg; Burr, Becky; Accountability Community; Andrew Sullivan; iab@iab.org<mailto:iab@iab.org> Subject: Re: [CCWG-ACCT] WP2 Issues from last night's call On 04/11/2015 14:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
Alan, If you read the clause carefully, you will see that it does not say that ICANN cannot regulate Internet content; that's just a loose paraphrasing some people have been using in conversation. Instead, it says that ICANN "shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide." So the target of that exclusion is not "content" but "services" and "the content that such services carry or provide". This neatly avoids the question of whether domain names are content, because even if they are, they are still outside the reach of that exclusion. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net_&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=A8DtJCyVMLau-WRON7AQ_czu4FzwQSRY5CwKB3_lfYQ&e=> London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=yv-2vaZRUToupIoctB5N26jR1-FX1R8g20SyyjFmT-8&s=iCNwcPAMpoUQGaoDRWeh9IT72SUScm3T-i7MFMaS454&e=> ================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================
Hi, Somehow, ICANN decding what is and what isn't content seems way out of scope. BTW, hanging out at the IETF this week, a few people have explained to me the importance of the IAB request, (I have also read Andrews words) and remove my objection to doing this. But suggestions such as declaring what is and what isn't content ís the sort of creepage that I was worried about in my concerns about reopening the mission. cheers avri On 04-Nov-15 23:17, Alan Greenberg wrote:
In the regulatory section, I would still like to see language that explicitly says that the unique identifiers themselves are deemed to not be "content".
What is the status of the two sections where "Where feasible and appropriate" had been deleted in the August proposal?
Alan
At 03/11/2015 10:13 AM, Burr, Becky wrote:
I've attached a revised deck trying to lay out our conclusions from last night.
1. We concluded to resolve the support/coordinate problem by eliminating the chapeau in the Mission Statement. See Slide 1 and the side-by-side document 2. Kavouss strongly urged us to modify the language of the regulatory preclusion. I have taken a shot at that in purple in the side-by-side document 3. Greg Shatan proposed a modification to the contracting language also reflected in purple on slide 2 4. We agreed to put transparency points 1 and 2 in WS1 and to address points 3 and 4 as part of WS2.
Becky
J. Beckwith Burr Deputy General Counsel & Chief Privacy Officer
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
participants (15)
-
Alan Greenberg -
Andrew Sullivan -
Avri Doria -
Burr, Becky -
Chartier, Mike S -
Dr Eberhard W Lisse -
Dr Eberhard W Lisse -
Drazek, Keith -
Eric Brunner-Williams -
Kavouss Arasteh -
Malcolm Hutty -
Martin Boyle -
Metalitz, Steven -
Paul Twomey -
Silver, Bradley