From: Subject: =?utf-8?Q?RFC_2026_:_Le_processus_de_stand?= =?utf-8?Q?ardisation_Internet_=28troisi=C3=A8me_=C3=A9?= =?utf-8?Q?dition=29?= Date: Sat, 23 Feb 2008 21:50:53 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Location: =?utf-8?Q?file://C:\Documents_and_Settings?= =?utf-8?Q?\Administrateur\Local_Settings\T?= =?utf-8?Q?emp\R=C3=A9pertoire_temporaire_2_pour?= =?utf-8?Q?_RFC2026.zip\RFC2026\rfc2026.htm?= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 =EF=BB=BF RFC 2026 : Le = processus de standardisation Internet (troisi=C3=A8me = =C3=A9dition)

Internet, le 5 f=C3=A9vrier 2008,
Ce document qui est une = traduction du=20 document RFC 2026 de l'IETF (Internet=20 Engineering Task Force) peut comporter des erreurs ou en = introduire de=20 nouvelles. Seul le document original =C3=A0 ftp://ftp.rfc-edit= or.org/in-notes/rfc2026.txt=20 fait r=C3=A9f=C3=A9rence.
La traduction est disponible sous licence = Creative Commons=20 (http://creativeco= mmons.org/licenses/by/2.0/fr/)
Traduit=20 par Jean-Jacques Solari et relu par Claude Briere de l'Isle et Olivier=20 Miakinen
(mis =C3=A0 jour le = 15 f=C3=A9vrier 2008).

RFC 2026

Network Working Group (err=
ata)                                S. Bradner
Document RFC : 2026                                   Harvard University
Document BCP : 9                                            Octobre 1996
Remplace     : 1602          =
                                          =20
Cat=C3=A9gorie    : Best Current Practice                                =
   =20

Le processus de standardisation Internet (3=C3=A8me = r=C3=A9vision)

Statut de ce m=C3=A9moire

Ce document recueille les pratiques exemplaires Internet courantes de = la=20 communaut=C3=A9 Internet, et il appelle le d=C3=A9bat et des suggestions = d'am=C3=A9lioration.=20 La distribution de ce m=C3=A9moire est libre.

R=C3=A9sum=C3=A9

Ce m=C3=A9moire documente le processus utilis=C3=A9 par la = communaut=C3=A9 Internet pour la=20 standardisation des protocoles et des proc=C3=A9dures. Il d=C3=A9finit = les stades du=20 processus de standardisation, les pr=C3=A9requis pour mouvoir un = document d'un stade=20 =C3=A0 l'autre et les types de documents utilis=C3=A9s au cours de ce = processus. Il traite=20 =C3=A9galement des questions de droits de propri=C3=A9t=C3=A9 = intellectuelle et de droits=20 d'auteur associ=C3=A9es au processus de standardisation.

Table des mati=C3=A8res

  1. 1. Introduction=20
    1. 1.1. Les=20 standards Internet=20
    2. 1.2. Le=20 processus de standardisation Internet=20
    3. 1.3. Organisation=20 de ce document
  2. 2. Les=20 publications li=C3=A9es aux standards Internet=20
    1. 2.1. Les=20 appels =C3=A0 commentaires (RFC)=20
    2. 2.2. Les=20 projets Internet
  3. 3. Les=20 sp=C3=A9cifications de standards Internet=20
    1. 3.1. Sp=C3=A9cification=20 technique (TS)=20
    2. 3.2. D=C3=A9claration=20 d'applicabilit=C3=A9 (AS)=20
    3. 3.3. Niveaux=20 d'exigence
  4. 4. Le=20 circuit des standards Internet=20
    1. 4.1. Les=20 niveaux de maturit=C3=A9 du circuit des standards=20
      1. 4.1.1. Proposed Standard=20
      2. 4.1.2. Draft Standard=20
      3. 4.1.3. Internet Standard
    2. 4.2. Les=20 niveaux de maturit=C3=A9 hors du circuit des standards=20
      1. 4.2.1. Experimental=20
      2. 4.2.2. Informational=20
      3. 4.2.3. Les=20 proc=C3=A9dures des RFC exp=C3=A9rimentaux et informationnels=20
      4. 4.2.4. Historic
  5. 5. Les=20 RFC de pratiques exemplaires courantes (BCP)=20
    1. 5.1. Le=20 processus de validation des BCP
  6. 6. Le=20 processus de standardisation Internet=20
    1. 6.1. Les=20 actions de standardisation=20
      1. 6.1.1. Le=20 lancement d'une action=20
      2. 6.1.2. La=20 validation et l'approbation de l'IESG=20
      3. 6.1.3. La=20 publication
    2. 6.2. La=20 progression dans le circuit des standards=20
    3. 6.3. La=20 r=C3=A9vision d'un standard=20
    4. 6.4. Le=20 retrait d'un standard=20
    5. 6.5. La=20 r=C3=A9solution des conflits et les appels=20
      1. 6.5.1. Les=20 d=C3=A9saccords des groupes de travail=20
      2. 6.5.2. Les=20 faillites du processus=20
      3. 6.5.3. La=20 pertinence des proc=C3=A9dures=20
      4. 6.5.4. La=20 proc=C3=A9dure d'appel
  7. 7. Les=20 normes et sp=C3=A9cifications externes=20
    1. 7.1. L'utilisation=20 des sp=C3=A9cifications externes=20
      1. 7.1.1. L'incorporation=20 d'une norme ouverte=20
      2. 7.1.2. L'incorporation=20 des autres sp=C3=A9cifications=20
      3. 7.1.3. La=20 prise en charge
  8. 8. Les=20 annonces et la tenue des archives=20
  9. 9. La=20 variation du processus=20
    1. 9.1. La=20 proc=C3=A9dure de dispense=20
    2. 9.2. Les=20 exclusions
  10. 10. Les=20 droits de propri=C3=A9t=C3=A9 intellectuelle=20
    1. 10.1. La=20 politique g=C3=A9n=C3=A9rale=20
    2. 10.2. Les=20 obligations de confidentialit=C3=A9=20
    3. 10.3. Les=20 droits et les permissions=20
      1. 10.3.1. Toutes=20 les contributions=20
      2. 10.3.2. Les=20 documents du circuit des standards=20
      3. 10.3.3. La=20 d=C3=A9termination des termes raisonnables et non = discriminatoires
    4. 10.4. Les=20 mentions l=C3=A9gales
  11. 11. Remerciements=20
  12. 12. Observations=20 sur la s=C3=A9curit=C3=A9=20
  13. 13. R=C3=A9f=C3=A9rences=20
  14. 14. D=C3=A9finitions=20 des termes=20
  15. 15. Coordonn=C3=A9es=20 de l'auteur=20
  16. Annexe A : Glossaire=20 des abr=C3=A9viations

1. Introduction

Ce m=C3=A9moire documente le processus actuel utilis=C3=A9 par la = communaut=C3=A9 Internet=20 pour la standardisation des protocoles et proc=C3=A9dures. Le processus = de=20 standardisation Internet (Internet = Standards=20 process) est une activit=C3=A9 de l'Internet Society = organis=C3=A9e et administr=C3=A9e=20 au nom de la communaut=C3=A9 Internet par l'IAB (Internet Architecture Board) et l'IESG (Internet Engineering Steering Group).

1.1. Les standards Internet

Internet, une collaboration internationale faiblement organis=C3=A9e = de r=C3=A9seaux=20 interconnect=C3=A9s autonomes, permet une communication h=C3=B4te =C3=A0 = h=C3=B4te au travers d'une=20 adh=C3=A9sion volontaire aux protocoles et proc=C3=A9dures ouverts = d=C3=A9finis par les=20 standards Internet. Il y a aussi beaucoup de r=C3=A9seaux = interconnect=C3=A9s isol=C3=A9s qui=20 ne sont pas connect=C3=A9s au r=C3=A9seau Internet global mais qui = utilisent les standards=20 Internet.

Le processus de standardisation Internet d=C3=A9crit dans ce document = concerne=20 tous les protocoles, proc=C3=A9dures et conventions utilis=C3=A9s au = sein de et par=20 Internet, qu'ils fassent partie ou non de la suite de protocoles TCP/IP. = En=20 revanche, dans le cas de protocoles d=C3=A9velopp=C3=A9s ou = standardis=C3=A9s par des=20 organismes non Internet, le processus de standardisation Internet vaut=20 habituellement pour l'application du protocole (ou de la proc=C3=A9dure) = dans le=20 contexte d'Internet et non pour la sp=C3=A9cification du protocole en = question.

En g=C3=A9n=C3=A9ral, un standard Internet est une sp=C3=A9cification = stable et bien=20 comprise, est techniquement suffisant, a plusieurs mises en =C5=93uvre = ind=C3=A9pendantes=20 et interop=C3=A9rables avec une exp=C3=A9rience en exploitation = consid=C3=A9rable, jouit d'un=20 soutien important du public, et est reconnu utile dans une partie ou la = totalit=C3=A9=20 d'Internet.

1.2. Le processus de standardisation = Internet

En th=C3=A9orie, le processus de cr=C3=A9ation d'un standard Internet = est simple :=20 une sp=C3=A9cification endure une p=C3=A9riode de d=C3=A9veloppement et = une r=C3=A9p=C3=A9tition de=20 passages en revue par la communaut=C3=A9 Internet et de r=C3=A9visions = d'apr=C3=A8s les retours=20 d'exp=C3=A9riences, est adopt=C3=A9e comme standard par l'instance = appropri=C3=A9e (voir=20 ci-dessous) puis est publi=C3=A9e. Dans la pratique, le processus est = plus compliqu=C3=A9=20 en raison de 1) la difficult=C3=A9 =C3=A0 cr=C3=A9er des = sp=C3=A9cifications de haute qualit=C3=A9=20 technique, 2) la n=C3=A9cessit=C3=A9 de tenir compte des = int=C3=A9r=C3=AAts de toutes les=20 parties affect=C3=A9es, 3) l'importance d'obtenir un large = consensus de la=20 communaut=C3=A9 et 4) la difficult=C3=A9 d'=C3=A9valuer = l'utilit=C3=A9 d'une sp=C3=A9cification=20 particuli=C3=A8re pour la communaut=C3=A9 Internet.

Les objectifs du processus de standardisation Internet = sont :

  • l'excellence technique ;=20
  • une mise en =C5=93uvre et des essais pr=C3=A9alables ;=20
  • une documentation claire, concise et facilement = compr=C3=A9hensible ;=20
  • l'ouverture et l'impartialit=C3=A9 ;=20
  • la ponctualit=C3=A9.

Les proc=C3=A9dures d=C3=A9crites dans ce document sont = =C3=A9labor=C3=A9es dans le but d'=C3=AAtre=20 justes, ouvertes et objectives, de refl=C3=A9ter une pratique existante = (prouv=C3=A9e) et=20 d'=C3=AAtre flexibles.

  • Ces proc=C3=A9dures sont destin=C3=A9es =C3=A0 =C3=A9tablir une = base juste, ouverte et=20 objective pour le d=C3=A9veloppement, l'=C3=A9valuation et l'adoption = des standards=20 Internet. Elles laissent une grande place =C3=A0 la participation et = aux=20 commentaires de toutes les parties int=C3=A9ress=C3=A9es. =C3=80 = chaque stade du processus de=20 standardisation, la sp=C3=A9cification est discut=C3=A9e =C3=A0 = plusieurs reprises et ses=20 m=C3=A9rites d=C3=A9battus dans des r=C3=A9unions libres ou des listes = de diffusion=20 =C3=A9lectroniques publiques, et elle est mise =C3=A0 disposition pour = examen via des=20 annuaires en ligne dans le monde entier.=20
  • Ces proc=C3=A9dures visent explicitement la reconnaissance et = l'adoption de=20 pratiques g=C3=A9n=C3=A9ralement accept=C3=A9es. Une = sp=C3=A9cification candidate doit ainsi faire=20 l'objet d'une mise en =C5=93uvre, son bon fonctionnement et sa bonne=20 interop=C3=A9rabilit=C3=A9 doivent =C3=AAtre test=C3=A9s par plusieurs = tiers ind=C3=A9pendants, et elle=20 doit =C3=AAtre utilis=C3=A9e dans des environnements de plus en plus = exigeants, avant=20 d'=C3=AAtre adopt=C3=A9e comme standard Internet.=20
  • Ces proc=C3=A9dures offent une grande flexibilit=C3=A9 pour = s'adapter aux situations=20 tr=C3=A8s vari=C3=A9es apparaissant dans le processus de = standardisation. L'exp=C3=A9rience=20 montre que cette flexibilit=C3=A9 est capitale pour r=C3=A9aliser les = objectifs list=C3=A9s=20 pr=C3=A9c=C3=A9demment.

L'objectif de qualit=C3=A9 technique, la condition de mise en = =C5=93uvre et d'essais=20 pr=C3=A9alables et la n=C3=A9cessit=C3=A9 d'assurer les commentaires des = parties int=C3=A9ress=C3=A9es,=20 tout cela demande beaucoup de temps et d'effort. =C3=80 l'inverse, = l'essor actuel de=20 la technologie des r=C3=A9seaux impose le d=C3=A9veloppement =C3=A0 = temps des standards. Le=20 processus de standardisation Internet se veut un compromis entre ces = termes=20 contradictoires. On estime que le processus est aussi court et simple = que=20 possible sans sacrifier l'excellence technique, les essais exhaustifs = avant=20 adoption d'un standard, ou l'ouverture et l'impartialit=C3=A9.

Depuis le d=C3=A9but, Internet est, et entend rester, un syst=C3=A8me = en =C3=A9volution dans=20 la conception et la mise en =C5=93uvre duquel ses participants = =C3=A9laborent=20 r=C3=A9guli=C3=A8rement de nouvelles exigences et technologies. Les = utilisateurs=20 d'Internet et les fournisseurs d'=C3=A9quipements, de logiciels et de = services qui le=20 soutiennent devraient anticiper et accepter cette =C3=A9volution comme = une doctrine=20 majeure de la philosophie Internet.

Les proc=C3=A9dures d=C3=A9crites dans ce document sont le = r=C3=A9sultat de longues ann=C3=A9es=20 d'=C3=A9volution, pouss=C3=A9e =C3=A0 la fois par les besoins de la = communaut=C3=A9 Internet de plus=20 en plus nombreuse et h=C3=A9t=C3=A9roclite, et par = l'exp=C3=A9rience.

1.3. Organisation de ce document

La section 2=20 d=C3=A9crit les publications et archives du processus de standardisation = Internet. La=20 section 3=20 d=C3=A9crit les types de sp=C3=A9cifications de standard Internet. La section 4=20 d=C3=A9crit le circuit (track) = des=20 sp=C3=A9cifications de standards Internet. La section 5=20 d=C3=A9crit les documents RFC de pratiques exemplaires courantes (Best Current Practice). La section 6=20 d=C3=A9crit le processus et les r=C3=A8gles de standardisation Internet. = La section 7=20 d=C3=A9finit comment les sp=C3=A9cifications et pratiques = parrain=C3=A9es ext=C3=A9rieurement,=20 d=C3=A9velopp=C3=A9es et contr=C3=B4l=C3=A9es par d'autres instances de = normalisation ou autres,=20 sont prises en compte dans le processus de standardisation Internet. La = section 8=20 d=C3=A9crit les exigences des annonces et de tenue des archives. La section 9=20 d=C3=A9finit un processus de dispense (variance=20 process) autorisant des exceptions ponctuelles aux exigences dans = ce=20 document. La section 10=20 pr=C3=A9sente les r=C3=A8gles n=C3=A9cessaires pour prot=C3=A9ger les = droits de propri=C3=A9t=C3=A9=20 intellectuelle dans le contexte de la mise en place et de l'utilisation = des=20 standards Internet. La section 11=20 remercie quelques unes des personnes impliqu=C3=A9es dans la = cr=C3=A9ation de ce document.=20 La section 12=20 fait valoir que les questions de s=C3=A9curit=C3=A9 ne sont pas = trait=C3=A9es par ce document.=20 La section 13=20 contient une liste de r=C3=A9f=C3=A9rences num=C3=A9rot=C3=A9es. La section 14=20 contient les d=C3=A9finitions de quelques termes utilis=C3=A9s dans ce = document. La section 15=20 indique les coordonn=C3=A9es de l'auteur. L'annexe A=20 contient une liste d'abr=C3=A9viations courantes.

2. Les publications li=C3=A9es aux standards = Internet

2.1. Les appels =C3=A0 commentaires = (RFC)

Chaque version distincte d'une sp=C3=A9cification li=C3=A9e aux = standards Internet est=20 publi=C3=A9e dans le cadre de la s=C3=A9rie des documents d'appels = =C3=A0 commentaires, ou RFC=20 (Request for Comments). Cette = s=C3=A9rie=20 d'archives est le canal de publication officiel des documents de = standards=20 Internet et d'autres publications de l'IESG, de l'IAB et de la = communaut=C3=A9=20 Internet. Les RFC peuvent =C3=AAtre obtenus aupr=C3=A8s de plusieurs = h=C3=B4tes Internet par=20 FTP anonyme, gopher, le World Wide Web et d'autres syst=C3=A8mes de = r=C3=A9cup=C3=A9ration de=20 documents Internet.

La s=C3=A9rie RFC des documents =C3=A0 propos des r=C3=A9seaux a = commenc=C3=A9 en 1969 dans le=20 cadre du projet original de mise en r=C3=A9seau =C3=A9tendu de l'ARPA = (ARPANET),=20 cf. l'annexe A=20 pour un glossaire des abr=C3=A9viations. Les RFC couvrent un grand = nombre de sujets=20 en plus des standards Internet, allant des premi=C3=A8res discussions de = nouveaux=20 concepts de recherche jusqu'aux m=C3=A9moires de statut =C3=A0 propos = d'Internet. La=20 publication des RFC est sous la responsabilit=C3=A9 directe de = l'=C3=A9diteur des RFC=20 (RFC Editor), sous la direction = g=C3=A9n=C3=A9rale de=20 l'IAB.

Les r=C3=A8gles de formatage et de soumission des RFC sont = d=C3=A9finies dans un RFC [5].=20 Chaque RFC est disponible dans un format texte ASCII. Certains RFC sont=20 =C3=A9galement disponibles en d'autres formats. Les autres versions d'un = RFC peuvent=20 contenir des informations (telles que des sch=C3=A9mas et des dessins) = non pr=C3=A9sentes=20 dans la version ASCII, et peuvent =C3=AAtre format=C3=A9es = diff=C3=A9remment.

Une exigence plus stricte touche les sp=C3=A9cifications = du circuit des=20 standards : la version en texte ASCII est la r=C3=A9f=C3=A9rence = d=C3=A9finitive et doit=20 donc =C3=AAtre une sp=C3=A9cification compl=C3=A8te et exacte du = standard, incluant tous les=20 sch=C3=A9mas et illustrations n=C3=A9cessaires.

Le statut des sp=C3=A9cifications de protocoles et services Internet = fait l'objet=20 d'un compte-rendu p=C3=A9riodique dans un RFC intitul=C3=A9 Internet Official Protocol Standards [1].=20 Ce RFC donne le niveau de maturit=C3=A9 et d'autres renseignements = utiles pour chaque=20 sp=C3=A9cification de protocole ou de service Internet (cf. la section 3).

Certains RFC documentent les standards Internet. Ces RFC constituent = la=20 sous-s=C3=A9rie 'STD' de la s=C3=A9rie des RFC [4].=20 Lorsqu'une sp=C3=A9cification est adopt=C3=A9e en tant que standard = Internet, elle re=C3=A7oit=20 l'=C3=A9tiquette suppl=C3=A9mentaire "STDxxx", mais conserve son = num=C3=A9ro de RFC et sa place=20 dans la s=C3=A9rie des RFC (cf. la section 4.1.3).

Certains RFC standardisent les r=C3=A9sultats des = d=C3=A9lib=C3=A9rations de communaut=C3=A9s =C3=A0=20 propos de d=C3=A9clarations de principe ou =C3=A0 propos de la meilleure = fa=C3=A7on d'effectuer=20 certaines op=C3=A9rations ou une fonction du processus IETF. Un tel RFC = forme une=20 sp=C3=A9cification qui est adopt=C3=A9e comme document de pratique = exemplaire BCP, il=20 re=C3=A7oit une =C3=A9tiquette suppl=C3=A9mentaire de la forme "BCPxxx", = mais conserve son=20 num=C3=A9ro de RFC et sa place dans la s=C3=A9rie des RFC (cf. la = section 5).

Toutes les sp=C3=A9cifications de protocoles ou de services pour = Internet ne=20 deviennent pas des standards Internet ou des BCP. Ces = sp=C3=A9cifications hors du=20 circuit des standards ne sont pas soumises aux r=C3=A8gles de = standardisation=20 Internet. Les sp=C3=A9cifications hors du circuit des standards sont = directement=20 publiables en tant que RFC =C2=AB exp=C3=A9rimentaux =C2=BB = (Experimental) ou = =C2=AB informationnels =C2=BB (Informational), =C3=A0 la = discr=C3=A9tion de l'=C3=A9diteur des=20 RFC en concertation avec l'IESG (cf. la section 4.2).

Il importe de se rappeler que les RFC ne sont pas tous = des=20 documents du circuit des standards, et que les documents du circuit des=20 standards n'atteindront pas tous le niveau de standard Internet. De la = m=C3=AAme=20 fa=C3=A7on, les RFC d=C3=A9crivant des pratiques courantes n'ont pas = tous =C3=A9t=C3=A9 examin=C3=A9s et=20 approuv=C3=A9s pour devenir des BCP. Cf. le RFC 1796 [6]=20 pour des pr=C3=A9cisions.

2.2. Les projets Internet

Au cours du d=C3=A9veloppement d'une sp=C3=A9cification, des = =C3=A9bauches du document sont=20 mises =C3=A0 disposition et plac=C3=A9es pour revue et commentaires = informels dans le=20 r=C3=A9pertoire des =C2=AB projets Internet =C2=BB (Internet-Drafts) de l'IETF, lequel est = r=C3=A9pliqu=C3=A9 sur=20 plusieurs h=C3=B4tes Internet. Cela rend accessible un document de = travail en=20 =C3=A9volution =C3=A0 un large public, en facilitant le processus de = validation (review) et de r=C3=A9vision.

Un projet Internet publi=C3=A9 comme RFC, ou qui est rest=C3=A9 = inchang=C3=A9 dans le=20 r=C3=A9pertoire des projets Internet pendant plus de 6 mois sans = =C3=AAtre recommand=C3=A9=20 =C3=A0 la publication comme RFC par l'IESG, est simplement retir=C3=A9 = du r=C3=A9pertoire des=20 projets Internet. Un projet Internet peut =C3=AAtre remplac=C3=A9 =C3=A0 = tout moment par une=20 version plus r=C3=A9cente de la m=C3=AAme sp=C3=A9cification, en = renouvelant le d=C3=A9lai de=20 6 mois.

Un projet Internet N'EST PAS un moyen de = =C2=AB publier =C2=BB une sp=C3=A9cification : les = sp=C3=A9cifications sont publi=C3=A9es=20 au travers du m=C3=A9canisme des RFC d=C3=A9crit dans la section = pr=C3=A9c=C3=A9dente. Les projets=20 Internet n'ont pas de statut formel et sont susceptibles de changer ou = de=20 dispara=C3=AEtre =C3=A0 tout moment.

Un article, un rapport ou un appel =C3=A0 proposition ne = devraient en=20 aucune circonstance r=C3=A9f=C3=A9rencer un projet Internet ni un = vendeur revendiquer une=20 conformit=C3=A9 avec un projet Internet.

Remarque : Il est admis = de r=C3=A9f=C3=A9rencer=20 une sp=C3=A9cification du circuit des standards sur le point d'=C3=AAtre = publi=C3=A9e comme RFC=20 en utilisant la formule consacr=C3=A9e Work in=20 Progress (N.d.T. travaux en cours), sans = r=C3=A9f=C3=A9rencer ainsi de projet Internet. On peut aussi le faire au = sein m=C3=AAme d'un=20 document du circuit des standards, =C3=A0 condition que celui-ci = constitue un=20 document complet et intelligible, qu'il fasse r=C3=A9f=C3=A9rence ou non = aux travaux en=20 cours ailleurs.

3. Les sp=C3=A9cifications de standards = Internet

Les sp=C3=A9cifications soumises au processus de standardisation = Internet tombent=20 dans l'une des deux cat=C3=A9gories suivantes : la = sp=C3=A9cification technique, ou=20 TS (Technical Specification), = et la=20 d=C3=A9claration d'applicabilit=C3=A9, ou AS (Applicability=20 Statement).

3.1. Sp=C3=A9cification technique = (TS)

Une sp=C3=A9cification technique est la description d'un protocole, = d'un service,=20 d'une proc=C3=A9dure, d'une convention ou d'un format. Elle peut = d=C3=A9crire la totalit=C3=A9=20 des aspects pertinents de son sujet ou laisser un ou plusieurs = param=C3=A8tres ou=20 options non d=C3=A9finis. Une sp=C3=A9cification technique peut = =C3=AAtre enti=C3=A8rement autonome=20 ou elle peut incorporer la substance d'autres sp=C3=A9cifications par = r=C3=A9f=C3=A9rence =C3=A0=20 d'autres documents (qui sont ou non des standards Internet).

Une sp=C3=A9cification technique devra comprendre une = d=C3=A9claration de sa port=C3=A9e=20 (scope) et l'intention = g=C3=A9n=C3=A9rale de son=20 utilisation (champs d'application). Ainsi, une sp=C3=A9cification = technique=20 sp=C3=A9cifique par nature =C3=A0 un contexte particulier contiendra une = d=C3=A9claration dans=20 ce sens. Par contre, une sp=C3=A9cification technique ne d=C3=A9finit = pas les conditions=20 de son utilisation au sein d'Internet : ces conditions, qui = d=C3=A9pendent du=20 contexte particulier dans lequel la sp=C3=A9cification technique est = incorpor=C3=A9e par=20 des configurations de syst=C3=A8mes diff=C3=A9rentes, sont d=C3=A9finies = par une d=C3=A9claration=20 d'applicabilit=C3=A9.

3.2. D=C3=A9claration d'applicabilit=C3=A9 = (AS)

Une d=C3=A9claration d'applicabilit=C3=A9 d=C3=A9finit comment et = dans quelles circonstances=20 une ou plusieurs sp=C3=A9cifications techniques sont appliqu=C3=A9es = pour soutenir une=20 capacit=C3=A9 Internet particuli=C3=A8re. Une d=C3=A9claration = d'applicabilit=C3=A9 peut d=C3=A9finir des=20 utilisations pour des sp=C3=A9cifications techniques qui ne sont pas des = standards=20 Internet, comme indiqu=C3=A9 dans la section 7.

Une d=C3=A9claration d'applicabilit=C3=A9 identifie les = sp=C3=A9cifications techniques=20 pertinentes et la fa=C3=A7on particuli=C3=A8re de les combiner ; = elle peut aussi=20 d=C3=A9finir les valeurs particuli=C3=A8res ou intervalles de = param=C3=A8tres de sp=C3=A9cifications=20 techniques, ou les sous-fonctions d'une sp=C3=A9cification technique de = protocole =C3=A0=20 mettre en =C5=93uvre. Une d=C3=A9claration d'applicabilit=C3=A9 = d=C3=A9finit =C3=A9galement les=20 circonstances dans lesquelles l'utilisation d'une sp=C3=A9cification = technique est=20 obligatoire, recommand=C3=A9e ou =C3=A9lective (cf. la section 3.3).

Une d=C3=A9claration d'applicabilit=C3=A9 peut d=C3=A9crire les = m=C3=A9thodes particuli=C3=A8res=20 d'utilisation d'une sp=C3=A9cification technique dans un = =C2=AB domaine=20 d'applicabilit=C3=A9 =C2=BB restreint tel que des routeurs = Internet, des serveurs=20 terminaux, des syst=C3=A8mes Internet en interface de r=C3=A9seaux = Ethernet ou des=20 serveurs de bases de donn=C3=A9es utilisant des datagrammes.

Le type de d=C3=A9claration d'applicabilit=C3=A9 le plus large est = repr=C3=A9sent=C3=A9 par une=20 sp=C3=A9cification de conformit=C3=A9 exhaustive, appel=C3=A9e = couramment un =C2=AB document=20 d'exigences =C2=BB (requirements = document),=20 pour une classe particuli=C3=A8re de syst=C3=A8mes Internet tels que des = routeurs Internet=20 ou des h=C3=B4tes Internet.

Une d=C3=A9claration d'applicabilit=C3=A9 dans le circuit des = standards ne peut pas=20 avoir un niveau de maturit=C3=A9 sup=C3=A9rieur =C3=A0 celui d'une = sp=C3=A9cification technique du=20 circuit des standards dont elle d=C3=A9pend (cf. la section 4.1).=20 Par exemple, une sp=C3=A9cification technique au niveau de standard = pr=C3=A9liminaire=20 (Draft Standard) peut =C3=AAtre = r=C3=A9f=C3=A9renc=C3=A9e par=20 une d=C3=A9claration d'applicabilit=C3=A9 =C3=A0 un niveau de standard = propos=C3=A9 (Proposed Standard) ou de standard = pr=C3=A9liminaire, mais pas=20 par une d=C3=A9claration d'applicabilit=C3=A9 au niveau de standard = (Standard).

3.3. Niveaux d'exigence

Une d=C3=A9claration d'applicabilit=C3=A9 appliquera l'un des = =C2=AB niveaux=20 d'exigence =C2=BB (requirement = levels)=20 suivants =C3=A0 chaque sp=C3=A9cification technique =C3=A0 laquelle elle = se rapporte :

  • (a) Obligatoire (Required) : une mise en =C5=93uvre de la = sp=C3=A9cification=20 technique r=C3=A9f=C3=A9renc=C3=A9e, comme d=C3=A9fini par la = d=C3=A9claration d'applicabilit=C3=A9, est=20 tenue d'atteindre une conformit=C3=A9 minimale. Par exemple, tous les = syst=C3=A8mes=20 Internet utilisant la suite de protocoles TCP/IP doivent mettre en = =C5=93uvre les=20 protocoles IP et ICMP.=20
  • (b) Recommand=C3=A9 (Recommended) : une mise en =C5=93uvre de = la=20 sp=C3=A9cification technique r=C3=A9f=C3=A9renc=C3=A9e n'est pas tenue = =C3=A0 une conformit=C3=A9 minimale,=20 mais l'exp=C3=A9rience ou une sagesse technique g=C3=A9n=C3=A9ralement = accept=C3=A9e sugg=C3=A8rent son=20 utilisation dans le domaine d'application de la d=C3=A9claration = d'applicabilit=C3=A9.=20 Les vendeurs sont vivement encourag=C3=A9s =C3=A0 inclure dans leurs = produits les=20 fonctions, les caract=C3=A9ristiques et les protocoles des = sp=C3=A9cifications=20 techniques recommand=C3=A9es, et ils ne devraient les omettre que si = cela est=20 justifi=C3=A9 par des circonstances particuli=C3=A8res. Par exemple, = tous les syst=C3=A8mes=20 utilisant un acc=C3=A8s distant devraient mettre en =C5=93uvre le = protocole TELNET.=20
  • (c) =C3=89lectif (Elective) : une=20 mise en =C5=93uvre de la sp=C3=A9cification technique = r=C3=A9f=C3=A9renc=C3=A9e est optionnelle dans le=20 domaine d'application de la d=C3=A9claration d'applicabilit=C3=A9, = c'est-=C3=A0-dire que la=20 d=C3=A9claration d'applicabilit=C3=A9 n'=C3=A9tablit aucune = n=C3=A9cessit=C3=A9 explicite d'appliquer=20 la sp=C3=A9cification technique. Toutefois, un vendeur particulier = peut d=C3=A9cider de=20 la mettre en =C5=93uvre, ou un utilisateur particulier d=C3=A9cider = qu'elle est=20 n=C3=A9cessaire dans un environnement sp=C3=A9cifique. Par exemple, la = base de donn=C3=A9es=20 MIB DECNET pourrait se r=C3=A9v=C3=A9ler pr=C3=A9cieuse dans un = environnement o=C3=B9 le protocole=20 DECNET est utilis=C3=A9.

Comme indiqu=C3=A9 dans la section 4.1,=20 il y a des sp=C3=A9cifications techniques qui sont hors du circuit des = standards ou=20 qui en ont =C3=A9t=C3=A9 retir=C3=A9es, et qui ne sont donc pas = obligatoires ni recommand=C3=A9es ni=20 =C3=A9lectives. Deux autres appellations de niveau d'exigence sont = disponibles pour=20 ces sp=C3=A9cifications techniques :

  • (d) Utilisation limit=C3=A9e (Limited=20 Use) : l'utilisation de la sp=C3=A9cification technique = est consid=C3=A9r=C3=A9e=20 comme appropri=C3=A9e uniquement dans des circonstances limit=C3=A9es = ou uniques. Par=20 exemple, l'utilisation d'un protocole avec l'appellation Experimental devrait g=C3=A9n=C3=A9ralement se = limiter =C3=A0 ceux=20 impliqu=C3=A9s activement dans l'exp=C3=A9rience.=20
  • (e) Non recommand=C3=A9 (Not=20 Recommended) : une sp=C3=A9cification technique = consid=C3=A9r=C3=A9e comme=20 inappropri=C3=A9e pour une utilisation g=C3=A9n=C3=A9rale est = =C3=A9tiquet=C3=A9e =C2=AB Non=20 recommand=C3=A9e =C2=BB. Cela peut =C3=AAtre =C3=A0 cause de sa = fonctionnalit=C3=A9 limit=C3=A9e, de sa=20 nature sp=C3=A9cialis=C3=A9e ou de son statut historique.

Bien que les sp=C3=A9cifications techniques (TS) et les = d=C3=A9clarations=20 d'applicabilit=C3=A9 (AS) soient conceptuellement distinctes, en = pratique, un=20 document du circuit des standards peut combiner une d=C3=A9claration = d'applicabilit=C3=A9=20 et une ou plusieurs sp=C3=A9cifications techniques apparent=C3=A9es. = Ainsi, les=20 sp=C3=A9cifications techniques d=C3=A9velopp=C3=A9es sp=C3=A9cialement = et exclusivement pour un=20 domaine d'application particulier, par exemple pour des serveurs de = courrier=20 =C3=A9lectronique, contiennent souvent dans une seule sp=C3=A9cification = toutes les=20 informations pertinentes de la d=C3=A9claration d'applicabilit=C3=A9 et = des sp=C3=A9cifications=20 techniques. Pour ces cas, il ne serait d'aucune utilit=C3=A9 de = r=C3=A9partir d=C3=A9lib=C3=A9r=C3=A9ment=20 les informations entre plusieurs documents juste pour conserver la = distinction=20 formelle AS/TS. En revanche, une sp=C3=A9cification technique qui = s'appliquera=20 vraisemblablement =C3=A0 plusieurs domaines d'application devrait = =C3=AAtre d=C3=A9velopp=C3=A9e de=20 fa=C3=A7on modulaire, pour faciliter son incorporation =C3=A0 de = multiples d=C3=A9clarations=20 d'applicabilit=C3=A9.

Le RFC Official Protocol = Standard (STD1)=20 attribue un niveau d'exigence g=C3=A9n=C3=A9ral =C3=A0 chaque = sp=C3=A9cification technique, en=20 utilisant la nomenclature d=C3=A9finie dans cette section. Ce RFC est = mis =C3=A0 jour=20 p=C3=A9riodiquement. Dans beaucoup de cas, on trouvera dans les = d=C3=A9clarations=20 d'applicabilit=C3=A9 appropri=C3=A9es des descriptions plus = d=C3=A9taill=C3=A9es des niveaux=20 d'exigence concernant des protocoles particuliers et leurs = caract=C3=A9ristiques=20 individuelles.

4. Le circuit des standards Internet

Les sp=C3=A9cifications destin=C3=A9es =C3=A0 devenir des standards = Internet =C3=A9voluent =C3=A0=20 travers un ensemble de niveaux de maturit=C3=A9 connu sous le nom de = =C2=AB circuit=20 des standards =C2=BB (standards = track). Ces=20 niveaux de maturit=C3=A9, =C3=A0 savoir standard propos=C3=A9 (Proposed Standard), standard pr=C3=A9liminaire = (Draft Standard) et standard (Standard), sont d=C3=A9finis et expliqu=C3=A9s = dans la section 4.1.=20 La fa=C3=A7on dont les sp=C3=A9cifications se meuvent dans le circuit = des standards est=20 d=C3=A9crite dans la section 6.

M=C3=AAme apr=C3=A8s qu'une sp=C3=A9cification a =C3=A9t=C3=A9 = adopt=C3=A9e comme standard Internet, il y a=20 souvent d'autres =C3=A9volutions en fonction de l'exp=C3=A9rience et de = la reconnaissance=20 de nouvelles exigences. La nomenclature et les proc=C3=A9dures de = standardisation=20 Internet pourvoient au remplacement des vieux standards retir=C3=A9s.Un = ensemble de=20 niveaux de maturit=C3=A9 est d=C3=A9fini dans la section 4.2=20 pour couvrir =C3=A0 la fois ces cas et ceux des autres = sp=C3=A9cifications non cens=C3=A9es=20 faire partie du circuit des standards.

4.1. Les niveaux de maturit=C3=A9 du = circuit des=20 standards

Les sp=C3=A9cifications Internet passent par des stades de = d=C3=A9veloppement, d'essai=20 et d'acceptation. Dans le processus de standardisation Internet, ces = stades=20 s'intitulent formellement des =C2=AB niveaux de = maturit=C3=A9 =C2=BB (maturity levels).

Cette section d=C3=A9crit les niveaux de maturit=C3=A9 et les = caract=C3=A9ristiques=20 attendues des sp=C3=A9cifications =C3=A0 chaque niveau.

4.1.1. Proposed=20 Standard

Le niveau de maturit=C3=A9 d'entr=C3=A9e du circuit des standards est = celui de standard=20 propos=C3=A9 (Proposed = Standard). Une action=20 sp=C3=A9cifique de l'IESG est n=C3=A9cessaire afin de placer une = sp=C3=A9cification sur le=20 circuit des standards au niveau Proposed=20 Standard.

Une sp=C3=A9cification au stade Proposed=20 Standard est g=C3=A9n=C3=A9ralement stable, a tranch=C3=A9 entre = les diff=C3=A9rents choix de=20 conception envisag=C3=A9s, est suppos=C3=A9e bien comprise, a = =C3=A9t=C3=A9 examin=C3=A9e en profondeur=20 par la communaut=C3=A9, et semble jouir d'un int=C3=A9r=C3=AAt suffisant = de la communaut=C3=A9 pour=20 =C3=AAtre consid=C3=A9r=C3=A9e comme valable. Toutefois, d'autres = =C3=A9tudes pourraient aboutir au=20 changement ou m=C3=AAme =C3=A0 la r=C3=A9tractation de la = sp=C3=A9cification avant qu'elle ne=20 progresse.

Habituellement, ni une mise en =C5=93uvre ni une exp=C3=A9rience = d'exploitation ne sont=20 n=C3=A9cessaires pour =C3=A9lever une sp=C3=A9cification au rang de = standard propos=C3=A9. Quoi=20 qu'il en soit, une telle exp=C3=A9rience est tr=C3=A8s souhaitable et = constituera=20 g=C3=A9n=C3=A9ralement un argument fort en faveur de la d=C3=A9signation = d'un standard=20 propos=C3=A9.

L'IESG peut imposer une mise en =C5=93uvre ou une exp=C3=A9rience = d'exploitation avant=20 d'accorder le statut de standard propos=C3=A9 =C3=A0 une = sp=C3=A9cification qui affecte=20 structurellement le noyau des protocoles Internet ou qui d=C3=A9finit un = comportement=20 susceptible d'avoir un impact important sur le fonctionnement = d'Internet.

Un standard propos=C3=A9 ne devrait pas avoir de lacunes techniques = connues par=20 rapport aux exigences plac=C3=A9es sur lui. Toutefois, l'IESG peut = renoncer =C3=A0 cette=20 condition pour permettre =C3=A0 une sp=C3=A9cification d'avancer au = stade de standard=20 propos=C3=A9 lorsque celle-ci est consid=C3=A9r=C3=A9e comme utile et = n=C3=A9cessaire (et=20 opportune), m=C3=AAme avec des lacunes techniques connues.

Les d=C3=A9veloppeurs devraient traiter les standards propos=C3=A9s = comme des=20 sp=C3=A9cifications immatures. Il est souhaitable de les mettre en = =C5=93uvre afin=20 d'acqu=C3=A9rir de l'exp=C3=A9rience et de valider, tester et clarifier = la sp=C3=A9cification.=20 Par contre, puisque le contenu des standards propos=C3=A9s peut changer = si des=20 probl=C3=A8mes sont d=C3=A9couverts ou de meilleures solutions = identifi=C3=A9es, il n'est pas=20 recommand=C3=A9 de d=C3=A9ployer des mises en =C5=93uvre fond=C3=A9es = sur de tels standards dans un=20 environnement sensible aux perturbations.

4.1.2. Draft=20 Standard

Une sp=C3=A9cification d'apr=C3=A8s laquelle au moins deux mises en = =C5=93uvre ind=C3=A9pendantes=20 et interop=C3=A9rables ont =C3=A9t=C3=A9 d=C3=A9velopp=C3=A9es, issues = de bases de code diff=C3=A9rentes, et=20 pour laquelle une exp=C3=A9rience d'exploitation r=C3=A9ussie suffisante = a =C3=A9t=C3=A9 obtenue,=20 peut =C3=AAtre =C3=A9lev=C3=A9e au niveau de standard pr=C3=A9liminaire = (Draft Standard). Pour les besoins de cette = section, le=20 terme =C2=AB interop=C3=A9rable =C2=BB d=C3=A9signe des = composants fonctionnellement=20 =C3=A9quivalents ou interchangeables du syst=C3=A8me ou du processus qui = les utilise. Si=20 une technologie brevet=C3=A9e ou contr=C3=B4l=C3=A9e autrement est = n=C3=A9cessaire pour la mise en=20 =C5=93uvre, les mises en =C5=93uvre s=C3=A9par=C3=A9es doivent aussi = provenir d'un exercice distinct=20 du processus de licence. L'=C3=A9l=C3=A9vation au stade de standard = pr=C3=A9liminaire constitue=20 une avanc=C3=A9e majeure du statut, marquant une grande confiance en la = maturit=C3=A9 et=20 l'utilit=C3=A9 de la sp=C3=A9cification.

L'exigence d'au moins deux mises en =C5=93uvre ind=C3=A9pendantes et = interop=C3=A9rables=20 s'applique =C3=A0 toutes les options et caract=C3=A9ristiques de la = sp=C3=A9cification. En cas=20 de non-d=C3=A9monstration de l'une ou de plusieurs options ou = caract=C3=A9ristiques dans=20 au moins deux mises en =C5=93uvre interop=C3=A9rables, la = sp=C3=A9cification ne pourra avancer=20 au niveau de standard pr=C3=A9liminaire que si ces options ou = caract=C3=A9ristiques sont=20 supprim=C3=A9es.

Le pr=C3=A9sident du groupe de travail est charg=C3=A9 de la = documentation des mises en=20 =C5=93uvre sp=C3=A9cifiques qui qualifient la sp=C3=A9cification au = statut de standard=20 pr=C3=A9liminaire ou de standard Internet, et de la documentation des = essais=20 d'interop=C3=A9rabilit=C3=A9 de ces mises en =C5=93uvre. La = documentation doit inclure les=20 donn=C3=A9es concernant la gestion de chacune des options et = caract=C3=A9ristiques=20 individuelles. Cette documentation devrait =C3=AAtre transmise au = responsable de=20 domaine (Area Director) selon = la demande=20 d'action de protocole (protocol action = request), cf. la section 6.

Un standard pr=C3=A9liminaire doit =C3=AAtre bien compris et connu = comme suffisamment=20 stable, =C3=A0 la fois dans sa s=C3=A9mantique et comme base de = d=C3=A9veloppement des mises en=20 =C5=93uvre. Un standard pr=C3=A9liminaire peut encore n=C3=A9cessiter = une exp=C3=A9rience de terrain=20 suppl=C3=A9mentaire ou plus =C3=A9tendue, puisqu'il est possible que des = mises en =C5=93uvre=20 fond=C3=A9es sur des sp=C3=A9cifications au stade standard = pr=C3=A9liminaire pr=C3=A9sentent des=20 comportements impr=C3=A9vus en utilisation intensive dans des = environnements de=20 production.

Un standard pr=C3=A9liminaire est normalement consid=C3=A9r=C3=A9 = comme une sp=C3=A9cification=20 finale, et des changements n'interviendront probablement que pour = r=C3=A9soudre les=20 probl=C3=A8mes sp=C3=A9cifiques rencontr=C3=A9s. Dans la plupart des = cas, les vendeurs peuvent=20 raisonnablement d=C3=A9ployer les mises en =C5=93uvre de standards = pr=C3=A9liminaires dans un=20 environnement sensible aux perturbations.

4.1.3. Internet=20 Standard

Une sp=C3=A9cification pour laquelle une mise en =C5=93uvre = significative et une=20 exp=C3=A9rience d'exploitation r=C3=A9ussie ont =C3=A9t=C3=A9 obtenues = peut =C3=AAtre =C3=A9lev=C3=A9e au niveau de=20 standard Internet (Internet = Standard). Un=20 standard Internet (appel=C3=A9 simplement un standard) est = caract=C3=A9ris=C3=A9 par un haut=20 degr=C3=A9 de maturit=C3=A9 technique et par l'opinion = g=C3=A9n=C3=A9rale que le protocole ou le=20 service d=C3=A9finis apportent un avantage important =C3=A0 la = communaut=C3=A9 Internet.

Une sp=C3=A9cification obtenant le statut de standard re=C3=A7oit un = num=C3=A9ro dans la=20 s=C3=A9rie des STD tout en conservant son num=C3=A9ro de RFC.

4.2. Les niveaux de maturit=C3=A9 hors du = circuit des=20 standards

Les sp=C3=A9cifications ne sont pas toutes dans le circuit des = standards. Une=20 sp=C3=A9cification n'est pas forc=C3=A9ment destin=C3=A9e =C3=A0 devenir = un standard Internet, ou=20 elle peut rechercher une =C3=A9ventuelle standardisation mais n'est pas = pr=C3=AAte pour=20 entrer dans le circuit des standards. Une sp=C3=A9cification peut avoir = =C3=A9t=C3=A9 remplac=C3=A9e=20 par un standard Internet plus r=C3=A9cent, ou sinon =C3=AAtre = tomb=C3=A9e en d=C3=A9su=C3=A9tude ou en=20 d=C3=A9faveur.

Les sp=C3=A9cifications qui ne sont pas dans le circuit des standards = sont=20 =C3=A9tiquet=C3=A9es d'un des trois niveaux de maturit=C3=A9 = =C2=AB hors circuit =C2=BB :=20 =C2=AB Experimental =C2=BB, = =C2=AB Informational =C2=BB ou =C2=AB Historic =C2=BB. Les documents portant ces = =C3=A9tiquettes ne=20 sont en aucune fa=C3=A7on des standards.

4.2.1. Experimental

L'appellation Experimental = d=C3=A9signe=20 typiquement une sp=C3=A9cification qui fait partie d'un effort de = recherche ou de=20 d=C3=A9veloppement. Une telle sp=C3=A9cification est publi=C3=A9e pour = l'information g=C3=A9n=C3=A9rale=20 de la communaut=C3=A9 technique Internet et comme document d'archives du = travail,=20 susceptible seulement de consid=C3=A9rations =C3=A9ditoriales et de = v=C3=A9rification de=20 l'articulation ad=C3=A9quate avec le processus de standardisation (voir = plus loin).=20 Une sp=C3=A9cification exp=C3=A9rimentale peut =C3=AAtre le produit d'un = effort organis=C3=A9 de=20 recherche Internet (par exemple, un groupe de recherche de l'IRTF), d'un = groupe=20 de travail IETF ou d'une contribution individuelle.

4.2.2. Informational

Une sp=C3=A9cification informationnelle est publi=C3=A9e pour = l'information g=C3=A9n=C3=A9rale de=20 la communaut=C3=A9 Internet et elle ne repr=C3=A9sente pas un consensus = ou une=20 recommandation de la communaut=C3=A9 Internet. L'appellation Informational pourvoit =C3=A0 la publication au = bon moment d'un=20 tr=C3=A8s large =C3=A9ventail de documents informationnels responsables = issus de=20 nombreuses sources, susceptible seulement de consid=C3=A9rations = =C3=A9ditoriales et de=20 v=C3=A9rification de l'articulation ad=C3=A9quate avec le processus de = standardisation=20 (cf. la section 4.2.3).

Les sp=C3=A9cifications pr=C3=A9par=C3=A9es hors de la = communaut=C3=A9 Internet et non=20 incorpor=C3=A9es au processus de standardisation Internet selon une des = dispositions=20 de la section 10=20 peuvent =C3=AAtre publi=C3=A9es comme RFC informationnels, avec la = permission de l'auteur=20 et le concours de l'=C3=A9diteur des RFC (RFC=20 Editor).

4.2.3. Les proc=C3=A9dures des RFC = exp=C3=A9rimentaux et=20 informationnels

=C3=80 moins d'=C3=AAtre le r=C3=A9sultat d'une action d'un groupe de = travail IETF, les=20 documents =C3=A0 publier avec un statut Experimental ou Informational devraient =C3=AAtre soumis = directement =C3=A0 l'=C3=A9diteur=20 des RFC. L'=C3=A9diteur des RFC publiera en tant que projets Internet = (Internet-Drafts) ces documents qui n'auraient = pas d=C3=A9j=C3=A0 =C3=A9t=C3=A9=20 publi=C3=A9s comme tels. Pour diff=C3=A9rencier ces projets Internet, = ils seront =C3=A9tiquet=C3=A9s=20 ou regroup=C3=A9s dans le r=C3=A9pertoire Internet-Drafts o=C3=B9 ils seront ais=C3=A9ment = reconnaissables.=20 L'=C3=A9diteur des RFC recueillera les commentaires pendant = 2 semaines suivant=20 la publication, avant de poursuivre. L'=C3=A9diteur des RFC est = cens=C3=A9 agir avec=20 discernement concernant la recevabilit=C3=A9 =C3=A9ditoriale d'un = document =C3=A0 publier avec=20 un statut Experimental ou Informational, et il peut refuser de publier un = document=20 qui, de l'avis expert de l'=C3=A9diteur, est =C3=A9tranger =C3=A0 = l'activit=C3=A9 Internet ou qui=20 est inf=C3=A9rieur aux standards techniques ou =C3=A9ditoriaux pour un = RFC.

Afin d'emp=C3=AAcher que l'on abuse des appellations hors circuit des = standards=20 Experimental et Informational dans le but de contourner le = processus de=20 standardisation Internet, l'IESG et l'=C3=A9diteur des RFC ont convenu = que l'=C3=A9diteur=20 des RFC signalera =C3=A0 l'IESG tout document soumis =C3=A0 publication = avec un statut=20 Experimental ou Informational qui, de l'avis de l'=C3=A9diteur, = serait en=20 rapport avec un travail en cours ou pr=C3=A9vu d'=C3=AAtre = r=C3=A9alis=C3=A9 dans la communaut=C3=A9=20 IETF. L'IESG examinera le document signal=C3=A9 dans un d=C3=A9lai = raisonnable et=20 recommandera soit de le publier comme soumis au d=C3=A9part, soit de le = renvoyer =C3=A0=20 l'IETF comme une contribution au processus de standardisation = Internet.

Si (a) l'IESG recommande de porter le document =C3=A0 l'IETF et = de le=20 poursuivre dans le contexte de l'IETF, et que l'auteur refuse de le = faire, ou=20 (b) si l'IESG consid=C3=A8re que le propos du document entre en = conflit avec, ou=20 est r=C3=A9ellement inamical envers, un effort IETF =C3=A9tabli, le = document peut toujours=20 =C3=AAtre publi=C3=A9 comme RFC exp=C3=A9rimental ou informationnel. = Auquel cas, cependant,=20 l'IESG peut ins=C3=A9rer un =C2=AB avis de = non-responsabilit=C3=A9 =C2=BB appropri=C3=A9 dans=20 le RFC, soit dans la section =C2=AB Statut de ce = m=C3=A9moire =C2=BB, soit=20 imm=C3=A9diatement apr=C3=A8s, afin d'=C3=A9clairer les circonstances de = sa publication aupr=C3=A8s=20 des lecteurs.

Les documents propos=C3=A9s comme RFC exp=C3=A9rimentaux ou = informationnels par les=20 groupes de travail IETF sont examin=C3=A9s par l'IESG. La validation est = lanc=C3=A9e en=20 fonction du processus d=C3=A9crit dans la section 6.1.1.

4.2.4. Historic

Une sp=C3=A9cification qui a =C3=A9t=C3=A9 remplac=C3=A9e par une = sp=C3=A9cification plus r=C3=A9cente, ou=20 qui est pour toute autre raison consid=C3=A9r=C3=A9e comme = obsol=C3=A8te, est affect=C3=A9e du=20 niveau Historic. (Des puristes = ont sugg=C3=A9r=C3=A9=20 =C2=AB Historical =C2=BB ; quoi qu'il en soit, de nos = jours, l'utilisation=20 d'Historic est historique.)

Remarque : Normalement, = les=20 sp=C3=A9cifications du circuit des standards ne doivent pas = d=C3=A9pendre d'autres=20 sp=C3=A9cifications du circuit des standards =C3=A0 un niveau de = maturit=C3=A9 inf=C3=A9rieur, ou=20 d'autres sp=C3=A9cifications hors du circuit des standards sauf = r=C3=A9f=C3=A9renc=C3=A9es aupr=C3=A8s=20 d'autres instances de normalisation (standards=20 bodies), cf. la section 7.

5. Les RFC de pratiques exemplaires = courantes=20 (BCP)

La sous-s=C3=A9rie des BCP (Best = Current=20 Practice) de la s=C3=A9rie des RFC est con=C3=A7ue comme un moyen = de standardiser=20 les pratiques et les r=C3=A9sultats de d=C3=A9lib=C3=A9rations de la = communaut=C3=A9. Un document=20 BCP est soumis au m=C3=AAme ensemble de proc=C3=A9dures de base que les = documents du=20 circuit des standards, et c'est donc un vecteur par lequel la = communaut=C3=A9 IETF=20 peut d=C3=A9finir et ratifier les meilleures r=C3=A9flexions courantes = sur une d=C3=A9claration=20 de principe ou sur ce qui est estim=C3=A9 la meilleure fa=C3=A7on = d'effectuer certaines=20 op=C3=A9rations ou la meilleure fa=C3=A7on de r=C3=A9aliser une fonction = du processus de=20 l'IETF.

Historiquement, les standards Internet traitaient = g=C3=A9n=C3=A9ralement des=20 sp=C3=A9cifications techniques pour les mat=C3=A9riels et logiciels = n=C3=A9cessaires =C3=A0 la=20 communication informatique =C3=A0 travers des r=C3=A9seaux = interconnect=C3=A9s. N=C3=A9anmoins,=20 puisque Internet m=C3=AAme se compose de r=C3=A9seaux exploit=C3=A9s par = des organisations tr=C3=A8s=20 vari=C3=A9es, avec des buts et des r=C3=A8gles diff=C3=A9rents, un bon = service aux utilisateurs=20 exige des op=C3=A9rateurs et des administrateurs de l'Internet qu'ils = suivent des=20 normes de guide et d'exploitation communes. Bien que ces normes soient=20 g=C3=A9n=C3=A9ralement diff=C3=A9rentes dans leur port=C3=A9e et leur = style des standards de=20 protocoles, leur constitution a besoin d'un processus similaire pour la=20 r=C3=A9alisation d'un consensus.

De la m=C3=AAme fa=C3=A7on que des entit=C3=A9s telles que l'IAB et = l'IESG se composent=20 d'individus pouvant participer =C3=A0 titre individuel au travail = technique de=20 l'IETF, les entit=C3=A9s elles-m=C3=AAmes ont =C3=A9galement le = r=C3=B4le de guides dans la=20 communaut=C3=A9.

En tant que guides dans la communaut=C3=A9 technique Internet, ces = entit=C3=A9s=20 devraient disposer d'un canal d'information pour proposer des id=C3=A9es = afin de=20 stimuler les travaux dans un domaine particulier, pour =C3=A9veiller la = sensibilit=C3=A9=20 de la communaut=C3=A9 sur un certain probl=C3=A8me, pour faire une = d=C3=A9claration de principe=20 d'architecture ou pour communiquer leurs r=C3=A9flexions sur d'autres = sujets. La=20 sous-s=C3=A9rie des BCP permet =C3=A0 ces entit=C3=A9s administratives = (management entities) d'ins=C3=A9rer de = fa=C3=A7on structur=C3=A9e et en=20 douceur des propositions dans les rouages de la construction du = consensus de=20 l'IETF tout en jaugeant la vision de la communaut=C3=A9 sur la = question.

Enfin, la s=C3=A9rie des BCP peut =C3=AAtre utilis=C3=A9e pour = documenter le fonctionnement=20 de l'IETF m=C3=AAme. Par exemple, ce document qui d=C3=A9finit le = processus de=20 standardisation IETF est publi=C3=A9 en tant que BCP.

5.1. Le processus de validation des = BCP

=C3=80 la diff=C3=A9rence des documents du circuit des standards, les = m=C3=A9canismes=20 d=C3=A9crits dans les BCP sont mal adapt=C3=A9s aux rappels par phase en = trois stades du=20 circuit des standards et n'ont en g=C3=A9n=C3=A9ral plut=C3=B4t de sens = que pour une=20 instanciation enti=C3=A8re et imm=C3=A9diate.

Le processus des BCP est similaire =C3=A0 celui des standards = propos=C3=A9s. Le BCP est=20 soumis =C3=A0 l'IESG pour examen (cf. la section 6.1.1)=20 et le processus de validation existant s'applique, y compris un dernier = appel=20 (Last-Call) sur la liste de = diffusion=20 Announce de l'IETF. Par contre, une fois le document approuv=C3=A9 par = l'IESG, le=20 processus se termine et le document est publi=C3=A9. Le document final = est pr=C3=A9sum=C3=A9=20 avoir l'approbation technique de l'IETF.

Sp=C3=A9cifiquement, pour recevoir le statut de BCP, un document doit = suivre les=20 proc=C3=A9dures d=C3=A9crites dans les sections 6.1=20 et 6.4=20 de ce document. Le processus des BCP peut faire l'objet d'un appel = conform=C3=A9ment=20 aux proc=C3=A9dures de la section 6.5.

Dans la mesure o=C3=B9 les BCP sont cens=C3=A9s exprimer un consensus = de la communaut=C3=A9=20 mais en y parvenant plus rapidement que les standards, ils = n=C3=A9cessitent une=20 attention particuli=C3=A8re. Sp=C3=A9cifiquement, les BCP ne devraient = pas simplement =C3=AAtre=20 vus comme des RFC informationnels plus forts mais plut=C3=B4t comme des = documents=20 adapt=C3=A9s =C3=A0 un contenu diff=C3=A9rent de celui des RFC = informationnels.

Une sp=C3=A9cification (ou un groupe de sp=C3=A9cifications) qui a = =C3=A9t=C3=A9 approuv=C3=A9e comme=20 BCP re=C3=A7oit un num=C3=A9ro dans la s=C3=A9rie des BCP tout en = conservant son num=C3=A9ro (ou=20 leurs num=C3=A9ros) de RFC.

6. Le processus de standardisation = Internet

La m=C3=A9canique du processus de standardisation Internet implique = des d=C3=A9cisions=20 de l'IESG concernant l'entr=C3=A9e d'une sp=C3=A9cification dans le = circuit des standards=20 ou le mouvement d'une sp=C3=A9cification du circuit des standards d'un = niveau de=20 maturit=C3=A9 =C3=A0 l'autre. Bien que nombre de crit=C3=A8res objectifs = raisonnables (d=C3=A9crits=20 ci-dessous et dans la section 4)=20 soient disponibles pour guider l'IESG dans sa d=C3=A9cision de placer, = promouvoir ou=20 sortir une sp=C3=A9cification du circuit des standards, il n'y a aucune = garantie=20 d'entr=C3=A9e ou de progression automatique d'une sp=C3=A9cification = dans le circuit des=20 standards. Le jugement collectif =C3=A9m=C3=A9rite de l'IESG sur la = qualit=C3=A9 technique=20 d'une sp=C3=A9cification propos=C3=A9e pour l'entr=C3=A9e ou la = promotion dans le circuit des=20 standards est un composant essentiel du processus de prise de = d=C3=A9cision.

6.1. Les actions de standardisation

Une =C2=AB action de standardisation =C2=BB (standards action), =C3=A0 savoir l'entr=C3=A9e = d'une sp=C3=A9cification=20 particuli=C3=A8re dans le circuit des standards, sa promotion ou son = retrait, doit=20 =C3=AAtre approuv=C3=A9e par l'IESG.

6.1.1. Le lancement d'une action

Une sp=C3=A9cification destin=C3=A9e =C3=A0 entrer ou =C3=A0 = progresser dans le circuit des=20 standards Internet devra d'abord =C3=AAtre publi=C3=A9e comme projet = Internet (cf. la=20 section 2.2),=20 =C3=A0 moins de n'avoir pas chang=C3=A9 depuis sa publication comme RFC. = Elle devra rester=20 =C3=A0 l'=C3=A9tat de projet Internet pendant une certaine p=C3=A9riode, = 2 semaines au=20 moins, permettant une revue utile par la communaut=C3=A9, =C3=A0 la = suite de quoi une=20 recommandation d'action peut =C3=AAtre lanc=C3=A9e.

L'action de standardisation est lanc=C3=A9e par la recommandation du = groupe de=20 travail IETF responsable de la sp=C3=A9cification aupr=C3=A8s de son = responsable de=20 domaine (Area Director), avec = copie au=20 secr=C3=A9tariat de l'IETF ou, dans le cas d'une sp=C3=A9cification non = associ=C3=A9e =C3=A0 un=20 groupe de travail, par la recommandation d'un individu aupr=C3=A8s de = l'IESG.

6.1.2. La validation et l'approbation de = l'IESG

L'IESG d=C3=A9terminera si une sp=C3=A9cification qui lui est soumise = conform=C3=A9ment =C3=A0 la=20 section 6.1.1=20 satisfait ou non aux crit=C3=A8res applicables pour l'action = recommand=C3=A9e=20 (cf. les sections 4.1=20 et 4.2),=20 et devra en plus d=C3=A9terminer si la qualit=C3=A9 et la clart=C3=A9 = techniques de la=20 sp=C3=A9cification sont compatibles ou non avec celles attendues pour le = niveau de=20 maturit=C3=A9 auquel la sp=C3=A9cification est recommand=C3=A9e.

Afin d'obtenir tous les renseignements n=C3=A9cessaires =C3=A0 ces = d=C3=A9terminations,=20 l'IESG peut commanditer =C3=A0 sa discr=C3=A9tion une analyse technique = ind=C3=A9pendante de la=20 sp=C3=A9cification, surtout lorsque l'IESG consid=C3=A8re la = sp=C3=A9cification extr=C3=AAmement=20 importante en ce qui concerne son impact potentiel sur Internet ou la = suite des=20 protocoles Internet.

L'IESG avertira l'IETF de son =C3=A9valuation en cours du (ou des) = document(s)=20 afin de permettre un examen final par la communaut=C3=A9 Internet en = g=C3=A9n=C3=A9ral. Cette=20 notification de dernier appel (Last-Call)=20 aura lieu via un courrier =C3=A9lectronique sur la liste de diffusion = Announce de=20 l'IETF. Les commentaires de tous sur un document de dernier appel seront = accept=C3=A9s et devraient =C3=AAtre envoy=C3=A9s selon les instructions = dans l'annonce de=20 dernier appel.

La p=C3=A9riode de dernier appel ne sera pas inf=C3=A9rieure =C3=A0 = 2 semaines, sauf si=20 l'action de standardisation propos=C3=A9e n'=C3=A9tait pas initi=C3=A9e = par un groupe de=20 travail IETF, auquel cas la p=C3=A9riode de dernier appel ne sera pas = inf=C3=A9rieure =C3=A0=20 4 semaines. Si l'IESG estime qu'un d=C3=A9lai sup=C3=A9rieur est = n=C3=A9cessaire pour les=20 commentaires dans l'int=C3=A9r=C3=AAt de la communaut=C3=A9, l'IESG peut = d=C3=A9cr=C3=A9ter une p=C3=A9riode=20 de dernier appel plus longue, ou la prolongation explicite de la = p=C3=A9riode de=20 dernier appel courante.

L'IESG n'est pas contraint par l'action recommand=C3=A9e lors de la = soumission de=20 la sp=C3=A9cification. Par exemple, l'IESG peut d=C3=A9cider d'examiner = la sp=C3=A9cification=20 pour publication dans une autre cat=C3=A9gorie que celle demand=C3=A9e. = Si l'IESG le=20 d=C3=A9termine avant l'annonce de dernier appel, son point de vue = devrait =C3=AAtre=20 refl=C3=A9t=C3=A9 dans le dernier appel. L'IESG pourrait =C3=A9galement = d=C3=A9cider de changer la=20 cat=C3=A9gorie de publication en fonction de la r=C3=A9ponse =C3=A0 un = dernier appel. Si cette=20 d=C3=A9cision se traduisait par la publication de la sp=C3=A9cification = =C3=A0 un niveau=20 sup=C3=A9rieur de celui du dernier appel initial, une nouvelle annonce = de dernier=20 appel devrait =C3=AAtre faite pour indiquer la d=C3=A9cision de l'IESG. = En outre, l'IESG=20 peut recommander la formation d'un nouveau groupe de travail en cas de=20 controverse importante en r=C3=A9ponse au dernier appel d'une = sp=C3=A9cification ne=20 provenant pas d'un groupe de travail IETF.

=C3=80 l'expiration de la p=C3=A9riode de dernier appel et dans les = meilleurs d=C3=A9lais,=20 l'IESG prendra sa d=C3=A9cision finale d'approuver ou non l'action de = standardisation=20 et en avertira l'IETF par un courrier =C3=A9lectronique sur la liste de = diffusion=20 Announce de l'IETF.

6.1.3. La publication

Si l'action de standardisation est approuv=C3=A9e, une notification = est envoy=C3=A9e =C3=A0=20 l'=C3=A9diteur des RFC en copie =C3=A0 l'IETF avec instruction de = publier la sp=C3=A9cification=20 comme RFC. La sp=C3=A9cification sera retir=C3=A9e du r=C3=A9pertoire = Internet-Drafts =C3=A0 ce moment.

Un r=C3=A9sum=C3=A9 officiel des actions de standardisation = termin=C3=A9es et en cours=20 appara=C3=AEtra dans chaque num=C3=A9ro de la lettre de diffusion de = l'Internet Society.=20 Elle constituera la =C2=AB publication des minutes =C2=BB = (publication of record) des actions de = standardisation=20 Internet.

L'=C3=A9diteur des RFC devra publier p=C3=A9riodiquement un RFC = intitul=C3=A9 Internet Official Protocol Standards = [1],=20 r=C3=A9sumant le statut de toutes les sp=C3=A9cifications de protocoles = et de=20 services.

6.2. La progression dans le circuit des=20 standards

La proc=C3=A9dure d=C3=A9crite dans la section 6.1=20 est observ=C3=A9e pour chaque action qui accompagne la progression d'une = sp=C3=A9cification au long du circuit des standards.

Une sp=C3=A9cification restera au niveau de standard propos=C3=A9 = (Proposed Standard) pendant au moins = 6 mois.

Une sp=C3=A9cification restera au niveau de standard = pr=C3=A9liminaire (Draft Standard) pendant au moins 4 mois, ou = jusqu'=C3=A0=20 ce qu'au moins une r=C3=A9union de l'IETF ait eu lieu, selon le dernier = =C3=A0=20 survenir.

Ces p=C3=A9riodes minimales ont pour but d'assurer un d=C3=A9lai = d'examen suffisant par=20 la communaut=C3=A9 sans nuire =C3=A0 la ponctualit=C3=A9. Ces = intervalles seront mesur=C3=A9s depuis=20 la date de publication du (ou des) RFC correspondant(s), ou, si l'action = n'aboutit pas =C3=A0 la publication d'un RFC, depuis la date de = l'annonce=20 d'approbation de l'action par l'IESG.

Une sp=C3=A9cification peut =C3=AAtre r=C3=A9vis=C3=A9e (en fait, ce = sera probablement le cas) au=20 cours de sa progression =C3=A0 travers le circuit des standards. =C3=80 = chaque stade,=20 l'IESG d=C3=A9terminera la port=C3=A9e et l'importance de la = r=C3=A9vision pour la=20 sp=C3=A9cification et, si n=C3=A9cessaire et appropri=C3=A9, modifiera = l'action recommand=C3=A9e.=20 Des r=C3=A9visions mineures sont =C3=A0 pr=C3=A9voir mais une = r=C3=A9vision majeure peut n=C3=A9cessiter=20 une exp=C3=A9rimentation suppl=C3=A9mentaire de la sp=C3=A9cification = =C3=A0 son niveau de maturit=C3=A9=20 courant avant toute progression. Enfin, si la sp=C3=A9cification a = re=C3=A7u beaucoup de=20 modifications, l'IESG peut recommander de traiter la r=C3=A9vision comme = un nouveau=20 document, en reprenant le circuit des standards au d=C3=A9but.

Un changement de statut se traduira par la republication de la = sp=C3=A9cification=20 comme RFC, sauf dans le cas rare o=C3=B9 il n'y aura eu aucune = modification du tout=20 depuis la derni=C3=A8re publication. En g=C3=A9n=C3=A9ral, les = modifications souhait=C3=A9es seront=20 diff=C3=A9r=C3=A9es et incorpor=C3=A9es au niveau suivant dans le = circuit des standards.=20 Toutefois, le report des modifications de la sp=C3=A9cification sur = l'action de=20 standardisation suivante ne sera pas toujours possible ou souhaitable. = Par=20 exemple, une erreur de typographie importante ou une erreur technique = qui ne=20 repr=C3=A9sentent pas un changement de la fonction d'ensemble de la = sp=C3=A9cification=20 peuvent n=C3=A9cessiter une correction imm=C3=A9diate. Auquel cas, on = peut demander =C3=A0=20 l'IESG ou =C3=A0 l'=C3=A9diteur des RFC de republier le RFC (sous un = nouveau num=C3=A9ro) avec=20 les corrections, sans r=C3=A9initialisation de la dur=C3=A9e minimale = =C3=A0 ce niveau.

Lorsqu'une sp=C3=A9cification du circuit des standards n'a pas = atteint le niveau=20 de standard Internet mais est rest=C3=A9e au m=C3=AAme niveau de = maturit=C3=A9 pendant=20 24 mois, et tous les 12 mois ensuite jusqu'=C3=A0 un = changement de statut,=20 l'IESG examinera la viabilit=C3=A9 de l'effort de standardisation = responsable de=20 cette sp=C3=A9cification et l'utilit=C3=A9 de la technologie. =C3=80 = l'issue de chaque examen,=20 l'IESG confirmera la dissolution ou la continuation de l'effort de=20 d=C3=A9veloppement, et d=C3=A9cidera =C3=A0 cette occasion de maintenir = la sp=C3=A9cification au=20 m=C3=AAme niveau de maturit=C3=A9 ou de lui affecter le statut = d'historique (Historic). Cette d=C3=A9cision sera = communiqu=C3=A9e =C3=A0=20 l'IETF par un courrier =C3=A9lectronique sur la liste de diffusion = Announce de l'IETF=20 pour y =C3=AAtre comment=C3=A9e par la communaut=C3=A9 Internet. Cette = disposition ne constitue=20 pas une menace =C3=A0 l'encontre de l'effort d'un groupe de travail = l=C3=A9gitime et actif=20 mais un m=C3=A9canisme administratif pour terminer un effort = moribond.

6.3. La r=C3=A9vision d'un standard

Une nouvelle version d'un standard Internet =C3=A9tabli doit = progresser =C3=A0 travers=20 tout le processus de standardisation Internet comme s'il s'agissait = d'une=20 sp=C3=A9cification enti=C3=A8rement nouvelle. Une fois le niveau de = standard (Standard) atteint par la nouvelle = version, elle=20 remplacera g=C3=A9n=C3=A9ralement la pr=C3=A9c=C3=A9dente qui recevra le = statut d'historique (Historic). Toutefois, dans certains = cas les deux=20 versions peuvent rester au statut de standard Internet (Internet Standard) pour honorer les exigences = d'une base=20 install=C3=A9e. Dans une telle situation, la relation entre la version = pr=C3=A9c=C3=A9dente et=20 la nouvelle doit =C3=AAtre explicitement mentionn=C3=A9e dans le texte = de la nouvelle=20 version ou d'un autre document appropri=C3=A9 (par exemple, une = d=C3=A9claration=20 d'applicabilit=C3=A9, cf. la section 3.2).

6.4. Le retrait d'un standard

Avec l'=C3=A9volution et la maturit=C3=A9 des technologies, il peut = arriver qu'une=20 nouvelle sp=C3=A9cification de standard soit si manifestement = sup=C3=A9rieure=20 techniquement qu'une ou plusieurs sp=C3=A9cifications du circuit des = standards de=20 m=C3=AAme fonction doivent =C3=AAtre retir=C3=A9es. Auquel cas, ou si = pour une autre raison il=20 est estim=C3=A9 qu'une sp=C3=A9cification du circuit des standards = devrait =C3=AAtre retir=C3=A9e,=20 l'IESG approuvera le changement du statut de la sp=C3=A9cification (ou = des=20 sp=C3=A9cifications) existante(s) pour Historic.=20 Cette recommandation devra =C3=AAtre effectu=C3=A9e selon les m=C3=AAmes = proc=C3=A9dures de dernier=20 appel et de notification utilis=C3=A9es pour toute autre action de = standardisation.=20 La demande de retrait d'un standard existant peut provenir d'un groupe = de=20 travail, d'un responsable de domaine ou d'un autre tiers = int=C3=A9ress=C3=A9.

6.5. La r=C3=A9solution des conflits et = les appels

Des d=C3=A9saccords peuvent survenir =C3=A0 divers stades du = processus IETF. Autant que=20 possible, le processus est con=C3=A7u de telle sorte que l'on puisse = faire des=20 compromis et parvenir =C3=A0 un v=C3=A9ritable consensus, mais parfois = m=C3=AAme les personnes=20 les plus raisonnables et les plus inform=C3=A9es n'arrivent pas =C3=A0 = se mettre d'accord.=20 Pour respecter les objectifs d'ouverture et d'impartialit=C3=A9, ces = conflits doivent=20 =C3=AAtre r=C3=A9solus par un processus de critique et de discussion = transparentes. Cette=20 section d=C3=A9crit les proc=C3=A9dures =C3=A0 suivre pour traiter les = probl=C3=A8mes des standards=20 Internet non solutionnables par le processus habituel avec lequel les = groupes de=20 travail IETF et les autres intervenants du processus des standards = Internet=20 aboutissent normalement =C3=A0 un accord.

6.5.1. Les d=C3=A9saccords des groupes = de travail

Une personne (qu'elle participe ou non au groupe de travail = concern=C3=A9) peut=20 =C3=AAtre en d=C3=A9saccord avec la recommandation d'un groupe de = travail, estimant que=20 (a) ses propres positions n'ont pas =C3=A9t=C3=A9 convenablement = =C3=A9valu=C3=A9es par le=20 groupe de travail, ou bien (b) qu'un choix technique erron=C3=A9 = met en grand=20 p=C3=A9ril la qualit=C3=A9 ou l'int=C3=A9grit=C3=A9 des produits du = groupe de travail. Le premier=20 objet de litige est un probl=C3=A8me de fonctionnement du groupe de = travail, le=20 dernier est l'affirmation d'une erreur technique. Bien que ces deux = types de=20 contentieux soient tr=C3=A8s diff=C3=A9rents, ils sont trait=C3=A9s par = un m=C3=AAme processus=20 d'examen.

Une personne en d=C3=A9saccord avec la recommandation d'un groupe de = travail=20 devrait d'abord en faire part au pr=C3=A9sident (ou aux pr=C3=A9sidents) = du groupe de=20 travail, lequel peut convier d'autres membres du groupe (ou le groupe de = travail=20 entier) =C3=A0 la discussion.

Si le d=C3=A9saccord persiste, chacune des parties concern=C3=A9es = peut le porter =C3=A0=20 l'attention du responsable (ou des responsables) de domaine (Area Director) du domaine auquel le groupe de = travail est=20 affect=C3=A9. Le responsable (ou les responsables) de domaine essaiera = de r=C3=A9soudre le=20 litige.

Si le d=C3=A9saccord ne peut =C3=AAtre r=C3=A9solu par le responsable = (ou les responsables)=20 de domaine, chacune des parties concern=C3=A9es peut alors faire appel = aupr=C3=A8s de=20 l'IESG dans son ensemble. Puis l'IESG examinera la situation et essaiera = d'y=20 rem=C3=A9dier =C3=A0 sa convenance.

Si la r=C3=A9solution au niveau de l'IESG ne satisfait pas les = parties, chacune=20 des parties concern=C3=A9es peut faire appel de la d=C3=A9cision = aupr=C3=A8s de l'IAB. Puis=20 l'IAB examinera la situation et essaiera d'y rem=C3=A9dier =C3=A0 sa = convenance.

La d=C3=A9cision de l'IAB est d=C3=A9finitive en ce qui concerne la = question du respect=20 ou non des proc=C3=A9dures de standardisation Internet et pour toutes = les questions=20 de nature technique.

6.5.2. Les faillites du processus

Ce document =C3=A9tablit les proc=C3=A9dures extraordinaires = n=C3=A9cessaires =C3=A0 observer=20 pour assurer l'ouverture et l'impartialit=C3=A9 du processus de = standardisation=20 Internet et la viabilit=C3=A9 technique des standards cr=C3=A9=C3=A9s. = L'IESG est l'agent=20 principal de l'IETF dans ce but, et c'est la t=C3=A2che de l'IESG de = s'assurer que=20 les proc=C3=A9dures =C3=A9dict=C3=A9es ont =C3=A9t=C3=A9 observ=C3=A9es = et que les conditions d'une action de=20 standardisation ont =C3=A9t=C3=A9 respect=C3=A9es.

Si une personne est en d=C3=A9saccord avec une action prise par = l'IESG au cours de=20 ce processus, elle devrait d'abord en faire part au pr=C3=A9sident de = l'IESG (IESG Chair). Si le pr=C3=A9sident ne = peut convaincre=20 le plaignant, l'IESG dans son ensemble doit alors r=C3=A9examiner = l'action engag=C3=A9e,=20 en m=C3=AAme temps que l'avis du plaignant, et d=C3=A9terminer si une = autre action est=20 n=C3=A9cessaire. L'IESG informera l'IETF de son instruction de la = plainte.

Si le plaignant n'est pas satisfait des conclusions de l'IESG, un = appel peut=20 =C3=AAtre formul=C3=A9 aupr=C3=A8s de l'IAB. Puis l'IAB examinera la = situation et essaiera d'y=20 rem=C3=A9dier =C3=A0 sa convenance, et informera l'IETF de ses = conclusions.

Si les circonstances le justifient, l'IAB peut ordonner l'annulation = d'une=20 d=C3=A9cision de l'IESG, et la situation redeviendra alors celle qu'elle = =C3=A9tait avant=20 la d=C3=A9cision de l'IESG. L'IAB peut =C3=A9galement recommander une = action =C3=A0 l'IESG ou=20 faire toutes autres recommandations en ce sens jug=C3=A9es = n=C3=A9cessaires. Par contre,=20 l'IAB ne peut pas empi=C3=A9ter sur le r=C3=B4le de l'IESG en = arr=C3=AAtant une d=C3=A9cision que=20 seul l'IESG est habilit=C3=A9 =C3=A0 prendre.

La d=C3=A9cision de l'IAB est d=C3=A9finitive en ce qui concerne la = question du respect=20 ou non des proc=C3=A9dures de standardisation Internet.

6.5.3. La pertinence des = proc=C3=A9dures

Un recours de plus est pr=C3=A9vu seulement pour les cas o=C3=B9 les = proc=C3=A9dures=20 elles-m=C3=AAmes (c'est-=C3=A0-dire les proc=C3=A9dures d=C3=A9crites = dans ce document) sont=20 pr=C3=A9tendues inad=C3=A9quates ou insuffisantes =C3=A0 prot=C3=A9ger = les droits de toutes les=20 parties dans un processus de standardisation Internet impartial et = ouvert. Les=20 r=C3=A9clamations de cette nature peuvent =C3=AAtre d=C3=A9pos=C3=A9es = aupr=C3=A8s du conseil=20 d'administration (Board of = Trustees) de=20 l'Internet Society. Le pr=C3=A9sident de l'Internet Society devra = accuser r=C3=A9ception=20 de cet appel dans les 2 semaines, et devra aviser le = requ=C3=A9rant, dans cet=20 accus=C3=A9 de r=C3=A9ception, des d=C3=A9lais pr=C3=A9visibles de = l'examen en appel par les=20 administrateurs (Trustees). Les = administrateurs examineront la situation =C3=A0 leur convenance et = informeront l'IETF=20 de leurs conclusions.

La d=C3=A9cision des administrateurs =C3=A0 l'issue de leur = instruction sera d=C3=A9finitive=20 en ce qui concerne tous les aspects litigieux.

6.5.4. La proc=C3=A9dure d'appel

Tous les pourvois en appel doivent inclure une description = d=C3=A9taill=C3=A9e et=20 sp=C3=A9cifique des faits du litige.

Tous les pourvois en appel doivent =C3=AAtre d=C3=A9pos=C3=A9s dans = les 2 mois suivant=20 la publication de l'action ou de la d=C3=A9cision contest=C3=A9es.

=C3=80 tous les stades du processus d'appel, les personnes ou les = organismes=20 responsables de la prise de d=C3=A9cisions ont le loisir de d=C3=A9finir = les proc=C3=A9dures=20 sp=C3=A9cifiques qu'ils suivront pour arriver =C3=A0 leur = d=C3=A9cision.

Dans tous les cas, la d=C3=A9cision concernant le traitement du = litige et la=20 communication de cette d=C3=A9cision aux parties engag=C3=A9es doivent = =C3=AAtre accomplies=20 dans un d=C3=A9lai raisonnable.

Remarque : Ces = proc=C3=A9dures,=20 intentionnellement et explicitement, n'=C3=A9tablissent pas de = d=C3=A9lai fixe maximal=20 consid=C3=A9r=C3=A9 comme =C2=AB raisonnable =C2=BB dans tous = les cas. Le processus de=20 standardisation Internet privil=C3=A9gie le consensus et les efforts = pour y parvenir,=20 et renonce d=C3=A9lib=C3=A9r=C3=A9ment =C3=A0 des proc=C3=A9dures = pr=C3=A9d=C3=A9termin=C3=A9es rapidement ex=C3=A9cut=C3=A9es, en=20 faveur d'une latitude o=C3=B9 l'on parvient =C3=A0 des accords = techniques plus=20 authentiques.

7. Les normes et sp=C3=A9cifications = externes

Hormis l'IETF, beaucoup de groupes de normalisation cr=C3=A9ent et = publient des=20 normes de protocoles de r=C3=A9seaux et de services. Lorsque ces = sp=C3=A9cifications=20 externes jouent un r=C3=B4le important dans Internet, il convient de = trouver un=20 terrain d'entente pour leur utilisation, c'est-=C3=A0-dire = d'=C3=A9tablir des standards=20 Internet concernant ces sp=C3=A9cifications externes.

Il y a deux cat=C3=A9gories de sp=C3=A9cifications = externes :

  1. (1) Les normes ouvertes (Open=20 Standards)=20

    Divers organismes de normalisation nationaux et internationaux, = tels que=20 l'ANSI, l'ISO, l'IEEE et l'ITU-T, d=C3=A9veloppent une grande = vari=C3=A9t=C3=A9 de=20 sp=C3=A9cifications de protocoles et de services similaires aux = sp=C3=A9cifications=20 techniques d=C3=A9finies ici. Certains groupes nationaux et = internationaux publient=20 =C3=A9galement des =C2=AB conventions de = r=C3=A9alisation =C2=BB (implementor agreements) qui sont analogues aux = d=C3=A9clarations d'applicabilit=C3=A9 (Applicability=20 Statement), en capturant un corpus de d=C3=A9tails = sp=C3=A9cifiques d'une mise en=20 =C5=93uvre en rapport avec l'application pratique de leurs normes. = Tous ces=20 documents sont consid=C3=A9r=C3=A9s comme des =C2=AB normes = ouvertes externes =C2=BB=20 pour le processus de standardisation Internet.

  2. (2) Les autres sp=C3=A9cifications=20

    D'autres sp=C3=A9cifications propri=C3=A9taires dont l'utilisation = s'est g=C3=A9n=C3=A9ralis=C3=A9e=20 dans Internet peuvent =C3=AAtre trait=C3=A9es par la communaut=C3=A9 = Internet comme des=20 standards. Une sp=C3=A9cification de ce genre n'est en = g=C3=A9n=C3=A9ral pas d=C3=A9velopp=C3=A9e=20 ouvertement, est typiquement brevet=C3=A9e (proprietary), et est contr=C3=B4l=C3=A9e par = le vendeur, les=20 vendeurs ou l'organisation qui l'ont produite.

7.1. L'utilisation des sp=C3=A9cifications = externes

Pour =C3=A9viter les conflits entre des versions concurrentes d'une = sp=C3=A9cification,=20 la communaut=C3=A9 Internet ne normalisera pas une sp=C3=A9cification = qui est simplement=20 une =C2=AB version Internet =C2=BB d'une sp=C3=A9cification = externe existante, =C3=A0=20 moins qu'un accord de coop=C3=A9ration explicite ne soit pris en ce = sens. Par contre,=20 une sp=C3=A9cification externe, importante pour le fonctionnement ou = l'=C3=A9volution=20 d'Internet, peut =C3=AAtre adopt=C3=A9e pour une utilisation Internet de = plusieurs=20 fa=C3=A7ons.

7.1.1. L'incorporation d'une norme = ouverte

Un standard Internet de type sp=C3=A9cification technique ou = d=C3=A9claration=20 d'applicabilit=C3=A9 peut incorporer un standard ouvert externe par = r=C3=A9f=C3=A9rence. Par=20 exemple, beaucoup de standards Internet incorporent par = r=C3=A9f=C3=A9rence le jeu de=20 caract=C3=A8res normalis=C3=A9 "ASCII" [2]=20 de l'ANSI. Autant que possible, la sp=C3=A9cification = r=C3=A9f=C3=A9renc=C3=A9e devra =C3=AAtre=20 disponible en ligne.

7.1.2. L'incorporation des autres=20 sp=C3=A9cifications

D'autres sp=C3=A9cifications propri=C3=A9taires peuvent =C3=AAtre = incorpor=C3=A9es par r=C3=A9f=C3=A9rence=20 dans une version de la sp=C3=A9cification tant que leurs d=C3=A9tenteurs = satisfont aux=20 exigences de la section 10.=20 Si l'autre sp=C3=A9cification propri=C3=A9taire n'est pas largement et = imm=C3=A9diatement=20 disponible, l'IESG peut demander qu'elle soit publi=C3=A9e comme RFC = informationnel=20 (Informational).

L'IESG ne devrait g=C3=A9n=C3=A9ralement pas favoriser une = sp=C3=A9cification propri=C3=A9taire=20 particuli=C3=A8re par rapport =C3=A0 une ou plusieurs = sp=C3=A9cifications concurrentes=20 techniquement =C3=A9quivalentes en rendant obligatoire ou = recommand=C3=A9e la=20 sp=C3=A9cification incorpor=C3=A9e d'un vendeur.

7.1.3. La prise en charge

Un groupe de travail IETF peut d=C3=A9marrer =C3=A0 partir d'une = sp=C3=A9cification externe=20 et la d=C3=A9velopper en une sp=C3=A9cification Internet. C'est = acceptable si (1) la=20 sp=C3=A9cification est fournie au groupe de travail en conformit=C3=A9 = avec les exigences=20 de la section 10,=20 et (2) le d=C3=A9veloppeur original de la sp=C3=A9cification a = pass=C3=A9 le contr=C3=B4le des=20 modifications de la sp=C3=A9cification ou des sp=C3=A9cifications = d=C3=A9riv=C3=A9es de l'originale=20 =C3=A0 l'IETF.

8. Les annonces et la tenue des = archives

Chaque organisation impliqu=C3=A9e dans le d=C3=A9veloppement et la = validation de=20 standards Internet devra annoncer publiquement et tenir une liste = accessible au=20 public de chaque activit=C3=A9 dans laquelle elle est engag=C3=A9e, dans = la mesure o=C3=B9=20 l'activit=C3=A9 repr=C3=A9sente la continuation d'une partie du = processus de=20 standardisation Internet. Pour les besoins de cette section, les = organisations=20 impliqu=C3=A9es dans le d=C3=A9veloppement et la validation des = standards Internet=20 comprennent l'IETF, l'IESG, l'IAB, tous les groupes de travail IETF, et = le=20 conseil d'administration de l'Internet Society.

Pour l'IETF et les r=C3=A9unions des groupes de travail, les annonces = devront =C3=AAtre=20 faites par courrier =C3=A9lectronique sur la liste de diffusion Announce = de l'IETF,=20 suffisamment en avance pour permettre =C3=A0 toutes les parties = int=C3=A9ress=C3=A9es de=20 participer. L'annonce devra contenir (ou pointer vers) toutes les = informations=20 n=C3=A9cessaires au soutien de la participation des = int=C3=A9ress=C3=A9s. Dans le cas d'une=20 r=C3=A9union, par exemple, l'annonce devra inclure un calendrier des = questions de=20 standardisation qui seront abord=C3=A9es.

L'enregistrement formel d'une activit=C3=A9 de standardisation d'une = organisation=20 devra au moins inclure les renseignements suivants :

  • la charte de l'organisation (ou un r=C3=A8glement =C3=A9quivalent = d'une=20 charte) ;=20
  • les proc=C3=A8s-verbaux complets et exacts des = r=C3=A9unions ;=20
  • les archives des courriers =C3=A9lectroniques des listes de = diffusion des=20 groupes de travail ;=20
  • toutes les contributions =C3=A9crites des participants ayant un = rapport avec=20 l'activit=C3=A9 de standardisation de l'organisation.

Concr=C3=A8tement, les enregistrements formels de toutes les = activit=C3=A9s du=20 processus de standardisation Internet sont conserv=C3=A9s par le = secr=C3=A9tariat de=20 l'IETF, sauf que chaque groupe de travail IETF est cens=C3=A9 tenir les = archives de=20 ses propres listes de diffusion et doit s'efforcer de capturer et = inclure tous=20 les =C3=A9changes dans les archives. En outre, le pr=C3=A9sident du = groupe de travail est=20 charg=C3=A9 de fournir au secr=C3=A9tariat de l'IETF les = proc=C3=A8s-verbaux complets et exacts=20 de toutes les r=C3=A9unions du groupe de travail. Les projets Internet = retir=C3=A9s du=20 r=C3=A9pertoire Internet-Drafts = (quelle qu'en=20 soit la raison) seront archiv=C3=A9s par le secr=C3=A9tariat de l'IETF = dans le seul but de=20 conserver un document historique de l'activit=C3=A9 de standardisation = Internet, et=20 ne sont donc pas r=C3=A9cup=C3=A9rables sauf circonstances = particuli=C3=A8res.

9. La variation du processus

Ce document, qui =C3=A9tablit les r=C3=A8gles et proc=C3=A9dures = selon lesquelles les=20 standards Internet et documents apparent=C3=A9s sont fabriqu=C3=A9s, est = lui-m=C3=AAme un=20 produit du processus de standardisation Internet (en tant que BCP, comme = d=C3=A9crit=20 dans la section 5).=20 Il remplace une version pr=C3=A9c=C3=A9dente et, avec le temps, sera = probablement remplac=C3=A9=20 =C3=A0 son tour.

Bien que ce document, lorsqu'il est publi=C3=A9, repr=C3=A9sente = l'opinion de la=20 communaut=C3=A9 =C3=A0 propos du processus exact =C3=A0 suivre, et des = conditions =C3=A0 r=C3=A9unir afin=20 de produire les standards Internet et les BCP les meilleurs possibles, = il n'est=20 pas s=C3=BBr que cela restera toujours le cas. De temps en temps, on = voudra peut-=C3=AAtre=20 le mettre =C3=A0 jour, en le rempla=C3=A7ant par une nouvelle version. = La mise =C3=A0 jour de=20 ce document emprunte les m=C3=AAmes proc=C3=A9dures que celles = utilis=C3=A9es pour n'importe=20 quel autre BCP.

Par ailleurs, des situations peuvent se pr=C3=A9senter o=C3=B9 = l'observation des=20 proc=C3=A9dures m=C3=A8ne =C3=A0 une impasse pour une sp=C3=A9cification = sp=C3=A9cifique, et o=C3=B9 les=20 proc=C3=A9dures n'offrent aucun guide. Dans ce cas, il faudra = peut-=C3=AAtre invoquer la=20 proc=C3=A9dure de dispense (variation = procedure)=20 d=C3=A9crite ci-dessous.

9.1. La proc=C3=A9dure de dispense

Sur la recommandation du groupe de travail IETF responsable (ou sur = la=20 recommandation d'un comit=C3=A9 sp=C3=A9cial, si aucun groupe de travail = n'est constitu=C3=A9),=20 l'IESG peut faire entrer une recommandation dans le circuit des = standards, ou=20 l'y faire progresser, m=C3=AAme si certaines exigences de ce document ne = sont pas=20 respect=C3=A9es, ou ne le seront pas. L'IESG ne peut toutefois approuver = un tel =C3=A9cart=20 qu'en d=C3=A9terminant d'abord si les b=C3=A9n=C3=A9fices potentiels = pour la communaut=C3=A9=20 Internet peuvent justifier les co=C3=BBts induits par le non respect des = exigences de=20 ce document aupr=C3=A8s de la communaut=C3=A9 Internet. Dans l'exercice = de ce pouvoir=20 discr=C3=A9tionaire, l'IESG devra au minimum consid=C3=A9rer (a) le = m=C3=A9rite technique=20 de la sp=C3=A9cification, (b) la possibilit=C3=A9 de r=C3=A9aliser = les objectifs du=20 processus de standardisation Internet sans accorder de dispense, = (c) les=20 alternatives au recours =C3=A0 une dispense, (d) les effets = secondaires et de=20 pr=C3=A9c=C3=A9dent du recours =C3=A0 une dispense et (e) la = possibilit=C3=A9 de cr=C3=A9er une=20 dispense aussi r=C3=A9duite que possible. Dans la d=C3=A9termination de = la dispense,=20 l'IESG a le droit d'en limiter la port=C3=A9e =C3=A0 des parties = sp=C3=A9cifiques de ce=20 document et d'imposer les restrictions et limitations jug=C3=A9es = n=C3=A9cessaires pour=20 prot=C3=A9ger les int=C3=A9r=C3=AAts de la communaut=C3=A9 Internet.

La dispense propos=C3=A9e doit d=C3=A9tailler le probl=C3=A8me = per=C3=A7u, pr=C3=A9ciser la=20 disposition de ce document justifiant son recours et indiquer les = conclusions de=20 l'IESG vis-=C3=A0-vis des consid=C3=A9rations des points (a) =C3=A0 (d) = dans le paragraphe=20 pr=C3=A9c=C3=A9dent. La dispense propos=C3=A9e sera publi=C3=A9e en tant = que projet Internet. Puis=20 l'IESG fera une annonce de dernier appel =C3=A9tendue, d'au moins = 4 semaines,=20 afin que la communaut=C3=A9 puisse commenter la proposition.

Rapidement apr=C3=A8s expiration de la p=C3=A9riode de dernier appel, = l'IESG prendra sa=20 d=C3=A9cision finale d'approuver ou non la dispense propos=C3=A9e et en = notifiera l'IETF=20 par un courrier =C3=A9lectronique sur la liste de diffusion Announce de = l'IETF. Si la=20 dispense est approuv=C3=A9e, elle sera transmise =C3=A0 l'=C3=A9diteur = des RFC avec instruction=20 de la publier en tant que BCP.

Cette proc=C3=A9dure de dispense est =C3=A0 utiliser lorsque la = modification ponctuelle=20 d'une disposition de ce document semble n=C3=A9cessaire. Les changements = permanents=20 du document auront lieu au travers du processus BCP normal.

Le processus d'appel de la section 6.5=20 s'applique =C3=A0 ce processus.

9.2. Les exclusions

L'utilisation de cette proc=C3=A9dure ne saurait en aucun cas = r=C3=A9duire les d=C3=A9lais=20 indiqu=C3=A9s, ni exempter une proposition quelconque des exigences = d'ouverture,=20 d'impartialit=C3=A9 ou de consensus, ni de l'obligation de tenir des = enregistrements=20 corrects des discussions des r=C3=A9unions et des listes de = diffusion.

Sp=C3=A9cifiquement, les sections suivantes de ce document ne peuvent = pas faire=20 l'objet d'une dispense : 5.1, 6.1, 6.1.1 (premier paragraphe), = 6.1.2, 6.3=20 (premi=C3=A8re phrase), 6.5 et 9.

10. Les droits de propri=C3=A9t=C3=A9 = intellectuelle

10.1. La politique = g=C3=A9n=C3=A9rale

Dans toutes les questions de droits de propri=C3=A9t=C3=A9 = intellectuelle et de=20 proc=C3=A9dures, c'est le b=C3=A9n=C3=A9fice de la communaut=C3=A9 = Internet et du public au sens=20 large qui est vis=C3=A9, tout en respectant les droits l=C3=A9gitimes = des autres.

10.2. Les obligations de = confidentialit=C3=A9

Aucune contribution soumise =C3=A0 une quelconque condition de = confidentialit=C3=A9 ou=20 restriction de diffusion n'est recevable dans une partie du processus de = standardisation Internet, et il ne doit y avoir aucune pr=C3=A9somption = d'obligation=20 de confidentialit=C3=A9 en ce qui concerne une telle contribution.

10.3. Les droits et les permissions

Au cours de la standardisation, l'IETF re=C3=A7oit des contributions = sous diverses=20 formes et de nombreuses personnes. Pour faciliter la diffusion de ces=20 contributions, il est n=C3=A9cessaire de comprendre quels sont les = droits de=20 propri=C3=A9t=C3=A9 intellectuelle (IPR) se rapportant aux = contributions.

10.3.1. Toutes les contributions

En soumettant une contribution, chaque soumettant est cens=C3=A9 = accepter les=20 termes et conditions suivants en son nom, au nom de l'organisation qu'il = repr=C3=A9sente (le cas =C3=A9ch=C3=A9ant) et au nom des d=C3=A9tenteurs = de droits de propri=C3=A9t=C3=A9 dans=20 la contribution. Lorsqu'une soumission identifie des contributeurs en = plus du=20 contributeur (ou des contributeurs) qui apporte effectivement la = soumission, le=20 soumettant effectif (ou les soumettants) fait valoir que chaque autre=20 contributeur nomm=C3=A9 a pris connaissance desdits termes et conditions = et les a=20 accept=C3=A9s en son nom, au nom d'une organisation qu'il = repr=C3=A9sente et de tout=20 d=C3=A9tenteur connu de droits de propri=C3=A9t=C3=A9 (proprietary rights) dans la contribution.

  1. l. Certains travaux (par exemple, les travaux du gouvernement des=20 =C3=89tats-Unis) ne sont pas soumis =C3=A0 des droits d'auteur. = Toutefois, dans la=20 mesure o=C3=B9 la soumission est soumise =C3=A0 des droits d'auteur ou = est susceptible=20 de l'=C3=AAtre, le contributeur, l'organisation qu'il repr=C3=A9sente = (le cas =C3=A9ch=C3=A9ant)=20 et les d=C3=A9tenteurs de droits de propri=C3=A9t=C3=A9 dans la = contribution conc=C3=A8dent une=20 licence illimit=C3=A9e, perp=C3=A9tuelle, non exclusive, sans = contrepartie, universelle=20 =C3=A0 l'ISOC et l'IETF selon tous les droits d'auteur dans la = contribution. Cette=20 licence comprend le droit de copier, publier et distribuer la = contribution sur=20 tout support, et de pr=C3=A9parer des =C5=93uvres d=C3=A9riv=C3=A9es = qui se fondent sur ou=20 incorporent tout ou partie de la contribution, la licence de ces = =C5=93uvres=20 d=C3=A9riv=C3=A9es =C3=A9tant du m=C3=AAme ordre que celle de la = contribution originale.=20
  2. 2. Le contributeur reconna=C3=AEt que l'ISOC et l'IETF n'ont = aucune obligation=20 de publier ou sinon d'utiliser ou diffuser une quelconque = contribution.=20
  3. 3. Le contributeur autorise la citation du nom et de l'adresse du=20 contributeur (ou des contributeurs) et de l'organisation (ou des=20 organisations) qu'il repr=C3=A9sente (le cas =C3=A9ch=C3=A9ant).=20
  4. 4. Le contributeur fait valoir que la contribution cite = correctement les=20 contributeurs principaux.=20
  5. 5. Le contributeur, l'organisation qu'il repr=C3=A9sente (le cas = =C3=A9ch=C3=A9ant) et=20 les d=C3=A9tenteurs de droits de propri=C3=A9t=C3=A9 dans la = contribution font valoir=20 qu'aucune information dans la contribution n'est confidentielle, et = que l'ISOC=20 et ses affili=C3=A9s peuvent divulguer librement toute information qui = y est=20 contenue.=20
  6. 6. Le contributeur fait valoir qu'il a divulgu=C3=A9 l'existence = de tous les=20 droits de propri=C3=A9t=C3=A9 et droits de propri=C3=A9t=C3=A9 = intellectuelle dans la=20 contribution, connus de lui raisonnablement et personnellement. Le=20 contributeur ne fait pas valoir qu'il a connaissance personnelle de = tous les=20 droits de propri=C3=A9t=C3=A9 et droits de propri=C3=A9t=C3=A9 = intellectuelle potentiellement=20 aff=C3=A9rents d=C3=A9tenus ou revendiqu=C3=A9s par l'organisation = qu'il repr=C3=A9sente (le cas=20 =C3=A9ch=C3=A9ant) ou des tiers.=20
  7. 7. Le contributeur fait valoir qu'il n'existe pas de limitations = de sa=20 capacit=C3=A9 =C3=A0 faire les concessions, acceptations et = conventions pr=C3=A9c=C3=A9dentes,=20 connues raisonnablement et personnellement du contributeur.

En ratifiant cette description du processus IETF, l'Internet Society = garantit=20 de ne pas limiter l'acc=C3=A8s traditionnellement libre et gratuit aux = documents IETF=20 auxquels une licence et un droit ont =C3=A9t=C3=A9 rattach=C3=A9s = conform=C3=A9ment aux proc=C3=A9dures=20 pr=C3=A9sent=C3=A9es dans cette section, y compris les projets Internet = et les RFC. Cette=20 assurance est perp=C3=A9tuelle et ne sera pas r=C3=A9voqu=C3=A9es par = l'Internet Society, ou=20 ses successeurs ou cessionnaires (assigns).

10.3.2. Les documents du circuit des=20 standards
  • (A) Lorsque des brevets, des demandes de brevets ou autres droits = de=20 propri=C3=A9t=C3=A9 sont connus, ou revendiqu=C3=A9s, par rapport = =C3=A0 une sp=C3=A9cification sur le=20 circuit des standards, et port=C3=A9s =C3=A0 l'attention de l'IESG, = l'IESG ne devra pas=20 promouvoir la sp=C3=A9cification sans y inclure une note signalant = l'existence de=20 ces droits ou ces droits revendiqu=C3=A9s (claimed=20 rights). Lorsque des mises en =C5=93uvre sont n=C3=A9cessaires = avant la promotion=20 d'une sp=C3=A9cification, pour montrer l'ad=C3=A9quation de la = sp=C3=A9cification, seules=20 seront prises en compte les mises en =C5=93uvre pour lesquelles les = mesures=20 ad=C3=A9quates d'observation de ces droits ou droits revendiqu=C3=A9s = auront =C3=A9t=C3=A9 prises,=20 selon la d=C3=A9claration des d=C3=A9veloppeurs.=20
  • (B) L'IESG rejette toute responsabilit=C3=A9 visant =C3=A0 = =C3=A9tablir l'existence ou =C3=A0=20 =C3=A9valuer l'applicabilit=C3=A9 des droits d'auteur, des brevets, = des demandes de=20 brevets ou d'autres droits revendiqu=C3=A9s dans l'exercice de ses = obligations=20 selon la clause (A), et ne prendra pas position sur la validit=C3=A9 = ou la port=C3=A9e=20 de ces droits.=20
  • (C) Lorsque l'IESG a connaissance de droits ou de droits = revendiqu=C3=A9s,=20 selon la clause (A), le directeur ex=C3=A9cutif de l'IETF essaiera = d'obtenir du=20 b=C3=A9n=C3=A9ficiaire (claimant) de ces droits=20 l'assurance =C3=A9crite que, d=C3=A8s l'approbation par l'IESG de la = sp=C3=A9cification ou=20 des sp=C3=A9cifications pertinentes du circuit des standards Internet, = chaque=20 partie aura le droit de mettre en =C5=93uvre, d'utiliser et de = distribuer la=20 technologie ou les r=C3=A9alisations fond=C3=A9es sur ladite ou = lesdites sp=C3=A9cifications,=20 en des termes clairs, raisonnables et non discriminatoires. Le groupe = de=20 travail qui propose l'utilisation de la technologie par rapport =C3=A0 = laquelle des=20 droits de propri=C3=A9t=C3=A9 sont revendiqu=C3=A9s peut assister le = directeur ex=C3=A9cutif de=20 l'IETF dans cet effort. Les conclusions de cette proc=C3=A9dure = n'affecteront pas=20 la progression d'une sp=C3=A9cification le long du circuit des = standards, except=C3=A9=20 le fait que l'IESG peut retarder l'approbation si le d=C3=A9lai permet = de faciliter=20 l'obtention d'une telle assurance. Quoi qu'il en soit, les conclusions = seront=20 enregistr=C3=A9es et mises =C3=A0 disposition par le directeur = ex=C3=A9cutif de l'IETF.=20 L'IESG peut =C3=A9galement ordonner d'inclure un r=C3=A9sum=C3=A9 des = conclusions dans tout=20 RFC publi=C3=A9 contenant la sp=C3=A9cification.
10.3.3. La d=C3=A9termination des = termes raisonnables=20 et non discriminatoires

Dans la pratique, l'IESG n'effectuera aucune d=C3=A9termination = explicite de ce=20 que la promesse de termes raisonnables et non discriminatoires pour=20 l'utilisation d'une technologie est v=C3=A9rifi=C3=A9e. L'IESG recourra = plut=C3=B4t aux=20 exigences normales de promotion des standards Internet pour = v=C3=A9rifier que les=20 termes d'utilisation sont raisonnables. Si les deux mises en =C5=93uvre = ind=C3=A9pendantes=20 de la sp=C3=A9cification requises pour avancer du statut de standard = propos=C3=A9 (Proposed Standard) =C3=A0 celui de = standard=20 pr=C3=A9liminaire (Draft = Standard) ont =C3=A9t=C3=A9=20 produites par des organisations ou des personnes diff=C3=A9rentes, ou si = la=20 =C2=AB mise en =C5=93uvre significative et l'exp=C3=A9rience = d'exploitation r=C3=A9ussie =C2=BB=20 exig=C3=A9es pour avancer de standard pr=C3=A9liminaire =C3=A0 standard = (Standard) ont =C3=A9t=C3=A9 valid=C3=A9es, on = peut supposer que les=20 termes doivent =C3=AAtre raisonnables et jusqu'=C3=A0 un certain = degr=C3=A9 non=20 discriminatoires. Cette supposition peut =C3=AAtre constest=C3=A9e = pendant la p=C3=A9riode de=20 dernier appel (Last-Call).

10.4. Les mentions l=C3=A9gales

  • (A) Les documents du circuit des standards devront inclure la = mention=20 suivante :=20

    =C2=AB The IETF takes no position regarding the validity or = scope of any=20 intellectual property or other rights that might be claimed to = pertain to=20 the implementation or use of the technology described in this = document or=20 the extent to which any license under such rights might or might not = be=20 available; neither does it represent that it has made any effort to = identify=20 any such rights. Information on the IETF's procedures with respect = to rights=20 in standards-track and standards-related documentation can be found = in=20 BCP-11. Copies of claims of rights made available for publication = and any=20 assurances of licenses to be made available, or the result of an = attempt=20 made to obtain a general license or permission for the use of such=20 proprietary rights by implementors or users of this specification = can be=20 obtained from the IETF Secretariat. =C2=BB

  • (B) L'IETF invite tous les tiers int=C3=A9ress=C3=A9s =C3=A0 = porter =C3=A0 son attention, le=20 plus t=C3=B4t possible, l'existence de tous les droits de = propri=C3=A9t=C3=A9 intellectuelle=20 =C3=A9ventuels aff=C3=A9rents aux standards Internet. Dans ce but, = chaque document de=20 standard devra inclure l'invitation suivante :=20

    =C2=AB The IETF invites any interested party to bring to its = attention=20 any copyrights, patents or patent applications, or other proprietary = rights=20 which may cover technology that may be required to practice this = standard.=20 Please address the information to the IETF Executive=20 Director. =C2=BB

  • (C) La mention de droits d'auteur et la clause de = non-responsabilit=C3=A9=20 suivantes devront =C3=AAtre incluses dans tous les documents li=C3=A9s = aux standards de=20 l'ISOC :=20

    =C2=AB Copyright (C) The Internet Society (date). All Rights = Reserved.

    This document and translations of it may be copied and furnished = to=20 others, and derivative works that comment on or otherwise explain it = or=20 assist in its implmentation may be prepared, copied, published and=20 distributed, in whole or in part, without restriction of any kind, = provided=20 that the above copyright notice and this paragraph are included on = all such=20 copies and derivative works. However, this document itself may not = be=20 modified in any way, such as by removing the copyright notice or = references=20 to the Internet Society or other Internet organizations, except as = needed=20 for the purpose of developing Internet standards in which case the=20 procedures for copyrights defined in the Internet Standards process = must be=20 followed, or as required to translate it into languages other than=20 English.

    The limited permissions granted above are perpetual and will not = be=20 revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on = an "AS=20 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK = FORCE=20 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT = LIMITED TO=20 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT = INFRINGE ANY=20 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A = PARTICULAR PURPOSE. =C2=BB

  • (D) Lorsque, au moment de la publication, l'IESG a connaissance de = droits=20 de propri=C3=A9t=C3=A9s revendiqu=C3=A9s par rapport =C3=A0 un = document du circuit des standards,=20 ou =C3=A0 la technologie qui y est d=C3=A9crite ou = r=C3=A9f=C3=A9renc=C3=A9e, ce document devra=20 contenir la mention suivante :=20

    =C2=AB The IETF has been notified of intellectual property = rights claimed=20 in regard to some or all of the specification contained in this = document.=20 For more information consult the online list of claimed=20 rights. =C2=BB

11. Remerciements

Au cours des ann=C3=A9es, de nombreuses personnes ont particip=C3=A9 = au d=C3=A9veloppement=20 de ce document d=C3=A9finissant le processus de standardisation IETF. Le = processus a=20 d'abord =C3=A9t=C3=A9 d=C3=A9crit dans le RFC 1310 puis = r=C3=A9vis=C3=A9 dans le RFC 1602 avant=20 le document courant (lequel s'inspire fortement de ses = pr=C3=A9d=C3=A9cesseurs). Des=20 remerciements particuliers doivent =C3=AAtre adress=C3=A9s =C3=A0 Lyman = Chapin, Phill Gross et=20 Christian Huitema, les r=C3=A9dacteurs des versions = pr=C3=A9c=C3=A9dentes, =C3=A0 Jon Postel et Dave=20 Crocker pour leurs contributions =C3=A0 ces versions, =C3=A0 Andy = Ireland, Geoff Stewart,=20 Jim Lampert et Dick Holleman pour leurs =C3=A9tudes des aspects = l=C3=A9gaux des proc=C3=A9dures=20 qui y sont d=C3=A9crites, et =C3=A0 John Stewart, Robert Elz et Steve = Coya pour leur=20 participation =C3=A9tendue dans la version finale.

En outre, une grande partie du m=C3=A9rite de l'=C3=A9laboration des = rouages des=20 processus de l'IETF revient aux nombreux membres des diverses = incarnations du=20 groupe de travail POISED.

12. Observations sur la = s=C3=A9curit=C3=A9

Les questions de s=C3=A9curit=C3=A9 ne sont pas abord=C3=A9es dans ce = m=C3=A9moire.

13. R=C3=A9f=C3=A9rences

  1. [1] Postel, J., Internet = Official Protocol=20 Standards, STD 1, USC/Information Sciences Institute, = mars 1996.=20
  2. [2] ANSI, Coded Character Set -- 7-Bit = American=20 Standard Code for Information Interchange, ANSI X3.4-1986.=20
  3. [3] Reynolds, J., and J. Postel, = Assigned=20 Numbers, STD 2, USC/Information Sciences Institute, = octobre 1994.=20
  4. [4] Postel, J., Introduction to = the STD=20 Notes, RFC 1311, USC/Information Sciences Institute, = mars 1992.=20
  5. [5] Postel, J., Instructions to = RFC=20 Authors, RFC 1543, USC/Information Sciences Institute,=20 octobre 1993.=20
  6. [6] Huitema, C., J. Postel, and S. = Crocker=20 Not All RFCs are Standards, RFC 1796, = avril 1995.

14. D=C3=A9finitions de termes

Domaine IETF (IETF = Area) :=20
Un secteur d'administration au sein de l'IETF. Un domaine (Area) se compose des groupes de travail en = rapport avec=20 un th=C3=A8me g=C3=A9n=C3=A9ral tel que le routage. Un domaine est = dirig=C3=A9 par un ou deux=20 responsables de domaine (Area = Director).=20
Responsable de domaine (Area=20 Director) :=20
Le responsable d'un domaine IETF. Les responsables de domaines = avec le=20 pr=C3=A9sident de l'IETF (IETF = Chair)=20 constituent l'IESG (Internet = Engineering=20 Steering Group).=20
FTP (File Transfer = Protocol) :=20
Une application Internet servant =C3=A0 transf=C3=A9rer des = fichiers dans un r=C3=A9seau=20 TCP/IP.=20
gopher :=20
Une application Internet utilis=C3=A9e pour s=C3=A9lectionner et = r=C3=A9cup=C3=A9rer de fa=C3=A7on=20 interactive des fichiers dans un r=C3=A9seau TCP/IP.=20
IAB (Internet Architecture=20 Board) :=20
Un groupe d=C3=A9sign=C3=A9 (par l'Internet Society) qui aide = =C3=A0 g=C3=A9rer le processus=20 de standardisation Internet.=20
IESG (Internet Engineering = Steering=20 Group) :=20
Un groupe compos=C3=A9 des responsables de domaines IETF (Area Director) et du pr=C3=A9sident de l'IETF = (IETF Chair). L'IESG est charg=C3=A9, avec = l'IAB, de=20 l'administration de l'IETF et constitue le conseil d'approbation des = standards=20 de l'IETF.=20
interop=C3=A9rable :=20
Pour les besoins de ce document, le terme = =C2=AB interop=C3=A9rable =C2=BB=20 signifie =C3=AAtre capable de fonctionner en environnement = h=C3=A9t=C3=A9rog=C3=A8ne =C3=A0 travers un=20 canal de communication de donn=C3=A9es.=20
dernier appel (Last-Call) :=20
Une p=C3=A9riode r=C3=A9serv=C3=A9e aux commentaires du public = servant =C3=A0 =C3=A9valuer le degr=C3=A9=20 de consensus autour de la justesse d'une action de standardisation = propos=C3=A9e=20 (cf. la section 6.1.2).=20
en ligne :=20
Se rapporte =C3=A0 une information mise =C3=A0 disposition sur = l'Internet. Dans le=20 contexte de ce document, une ressource est dite en ligne lorsqu'elle = est=20 r=C3=A9cup=C3=A9rable sans restriction ni contrepartie indue en = utilisant des=20 applications Internet standards telles que FTP anonyme, gopher ou le = web.=20
groupe de travail (Working=20 Group) :=20
Un groupe nomm=C3=A9 par l'IESG et l'IAB afin de travailler sur = une=20 sp=C3=A9cification, un ensemble de sp=C3=A9cifications ou un = th=C3=A8me particuliers.

15. Coordonn=C3=A9es de l'auteur

Scott O. Bradner
Harvard University
Holyoke Center, Room=20 813
1350 Mass. Ave.
Cambridge, MA 02138
USA

Phone: +1 = 617 495=20 3864
EMail: sob@harvard.edu

Annexe A : Glossaire des = abr=C3=A9viations

ANSI=20
American National Standards Institute=20
ARPA=20
Advanced Research Projects Agency (=C3=89.-U.)=20
AS=20
Applicability Statement=20
FTP=20
File Transfer Protocol=20
ASCII=20
American Standard Code for Information Interchange=20
ITU-T=20
Telecommunications Standardization sector of the International=20 Telecommunication Union (ITU), une organisation du trait=C3=A9 des = Nations-Unies.=20 L'ancienne appellation de l'ITU-T =C3=A9tait CCITT.=20
IAB=20
Internet Architecture Board=20
IANA=20
Internet Assigned Numbers Authority=20
IEEE=20
Institute of Electrical and Electronics Engineers=20
ICMP=20
Internet Control Message Protocol=20
IESG=20
Internet Engineering Steering Group=20
IETF=20
Internet Engineering Task Force=20
IP=20
Internet Protocol=20
IRSG=20
Internet Research Steering Group=20
IRTF=20
Internet Research Task Force=20
ISO=20
International Organization for Standardization=20
ISOC=20
Internet Society=20
MIB=20
Management Information Base=20
OSI=20
Open Systems Interconnection=20
RFC=20
Request for Comments=20
TCP=20
Transmission Control Protocol=20
TS=20
Technical Specification=20
WWW=20
World Wide Web