[AfrICANN-discuss] Re: AfrICANN Digest, Vol 58, Issue 11

Baudouin Schombe baudouin.schombe at gmail.com
Thu Dec 8 13:41:09 SAST 2011


Bonjour,

En ce qui concerne l'IPv6 en RDCongo, Taddy a exprimé certaines
préoccupations mais il convient de relever que l'information
mobilisante n'est pas effective pour la mutation d'IPv4 à l'IPv6.

Il ne s'agit pas tellement de réticence mais d'un très grand lapsus
d'information concernant les enjeux sur l'IPv6.

Baudouin

Le 07/12/11, africann-request at afrinic.net<africann-request at afrinic.net>
a écrit :
> Send AfrICANN mailing list submissions to
> 	africann at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.afrinic.net/mailman/listinfo.cgi/africann
> or, via email, send a message with subject or body 'help' to
> 	africann-request at afrinic.net
>
> You can reach the person managing the list at
> 	africann-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AfrICANN digest..."
>
>
> Today's Topics:
>
>    1. RE: Hackers target IPv6 (Victor NDONNANG)
>    2. WHOIS Policy Review Team Draft Report - Public	Comment open
>       (Glen de Saint G?ry)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 7 Dec 2011 15:07:31 +0100
> From: "Victor NDONNANG" <ndonnang at isoc-cameroon.org>
> Subject: RE: [AfrICANN-discuss] Hackers target IPv6
> To: <africann at afrinic.net>
> Message-ID: <013d01ccb4e9$912df6b0$b389e410$@org>
> Content-Type: text/plain;	charset="UTF-8"
>
> Merci Daddy Talasi!
>
> Nous n'allons pas manquer de vous mettre au courant de l'évolution du projet
> "IMPACT IPv6" au Cameroon. Si vous souhaitez reproduire ce projet au niveau
> de la RDC, nous nous ferons un plaisir de partager notre expérience avec
> vous et de vous assister.
> Cordialement,
> Victor.
>
>
> -----Message d'origine-----
> De : africann-bounces at afrinic.net [mailto:africann-bounces at afrinic.net] De
> la part de Daddy TALASI KAZIAMA
> Envoyé : mercredi 7 décembre 2011 14:08
> À : africann at afrinic.net
> Objet : Re: [AfrICANN-discuss] Hackers target IPv6
>
> Bonjour à tous,
>
>
> Merci Victor,
>
> pour ton intervention, je pense qu'il vraiment temps qu'on se met pour
> travailler, car beaucoup des gents même ici en RDC, le gents sont
> toujours retissant par rapport au deploiyement de la version 6 d'IP,
> en disant que l'IPv4 fonctionnent bien pourquoi adopter l'IPv6?
>
> je pense qu'on moment où le projet du caméroun va marcher penser à
> nous en contact pour les ateliers et autres.
>
> Franche collaboration.
>
> Le 06/12/11, nabil benamar<benamar73 at gmail.com> a écrit :
>> Bonjour à tous,
>>
>> Je me demande aussi pourquoi IPv6 accuse un retard par rapport à son
>> déploiement? J'ai essayé d'écrire des articles de vulgarisation au Maroc
>> pour débattre des différents aspects relatifs à IPv6. J'ai même préparé un
>> atelier de formation qui est maintenant certifié par l'ipv6forum. Voir le
>> lien nabilbenamar.com
>>
>> Merci
>>
>> Le 6 décembre 2011 12:08, ISOC Cameroon Chapter <info at isoc-cameroon.org> a
>> écrit :
>>
>>> Merci Jean-Robert pour le lien original!
>>>
>>> Tu avais raison Nacer, l'article en anglais est beaucoup plus
>>> compréhensible. Cette faille de sécurité serait-elle un justificatif du
>>> retard accusé dans le déploiement de l'IPv6?
>>>
>>> Je me suis toujours demandé le pourquoi de cette lenteur dans l'adoption
>>> et
>>> le déploiement de ce "nouveau-ancien" protocole qu'est l'IPv6. Il faut
>>> noté
>>> qu'IPv6 est prêt et utilisable depuis 1999 quand même!
>>>
>>> L'une des raisons principales de ce retard est sans doute que l'IPv4 est
>>> là,
>>> disponible et marche bien! Pourquoi investir dans le nouveau alors que
>>> l'ancien est là disponible et fonctionnel? Et l'être humain est toujours
>>> retissant et sceptique envers le changement. Alors un vrai travail
>>> didactique de conduite du changement s'impose.
>>>
>>> Je profite de ce mail pour vous annoncer que le Projet "IMPACT IPv6" du
>>> Chapitre Cameroun de l'Internet Society qui a été sélectionné par le
>>> programme de subventions à la communauté de l'ISOC (prix de novembre
>>> 2011:
>>> http://www.isoc.org/isoc/chapters/projects/awards.php?phase=14 ) vise à
>>> accompagner la conduite du changement vers l'IPv6 au niveau du Cameroun.
>>> Je
>>> vous en dirais plus dès que le projets sera effectivement lancé.
>>> Cordialement,
>>>
>>> Victor Ndonnang
>>> SG
>>> ISOC Cameroon Chapter
>>>
>>> -----Message d'origine-----
>>> De : africann-bounces at afrinic.net [mailto:africann-bounces at afrinic.net]
>>> De
>>> la part de Jean-Robert Hountomey
>>> Envoyé : lundi 5 décembre 2011 15:10
>>> À : africann at afrinic.net
>>> Objet : RE: [AfrICANN-discuss] Hackers target IPv6
>>>
>>> http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html
>>>
>>> -----Message d'origine-----
>>> De : africann-bounces at afrinic.net [mailto:africann-bounces at afrinic.net]
>>> De
>>> la part de Nacer Adamou Saidou
>>> Envoyé : Monday, December 05, 2011 7:32 AM
>>> À : africann at afrinic.net
>>> Objet : Re: [AfrICANN-discuss] Hackers target IPv6
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Bonjour,
>>> ce message est franchement utile, mais je pense qu'il s'agit du résultat
>>> d'une traduction automatique et le français qui en résulte est vraiment
>>> difficile à déchiffrer.
>>> Est ce possible d'avoir le lien original de l'article ou carrément la
>>> version en anglais?
>>> Amicalement
>>>
>>> Le 05/12/2011 13:48, Joseph Mandjolo a écrit :
>>> > Hackers target IPv6
>>> >
>>> > Les entreprises ont besoin d'être conscient de la vulnérabilité cachée
>>> > IPv6
>>> >
>>> > Par Susan Perschke, Network World
>>> > 28 novembre 2011 06:10 HE
>>> >
>>> > Si votre stratégie IPv6 est de retarder la mise en œuvre aussi
>>> > longtemps que vous le pouvez, vous devez toujours répondre aux
>>> > préoccupations de sécurité IPv6 dès maintenant.
>>> >
>>> > Si vous envisagez de déployer l'IPv6 dans une configuration dual-stack
>>> > avec IPv4, vous n'êtes toujours pas décroché quand il s'agit de
>>> > sécurité. Et si vous pensez que vous pouvez simplement désactiver
>>> > l'IPv6, cela ne va pas voler non plus.
>>> >
>>> > La plus grande menace imminente de sécurité réside dans le fait que
>>> > les réseaux d'entreprise ont déjà des tonnes d'appareils compatibles
>>> > IPv6, y compris tous les appareils fonctionnant sous Windows Vista ou
>>> > Windows 7, Mac OS / X, tous les périphériques sous Linux et BSD.
>>> >
>>> > Et contrairement à son prédécesseur, le protocole DHCP pour IPv4, IPv6
>>> > sans état ne nécessite pas de configuration manuelle. Cette
>>> > auto-configuration sans fonction, activée par défaut dans la plupart
>>> > des systèmes d'exploitation, signifie que «IPv6 appareils sont
>>> > simplement en attente d'un annonce de routeur simple de s'identifier
>>> > sur le réseau», explique Eric Vyncke, Distinguished Engineer chez
>>> > Cisco Systems Systèmes et co -auteur du livre «La sécurité IPv6."
>>> >
>>> > Il avertit que «IPv4 uniquement les routeurs et les commutateurs ne
>>> > reconnaissent pas ou répondre aux annonces dispositif d'IPv6, mais un
>>> > routeur IPv6 voyous pouvaient envoyer et d'interpréter ce trafic."
>>> >
>>> > L'auto-configuration permet à tout appareil compatible IPv6 pour
>>> > communiquer avec d'autres périphériques réseau et les services IPv6
>>> > sur le même LAN. Pour ce faire, l'appareil annonce sa présence et se
>>> > trouve via
>>> > l'IPv6 Neighbor Discovery Protocol (NPD).
>>> >
>>> > Mais elle n'était pas maîtrisée, NPD peut être un peu trop de bon
>>> > voisinage, éventuellement exposer les dispositifs d'attaquants
>>> > désireux de glaner des informations sur ce qui se passe à l'intérieur
>>> > du réseau, ou même en tenant l'appareil lui-même pour être repris et
>>> > transformé en un "zombie".
>>> >
>>> > Vyncke affirme que la menace est réelle. "Nous avons observé dans le
>>> > monde entier que les robots sont d'accroître leur utilisation de
>>> > l'IPv6 comme un canal caché pour communiquer avec leurs botmaster».
>>> > Parmi ses nombreux déguisements, IPv6 logiciels malveillants peuvent
>>> > prendre la forme d'une charge utile malveillante encapsulé dans un ou
>>> > plusieurs messages IPv4. Sans mesures de sécurité IPv6 spécifiques
>>> > telles que l'inspection approfondie des paquets, ce type de charge
>>> > utile peut passer à travers le périmètre
>>> > IPv4 et défenses DMZ inaperçue.
>>> >
>>> > ENVOYER (Secure Neighbor Discovery) est la solution IETF pour Layer-2
>>> > menaces telles que IPv6 voyous RA et l'usurpation du NPD, qui
>>> > équivalent à
>>> > IPv4 menaces appelé DHCP voyous et de l'ARP spoofing. Certains
>>> > fournisseurs OS soutien envoient, tandis que d'autres, notamment
>>> > Microsoft et Apple, n'en ont pas.
>>> >
>>> > Cisco et l'IETF est en train de mettre en œuvre les mécanismes de
>>> > sécurité de même pour IPv6 qui sont actuellement utilisés pour
>>> > protéger contre ces menaces IPv4.
>>> >
>>> > L'IETF a un. Groupe de travail SAVI (validation d'adresse source) et
>>> > Cisco met en œuvre un plan en trois phases visant à moderniser son IOS
>>> > qui a débuté en 2010 et seront entièrement mises en œuvre par quelque
>>> > part en 2012, selon le type de commutateur
>>> >
>>> > Vyncke note que certains des risques les plus communs de sécurité IPv6
>>> > sont accidentellement créé par une mauvaise configuration de
>>> > l'utilisateur final périphérique sur le réseau, et que la
>>> > configuration appropriée et de mesures de sécurité IPv6 permettrait
>>> d'éliminer nombre de ces risques.
>>> >
>>> > "La réponse à ce type de problème est de déployer l'IPv6 natif, et de
>>> > protéger le trafic IPv6 au même niveau et contre les mêmes types de
>>> > menaces que vous avez déjà de défendre en IPv4», explique Vyncke.
>>> >
>>> > Le mythe IPSec
>>> >
>>> > Il ya une perception commune que l'IPv6 est nativement plus sécurisé
>>> > que IPv4, car en charge IPSec est obligatoire dans IPv6. «C'est un
>>> > mythe qui a besoin d'être démystifié», dit Vyncke.
>>> >
>>> > Il souligne que, outre les difficultés pratiques liées à la mise en
>>> > œuvre à grande échelle du protocole IPSec, le contenu de IPSec
>>> > encapsulé le trafic devient invisible pour périphériques (routeurs /
>>> > commutateurs / firewalls), interférant ainsi avec leurs fonctions de
>>> sécurité importantes.
>>> >
>>> > Pour cette raison, Vyncke, qui est également un membre actif de l'IETF
>>> > et l'auteur de la RFC 3585, rapporte qu'un groupe de travail IETF
>>> > envisage une modification qui ferait en charge IPSec «recommandé»
>>> > plutôt que «nécessaire» dans les implémentations d'IPv6.
>>> >
>>> > En ce qui concerne IPv6 invalidante, Vyncke dit que c'est une mauvaise
>>> > idée pour deux raisons. One, Microsoft a déclaré que la désactivation
>>> > de l'IPv6 sur Windows 2008 constitue une configuration non prise en
>>> > charge. Et Vyncke dit essayer de désactiver l'IPv6 est une
>>> > tête-de-sable-stratégie qui retarde l'inévitable et pourrait faire de
>>> > la sécurité pire parce que les périphériques compatibles IPv6 vont
>>> > être apparaître sur le réseau qu'il le veuille ou non.
>>> >
>>> > Renforcer la dynamique
>>> >
>>> > Les menaces de sécurité côté, il ya une analyse de rentabilisation
>>> > croissante pour IPv6 qui devient plus difficile de balayer sous le
>>> > tapis. Les banques et les courtiers en ligne font déjà face au défi de
>>> > perdre la communication avec les clients internationaux dont les
>>> > réseaux ne supportent plus l'IPv4.
>>> >
>>> > Des entreprises comme Telefonica et T-Mobile IPv6 sont embrassant dans
>>> > une grande manière, surtout pour leurs bases européennes. Et le
>>> > gouvernement américain, qui n'a cessé de migrer vers l'IPv6, réclame à
>>> > grands cris pour les prestataires et fournisseurs à fournir des
>>> > produits plus IPv6 et des services.
>>> >
>>> > «Vous ne voulez jamais être dans une position où vous ne pouvez pas
>>> > interagir avec vos clients», affirme Keith Stewart, directeur des
>>> > produits Brocade Communications Systems livraison Applications.
>>> > Néanmoins, le partage de l'opinion la plus répandue parmi les
>>> > fournisseurs de réseau, Stewart voit une migration progressive vers
>>> > IPv6.
>>> >
>>> > "Une mise à niveau de gros à travers l'Internet IPv6 n'est ni pratique
>>> > ni efficace», dit Stewart. «Les clients ont besoin d'une approche
>>> > équilibrée et pratique." Il note que les fournisseurs de services, qui
>>> > consomment adresses plus vite que n'importe qui d'autre, sont en
>>> > première ligne pour les mises à niveau IPv6, suivie par les hébergeurs
>>> > de contenu (Google et Facebook), et enfin les utilisateurs finaux,
>>> > dont la maison routeurs sont encore 99%, basé sur IPV4.
>>> >
>>> > Lorsque Brocade nécessaire pour passer à l'IPv6, il a fallu les
>>> > équilibreurs de charge existants et tourné sur la traduction IPv6 pour
>>> > les services au public, la préservation de la connectivité IPv4 sur le
>>> > réseau interne. "La pile du public est le plus important. Choisissez
>>> > un petit projet où vous pouvez faire une analyse de rentabilisation
>>> > pour communiquer avec les clients IPv6. Lors de la construction hors
>>> > de votre prochaine série de services, la demande que ce double pile
>>> > capable ou traduction capables d'anciens IPv4 architectures . Cela
>>> > vous permet de bâtir une entreprise orientée ROI que vos équipes
>>> > acquérir
>>> une compétence avec IPv6.
>>> > Toute transition devrait être conçu pour être transparent pour
>>> > l'utilisateur final », dit Stewart.
>>> >
>>> > Juniper Networks rapporte que jusqu'à présent, la majorité de ses
>>> > clients demandant des services IPv6 sont des secteurs de l'éducation
>>> > et du gouvernement, plus précisément laboratoires de recherche
>>> > universitaires et les unités gouvernementales qui cherchent à se
>>> > conformer aux mandats fédéraux IPv6.
>>> >
>>> > Juniper prévoit une activité accrue d'IPv6 pour 2012, notamment chez
>>> > les fournisseurs de services. «IPv4 épuisement des adresses devient un
>>> > problème important pour nos clients du monde entier», explique Alain
>>> > Durand, directeur du génie logiciel, plate-forme et la Division des
>>> > systèmes CTO du groupe. Même ainsi, Durand s'attend à ce que la
>>> > plupart des déploiements
>>> > IPv6 seront plus petits projets mis en œuvre avec le protocole IPv6
>>> > comme un «add-on» (dual-stack) pour IPv4 existante services au public.
>>> > «Pour faire face à la pénurie croissante d'adresses IPv4, les clients
>>> > ont toujours la possibilité d'ajouter une autre couche de NAT",
>>> > explique
>>> Durand.
>>> >
>>> > Bien qu'il n'y ait aucun moyen de prédire avec certitude combien de
>>> > temps exactement il faudra attendre toutes les adresses IPv4 sont
>>> > épuisés, les statistiques quotidiennes compilées par Geoff Huston,
>>> > chief scientist chez APNIC, sont fréquemment citées comme une source
>>> > fiable. Modèle de Huston, qui est basé sur les sources de données
>>> > publiques tirées de données publiées par l'IANA et les Registres
>>> > Internet Régionaux, prédit l'épuisement complet de tous les autres
>>> > adresses IPv4 non attribuées en 2014.
>>> >
>>> > Cependant, il est important de noter que le modèle de Huston ne tient
>>> > pas compte des adresses qui peuvent être détenus par des organisations
>>> > privées pour un usage futur ou de la vente. Par exemple, il ne serait
>>> > pas facteur de plus de 600.000 adresses IPv4 récemment acquis par
>>> > Microsoft en vertu de son acquisition d'actifs faillite de Nortel.
>>> > Bien qu'il soit prudent de supposer que IPv4 suffisante adresses
>>> > seront disponibles à court terme, beaucoup prédisent coûts augmenter à
>>> mesure que diminue l'offre.
>>> >
>>> > Sans établir les meilleures pratiques pour l'IPv6, les gestionnaires
>>> > de réseau de nombreux ont été réticents à agir. Mais avec
>>> > l'augmentation des menaces de sécurité et les préoccupations
>>> > concernant la perte de communication avec les clients qui sont déjà
>>> > migrer vers IPv6 uniquement les systèmes, en attendant que d'autres
>>> > vont d'abord et ne rien faire en attendant la position n'est pas la
>>> «position neutre» qu'il n'y paraît.
>>> >
>>> > La phase de planification est un bon temps pour établir ou rétablir
>>> > des liens avec un vendeur de réseau de confiance qui peut fournir
>>> > l'architecture et les conseils de sécurité, avec des solutions
>>> > évolutives pour un large éventail d'options de migration.
>>> >
>>> > Perschke est co-propriétaire de deux sociétés de services
>>> > informatiques spécialisée dans l'hébergement web, SaaS (nuage) le
>>> > développement d'applications et la modélisation et l'intégration de
>>> > SGBDR. Susan a également la responsabilité exécutive pour la gestion
>>> > des risques et la sécurité du réseau au centre de ses entreprises »de
>>> > données. Elle peut être atteint à susan at arcseven.com.
>>> >
>>> > Avec nos meilleures salutations
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > AfrICANN mailing list
>>> > AfrICANN at afrinic.net
>>> > https://lists.afrinic.net/mailman/listinfo.cgi/africann
>>>
>>> - --
>>> Nacer Adamou Saïdou
>>> LPC-1 Certified Engineer
>>> Wave: nacerix at waveinabox.net
>>> Blog: http://nacerix.blogspot.com
>>> Twitter: nacerix
>>> Identi.ca: nacerix
>>> http://paper.li/nacerix
>>> http://netvibes.net/nacerix
>>> https://launchpad.net/~adamou-nacer
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJO3MeyAAoJELZpU0pKyeBuHE8IAJfRdSej3XkX4C95bQhaT+kC
>>> yF0Ctraxkm6f4NIo6k74+o73UiXXgBZ/NeF1aXBbmte+sRaXWo8km79KS7WZayzt
>>> YDx2X3lEs0uA3IjjWqO1cBYpr5MiEmURsTkyl+szW9q3YnOp/wLPICUBjaMeFbmN
>>> nqrqb8Rs6zJiqm13Wo9FTTqmoZVSttyxVdaiFOPn+TwhOvUeazcjKAh1cFVf+NR2
>>> 5btKv7AEQy5zHOAdTWdG0ep6pS7a4PIFqeVSWf4PaG1xB+WH22a3Kh+7SeUowG8W
>>> waOyCAiDcaib9Lj9z7lyDXYTjg8Bbkapv8VuucIYlenRJNgaYHu33tiPFxcnO8w=
>>> =lT9v
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> AfrICANN mailing list
>>> AfrICANN at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo.cgi/africann
>>>
>>>
>>> _______________________________________________
>>> AfrICANN mailing list
>>> AfrICANN at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo.cgi/africann
>>>
>>> _______________________________________________
>>> AfrICANN mailing list
>>> AfrICANN at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo.cgi/africann
>>>
>>
>>
>>
>> --
>> *
>> *
>> *تحياتي ، **Cordialement, Regards*
>> *
>> *
>> *
>> *
>> *نبيل بنعمرو Nabil Benamar*
>> Enseignant-chercheur en Informatique
>> Faculté des Lettres et Sciences Humaines
>> Université Moulay Ismail*
>> Meknes
>> Morocco
>> *GSM: * *+ 212 6 70832236
>> http://nabilbenamar.com/
>>
>> *
>> --------------------------------------------------------------------------------
>> *
>>
>
>
> --
> Daddy TALASI KAZIAMA
> Consultant en Informatique Maintenance et Réseaux ,
> Fondateur du Centre IPv6 Center IN DRC,
> Kinshasa-Limete
> Tél: +243 099 394 653/ 0899871283
> e-mail: daddytalasi at gmail.com
>            talasidaddy at yahoo.fr
> _______________________________________________
> AfrICANN mailing list
> AfrICANN at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/africann
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 7 Dec 2011 11:21:29 -0800
> From: Glen de Saint G?ry <Glen at icann.org>
> Subject: [AfrICANN-discuss] WHOIS Policy Review Team Draft Report -
> 	Public	Comment open
> To: "mail=africann at afrinic.net" <africann at afrinic.net>
> Message-ID:
> 	<41F6C547EA49EC46B4EE1EB2BC2F34184A7DDCE99F at EXVPMBX100-1.exc.icann.org>
> 	
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> http://www.icann.org/en/announcements/announcement-05dec11-en.htm
>
> WHOIS Policy Review Team Draft Report
>
> Comment Period Deadlines (*)
>
> Important Information Links
>
> Public Comment
> Box<http://www.icann.org/en/public-comment/whois-rt-draft-final-report-05dec11-en.htm>
>
> Open Date:
>
> 5 December 2011
>
> To Submit Your Comments
> (Forum)<mailto:whois-rt-draft-final-report at icann.org>
>
> Close Date:
>
> 18 March 2012
>
> Time (UTC):
>
> 23:59
>
> View Comments
> Submitted<http://forum.icann.org/lists/whois-rt-draft-final-report/>
>
> Section I: Description, Explanation, and Purpose
>
>
> The WHOIS Policy Review Team, constituted under ICANN's Affirmation of
> Commitments with the U.S. Department of Commerce, publishes its Draft Report
> and Recommendations for public comment.
>
> In addition to general comments and feedback, the Review Team seeks comment
> on the following issues:
>
>  *   Acceptable timeframes for ICANN to implement the Review Team's
> recommendations;
>  *   Particular ICANN departments, staff or supporting organizations which
> ought to be tasked with particular recommendations, with some explanation;
>  *   Input on all Recommendations, including Recommendation 17 in which two
> variations of scope are presented for the "common interface" recommendation;
>  *   Input on effective and efficient mechanisms for monitoring ICANN's
> progress in implementing the final Recommendations between completion of
> this Report and start of the next WHOIS Policy Review Team; and
>  *   Additional input and notes.
>
> Section II: Background
>
> Over its year of work, the WHOIS Policy Review Team engaged in extensive
> outreach to communities within and outside of ICANN. The Report draws from
> the fact-finding, comments and analysis conducted by a law enforcement
> questionnaire circulated by the Serious Organized Crime Agency (SOCA) of the
> UK, a survey of international Internet users conducted by Atlanta-based User
> Insight, and extensive outreach to all Supporting Organizations and Advisory
> Committees via public comment periods, public forums and individual
> meetings.
>
> Section III: Document and Resource Links
>
>
> Translations of the Draft Report and Recommendations report will be
> provided.
>
>  *   The full WHOIS Policy Review Team Report and Recommendations runs 90
> pages, and can be found here:
> http://www.icann.org/en/reviews/affirmation/whois-rt-draft-final-report-05dec11-en.pdf
> [PDF, 1.04 MB]
>  *   An Executive Summary provides an overview of the Review Team's main
> findings and all recommendations:
> http://www.icann.org/en/reviews/affirmation/whois-rt-draft-final-report-exec-summary-05dec11-en.pdf
> [PDF, 297 KB]
>  *   Appendices can be found here (to be published by 12 December).
>
> Please refer to the WHOIS Policy Review Team's public wiki for more
> information:
> https://community.icann.org/display/whoisreview/WHOIS+Policy+Review+Team
>
> Section IV: Additional Information
>
> The Review Team also will present its Draft Report and Recommendations in
> upcoming Webinars (dates to be announced) and will hold a public forum at
> the March 2012 ICANN meeting in Costa Rica. Given that the Report and
> Recommendations are extensive, and carry implications for many areas of
> ICANN and communities within and outside of ICANN, the Public Comment period
> will remain open through the end of the ICANN Costa Rica meeting, until 18
> March 2012. The WHOIS Policy Review Team's Final Report and Recommendations
> will be published by 30 April 2012.
>
> Staff Contact:
>
> Olof Nordling
>
> Email:
>
> olof.nordling at icann.org<mailto:olof.nordling at icann.org?subject=More%20information%20on%20the%20WHOIS%20Policy%20Review%20Team%20Draft%20Report%20public%20comment%20period>
>
>
> Glen de Saint Géry
> GNSO Secretariat
> gnso.secretariat at gnso.icann.org<mailto:gnso.secretariat at gnso.icann.org>
> http://gnso.icann.org
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.afrinic.net/pipermail/africann/attachments/20111207/3375e714/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> AfrICANN mailing list
> AfrICANN at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/africann
>
>
> End of AfrICANN Digest, Vol 58, Issue 11
> ****************************************
>


-- 
SCHOMBE BAUDOUIN
CENTRE AFRICAIN D'ECHANGE CULTUREL/
ACADEMIE DES TIC
FACILITATEUR GAID/AFRIQUE Membre
At-Large Member
NCSG Member

email:baudouin.schombe at gmail.com
         baudouin.schombe at ticafrica.net
tél:+243998983491
skype:b.schombe
wite web:http://webmail.ticafrica.net
blog:http://akimambo.unblog.fr


More information about the AfrICANN mailing list