6. IANA Considerations

Cette section fournit des directives à l'Internet Assigned Numbers Authority (IANA) concernant l'enregistrement de valeurs relatives au protocole EAP, conformément à la BCP 26, [RFC2434].

Il existe deux espaces de noms dans EAP qui requièrent un enregistrement : les codes de paquet (Packet Codes) et les types de méthode (Method Types).

EAP n'est pas destiné à être un protocole à usage général, et les allocations NE DEVRAIENT PAS être faites à des fins non liées à l'authentification.

Les termes suivants sont utilisés ici avec les significations définies dans la BCP 26 : « espace de noms », « valeur assignée », « enregistrement ».

Les politiques suivantes sont utilisées ici avec les significations définies dans la BCP 26 : « Usage privé » (Private Use), « Premier arrivé, premier servi » (First Come First Served), « Revue par un expert » (Expert Review), « Spécification requise » (Specification Required), « Consensus IETF » (IETF Consensus), « Action de normalisation » (Standards Action).

Pour les demandes d'enregistrement où un Expert Désigné doit être consulté, le directeur d'aire IESG responsable doit nommer l'Expert Désigné. L'intention est que toute allocation soit accompagnée d'un RFC publié. Mais afin de permettre l'allocation de valeurs avant que le RFC ne soit approuvé pour publication, l'Expert Désigné peut approuver des allocations dès qu'il apparaît clair qu'un RFC sera publié. L'Expert Désigné publiera une demande sur la liste de diffusion du groupe de travail EAP (ou un successeur désigné par le directeur d'aire) pour commentaire et revue, incluant un Internet-Draft. Avant qu'une période de 30 jours ne se soit écoulée, l'Expert Désigné approuvera ou rejettera la demande d'enregistrement et publiera un avis de décision à la liste de diffusion du groupe de travail EAP ou à son successeur, tout en informant l'IANA. Un avis de rejet doit être justifié par une explication, et, dans les cas où c'est possible, des suggestions concrètes sur la façon dont la demande peut être modifiée pour devenir acceptable doivent être fournies.

6.1. Codes de paquet (Packet Codes)

Les codes de paquet ont une plage de 1 à 255, dont 1-4 ont été alloués. Parce qu'un nouveau code de paquet a un impact considérable sur l'interopérabilité, un nouveau code de paquet requiert une Action de normalisation (Standards Action), et devrait être alloué à partir de 5.

6.2. Types de méthode (Method Types)

L'espace de types de méthode EAP original a une plage de 1 à 255, et est la ressource la plus rare dans EAP, et doit donc être alloué avec précaution. Les types de méthode 1-45 ont été alloués, dont 20 disponibles pour réutilisation. Les types de méthode 20 et 46-191 peuvent être alloués sur les conseils d'un Expert Désigné, avec Spécification requise (Specification Required).

L'allocation de blocs de types de méthode (plus d'un pour un objectif donné) devrait requérir un Consensus IETF (IETF Consensus). Les valeurs de type EAP 192-253 sont réservées et l'allocation requiert une Action de normalisation (Standards Action).

Le type de méthode 254 est alloué pour le Type étendu (Expanded Type). Lorsque le champ Vendor-Id est non nul, le Type étendu est utilisé pour des fonctions spécifiques à l'implémentation EAP d'un seul fournisseur, où aucune interopérabilité n'est jugée utile. Lorsqu'il est utilisé avec un Vendor-Id de zéro, le type de méthode 254 peut également être utilisé pour fournir un espace de type de méthode IETF étendu. Les valeurs de type de méthode 256-4294967295 peuvent être allouées après que les valeurs de type 1-191 ont été allouées, sur les conseils d'un Expert Désigné, avec Spécification requise (Specification Required).

Le type de méthode 255 est alloué pour un usage expérimental, tel que le test de nouvelles méthodes EAP avant qu'un type permanent ne soit alloué.