Réflexions sur le DNS, la RFC1591, et les catégories de domaines

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice des droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Résumé

La RFC1591, "Structure et délégation du système des noms de domaines", posait le concept et les principes administratifs de base de l’allocation et de l’administration des domaines, depuis le niveau supérieur jusqu’en bas. Elle a été écrite avant l’introduction de la toile mondiale (WWW, world wide web) et la croissance rapide de l’Internet a fait peser une pression significative du marché, de la société, et de la politique sur les allocations de noms de domaines. Ces dernières années, la RFC1591 a été citée de tous côtés dans divers débats, et des tentatives ont été faites par divers organes pour la mettre à jour ou ajuster ses dispositions, parfois sous des pressions qui ont eu pour résultat discutable de produire des politiques qui sont moins bien pensées que celles de l’original. Certains de ces efforts sont partis d’un malentendu sur les dispositions de la RFC1591 ou sur les motivations de ces dispositions. Les directives actuelles de la corporation de l’Internet pour l’allocation des noms et des numéros (ICANN, Internet Corporation for Assigned Names and Numbers) et des autres groupes qui déterminent maintenant les orientations de la politique du système des noms de domaines (DNS, Domain Name System) paraissent dériver de la politique et de la philosophie de la RFC1591. Le présent document est publié principalement pour le contexte historique et des besoins de comparaison, essentiellement pour documenter des réflexions sur la façon dont la RFC1591 pourrait être interprétée et ajustée par l’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) et l’ICANN pour mieux refléter le monde d’aujourd’hui tout en conservant les caractéristiques et les politiques qui ont prouvé leur efficacité en prenant en charge la croissance et la stabilité de l’Internet. Une variante antérieure du présent mémoire a été soumise à l’ICANN comme un commentaire sur sa politique pour l’évolution des domaines de niveau supérieur (TLD, Top-level Domain).

1. Introduction

La RFC1591 [1] a été longuement discutée et a servi de référence ces deux dernières années, en particulier dans les discussions au sein de l’ICANN et de ses prédécesseurs au sujet de la création, de la délégation, et de la gestion des domaines de niveau supérieur. En particulier, l’Organisation de prise en charge des noms de domaines (DNSO, Domain Name Supporting Organization) de l’ICANN, et en particulier sa constitution du ccTLD, ont été le lieu de nombreuses discussions dans lesquelles la RFC1591 et ses interprétations on été citées à l’appui de positions diverses et parfois contradictoires. Durant cette période, d’autres discussions sont allé bon train pour essayer de reconstruire la pensée qui sous-tendait la RFC1591. Ce sont elles qui m’ont conduit avec quelques autres à réfléchir à la façon dont ces idées fondatrices pouvaient se rapporter à certaines des questions soulevées aujourd’hui. La RFC1591 est, je le crois, un des chef d’œuvre de Jon Postel, liant ensemble des philosophies très différentes (par exemple, son idée favorite que les gens sont fondamentalement raisonnables et feront ce qui est bien si on leur dit ce que c’est avec quelques mécanismes plus forts quand ce modèle ne réussit pas) en un tout unitaire.

La RFC1591 a été écrite dans le contexte de l’hypothèse que ce qui a été décrit comme domaines de niveau supérieur génériques serait lié à des politiques et des catégories d’enregistrement (voir le texte "Ce domaine est destiné..." à la section 2) alors que les ccTLD étaient supposés être utilisés principalement pour prendre en charge les utilisateurs et les utilisations au sein d’un pays et pour ses résidents. La notion que des domaines différents fonctionneraient de façons différentes – quoique au sein des larges contextes de "service public au nom de la communauté de l’Internet" et de "dépositaire... pour la communauté mondiale de l’Internet" -- était considérée comme une caractéristique de conception et un garde-fou contre divers abus potentiels. Visiblement, le monde a changé de nombreuses façons dans les sept ou huit ans écoulés depuis la rédaction de la RFC1591. En particulier, l’Internet est devenu plus lourdement utilisé et, parce que le concept de toile mondiale a mis les noms de domaines en première ligne devant les utilisateurs, les noms de domaines de niveau supérieur et les enregistrements en leur sein on été en forte demande : non seulement avec la croissance spectaculaire du nombre d’hôtes durant cette période, mais le rapport entre les noms de domaine enregistrés et les hôtes physiques a augmenté de façon très significative.

Les questions que la RFC1591 tentait de régler lors de sa rédaction et celles qui nous font face aujourd’hui n’ont pas changé de façon significative dans leur principe. Mais une alternative aux tendances présentes serait de prendre un peu de recul pour préciser un modèle qui peut fonctionner efficacement aujourd’hui. Il peut donc être utile d’essayer de reconstruire les principes de la RFC1591 et de réfléchir à leur applicabilité aujourd’hui comme un modèle qui pourrait continuer de s’appliquer, non pas à cause de sa signification historique, mais parce que nombre de ses éléments se sont révélés fonctionner raisonnablement bien, même dans des situations difficiles. En particulier, pour de nombreux domaines (certains dans la liste des "génériques" de la RFC1591 et d’autres dans la catégorie des "codes de pays") la notion de "service public" – dont on attendait alors qu’elle implique une prise en charge gratuite ou à un coût minimal pour les utilisateurs, et pas simplement sur la base de l’absence de bénéfice – a donné lieu à des calculs de profitabilité. Et pour le reste, dans la plus grande partie, les considérations de calcul et de récupération des coûts se sont insinuées. Alors que beaucoup d’entre nous éprouvent une certaine nostalgie à l’égard du vieux système, il est clair que ses jours sont comptés sinon passés ; peut-être que les notions de service public telles qu’elles étaient comprises lors de la rédaction de la RFC1591 ne s’adaptent tout simplement pas à la croissance rapide de l’Internet et au très grand nombre d’enregistrements.

En particulier, certains domaines de niveau supérieur de code de pays (ccTLD, country code top-level domain) ont annoncé des enregistrements en-dehors du pays désigné (ou autres entités) alors que d’autres ont pris des décisions explicites pour permettre des enregistrements de non nationaux. Ces décisions et d’autres ont produit des protestations de nombreux côtés, qui suggèrent à leur tour que la refonte des catégories est à l’ordre du jour. Par exemple, on a entendu les inquiétudes des gouvernements et des dirigeants d’entreprises de ccTLD traditionnels, de "services publics" nationaux, sur les interférences excessives de l’ICANN et de leur peur d’être forcés de se conformer à des politiques établies au niveau international pour la résolution de conflits alors que leurs politiques domestiques sont considérées comme plus appropriées. On a aussi entendu les inquiétudes des registraires et des opérateurs de ces ccTLD à promotion commerciale externe sur l’interférence déraisonnable des gouvernements et de la part des registraires et enregistrés des TLD génériques (gTLD) sur la concurrence déraisonnables qui leur est livrée par les ccTLD au démarchage commercial agressif. La distinction appropriée n’est plus entre ce que décrivait la RFC1591 comme TLD "génériques" (mais qui étaient réellement destinés à être "spécifiques d’un objet", un terme que j’utiliserai à nouveau plus loin) et les ccTLD mais entre :

(i) Les vrais TLD "génériques", dans lesquels tout enregistrement est acceptable et où, ordinairement, les enregistrements provenant de toutes sources sont activement promus. Cette liste inclut actuellement les (anciennement spécifiques d’un objet) COM, NET, et ORG, et certains ccTLD. Il y a de temps en temps des propositions pour ajouter des TLD de cette variété dans laquelle, comme avec COM (et, plus récemment, NET et ORG) n’importe qui (sous réserve généralement des seuls conflits de nom et de législations nationales) pourrait s’enregistrer moyennant finances.

(ii) Les TLD spécifiques d’un objet, dans lesquels l’enregistrement n’est accepté que de la part d’organisations ou individus qui satisfont à des qualifications particulières, mais où ces qualifications ne sont pas liées à des frontières nationales. Cette liste inclut actuellement INT, EDU, le domaine d’infrastructure ARPA, et, qu’on peut discuter, les TLD spécialisés du gouvernement US MIL et GOV. Il y a de temps en temps des propositions pour d’autres TLD internationaux de cette variété, par exemple, pour des entités médicales telles que les pharmacies et les hôpitaux ainsi que pour les musées. L’ICANN a récemment approuvé plusieurs TLD de ce type et les décrit comme des TLD "parrainés".

(iii) Les domaines de pays, qui fonctionnent conformément aux hypothèses de base originales de la RFC1591, c’est-à-dire que les enregistrés sont dans une large mesure supposés être des gens ou autres entités du pays. Bien que des adhésions externes puissent être acceptées par certains d’entre eux, le pays ne fait pas une publicité agressive pour de telles adhésions, et personne ne s’attend à une dérive significative du revenu des redevances à partir de ces adhésions externes. Tous les domaines actuels dans cette catégorie sont des ccTLD, mais tous les ccTLD ne sont pas dans cette catégorie.

Ces catégories sont clairement orthogonale à l’association entre l’utilisation de la liste des codes enregistrés par la norme internationale ISO 3166-1 [2] et les noms de "pays" à deux lettres. Si cette relation doit être conservée (et je pense que c’est souhaitable) la seule exigence intrinsèque est qu’aucun TLD à deux lettres ne soit créé sauf à partir de cette liste (afin d’éviter des conflits à l’avenir). L’ICANN devrait contrôler l’allocation et la délégation des TLD en utilisant ces critères, parmi d’autres, mais seuls les codes à deux lettres enregistrés par ISO 3166-1 devraient être utilisés comme TLD à deux lettres.

2. Implications des catégories

Si nous avions adopté ce type de catégorisation à trois branches et si on avait pu le faire fonctionner, je pense que cela aurait présenté plusieurs opportunités à l’ICANN et plus généralement à l’ensemble de la communauté pour réduire les controverses et aller de l’avant. Bien sûr, il y a des cas où la catégorisation d’un domaine particulier et de son style de fonctionnement ne va pas être complètement tranchée (voir la section 3, ci-après). Mais voir l’ICANN trouver des procédures pour traiter ces situations (probablement peu nombreuses) apparaît préférable aux stratégies qui tendent à propulser l’ICANN dans des arènes qui sont au-delà de sa compétence ou qui pourraient requérir une expansion significative de son mandat.

D’abord, les ccTLD fonctionnant en interne (la catégorie iii ci-dessus) ne devraient pas être obligés d’avoir une interaction forte avec l’ICANN ou réciproquement. Une fois qu’un domaine de cette sorte est établi et délégué, et en supposant que la règle du "contact administratif dans le pays" est strictement observée, le domaine devrait être capable de fonctionner de façon efficace sans intervention ou supervision de l’ICANN. En particulier, alors qu’un pays pourrait choisir d’adopter les politiques générales de l’ICANN sur la résolution des conflits ou la gestion des noms, les problèmes qui surviennent dans ces domaines pourraient tout aussi bien être traités exclusivement dans le cadre des lois nationales applicables. Si un domaine choisit d’utiliser les services de l’ICANN dont la fourniture coûte des ressources, il devrait contribuer à la prise en charge de l’ICANN, mais si il ne le fait pas, l’ICANN ne devrait pas envisager de lui faire payer autre chose qu’une fraction raisonnable des coûts de l’ICANN pour le fonctionnement de la racine, des serveurs racines, et de tous les systèmes de répertoires dont il y a accord général sur leur nécessité et auxquels participe le domaine.

À l’opposé, les ccTLD qui fonctionnent comme des domaines génériques devraient être traités comme des domaines génériques. Les politiques de l’ICANN en matière de résolution de conflit et de gestion des noms et toutes les règles spéciales développées pour protéger l’Internet public dans plusieurs situations de registraire ou d’enregistré devraient raisonnablement s’appliquer.

3. Séparer les types de TLD

Si des politiques appropriées sont adoptées, les ccTLD qui fonctionnent comme des domaines génériques (la catégorie (i) ci-dessus) et ceux qui fonctionnent comme des domaines de pays (la catégorie (iii) ci-dessus) devraient pouvoir être identifiés tout seuls. Il y a plusieurs critères qui pourraient être appliqués à cette détermination. Par exemple, si un domaine a ou non une politique de recherche agressive d’adhésions extérieures et si la grande majorité de ses enregistrés dans son domaine est ou non dans le pays. On pourrait aussi voir cela comme la question d’avoir un niveau de présence tangible dans le domaine de juridiction – par exemple, le contact administratif est-il soumis, en pratique, aux lois du pays, ou les règles d’enregistrement sont elles telles qu’il soit raisonnablement vraisemblable qu’un tribunal dans la juridiction du pays associé au domaine puisse exercer sa juridiction et mettre en application un jugement contre l’enregistrant ?

Une règle (bien peu intrusive) que l’ICANN pourrait bien imposer à tous les domaines de niveau supérieur serait qu’ils identifient et publient les politiques qu’ils ont l’intention d’utiliser. Par exemple, que les enregistrants dans un domaine qui va utiliser les lois d’un pays particuliers pour résoudre les disputes devraient avoir une opportunité raisonnable de comprendre ces politiques avant l’enregistrement et de prendre d’autres dispositions (par exemple, de s’enregistrer ailleurs) si ce mécanisme de résolution des conflits n’est pas acceptable. Donner à l’IANA (comme registraire racine) des informations incorrectes sur les objectifs et l’utilisation d’un domaine devrait pouvoir être mis en cause, et devrait servir de base à la révision de l’opportunité de la délégation de domaine, tout comme le fait d’agir de façon incohérente et inéquitable donne de telles bases selon les dispositions originales de la RFC1591.

Pour s’assurer de la disponibilité d’informations d’enregistrement précises et à jour, les critères doivent être cohérents, et en cohérence avec les gTLD plus traditionnels, pour tous les domaines nominalement de code de pays qui fonctionnent comme TLD génériques.

4. Rôle de l’ICANN dans les domaines de pays

L’ICANN (et l’IANA) devraient, comme décrit ci-dessus, avoir aussi peu d’engagement que possible dans la direction des vrais domaines de pays [de code de pays] (c’est-à-dire, la catégorie (iii)). Il n’y a pas de raison particulière pour que ces domaines soient soumis à la régulation de l’ICANN au delà des principes de base de la RFC1591 et des arrangements associés nécessaires pour s’assurer de l’interopérabilité et de la stabilité de l’Internet.

Que l’ICANN évite de s’impliquer dans cette direction la renforce : il est très souhaitable d’éviter des collisions avec la souveraineté nationale, et les questions de détermination de la légitimité des gouvernements, et de l’autorité de quelqu’un qui prétend écrire au nom d’un gouvernement, sont tout aussi importantes aujourd’hui qu’elles l’étaient lors de la rédaction de la RFC1591. Les solutions de remplacement nous font passer rapidement de "l’administration" à la "gouvernance de l’Internet" ou, dans le cas de la détermination de quel prétendant est le gouvernement légitime d’un pays, aux "relations internationales", et les raisons pour ne pas avancer dans cette direction là sont légion.

5. Rôle des gouvernements

L’histoire de la stratégie de l’IANA face au traitement des ccTLD comportait trois considérations majeures de "choses à éviter" :

* Ne jamais se trouver impliqué dans la détermination des entités qui sont des pays et de celles qui n’en sont pas.

* Ne jamais se trouver impliqué dans la détermination de qui est, ou n’est pas, le gouvernement légitime d’un pays. Et plus généralement, éviter de décider quelle légitimité ou droits a telle ou telle entité -- gouvernement, religion, commerce, académie, etc..

* Si possible, ne jamais se trouver impliqué dans des disputes internes à un pays. Encourager plutôt très fortement les parties internes à résoudre les problèmes entre elles. Au plus, adopter un rôle de médiateur et d’éducateur, plutôt que de juge, sauf si des abus sont très clairs et qu’il est évident qu’ils ne seront pas réglés par un mécanisme interne.

Ces trois considérations sont évidemment destinées à éviter que l’IANA soit entraînée dans un bourbier politique dans lequel elle n’avait (et, je pense, n’a) aucune compétence pour résoudre les questions et ne pourrait que prendre des coups. La première considération était la plus visible (et la plus facile) et a été mise en œuvre par une stricte et attentive adhésion (voir ci-dessous) à la liste des codes de pays enregistrée dans la norme ISO 3166. Si une entité a un code, elle est éligible à l’enregistrement comme TLD (bien que l’IANA soit libre d’appliquer des critères supplémentaires – dont la plupart sont établis dans la RFC1591). Si elle n’en a pas, il n’y a pas d’exception : le seul recours du demandeur est de discuter avec l’autorité d’enregistrement de la norme ISO 3166 (qui est maintenant l’Agence de maintenance, souvent juste désignée "3166/MA") ou avec le Bureau des statistiques des Nations Unies, pas avec l’IANA.

Il y a en fait cinq ccTLD qui font exception à ces règles strictes. L’une, "UK", est historique : elle anticipe l’adoption de la norme ISO 3166 sur le sujet. Les autres – île de l’Ascension, Guernesey, île de Man, et Jersey – sont discutables, au moins rétrospectivement, et de simples fautes. Sans considération des raisons historiques (au sujet desquelles il y a eu de nombreuses spéculations) c’est très certainement le cas où la bonne façon de traiter les erreurs de cette sorte est de les reconnaître et de passer à autre chose, plutôt que d’essayer de les utiliser comme précédents pour justifier encore plus d’erreurs.

Ceci est visiblement aussi un argument contre l’utilisation de la liste "réservée" (techniquement interne à l’activité de maintenance de la norme ISO 3166, et qui ne fait pas partie de la norme) : comme l’IANA (ou l’ICANN) peut demander qu’un nom soit placé sur cette liste, il n’y a pas de règle d’une détermination absolue par une organisation externe. Les candidats au titre de pays peuvent venir voir l’ICANN, insister pour avoir des délégations et persuader l’ICANN de demander que les noms soient réservés. Comme le nom réservé va exister, ils pourraient alors insister pour que le domaine soit délégué. Pire, quelqu’un pourrait utiliser une autre organisation pour faire demander la réservation du nom par 3166/MA ; une fois qu’il serait réservé, l’ICANN pourrait être harcelée pour ne pas faire la délégation. Bien sûr, l’ICANN pourrait (et y serait probablement forcée) adopter des critères supplémentaires autres que celui de l’apparition sur la "liste réservée" afin de déléguer de tels domaines. Mais ces critères seraient presque certainement équivalents à déterminer quels candidats sont légitimes et suffisamment stables pour être considérés comme un pays, l’exact processus de décision que la RFC1591 s’efforçait d’éviter.

Les deux autres considérations étaient plus subtiles et pas toujours couronnées de succès : de temps en temps, à la fois avant et après le glissement de la politique formelle vers l’idée que "les gouvernements pourraient avoir leur mot à dire", l’IANA recevait des lettres de gens qui prétendaient être les autorités gouvernementales compétentes pour demander des changements. Certaines d’entre elles se révélèrent plus tard n’avoir pas cette autorité ou les qualifications appropriées. L’hypothèse de la RFC1591 elle-même était que si la règle du "contact administratif dans le pays" était strictement observée, comme l’était la règle que les changements de délégation demandés par le contact administratif seraient honorés, donc, si un gouvernement voulait réellement s’affirmer comme tel, il pouvait mettre la pression sur le contact administratif pour qu’il demande les changements voulus, en utilisant tout ce qui pourrait passer pour le processus légal dans ce pays. Et la capacité à appliquer ce processus et la pression déterminerait efficacement qui est le gouvernement et qui ne l’est pas, et agirait ainsi beaucoup plus efficacement que n’importe quelle évaluation de l’IANA de, par exemple, si le papier à lettre de la demande a l’air authentique (et beaucoup plus sûrement pour l’ICANN que de demander l’opinion d’un autre gouvernement particulier ou d’une sélection de gouvernements).

Le langage spécifique de la RFC1591 a permis à l’IANA d’adopter un principe de "trouvez par vous-mêmes ; si nous devons décider, nous feront des efforts pour une solution qui ne sera satisfaisante pour personne". Cette approche a été utilisée avec succès, additionnée d’une large dose de pédagogie, en de nombreuses occasions pendant ces années, pour éviter à l’IANA d'avoir à assumer le rôle de juge entre des parties en conflit.

Des principes similaires pourraient être appliqués aux frontières entre les TLD génériques fondés sur des codes de pays. Des pays différents, dans des circonstances différentes, peuvent préférer faire fonctionner le ccTLD comme un service national ou comme un centre de profit lorsque les "consommateurs" sont largement externes. Quelles que soient les décisions qui ont été prises dans le passé, la stabilité générale de l’Internet plaide que les changements ne devraient pas être faits à la légère. En même temps, si un gouvernement souhaite faire un changement, le meilleur mécanisme pour le faire est de ne pas impliquer l’ICANN dans une éventuelle détermination de légitimité (ou même d’avoir le comité consultatif de gouvernement (GAC, Government Advisory Committee) de l’ICANN qui essaye de prendre formellement cette décision pour des pays individuels) mais que le gouvernement concerné utilise ses propres procédures pour persuader le contact administratif de demander le changement et que l’IANA satisfasse promptement et efficacement les demandes faites par les contacts administratifs.

6. Implications pour la structure ICANN DNSO actuelle

Les arguments de certains administrateurs de ccTLD selon lesquels ils sont différents du reste des structures de l’ICANN et du DNSO sont (dans ce modèle) corrects : ils sont différents. Les ccTLD qui fonctionnent comme des TLD génériques devraient être séparés de la circonscription des ccTLD et rejoindre la circonscription des gTLD. Les ccTLD de pays devraient être séparés de la structure des organisations de soutien immédiat de l’ICANN et fonctionner dans une structure parallèle et consultative auprès de l’ICANN, de façon semblable aux arrangements utilisés avec le GAC. Le DNSO et les TLD de pays ne devraient pas être obligés d’interagir les uns avec les autres sauf sur une base mutuelle volontaire, et si l’ICANN a besoin d’interaction ou d’avis de certains ou de tous ces TLD, il serait plus approprié de l’avoir sous la forme d’un organe consultatif comme le GAC que sous la forme du DNSO.

7. Références

[1] J. Postel, "Structure et délégation du système de noms de domaine", RFC1591, mars 1994. (Information)

[2] ISO 3166. ISO 3166-1. "Codes pour la représentation des noms de pays et leurs subdivisions - Partie 1 : Codes de pays" (1997).

8. Remerciements

Ces réflexions ont été préparées en mon seul nom et ne reflètent pas nécessairement les vues de mes employeurs passés ou présents. Plusieurs personnes, parmi lesquelles Randy Bush, Theresa Swinehart, Zita Wenzel, Geoff Huston, Havard Eidnes, et plusieurs réviseurs anonymes, ont fait des suggestions ou proposé des commentaires rédactionnels sur des versions précédentes de ce document. Cord Wischhoefer, de l’ISO 3166/MA, a aussi été assez gentil pour relire le projet et a fourni des précisions utiles. Ces commentaires ont contribué de façon significative à la clarté de ce document, mais l’auteur porte la responsabilité du choix des commentaires qui ont été en fin de compte incorporés et de la façon de présenter les conclusions.

9. Considérations pour la sécurité

Le présent mémoire vise le contexte d’un ensemble de décisions et procédures administratives, et ne soulève ou ne règle aucune question de sécurité.

10. Adresse de l’auteur

John C. Klensin

1770 Massachusetts Ave, Suite 322

Cambridge, MA 02140

USA

mél : klensin@jck.com

11. Déclaration de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.