Fwd: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, Have you seen the draft response from ISOC? I think it makes some good points, in particular with regard to the role of the Contractor in assessing whether policies and national laws have been complied with (see below, "Finally, and most importantly,"). I would be pleased if the ISPCP response could incorporate at least this last point in its own response. Also, are we really at the point where we're calling for every last vestige of US oversight of the IANA function to be withdrawn? Malcolm. - -------- Original Message -------- Subject: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry Date: Mon, 18 Jul 2011 11:33:25 +0200 From: Markus Kummer <kummer@isoc.org> To: isoc-advisory-council@elists.isoc.org Dear Advisory Council Members, I refer to the email I sent out on 19 June, seeking your input for our response to the US Department of Commerce IANA Further Notice of Inquiry (FNOI). Meanwhile, we have had the opportunity to assess the FNOI more in detail and also exchange views with others, including representatives of the National Telecommunications and Information Administration (NTIA). First and foremost, we welcome the open and transparent process which should ultimately contribute to broadening transparency, predictability and global confidence in the way the Department of Commerce deals with the IANA function. Nevertheless, we have some areas of concern. In our draft response to the FNOI, which is attached to this email, .we highlight the following areas where we believe further clarifications are needed: First, the Internet technical community should be recognized as materially affected parties to the contract. Second, the FNOI is DNS centric. The DNS component of the IANA Functions Contract is only one of three IANA functions that are of equal importance to the well-functioning Internet. The Contract should therefore be drafted in such a way that the full range of IANA functions to be performed by the Contractor are reflected throughout the document and treated as separate functions of equal importance. Third, the functional separation between the processing of the IANA functions and the development of associated policies needs further clarification. We believe the current wording is too rigid. The IANA staff are sometimes uniquely qualified to provide informed inputs to the policy making process, based on their technical expertise and operational experience. A good policy development process requires informed technical advice from professional staff to understand why a proposed policy may or may not be implementable, or where it could be more effective, if it is put forward in one way rather than another. Finally, and most importantly, we believe the requirement for the IANA Contractor to document compliance with relevant policies and procedures or, more critically, with relevant national laws, needs to be revisited. To be consistent with the requirement for the functional separation between the processing of the IANA functions and the development of associated policies, it is essential that IANA staff not be required to assess whether or not requests for processing are compliant with relevant policies and procedures, and most certainly not whether they are compliant with relevant national laws. Compliance is a matter for the policy-making bodies the ICANN Board, the RIRs through the NRO, and the IETF. The final SOW must make it clear that the IANA Contractors staff is responsible only for documenting that the relevant organization has stated that their decision is compliant with policy, procedures and laws, and not for judging the accuracy of such statements. Please let us know if you have any comments. Any response submitted by 24 July will be considered in the finalization of our response. Best regards Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4motoACgkQJiK3ugcyKhSbMgCgqTnQyD6r6wVsGMkwUyUbIFa2 m2QAnikOTuuRYdJHoHXxddGdLYW5MCaZ =gz6t -----END PGP SIGNATURE-----
Malcolm Thanks for this. Alain - could you have a look at incorporating the additional point Malcolm has proposed. Regards Tony -----Original Message----- From: Malcolm Hutty [mailto:malcolm@linx.net] Sent: 20 July 2011 10:42 To: Tonyarholmes@btinternet.com; ispcp@icann.org Subject: Fwd: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, Have you seen the draft response from ISOC? I think it makes some good points, in particular with regard to the role of the Contractor in assessing whether policies and national laws have been complied with (see below, "Finally, and most importantly,"). I would be pleased if the ISPCP response could incorporate at least this last point in its own response. Also, are we really at the point where we're calling for every last vestige of US oversight of the IANA function to be withdrawn? Malcolm. - -------- Original Message -------- Subject: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry Date: Mon, 18 Jul 2011 11:33:25 +0200 From: Markus Kummer <kummer@isoc.org> To: isoc-advisory-council@elists.isoc.org Dear Advisory Council Members, I refer to the email I sent out on 19 June, seeking your input for our response to the US Department of Commerce IANA Further Notice of Inquiry (FNOI). Meanwhile, we have had the opportunity to assess the FNOI more in detail and also exchange views with others, including representatives of the National Telecommunications and Information Administration (NTIA). First and foremost, we welcome the open and transparent process which should ultimately contribute to broadening transparency, predictability and global confidence in the way the Department of Commerce deals with the IANA function. Nevertheless, we have some areas of concern. In our draft response to the FNOI, which is attached to this email, .we highlight the following areas where we believe further clarifications are needed: First, the Internet technical community should be recognized as “materially affected parties” to the contract. Second, the FNOI is “DNS centric”. The DNS component of the IANA Functions Contract is only one of three IANA functions that are of equal importance to the well-functioning Internet. The Contract should therefore be drafted in such a way that the full range of IANA functions to be performed by the Contractor are reflected throughout the document and treated as separate functions of equal importance. Third, the functional separation between the processing of the IANA functions and the development of associated policies needs further clarification. We believe the current wording is too rigid. The IANA staff are sometimes uniquely qualified to provide informed inputs to the policy making process, based on their technical expertise and operational experience. A good policy development process requires informed technical advice from professional staff to understand why a proposed policy may or may not be implementable, or where it could be more effective, if it is put forward in one way rather than another. Finally, and most importantly, we believe the requirement for the IANA Contractor to document compliance with relevant policies and procedures or, more critically, with relevant national laws, needs to be revisited. To be consistent with the requirement for the functional separation between the processing of the IANA functions and the development of associated policies, it is essential that IANA staff not be required to assess whether or not requests for processing are compliant with relevant policies and procedures, and most certainly not whether they are compliant with relevant national laws. Compliance is a matter for the policy-making bodies – the ICANN Board, the RIRs through the NRO, and the IETF. The final SOW must make it clear that the IANA Contractor’s staff is responsible only for documenting that the relevant organization has stated that their decision is compliant with policy, procedures and laws, and not for judging the accuracy of such statements. Please let us know if you have any comments. Any response submitted by 24 July will be considered in the finalization of our response. Best regards Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4motoACgkQJiK3ugcyKhSbMgCgqTnQyD6r6wVsGMkwUyUbIFa2 m2QAnikOTuuRYdJHoHXxddGdLYW5MCaZ =gz6t -----END PGP SIGNATURE-----
Tony, Malcom, I tried to integrate it (see revision marks). My understanding is that the concerns is on the Draft SOW article C.2.2.1.3.2, and that we already coverded this issue in our draft. I must also say that if I understand the concerns expressed by ISOC, I am unconfortable to see the RIRs (or even the NRO) presented as "policy making bodies". Excactly the same concerns if IANA was presented as a policy making body. Regarding Malcom's question: "are we really at the point where we're calling for every last vestige of US oversight of the IANA function to be withdrawn?" by short and clear reponse would be YES. Alain Bidron FT/OLNC/NAD/EAS/NAN Head of Naming Addressing Numbering Unit tel. + 33 1 57 36 17 24 mob. + 33 6 87 65 90 94 alain.bidron@orange-ftgroup.com -----Message d'origine----- De : owner-ispcp@gnso.icann.org [mailto:owner-ispcp@gnso.icann.org] De la part de Tony Holmes Envoyé : mercredi 20 juillet 2011 22:02 À : 'Malcolm Hutty'; ispcp@icann.org Objet : [ispcp] RE: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry Malcolm Thanks for this. Alain - could you have a look at incorporating the additional point Malcolm has proposed. Regards Tony -----Original Message----- From: Malcolm Hutty [mailto:malcolm@linx.net] Sent: 20 July 2011 10:42 To: Tonyarholmes@btinternet.com; ispcp@icann.org Subject: Fwd: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, Have you seen the draft response from ISOC? I think it makes some good points, in particular with regard to the role of the Contractor in assessing whether policies and national laws have been complied with (see below, "Finally, and most importantly,"). I would be pleased if the ISPCP response could incorporate at least this last point in its own response. Also, are we really at the point where we're calling for every last vestige of US oversight of the IANA function to be withdrawn? Malcolm. - -------- Original Message -------- Subject: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry Date: Mon, 18 Jul 2011 11:33:25 +0200 From: Markus Kummer <kummer@isoc.org> To: isoc-advisory-council@elists.isoc.org Dear Advisory Council Members, I refer to the email I sent out on 19 June, seeking your input for our response to the US Department of Commerce IANA Further Notice of Inquiry (FNOI). Meanwhile, we have had the opportunity to assess the FNOI more in detail and also exchange views with others, including representatives of the National Telecommunications and Information Administration (NTIA). First and foremost, we welcome the open and transparent process which should ultimately contribute to broadening transparency, predictability and global confidence in the way the Department of Commerce deals with the IANA function. Nevertheless, we have some areas of concern. In our draft response to the FNOI, which is attached to this email, .we highlight the following areas where we believe further clarifications are needed: First, the Internet technical community should be recognized as "materially affected parties" to the contract. Second, the FNOI is "DNS centric". The DNS component of the IANA Functions Contract is only one of three IANA functions that are of equal importance to the well-functioning Internet. The Contract should therefore be drafted in such a way that the full range of IANA functions to be performed by the Contractor are reflected throughout the document and treated as separate functions of equal importance. Third, the functional separation between the processing of the IANA functions and the development of associated policies needs further clarification. We believe the current wording is too rigid. The IANA staff are sometimes uniquely qualified to provide informed inputs to the policy making process, based on their technical expertise and operational experience. A good policy development process requires informed technical advice from professional staff to understand why a proposed policy may or may not be implementable, or where it could be more effective, if it is put forward in one way rather than another. Finally, and most importantly, we believe the requirement for the IANA Contractor to document compliance with relevant policies and procedures or, more critically, with relevant national laws, needs to be revisited. To be consistent with the requirement for the functional separation between the processing of the IANA functions and the development of associated policies, it is essential that IANA staff not be required to assess whether or not requests for processing are compliant with relevant policies and procedures, and most certainly not whether they are compliant with relevant national laws. Compliance is a matter for the policy-making bodies - the ICANN Board, the RIRs through the NRO, and the IETF. The final SOW must make it clear that the IANA Contractor's staff is responsible only for documenting that the relevant organization has stated that their decision is compliant with policy, procedures and laws, and not for judging the accuracy of such statements. Please let us know if you have any comments. Any response submitted by 24 July will be considered in the finalization of our response. Best regards Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4motoACgkQJiK3ugcyKhSbMgCgqTnQyD6r6wVsGMkwUyUbIFa2 m2QAnikOTuuRYdJHoHXxddGdLYW5MCaZ =gz6t -----END PGP SIGNATURE----- ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ********************************************************************************
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/07/2011 09:14, alain.bidron@orange-ftgroup.com wrote:
I must also say that if I understand the concerns expressed by ISOC, I am unconfortable to see the RIRs (or even the NRO) presented as "policy making bodies".
The RIRs do make technical policy such as, for example, the policy that governs how the last /8 of IPv4 is allocated or policy as to whether IP address allocations are tradeable. In the RIPE region policy is actually made by RIPE rather than the RIPE NCC, but that's a local complication about the split in RIR functions in that region between RIPE and RIPE NCC. The NRO is not a policy making body. It is, essentially, a trade association of the RIRs. It has a role in helping coordinate policy-development work between the RIRs so that policy implementation dates of equivalent policies are aligned, and it has a role in communicating outcomes to stakeholders, but it doesn't have an acknowledged role in making policy decisions. - -- 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 Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4n5egACgkQJiK3ugcyKhQUfwCgvRrmgv4Ameg8MaZyRjuf4pFM yAwAnRbVElnFbdiwr9QhSOdXJCnUu7+Z =gs74 -----END PGP SIGNATURE-----
When we refer to the RIRs if we take the RIPE region as an example, we clearly design the RIPE-NCC. The RIPE-NCC do NOT propose policies or develop policies. As you know the RIPE community does. I do not see that as a "local complication" but as a requirement that the one managing the resources not being the one developing policies, in the same way IANA should not develop policies. Regarding the NRO, I agree with your comment. This is why the way ISOC has formulated is a bit ambiguous in my view even if I understand the intention. Regards Alain Alain Bidron FT/OLNC/NAD/EAS/NAN Head of Naming Addressing Numbering Unit tel. + 33 1 57 36 17 24 mob. + 33 6 87 65 90 94 alain.bidron@orange-ftgroup.com -----Message d'origine----- De : Malcolm Hutty [mailto:malcolm@linx.net] Envoyé : jeudi 21 juillet 2011 10:40 À : BIDRON Alain OLNC/NAD Cc : Tony Holmes; ispcp@icann.org Objet : Re: [ispcp] RE: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/07/2011 09:14, alain.bidron@orange-ftgroup.com wrote:
I must also say that if I understand the concerns expressed by ISOC, I am unconfortable to see the RIRs (or even the NRO) presented as "policy making bodies".
The RIRs do make technical policy such as, for example, the policy that governs how the last /8 of IPv4 is allocated or policy as to whether IP address allocations are tradeable. In the RIPE region policy is actually made by RIPE rather than the RIPE NCC, but that's a local complication about the split in RIR functions in that region between RIPE and RIPE NCC. The NRO is not a policy making body. It is, essentially, a trade association of the RIRs. It has a role in helping coordinate policy-development work between the RIRs so that policy implementation dates of equivalent policies are aligned, and it has a role in communicating outcomes to stakeholders, but it doesn't have an acknowledged role in making policy decisions. - -- 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 Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4n5egACgkQJiK3ugcyKhQUfwCgvRrmgv4Ameg8MaZyRjuf4pFM yAwAnRbVElnFbdiwr9QhSOdXJCnUu7+Z =gs74 -----END PGP SIGNATURE----- ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ********************************************************************************
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/07/2011 10:01, alain.bidron@orange-ftgroup.com wrote:
When we refer to the RIRs if we take the RIPE region as an example, we clearly design the RIPE-NCC. The RIPE-NCC do NOT propose policies or develop policies. As you know the RIPE community does. I do not see that as a "local complication" but as a requirement that the one managing the resources not being the one developing policies, in the same way IANA should not develop policies. Regarding the NRO, I agree with your comment. This is why the way ISOC has formulated is a bit ambiguous in my view even if I understand the intention.
I see what you mean. I think we're on the same page here. Getting back to our response, the point being made by ISOC (and I think implicitly endorsed by what you say above) is that the IANA contractor shouldn't be second-guessing the ICANN Board as to whether the Board has followed ICANN procedures, nor should it be refusing to implement an ICANN Board decision on the grounds that it believes it may be contrary to some national law. I don't think "ISPCP also expect some clarification on the request for developing a process for documenting the source of the policies and procedures and compliance with these policies and relevant national laws. " is clear about that. - -- 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 Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4n7YMACgkQJiK3ugcyKhTynACfTTF8eLgFlk3TTVRfmk1o8Ii4 t+UAmwWWzVE/aI/7x2V6noXCK0KG11CC =f/wR -----END PGP SIGNATURE-----
I agree that we are on the same page and clearly I am not satisfied with the proposal I made to cover the issue. Could you suggest something to be inserted? Regards. Alain Alain Bidron FT/OLNC/NAD/EAS/NAN Head of Naming Addressing Numbering Unit tel. + 33 1 57 36 17 24 mob. + 33 6 87 65 90 94 alain.bidron@orange-ftgroup.com -----Message d'origine----- De : Malcolm Hutty [mailto:malcolm@linx.net] Envoyé : jeudi 21 juillet 2011 11:13 À : BIDRON Alain OLNC/NAD Cc : Tony Holmes; ispcp@icann.org Objet : Re: [ispcp] RE: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/07/2011 10:01, alain.bidron@orange-ftgroup.com wrote:
When we refer to the RIRs if we take the RIPE region as an example, we clearly design the RIPE-NCC. The RIPE-NCC do NOT propose policies or develop policies. As you know the RIPE community does. I do not see that as a "local complication" but as a requirement that the one managing the resources not being the one developing policies, in the same way IANA should not develop policies. Regarding the NRO, I agree with your comment. This is why the way ISOC has formulated is a bit ambiguous in my view even if I understand the intention.
I see what you mean. I think we're on the same page here. Getting back to our response, the point being made by ISOC (and I think implicitly endorsed by what you say above) is that the IANA contractor shouldn't be second-guessing the ICANN Board as to whether the Board has followed ICANN procedures, nor should it be refusing to implement an ICANN Board decision on the grounds that it believes it may be contrary to some national law. I don't think "ISPCP also expect some clarification on the request for developing a process for documenting the source of the policies and procedures and compliance with these policies and relevant national laws. " is clear about that. - -- 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 Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4n7YMACgkQJiK3ugcyKhTynACfTTF8eLgFlk3TTVRfmk1o8Ii4 t+UAmwWWzVE/aI/7x2V6noXCK0KG11CC =f/wR -----END PGP SIGNATURE----- ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ********************************************************************************
participants (3)
-
alain.bidron＠orange-ftgroup.com -
Malcolm Hutty -
Tony Holmes