RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales Alberto Soto -----Mensaje original----- De: ianaxfer-bounces@nro.net [mailto:ianaxfer-bounces@nro.net] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer@nro.net Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June On Jun 7, 2015, at 11:51 PM, David Conrad <drc@virtualized.org> wrote:
Hi,
I have been hesitant to provide comments on the draft SLA due to my current role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community. However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.
Perhaps this can be a lesson in being careful what you ask for...
While I can assert the following input is, in fact, (a) purely my own, (b) is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.
David - Thanks for these comments - I have no doubt that they will lead to an improved SLA as a result.
I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.
Along that spirit, I am going to refrain from responding to the vast majority of the comments (as the community is likely to have ample comments), but but will comment on three areas which relate to the overall assumptions for the IANA Stewardship transition process at a high-level.
... In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole.
Agreed.
As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.
I believe that the roles and responsibilities of the parties must be defined, but that doesn’t necessarily have to be (or even should be) in a single document. The rather colorful structure and evolution of ICANN has resulted in it having multiple roles, and yet these roles are not strictly dependent on each other. For example, if the ICANN IANA team were to experience extremely and chronic performance issues in the administration of the IANA number registries (the opposite of the excellent performance provided to date), then there could be a circumstances where the numbers community would need (via the RIRs as their representative) to contract for an alternative IANA numbers registry operator. The SLA should be suitable for that arrangement (even though ICANN would not longer be performing the IANA numbers registry function.) However, in my personal opinion, such a change should not in any way change the RIRs collectively operating under ICANN’s overall Internet identifier coordination role; i.e. the community should still submit global policies to ICANN for ratification, the ASO MOU should remain in effect, the RIR community should participate in accountability and transparency reviews (ATRT) as part of the ICANN system, etc. ICANN serves as an important role external to the Internet numbers community that improves overall accountability and transparency, and helps in broad outreach to the global Internet community. So, I think we’re in agreement that role and responsibilities should be clearly defined, but it is not clear that it should be done in a single document since there are multiple relationships: 1) RIRs/NRO serving as the global Address Supporting Organization within ICANN, with its incumbent obligations, and 2) ICANN serving as the IANA numbers service operator for numbering community as represented by the RIRs.
5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."
Um, what? So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.
Actually, I believe it is $100 _in total_ under the present language… Is there a value that makes more sense - i.e. what do you believe the full costs of providing “the extremely limited activity” of the IANA numbering function? I personally believe that it is in the community's interest for this value be an accurate estimate of such costs, and the present ICANN ASO contribution should be reduced by the same amount once established. In this manner, if the worst-cast were to happen and another party had to perform IANA services, then the RIRs would have budgeted at least a meaningful amount for this purpose, and while ICANN would lose this amount, it would correspond with a similar reduction in the level of effort in their IANA team.
12.1.1: "Operator does hereby assign and transfer any and all right, title and interest in and to such intellectual property rights to the RIRs, their successors, assigns and designees."
I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.
12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."
Similar comment as above.
12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the “IP Assets”)."
This is backwards. ICANN currently owns the rights to that intellectual property.
It would be nice if we could all come to agreement that the rights to the community's intellectual property related to these activities (including any data rights, trademark, domain names, etc.) should be held by an entity which was actually set up for such a purpose, had no operational role, would make appropriate licenses available to all parties that had a role in IANA operations, etc. Last I checked, the IETF Trust met all of these criteria (whereas neither ICANN nor the RIRs do) One can imagine some rather extreme worse-case scenarios involving transitions where it would be very helpful it we could all rely on the intellectual property being made available to whomever needed it to perform the functions, and not otherwise caught in transition. Thanks again for the comments! /John Disclaimer: The remarks above are my own as CEO of ARIN. While I believe them to be fully compatible with the organization's positions on these matters to date, neither the ARIN Board nor ARIN community has discussed David’s comments and developed specific positions on these topics at this time. _______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus
Alberto, mil gracias por compartir este intercambio de mensajes. Como bien lo señalas, el tema es muy específico y la discusión en extremo detallada. Sin embargo, y sobre todo con la respuesta de John Curran, el asunto del que trata es de la mayor escala y la mayor importancia. Nuestra comunidad debe estar preparada para intervenir a nivel regional y global. 1. Es indispensable contrarrestar todos los esfuerzos de los RIRs que conducen a fragmentar a ICANN, en particular a través de la fragmentación de IANA. Aunque se profesa carecer de esa intención, la firma de un convenio o contrato comercial separado para los recursos de numeración y la desproporción en los pagos entre números y nombres impulsan esa dirección. 2. La razón asiste a David Conrad en la mayor parte de sus observaciones. Ya es de suyo complejo establecer un SLA (acuerdo de nivel de servicio) con un proveedor comercial convencional de servicios que el mercado define. Reducir a un contrato de este tipo la función de "stewardship" de ICANN e IANA crea los incentivos más contraproducemtes posibles. Espero que otras organizaciones se manifiesten y propongo expresar los dos puntos aquí expuestos como una posición de consenso de LACRALO, para lo cual solicito a la Presidencia y la Secretaría instituyan los procesos formales correspondientes. Alejandro Pisanty On Mon, Jun 8, 2015 at 9:16 AM, Alberto Soto <asoto@ibero-americano.org> wrote:
Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales
Alberto Soto
-----Mensaje original----- De: ianaxfer-bounces@nro.net [mailto:ianaxfer-bounces@nro.net] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer@nro.net Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
On Jun 7, 2015, at 11:51 PM, David Conrad <drc@virtualized.org> wrote:
Hi,
I have been hesitant to provide comments on the draft SLA due to my
current role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community. However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.
Perhaps this can be a lesson in being careful what you ask for...
While I can assert the following input is, in fact, (a) purely my own,
(b) is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.
David -
Thanks for these comments - I have no doubt that they will lead to an improved SLA as a result.
I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.
Along that spirit, I am going to refrain from responding to the vast majority of the comments (as the community is likely to have ample comments), but but will comment on three areas which relate to the overall assumptions for the IANA Stewardship transition process at a high-level.
... In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole.
Agreed.
As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.
I believe that the roles and responsibilities of the parties must be defined, but that doesn’t necessarily have to be (or even should be) in a single document. The rather colorful structure and evolution of ICANN has resulted in it having multiple roles, and yet these roles are not strictly dependent on each other. For example, if the ICANN IANA team were to experience extremely and chronic performance issues in the administration of the IANA number registries (the opposite of the excellent performance provided to date), then there could be a circumstances where the numbers community would need (via the RIRs as their representative) to contract for an alternative IANA numbers registry operator. The SLA should be suitable for that arrangement (even though ICANN would not longer be performing the IANA numbers registry function.)
However, in my personal opinion, such a change should not in any way change the RIRs collectively operating under ICANN’s overall Internet identifier coordination role; i.e. the community should still submit global policies to ICANN for ratification, the ASO MOU should remain in effect, the RIR community should participate in accountability and transparency reviews (ATRT) as part of the ICANN system, etc. ICANN serves as an important role external to the Internet numbers community that improves overall accountability and transparency, and helps in broad outreach to the global Internet community.
So, I think we’re in agreement that role and responsibilities should be clearly defined, but it is not clear that it should be done in a single document since there are multiple relationships: 1) RIRs/NRO serving as the global Address Supporting Organization within ICANN, with its incumbent obligations, and 2) ICANN serving as the IANA numbers service operator for numbering community as represented by the RIRs.
5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."
Um, what? So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.
Actually, I believe it is $100 _in total_ under the present language… Is there a value that makes more sense - i.e. what do you believe the full costs of providing “the extremely limited activity” of the IANA numbering function? I personally believe that it is in the community's interest for this value be an accurate estimate of such costs, and the present ICANN ASO contribution should be reduced by the same amount once established. In this manner, if the worst-cast were to happen and another party had to perform IANA services, then the RIRs would have budgeted at least a meaningful amount for this purpose, and while ICANN would lose this amount, it would correspond with a similar reduction in the level of effort in their IANA team.
12.1.1: "Operator does hereby assign and transfer any and all right, title and interest in and to such intellectual property rights to the RIRs, their successors, assigns and designees."
I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.
12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."
Similar comment as above.
12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the “IP Assets”)."
This is backwards. ICANN currently owns the rights to that intellectual property.
It would be nice if we could all come to agreement that the rights to the community's intellectual property related to these activities (including any data rights, trademark, domain names, etc.) should be held by an entity which was actually set up for such a purpose, had no operational role, would make appropriate licenses available to all parties that had a role in IANA operations, etc. Last I checked, the IETF Trust met all of these criteria (whereas neither ICANN nor the RIRs do) One can imagine some rather extreme worse-case scenarios involving transitions where it would be very helpful it we could all rely on the intellectual property being made available to whomever needed it to perform the functions, and not otherwise caught in transition.
Thanks again for the comments! /John
Disclaimer: The remarks above are my own as CEO of ARIN. While I believe them to be fully compatible with the organization's positions on these matters to date, neither the ARIN Board nor ARIN community has discussed David’s comments and developed specific positions on these topics at this time.
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
--- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus
_______________________________________________ lac-discuss-es mailing list lac-discuss-es@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . .
Coincido Alejandro. Particularmente coincide con David en que un SLA debe contener todo lo necesario y ser redactado con la mayor claridad posible. He redactado algunos SLA como abogado y también he soportado como informático algunos de ellos, en un grupo muy grande y multinacional. Gracias por estas colaboraciones Saludos cordiales Alberto Soto De: Alejandro Pisanty [mailto:apisanty@gmail.com] Enviado el: lunes, 08 de junio de 2015 12:36 p.m. Para: Alberto Soto CC: LACRALO Español Asunto: Re: [lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June Alberto, mil gracias por compartir este intercambio de mensajes. Como bien lo señalas, el tema es muy específico y la discusión en extremo detallada. Sin embargo, y sobre todo con la respuesta de John Curran, el asunto del que trata es de la mayor escala y la mayor importancia. Nuestra comunidad debe estar preparada para intervenir a nivel regional y global. 1. Es indispensable contrarrestar todos los esfuerzos de los RIRs que conducen a fragmentar a ICANN, en particular a través de la fragmentación de IANA. Aunque se profesa carecer de esa intención, la firma de un convenio o contrato comercial separado para los recursos de numeración y la desproporción en los pagos entre números y nombres impulsan esa dirección. 2. La razón asiste a David Conrad en la mayor parte de sus observaciones. Ya es de suyo complejo establecer un SLA (acuerdo de nivel de servicio) con un proveedor comercial convencional de servicios que el mercado define. Reducir a un contrato de este tipo la función de "stewardship" de ICANN e IANA crea los incentivos más contraproducemtes posibles. Espero que otras organizaciones se manifiesten y propongo expresar los dos puntos aquí expuestos como una posición de consenso de LACRALO, para lo cual solicito a la Presidencia y la Secretaría instituyan los procesos formales correspondientes. Alejandro Pisanty On Mon, Jun 8, 2015 at 9:16 AM, Alberto Soto <asoto@ibero-americano.org <mailto:asoto@ibero-americano.org> > wrote: Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales Alberto Soto -----Mensaje original----- De: ianaxfer-bounces@nro.net <mailto:ianaxfer-bounces@nro.net> [mailto:ianaxfer-bounces@nro.net <mailto:ianaxfer-bounces@nro.net> ] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer@nro.net <mailto:ianaxfer@nro.net> Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June On Jun 7, 2015, at 11:51 PM, David Conrad <drc@virtualized.org <mailto:drc@virtualized.org> > wrote:
Hi,
I have been hesitant to provide comments on the draft SLA due to my current role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community. However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.
Perhaps this can be a lesson in being careful what you ask for...
While I can assert the following input is, in fact, (a) purely my own, (b) is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.
David - Thanks for these comments - I have no doubt that they will lead to an improved SLA as a result.
I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.
Along that spirit, I am going to refrain from responding to the vast majority of the comments (as the community is likely to have ample comments), but but will comment on three areas which relate to the overall assumptions for the IANA Stewardship transition process at a high-level.
... In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole.
Agreed.
As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.
I believe that the roles and responsibilities of the parties must be defined, but that doesn’t necessarily have to be (or even should be) in a single document. The rather colorful structure and evolution of ICANN has resulted in it having multiple roles, and yet these roles are not strictly dependent on each other. For example, if the ICANN IANA team were to experience extremely and chronic performance issues in the administration of the IANA number registries (the opposite of the excellent performance provided to date), then there could be a circumstances where the numbers community would need (via the RIRs as their representative) to contract for an alternative IANA numbers registry operator. The SLA should be suitable for that arrangement (even though ICANN would not longer be performing the IANA numbers registry function.) However, in my personal opinion, such a change should not in any way change the RIRs collectively operating under ICANN’s overall Internet identifier coordination role; i.e. the community should still submit global policies to ICANN for ratification, the ASO MOU should remain in effect, the RIR community should participate in accountability and transparency reviews (ATRT) as part of the ICANN system, etc. ICANN serves as an important role external to the Internet numbers community that improves overall accountability and transparency, and helps in broad outreach to the global Internet community. So, I think we’re in agreement that role and responsibilities should be clearly defined, but it is not clear that it should be done in a single document since there are multiple relationships: 1) RIRs/NRO serving as the global Address Supporting Organization within ICANN, with its incumbent obligations, and 2) ICANN serving as the IANA numbers service operator for numbering community as represented by the RIRs.
5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."
Um, what? So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.
Actually, I believe it is $100 _in total_ under the present language… Is there a value that makes more sense - i.e. what do you believe the full costs of providing “the extremely limited activity” of the IANA numbering function? I personally believe that it is in the community's interest for this value be an accurate estimate of such costs, and the present ICANN ASO contribution should be reduced by the same amount once established. In this manner, if the worst-cast were to happen and another party had to perform IANA services, then the RIRs would have budgeted at least a meaningful amount for this purpose, and while ICANN would lose this amount, it would correspond with a similar reduction in the level of effort in their IANA team.
12.1.1: "Operator does hereby assign and transfer any and all right, title and interest in and to such intellectual property rights to the RIRs, their successors, assigns and designees."
I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.
12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."
Similar comment as above.
12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the “IP Assets”)."
This is backwards. ICANN currently owns the rights to that intellectual property.
It would be nice if we could all come to agreement that the rights to the community's intellectual property related to these activities (including any data rights, trademark, domain names, etc.) should be held by an entity which was actually set up for such a purpose, had no operational role, would make appropriate licenses available to all parties that had a role in IANA operations, etc. Last I checked, the IETF Trust met all of these criteria (whereas neither ICANN nor the RIRs do) One can imagine some rather extreme worse-case scenarios involving transitions where it would be very helpful it we could all rely on the intellectual property being made available to whomever needed it to perform the functions, and not otherwise caught in transition. Thanks again for the comments! /John Disclaimer: The remarks above are my own as CEO of ARIN. While I believe them to be fully compatible with the organization's positions on these matters to date, neither the ARIN Board nor ARIN community has discussed David’s comments and developed specific positions on these topics at this time. _______________________________________________ ianaxfer mailing list ianaxfer@nro.net <mailto:ianaxfer@nro.net> https://www.nro.net/mailman/listinfo/ianaxfer --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus _______________________________________________ lac-discuss-es mailing list lac-discuss-es@atlarge-lists.icann.org <mailto:lac-discuss-es@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es http://www.lacralo.org -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus
Alberto, mil gracias por esta nota. Esa misma experiencia con SLAs nos debe indicar que la relación entre dos partes contratantes no se puede reducir al SLA. El SLA es un derivado del contrato "mayor" entre las partes; aunque es vital, no deja de ser un apéndice. Por lo mismo creo que debemos insistir desde LACRALO en un gran acuerdo, como el que hoy existe, para mantener a IANA unificada. En la propuesta de los RIRs no alcanza el dinero ni para las llaves de la puerta de la oficina. Suponen que IANA opera, pagada por los intereses de nombres de dominio, y pretenden aportar unos centavitos al mes por los servicios que reciben. Los costos unitarios de algunos de estos servicios pueden ser bajos pero la existencia misma del servicio se basa en una organización más grande y mucho más sólida. Por eso es fácil para los RIRs expresar la amenaza de buscar un proveedor alterno y fraccionar a IANA de manera irreversible. Es poco realista y muy lesiva. Nuestra representación en todos los grupos de trabajo debe oponerse. Conviene que ratifiquemos formalmente nuestro mandato con la solicitud que hice a ti y a Humberto para iniciar un proceso de consulta. Alejandro Pisanty - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . ________________________________ Desde: lac-discuss-es-bounces@atlarge-lists.icann.org [lac-discuss-es-bounces@atlarge-lists.icann.org] en nombre de Alberto Soto [asoto@ibero-americano.org] Enviado el: lunes, 08 de junio de 2015 11:58 Hasta: 'Alejandro Pisanty' CC: 'LACRALO Español' Asunto: Re: [lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June Coincido Alejandro. Particularmente coincide con David en que un SLA debe contener todo lo necesario y ser redactado con la mayor claridad posible. He redactado algunos SLA como abogado y también he soportado como informático algunos de ellos, en un grupo muy grande y multinacional. Gracias por estas colaboraciones Saludos cordiales Alberto Soto De: Alejandro Pisanty [mailto:apisanty@gmail.com] Enviado el: lunes, 08 de junio de 2015 12:36 p.m. Para: Alberto Soto CC: LACRALO Español Asunto: Re: [lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June Alberto, mil gracias por compartir este intercambio de mensajes. Como bien lo señalas, el tema es muy específico y la discusión en extremo detallada. Sin embargo, y sobre todo con la respuesta de John Curran, el asunto del que trata es de la mayor escala y la mayor importancia. Nuestra comunidad debe estar preparada para intervenir a nivel regional y global. 1. Es indispensable contrarrestar todos los esfuerzos de los RIRs que conducen a fragmentar a ICANN, en particular a través de la fragmentación de IANA. Aunque se profesa carecer de esa intención, la firma de un convenio o contrato comercial separado para los recursos de numeración y la desproporción en los pagos entre números y nombres impulsan esa dirección. 2. La razón asiste a David Conrad en la mayor parte de sus observaciones. Ya es de suyo complejo establecer un SLA (acuerdo de nivel de servicio) con un proveedor comercial convencional de servicios que el mercado define. Reducir a un contrato de este tipo la función de "stewardship" de ICANN e IANA crea los incentivos más contraproducemtes posibles. Espero que otras organizaciones se manifiesten y propongo expresar los dos puntos aquí expuestos como una posición de consenso de LACRALO, para lo cual solicito a la Presidencia y la Secretaría instituyan los procesos formales correspondientes. Alejandro Pisanty On Mon, Jun 8, 2015 at 9:16 AM, Alberto Soto <asoto@ibero-americano.org<mailto:asoto@ibero-americano.org>> wrote: Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales Alberto Soto -----Mensaje original----- De: ianaxfer-bounces@nro.net<mailto:ianaxfer-bounces@nro.net> [mailto:ianaxfer-bounces@nro.net<mailto:ianaxfer-bounces@nro.net>] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer@nro.net<mailto:ianaxfer@nro.net> Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June On Jun 7, 2015, at 11:51 PM, David Conrad <drc@virtualized.org<mailto:drc@virtualized.org>> wrote:
Hi,
I have been hesitant to provide comments on the draft SLA due to my current role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community. However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.
Perhaps this can be a lesson in being careful what you ask for...
While I can assert the following input is, in fact, (a) purely my own, (b) is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.
David - Thanks for these comments - I have no doubt that they will lead to an improved SLA as a result.
I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.
Along that spirit, I am going to refrain from responding to the vast majority of the comments (as the community is likely to have ample comments), but but will comment on three areas which relate to the overall assumptions for the IANA Stewardship transition process at a high-level.
... In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole.
Agreed.
As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.
I believe that the roles and responsibilities of the parties must be defined, but that doesn’t necessarily have to be (or even should be) in a single document. The rather colorful structure and evolution of ICANN has resulted in it having multiple roles, and yet these roles are not strictly dependent on each other. For example, if the ICANN IANA team were to experience extremely and chronic performance issues in the administration of the IANA number registries (the opposite of the excellent performance provided to date), then there could be a circumstances where the numbers community would need (via the RIRs as their representative) to contract for an alternative IANA numbers registry operator. The SLA should be suitable for that arrangement (even though ICANN would not longer be performing the IANA numbers registry function.) However, in my personal opinion, such a change should not in any way change the RIRs collectively operating under ICANN’s overall Internet identifier coordination role; i.e. the community should still submit global policies to ICANN for ratification, the ASO MOU should remain in effect, the RIR community should participate in accountability and transparency reviews (ATRT) as part of the ICANN system, etc. ICANN serves as an important role external to the Internet numbers community that improves overall accountability and transparency, and helps in broad outreach to the global Internet community. So, I think we’re in agreement that role and responsibilities should be clearly defined, but it is not clear that it should be done in a single document since there are multiple relationships: 1) RIRs/NRO serving as the global Address Supporting Organization within ICANN, with its incumbent obligations, and 2) ICANN serving as the IANA numbers service operator for numbering community as represented by the RIRs.
5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."
Um, what? So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.
Actually, I believe it is $100 _in total_ under the present language… Is there a value that makes more sense - i.e. what do you believe the full costs of providing “the extremely limited activity” of the IANA numbering function? I personally believe that it is in the community's interest for this value be an accurate estimate of such costs, and the present ICANN ASO contribution should be reduced by the same amount once established. In this manner, if the worst-cast were to happen and another party had to perform IANA services, then the RIRs would have budgeted at least a meaningful amount for this purpose, and while ICANN would lose this amount, it would correspond with a similar reduction in the level of effort in their IANA team.
12.1.1: "Operator does hereby assign and transfer any and all right, title and interest in and to such intellectual property rights to the RIRs, their successors, assigns and designees."
I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.
12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."
Similar comment as above.
12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the “IP Assets”)."
This is backwards. ICANN currently owns the rights to that intellectual property.
It would be nice if we could all come to agreement that the rights to the community's intellectual property related to these activities (including any data rights, trademark, domain names, etc.) should be held by an entity which was actually set up for such a purpose, had no operational role, would make appropriate licenses available to all parties that had a role in IANA operations, etc. Last I checked, the IETF Trust met all of these criteria (whereas neither ICANN nor the RIRs do) One can imagine some rather extreme worse-case scenarios involving transitions where it would be very helpful it we could all rely on the intellectual property being made available to whomever needed it to perform the functions, and not otherwise caught in transition. Thanks again for the comments! /John Disclaimer: The remarks above are my own as CEO of ARIN. While I believe them to be fully compatible with the organization's positions on these matters to date, neither the ARIN Board nor ARIN community has discussed David’s comments and developed specific positions on these topics at this time. _______________________________________________ ianaxfer mailing list ianaxfer@nro.net<mailto:ianaxfer@nro.net> https://www.nro.net/mailman/listinfo/ianaxfer --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus _______________________________________________ lac-discuss-es mailing list lac-discuss-es@atlarge-lists.icann.org<mailto:lac-discuss-es@atlarge-lists.icann.org> https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es http://www.lacralo.org -- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . ________________________________ [Avast logo] <https://www.avast.com/antivirus> El software de antivirus Avast ha analizado este correo electrónico en busca de virus. www.avast.com<https://www.avast.com/antivirus>
Comparto integralmente con las observaciones de Alex. Hay de facto una gran posibilidad de fragmentación. David viene psotando observaciones muy validas que nosotros debíamos tomar en consideración. Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. From: Alejandro Pisanty <apisanty@gmail.com> Date: Monday, June 8, 2015 at 12:36 To: Alberto Soto <asoto@ibero-americano.org> Cc: "lac-discuss-es@atlarge-lists.icann.org" <lac-discuss-es@atlarge-lists.icann.org> Subject: Re: [lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June Alberto, mil gracias por compartir este intercambio de mensajes. Como bien lo señalas, el tema es muy específico y la discusión en extremo detallada. Sin embargo, y sobre todo con la respuesta de John Curran, el asunto del que trata es de la mayor escala y la mayor importancia. Nuestra comunidad debe estar preparada para intervenir a nivel regional y global. 1. Es indispensable contrarrestar todos los esfuerzos de los RIRs que conducen a fragmentar a ICANN, en particular a través de la fragmentación de IANA. Aunque se profesa carecer de esa intención, la firma de un convenio o contrato comercial separado para los recursos de numeración y la desproporción en los pagos entre números y nombres impulsan esa dirección. 2. La razón asiste a David Conrad en la mayor parte de sus observaciones. Ya es de suyo complejo establecer un SLA (acuerdo de nivel de servicio) con un proveedor comercial convencional de servicios que el mercado define. Reducir a un contrato de este tipo la función de "stewardship" de ICANN e IANA crea los incentivos más contraproducemtes posibles. Espero que otras organizaciones se manifiesten y propongo expresar los dos puntos aquí expuestos como una posición de consenso de LACRALO, para lo cual solicito a la Presidencia y la Secretaría instituyan los procesos formales correspondientes. Alejandro Pisanty On Mon, Jun 8, 2015 at 9:16 AM, Alberto Soto <asoto@ibero-americano.org> wrote:
Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales
Alberto Soto
-----Mensaje original----- De: ianaxfer-bounces@nro.net [mailto:ianaxfer-bounces@nro.net] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer@nro.net Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
On Jun 7, 2015, at 11:51 PM, David Conrad <drc@virtualized.org> wrote:
Hi,
I have been hesitant to provide comments on the draft SLA due to my current
role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community. However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.
Perhaps this can be a lesson in being careful what you ask for...
While I can assert the following input is, in fact, (a) purely my own, (b)
is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.
David -
Thanks for these comments - I have no doubt that they will lead to an improved SLA as a result.
I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.
Along that spirit, I am going to refrain from responding to the vast majority of the comments (as the community is likely to have ample comments), but but will comment on three areas which relate to the overall assumptions for the IANA Stewardship transition process at a high-level.
... In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole.
Agreed.
As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.
I believe that the roles and responsibilities of the parties must be defined, but that doesn¹t necessarily have to be (or even should be) in a single document. The rather colorful structure and evolution of ICANN has resulted in it having multiple roles, and yet these roles are not strictly dependent on each other. For example, if the ICANN IANA team were to experience extremely and chronic performance issues in the administration of the IANA number registries (the opposite of the excellent performance provided to date), then there could be a circumstances where the numbers community would need (via the RIRs as their representative) to contract for an alternative IANA numbers registry operator. The SLA should be suitable for that arrangement (even though ICANN would not longer be performing the IANA numbers registry function.)
However, in my personal opinion, such a change should not in any way change the RIRs collectively operating under ICANN¹s overall Internet identifier coordination role; i.e. the community should still submit global policies to ICANN for ratification, the ASO MOU should remain in effect, the RIR community should participate in accountability and transparency reviews (ATRT) as part of the ICANN system, etc. ICANN serves as an important role external to the Internet numbers community that improves overall accountability and transparency, and helps in broad outreach to the global Internet community.
So, I think we¹re in agreement that role and responsibilities should be clearly defined, but it is not clear that it should be done in a single document since there are multiple relationships: 1) RIRs/NRO serving as the global Address Supporting Organization within ICANN, with its incumbent obligations, and 2) ICANN serving as the IANA numbers service operator for numbering community as represented by the RIRs.
5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."
Um, what? So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.
Actually, I believe it is $100 _in total_ under the present language Is there a value that makes more sense - i.e. what do you believe the full costs of providing ³the extremely limited activity² of the IANA numbering function? I personally believe that it is in the community's interest for this value be an accurate estimate of such costs, and the present ICANN ASO contribution should be reduced by the same amount once established. In this manner, if the worst-cast were to happen and another party had to perform IANA services, then the RIRs would have budgeted at least a meaningful amount for this purpose, and while ICANN would lose this amount, it would correspond with a similar reduction in the level of effort in their IANA team.
12.1.1: "Operator does hereby assign and transfer any and all right, title and interest in and to such intellectual property rights to the RIRs, their successors, assigns and designees."
I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.
12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."
Similar comment as above.
12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the ³IP Assets²)."
This is backwards. ICANN currently owns the rights to that intellectual property.
It would be nice if we could all come to agreement that the rights to the community's intellectual property related to these activities (including any data rights, trademark, domain names, etc.) should be held by an entity which was actually set up for such a purpose, had no operational role, would make appropriate licenses available to all parties that had a role in IANA operations, etc. Last I checked, the IETF Trust met all of these criteria (whereas neither ICANN nor the RIRs do) One can imagine some rather extreme worse-case scenarios involving transitions where it would be very helpful it we could all rely on the intellectual property being made available to whomever needed it to perform the functions, and not otherwise caught in transition.
Thanks again for the comments! /John
Disclaimer: The remarks above are my own as CEO of ARIN. While I believe them to be fully compatible with the organization's positions on these matters to date, neither the ARIN Board nor ARIN community has discussed David¹s comments and developed specific positions on these topics at this time.
_______________________________________________ ianaxfer mailing list ianaxfer@nro.net https://www.nro.net/mailman/listinfo/ianaxfer
--- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus
_______________________________________________ lac-discuss-es mailing list lac-discuss-es@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Alejandro Pisanty Facultad de Química UNAM Av. Universidad 3000, 04510 Mexico DF Mexico +52-1-5541444475 FROM ABROAD +525541444475 DESDE MÉXICO SMS +525541444475 Blog: http://pisanty.blogspot.com LinkedIn: http://www.linkedin.com/in/pisanty Unete al grupo UNAM en LinkedIn, http://www.linkedin.com/e/gis/22285/4A106C0C8614 Twitter: http://twitter.com/apisanty ---->> Unete a ISOC Mexico, http://www.isoc.org . . . . . . . . . . . . . . . . _______________________________________________ lac-discuss-es mailing list lac-discuss-es@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es http://www.lacralo.org
participants (4)
-
Alberto Soto -
Alejandro Pisanty -
Dr. Alejandro Pisanty Baruch -
Vanda Scartezini