<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [ispcp] RE: [isoc-advisory-council] ISOC Draft Response to the US Department of Commerce IANA Further Notice of Inquiry
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@xxxxxxxxxxxxxxxxxx
-----Message d'origine-----
De : Malcolm Hutty [mailto:malcolm@xxxxxxxx]
Envoyé : jeudi 21 juillet 2011 11:13
À : BIDRON Alain OLNC/NAD
Cc : Tony Holmes; ispcp@xxxxxxxxx
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@xxxxxxxxxxxxxxxxxx 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.
********************************************************************************
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|