Équipe d'ingénierie de l'Internet (IETF)	M. Eisler, NetApp	
Request for Comments: 5665	janvier 2010	
RFC mise à jour : 1833		
Catégorie : Sur la voie de la normalisation		
ISSN: 2070-1721  	Traduction Claude Brière de L'Isle	

Considérations de l'IANA pour les identifiants de réseau et les formats d'adresse universelles d'appel de procédure distante (RPC)

Résumé
Le présent document fait la liste des considérations relatives à l'IANA pour les identifiants de réseau (netid, Network Identifier) et les adresses réseau universelles (uaddr, Universal Network Address) d'appel de procédure distante (RPC, Remote Procedure Call). Le présent document met à jour, mais ne remplace pas, la RFC 1833.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5665 

Notice de droits de reproduction
Copyright (c) 2010 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Table des matières
1. Introduction et motivation	1
2. Langage des exigences	2
3. Considérations sur le Netid du protocole de transmission de commandes de flux	2
4. Considérations sur la sécurité	2
5. Considérations relatives à l'IANA	2
5.1 Considérations de l'IANA sur les identifiants de réseau	2
5.2 Considérations de l'IANA sur les formats d'Uaddr	4
5.3 Référence croisée entre le Netid et le registre de formats	6
5.4 Allocation d'accès pour NFS sur SCTP	6
6. Références	6
6.1 Références normatives	6
6.2 Références pour information	6
Appendice A. Remerciements	7
Adresse de l'auteur	7

 	1.	Introduction et motivation

Les concepts d'un RPC (défini dans la [RFC5531])  d'un identifiant de réseau (netid, Network Identifier) et d'une adresse universelle de RPC (uaddr, Universal Address) ont été introduits dans la [RFC1833] pour distinguer les adresses réseau de plusieurs protocoles et représenter ces adresses en forme canonique. La RFC 1833 déclare qu'un netid "est défini par un administrateur de système sur la base de conventions locales, et ne peut pas dépendre d'avoir la même valeur sur chaque système". (Le netid est contenu dans le champ r_netid du type de données rpcb_entry, et l'uaddr est contenue dans le champ r_addr du même type de données, où rpcb_entry est défini dans la RFC 1833.) Depuis la publication de la RFC 1833, il a été trouvé que des protocoles comme le système de fichier réseau version 4 (NFSv4.0, Network File System version 4) [RFC3530] et l'accès direct à la mémoire distante (RPC/RDMA, Remote Direct Memory Access) [RFC5666] dépendent de valeurs cohérentes des netids et des représentations des uaddrs. Les pratiques courantes tendent à assurer cette cohérence. Donc, le présent document identifie les considérations pour que l'IANA établisse les registres de formats de netid et de uaddr pour RPC et spécifie le contenu initial des deux registres.

 	2.	Langage des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Considérations sur le netid du protocole de transmission de commandes de flux

Le protocole de transmission de commandes de flux (SCTP, Stream Control Transmission Protocol) (décrit dans la [RFC4960]) est un protocole en mode connexion qui prend en charge le transfert de données en mode de flux d'octets et en mode enregistrement. Quand les identifiants de réseau"sctp" et "sctp6" sont utilisés, la norme de marquage d'enregistrement RPC de calcul de réseau ouvert (ONC, Open Network Computing) (voir la Section 11 de la [RFC5531]) n'est pas utilisée ; à la place est utilisé le transfert de données natif en mode enregistrement de SCTP.

 	4.	Considérations sur la sécurité

Comme le présent document est seulement concerné par la gestion par l'IANA du registre de format d'identifiant de réseau (netid, Network Identifier) et d'adresses universelles de réseau (uaddr, Universal Network Address) il ne soulève pas de nouveau problème de sécurité.

 	5.	Considérations relatives à l'IANA

Cette section utilise des termes qui sont définis dans la [RFC5526].

 	5.1	Considérations de l'IANA sur les identifiants de réseau
L'IANA a créé un registre appelé "Identifiants de réseau ONC RPC". Le reste de cette section décrit le registre.

Toutes les allocations au registre des netid ONC RPC sont faites sur une des deux bases suivantes :

o	Un sous registre au premier arrivé, premier servi conformément au paragraphe 4.1 de la RFC 5226.

o	Un sous registre sur la base d'action de normalisation conformément au paragraphe 4.1 de la RFC 5226.

Le codage de représentation de données externes (XDR, eXternal Data Representation) permet que les netids fassent jusqu'à 2^32 - 1 octets de long, mais le registre va seulement permettre une longueur bien plus courte. Les allocations faites par action de normalisation devraient allouer des netids long de 1 à 8 octets. Les allocations faites au premier arrivé, premier servi devraient allouer des netids long de 9 à 128 octets. Des exceptions sont mentionnées au Tableau 2.

Une portion de l'espace de noms de netid est réservée :

o	Tous les netids, sans considération de longueur, qui commencent par les préfixes "STDS" ou "FCFS" sont réservés, afin d'étendre l'espace de noms d'action de normalisation ou de premier arrivé, premier servi.

o	Pour donner à l'avenir à l'IESG la souplesse de permettre des utilisations privées et expérimentales, tous les netids avec les préfixes "PRIV" ou "EXPE" sont réservés.

o	Pour prévenir toute confusion avec le protocole de contrôle de même nom [RFC0792], les netids avec le préfixe "ICMP" sont réservés.

o	Comme les netids ne sont pas construits d'une manière explicitement hiérarchique, le présent document ne donne pas d'allocation hiérarchique des netids. Néanmoins, tous les netids qui contiennent l'octet "." sont réservés pour une future possible disposition d'allocation hiérarchique.

o	Le netid de longueur zéro est réservé.

Une convention recommandée pour les netids correspondants aux transports qui fonctionnent sur le protocole IPv6 est d'avoir "6" comme dernier caractère du nom du netid.

Il y a deux sous registres de netids : un pour les allocations d'action de normalisation et un pour les allocations de premier arrivé, premier servi. Chaque registre de netids est une liste d'allocations, chacune contenant cinq champs pour chaque allocation.

1.	Une chaîne US-ASCII de nom qui est le netid réel. Le netid devrait être long de 1 à 8 octets pour le sous registre d'action de normalisation, et de 9 à 128 octets pour le sous registre de premier arrivé, premier servi. Le netid NE DOIT PAS entrer en conflit avec tout autre netid enregistré. En dépit du fait que les netids sont sensibles à la casse, le netid, quand il est transposé en majuscules, NE DOIT PAS être en conflit avec la valeur d'un autre netid enregistré après que le netid enregistré est transposé en majuscules. De plus, quand il est transposé en majuscules, le préfixe du netid NE DOIT PAS être égal à un préfixe réservé.

2.	Un nom constant qui peut être utilisé pour des programmes de logiciel qui souhaitent utiliser le protocole de transport associé au netid. Le nom de la constante a normalement le préfixe "NC_", et un suffixe égal à la version majuscule du netid. Ce nom constant devrait être une constante valide dans le langage de programmation C. Ce nom constant NE DOIT PAS entrer en conflit avec un autre nom constant de netid. Les noms constants avec le préfixe "NC_STDS", "NC_FCFS", "NC_PRIV", "NC_EXPE", et "NC_ICMP" sont réservés. Les noms constants avec un préfixe de "NC_" et une longueur totale de 11 caractères ou moins devraient être pour des allocations faites sur la base d'action de normalisation. La constante "NC_" est réservée. Le nom constant peut être de 1 à 131 octets.

Étant donnée la déduction normale du nom constant du netid, l'enregistrement de la constante pourrait être considéré comme redondant. Ce n'est pas toujours vrai. Par exemple, un netid pourrait utiliser un caractère qui n'est pas valide dans le langage de programmation. La première entrée du Tableau 1 donne un tel exemple.

3.	Une description et/ou une référence à une description de comment le netid va être utilisé. Pour les allocations faites au premier arrivé, premier servi, la description devrait inclure, si applicable, une référence aux protocoles de transport et de réseau correspondants au netid. Pour les allocations faites sur la base d'une action de normalisation, le champ de description doit inclure le numéro des RFC du protocole associé au netid, incluant, si applicable, les numéros de RFC des protocoles de transport et de réseau.

4.	Un point de contact de l'enregistrant. Pour les allocations faites au premier arrivé, premier servi :
*	le point de contact devrait inclure une adresse de messagerie,
*	sous réserve de l'autorisation d'un expert désigné, le point de contact peut être omis pour des situations extraordinaires, comme l'enregistrement d'un netid couramment utilisé lorsque le propriétaire est inconnu.
Pour les allocations sur la base d'une action de normalisation, le point de contact est toujours déterminé par l'IESG.

5.	Une valeur numérique, utilisée pour croiser la référence de l'allocation du netid avec une allocation dans le registre de format uaddr (voir le paragraphe 5.2). Si l'enregistrant enregistre un netid qui croise la référence d'une allocation existante dans le registre de format uaddr, alors l'enregistrant fournit la valeur réelle de la référence croisée avec la date à laquelle l'enregistrant a restitué la valeur de la référence croisée du registre de format uaddr. Si l'enregistrant enregistre à la fois un nouveau netid et un nouveau format d'uaddr, alors l'enregistrant fournit une valeur de TBD1 dans la demande de netid, et utilise TBD1 dans la demande de format uaddr. L'IANA va alors substituer le TBD1 au numéro de référence croisée qu'alloue l'IANA. Noter que si un document demande plusieurs allocations de netid et d'uaddr, chaque référence croisée de format uaddr supplémentaire va être identifiée comme TBD2, TBD3, ..., etc.

 	5.1.1	Registre initial
La liste initiale des netids est séparée en deux sous registres : ceux alloués au premier arrivé, premier servi dans le Tableau  1 et ceux alloués par action de normalisation dans le Tableau 2. Ces listes vont changer lorsque l'IANA enregistrera comme nécessaire des netids supplémentaires, et la liste d'autorité des netids enregistrés sera toujours tenue par l'IANA.

Netid	Nom de constante	Description et/ou référence	PoC	CR	
"-"	NC_NOPROTO	[RFC1833], § 5.2.3.2 de la RFC 5665	1		
"ticlts"	NC_TICLTS	Transport de rebouclage sans connexion utilisé dans le système V livraison 4 et autres systèmes d'exploitation. Bien que cette allocation soit faite au premier arrivé, premier servi et fasse moins de neuf caractères, l'exception est autorisée. Voir [UNIX].		0	
"ticots"	NC_TICOTS	Transport de rebouclage en mode connexion utilisé dans le système V livraison 4 et autres systèmes d'exploitation. Voir [UNIX]. Bien que cette allocation soit faite au premier arrivé, premier servi  et fasse moins de neuf caractères, l'exception est autorisée.		0	
"ticotsord"	NC_TICOTSORD	Transport de rebouclage en mode connexion avec livraison dans l'ordre utilisé dans le système V livraison 4 et autres systèmes d'exploitation. Voir [UNIX].		0	

Tableau 1 : Allocations initiales de netid au premier arrivé, premier servi

PoC : point de contact.
CR : référence croisée au registre de format uaddr.

Netid	Nom de constante	RFC(s) et description (si incorporée)	PoC	CR
"rdma"	NC_RDMA	[RFC5666], [RFC0791] 	IESG	2
"rdma6"	NC_RDMA6	[RFC5666], [RFC2460]	IESG	3
"sctp"	NC_SCTP	[RFC4960], [RFC0791], Section 3 de [RFC5665]	IESG	2
"sctp6"	NC_SCTP6	[RFC4960], [RFC2460], Section 3 de [RFC 5665]	IESG	3
"tcp"	NC_TCP	[RFC0793], [RFC0791], Section 11 de [RFC5531]	IESG	2
"tcp6"	NC_TCP6	[RFC0793], [RFC2460], Section 11 de [RFC5531]	IESG	3
"udp"	NC_UDP	[RFC0768], [RFC0791]	IESG	2
"udp6"	NC_UDP6	[RFC0768], [RFC2460]	IESG	3

Tableau 2 : Allocations initiales de netid par action de normalisation

 	5.1.2	Mise à jour des enregistrements
Conformément au paragraphe 5.2 de la RFC 5226, il est toujours permis à l'enregistrant de mettre à jour un enregistrement fait sur la base du premier arrivé, premier servi sous réserve des mêmes contraintes et de revue qu'avec de nouveaux enregistrements. Il est permis à l'IESG ou un expert désigné de mettre à jour tout enregistrement fait sur la base du premier arrivé, premier servi, ce qui est normalement fait quand le PoC ne peut pas être joint afin de faire les mises à jour nécessaires. Des exemples où une mise à jour serait nécessaire incluent, mais ne se limitent pas à l'adresse de messagerie ou d'autres informations de contact deviennent invalides, la référence au protocole correspondant devient obsolète ou indisponible, la RFC 1833 est mise à jour ou remplacée d'une façon telle que la portée des netids change, exigeant des champs supplémentaires dans l'allocation.

Seul l'IESG, sur avis d'un expert désigné, peut mettre à jour un enregistrement fait par action de normalisation.

 	5.2	Considérations de l'IANA sur les formats d'uaddr
L'IANA a créé un registre appelé "Registre des formats d'uaddr ONC RPC" (appelé "registre des formats" dans la suite de ce document). Ce paragraphe décrit le registre.

Toutes les allocations au registre des formats sont faites sur une des deux bases :
o	Premier arrivé, premier servi selon le paragraphe 4.1 de la RFC 5226.
o	Action de normalisation selon le paragraphe 4.1 de la RFC 5226.

Le registre des formats est une liste d'allocations, chacune contenant quatre champs pour chaque allocation.

1.	La base d'allocation, qui peut être soit FCFS (First Come First Served) soit STDS (Standards Action).

2.	Une description et/ou référence à une description du format d'uaddr actuel. Les allocations faites par action de normalisation ont toujours une référence à une RFC.

3.	Pour les allocations faites au premier arrivé, premier servi, un point de contact, incluant une adresse de messagerie. Sous réserve d'autorisation par un expert désigné, le point de contact peut être omis pour des situations extraordinaires, comme l'enregistrement d'un format couramment utilisé où le propriétaire est inconnu. Pour les allocations faites par action de normalisation, le point de contact est toujours déterminé par l'IESG.

4.	Une valeur numérique, utilisée pour une référence croisée à l'allocation de format avec une allocation dans le registre de netid. L'enregistrant fournit une valeur de TBD1 pour le champ de référence croisée quand il demande une allocation. L'IANA va allouer à TBD1 une valeur réelle. Noter que si un document demande plusieurs allocations d'uaddr, chaque référence croisée de format d'uaddr va être identifiée par TBD2, TBD3, ..., etc.

Toutes les demandes d'allocations au registre de format sur la base d'une action de normalisation sont par des RFC sur la voie de la normalisation approuvée par l'IESG.

 	5.2.1	Registre initial
La liste initiale des formats est dans le Tableau 3. Cette liste va changer lorsque IANA enregistrera des formats supplémentaires comme nécessaire, et la liste d'autorité des formats enregistrés sera toujours tenue par l'IANA.

Base	Description et/ou référence	PoC	CR
FCFS	Format d'uaddr de transport de bouclage de système V livraison 4.		0
	Paragraphe 5.2.3.1 de la RFC 5665
FCFS	Format d'uaddr pour NC_NOPROTO. § 5.2.3.2 de RFC 5665		1
STDS	Format d'uaddr pour transports IPv4. § 5.2.3.3 de RFC 5665	IESG	2
STDS	Format d'uaddr pour transports IPv6. § 5.2.3.4 de RFC 5665	IESG	3

Tableau 3 : Allocations initiales de format

 	5.2.2	Mise à jour des enregistrements
Il est toujours permis à l'enregistrant de mettre à jour un enregistrement fait au premier arrivé premier servi "sous réserve des mêmes contraintes et revue qu'avec les nouveaux enregistrements". Il est permis à l'IESG de mettre à jour tout enregistrement fait au premier arrivé, premier servi, qui est normalement fait quand le PoC ne peut pas être joint pour faire les mises à jour nécessaires. Des exemples où une mise à jour serait nécessaire incluent, sans s'y limiter, que l'adresse de messagerie ou d'autres information de contact deviennent invalides, la référence à la description de format devient obsolète ou indisponible, la RFC 1833 est mise à jour ou remplacée d'une manière telle que la portée des formats d'uaddr change, exigeant des champs supplémentaires dans les allocations.

Seul l'IESG, sur l'avis d'un expert désigné, peut mettre à jour un enregistrement fait par une action de normalisation.

 	5.2.3	Formats d'uaddr
 	5.2.3.1	Formats d'uaddr pour les bouclages de transports de système V livraison 4
Bien que la RFC 1833 spécifie une uaddr comme une chaîne de type de données XDR (donc, limitée à de l'US-ASCII) les mises en œuvre de transports de rebouclage de système V livraison 4 vont utiliser une chaîne opaque d'octets. Donc, le format d'une adresse de transport de rebouclage est tout dispositif d'octets de longueur non zéro.

 	5.2.3.2	Format d'uaddr pour netid "-"
Il n'y a pas de format d'adresse pour le netid "-". Ce netid est apparemment pour usage interne afin de prendre en charge certaines mises en œuvre de la RFC 1833.

 	5.2.3.3	Format d'uaddr pour la plupart des transports IPv4
La plupart des protocoles de transport qui opèrent sur IPv4 utilisent des numéros d'accès de 16 bits, y compris RDMA [RFC5666], SCTP [RFC4960], TCP [RFC0793], et UDP [RFC0768]. Le format de l'uaddr pour les transports d'accès à 16  bits ci-dessus (quand ils sont utilisés sur IPv4) est la chaîne US-ASCII : h1.h2.h3.h4.p1.p2

Le préfixe "h1.h2.h3.h4" est la forme textuelle standard pour représenter une adresse IPv4, qui est toujours longue de quatre octets. En supposant l'ordre gros boutien, h1, h2, h3, et h4 sont, respectivement, du premier au quatrième octet, chacun convertis en ASCII décimal. Le suffixe "p1.p2" est une forme textuelle pour représenter un accès de service. En supposant l'ordre gros boutien, p1 et p2 sont, respectivement, le premier et le second octet, chacun convertis en ASCII décimal. Par exemple, si un hôte, en ordre gros boutien, a une adresse en hexadécimal de 0xC0000207 et si un service écoute dessus, en ordre gros boutien, accès 0xCB51 (décimal 52049) alors l'uaddr complet est "192.0.2.7.203.81".

 	5.2.3.4	Format d'uaddr pour la plupart des transports IPv6
La plupart des protocoles de transport qui opèrent sur IPv6 utilisent des numéros d'accès de 16 bits, y compris RDMA [RFC5666], SCTP [RFC4960], TCP [RFC0793], et UDP [RFC0768]. Le format de l'uaddr pour les transports d'accès de 16  bits ci-dessus (quand utilisés sur IPv6) est la chaîne US-ASCII : x1:x2:x3:x4:x5:x6:x7:x8.p1.p2

Le suffixe "p1.p2" est l'accès de service, et est calculé de la même façon qu'avec les uaddrs pour les transports sur IPv4 (voir le paragraphe 5.2.3.3). Le préfixe "x1:x2:x3:x4:x5:x6:x7:x8" est la forme textuelle préférée pour représenter une adresse IPv6 comme défini au paragraphe 2.2 de la [RFC4291]. De plus, les deux formes de remplacement spécifiées au paragraphe 2.2 de la RFC 4291 sont aussi acceptables.

 	5.2.3.5	Format d'uaddr pour ICMP sur IPv4 et IPv6
Comme ICMP n'est pas un vrai transport, il n'y a pas de format d'uaddr pour ICMP. Les allocations de netid "icmp" et "icmp6" et leur "format" d'uaddr partagé sont mentionnées pour empêcher tout enregistrant d'allouer les netids "icmp" et "icmp6" pour un objet qui causerait probablement de la confusion.

 	5.3	Référence croisée entre le netid et le registre de formats
Le dernier champ du registre des netids est utilisé pour faire une référence croisée avec le dernier champ du registre de formats. L'IANA n'a aucune obligation de maintenir les mêmes valeurs numériques dans les références croisées quand elle met à jour chaque registre ; c'est-à-dire, l'IANA est libre de "re-numéroter" les champs correspondants. Cependant, si l'IANA le fait, les deux registres de netids et de formats doivent être chacun mis à jour.

 	5.4	Allocation d'accès pour NFS sur SCTP
L'accès 2049 est alloué à NFS sur SCTP pour les identifiants de réseau sctp et sctp6.
 	6.	Références
 	6.1	Références normatives

[RFC1833]	R. Srinivasan, "Protocoles de liaison pour RPC ONC version 2", août 1995. (P.S.) (MàJ par RFC5665)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC4291]	R. Hinden, S. Deering, "Architecture d'adressage IP version 6", février 2006, DOI 10.17487/RFC4291. (MàJ par 5952 et 6052, 8064) (D.S.)

 	6.2	Références pour information

[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC0792]	J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981. (MàJ par la RFC6633) 

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7,  DOI 10.17487/RFC0793, septembre 1981. (Remplacée par 9293)

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S ; Remplacée par RFC8200, STD 86)

[RFC3530]	S. Shepler et autres, "Protocole de système de fichiers réseau (NFS) v. 4", avril 2003. (P.S. ; remplacée par RFC7530)

[RFC4960]	R. Stewart, éd., "Protocole de transmission de commandes de flux (SCTP)", septembre 2007. (Remplace RFC2960, RFC3309 ; P.S. ; Remplacée par RFC9260)

[RFC5526]	J. Livingood, P. Pfautz, R. Stastny, "Application du système de découverte dynamique de délégation (DDDS) de E.164 en identifiant uniforme de ressource (URI) pour l'infrastructure ENUM", avril 2009. (Information)

[RFC5531]	R. Thurlow, "RPC : version 2 de la spécification du protocole d'appel de procédure à distance", mai 2009. (P.S. ; remplace RFC1831 ; MàJ par 9289)

[RFC5666]	T. Talpey, B. Callaghan, "Transport de l'accès direct en mémoire distante pour les appels de procédure distante", janvier  2010. (P.S. ; Remplacée par RFC8166)

[UNIX]	American Telephone et Telegraph Company, "UNIX System V, Release 4 Programmer's Guide: Networking Interfaces", ISBN 0139470786, 1990.

 	Appendice A.	Remerciements

Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen Schoenwaelder, et Robert Sparks ont relu le document et fourni de précieux retours.

 	Adresse de l'auteur

Mike Eisler
NetApp
5765 Chase Point Circle
Colorado Springs, CO  80919
US
téléphone : +1-719-599-9026
mél : mike@eisler.com