5. Designated Experts (Experts désignés)

5.1. The Motivation for Designated Experts (La motivation pour les experts désignés)

Les discussions sur une liste de diffusion peuvent fournir des retours techniques précieux, mais les opinions varient souvent et les discussions peuvent se poursuivre pendant un certain temps sans résolution claire. De plus, l'IANA ne peut pas participer à toutes ces listes de diffusion et ne peut pas déterminer si ou quand de telles discussions atteignent un consensus. Par conséquent, l'IANA s'appuie sur un "expert désigné" (designated expert) pour obtenir des conseils concernant la question spécifique de savoir si une attribution doit être effectuée. L'expert désigné est une personne responsable de réaliser une évaluation appropriée et de retourner une recommandation à l'IANA.

Il convient de noter qu'une motivation clé pour avoir des experts désignés est que l'IETF fournisse à l'IANA un expert en la matière (subject matter expert) à qui le processus d'évaluation peut être délégué. L'IANA transmet les demandes d'attribution à l'expert pour évaluation, et l'expert (après avoir effectué l'évaluation) informe l'IANA s'il faut ou non effectuer l'attribution ou l'enregistrement. Dans la plupart des cas, les demandeurs ne travaillent pas directement avec les experts désignés. La liste des experts désignés pour un registre est répertoriée dans le registre.

Il sera souvent utile d'utiliser un expert désigné seulement une partie du temps, en complément d'autres processus. Pour plus de discussion sur ce sujet, voir la Section 4.12.

5.2. The Role of the Designated Expert (Le rôle de l'expert désigné)

L'expert désigné est responsable de coordonner l'examen approprié d'une demande d'attribution. L'examen peut être large ou étroit, selon la situation et le jugement de l'expert désigné. Cela peut impliquer une consultation avec un ensemble d'experts techniques, une discussion sur une liste de diffusion publique, une consultation avec un groupe de travail (ou sa liste de diffusion si le groupe de travail a été dissous), etc. Idéalement, l'expert désigné suit des critères d'examen spécifiques tels que documentés avec le protocole qui crée ou utilise l'espace de noms. Voir les sections IANA Considerations de [RFC3748] et [RFC3575] pour des exemples spécifiques.

Les experts désignés sont censés être capables de défendre leurs décisions auprès de la communauté IETF, et le processus d'évaluation n'est pas destiné à être secret ou à conférer un pouvoir incontesté à l'expert. Les experts sont censés appliquer les procédures d'examen ou de vérification documentées applicables, ou en l'absence de critères documentés, suivre les normes généralement acceptées telles que celles de la Section 5.3. Les experts désignés ne sont généralement pas censés être des "gardiens" (gatekeepers), cherchant à rendre difficile l'obtention d'enregistrements, à moins que les directives du document de définition ne spécifient qu'ils doivent agir en tant que tels. En l'absence de directives plus strictes, les experts devraient évaluer les demandes d'enregistrement pour leur complétude, leur interopérabilité et les conflits avec les protocoles et options existants.

Il s'est avéré utile d'avoir plusieurs experts désignés pour certains registres. Parfois, ces experts travaillent ensemble pour évaluer une demande, tandis que dans d'autres cas, des experts supplémentaires servent de remplaçants, n'agissant que lorsque l'expert principal n'est pas disponible. Dans les registres avec un pool d'experts, le pool a souvent un seul président responsable de définir comment les demandes doivent être attribuées aux experts et examinées par eux. Dans d'autres cas, l'IANA peut attribuer des demandes à des membres individuels dans un ordre séquentiel ou approximativement aléatoire. Le document définissant le registre peut, s'il est approprié pour la situation, spécifier comment le groupe doit fonctionner -- par exemple, il pourrait être approprié de spécifier un consensus approximatif (rough consensus) sur une liste de diffusion, au sein d'un groupe de travail connexe ou parmi un pool d'experts désignés.

En cas de désaccord entre plusieurs experts, il incombe à ces experts de faire une seule recommandation claire à l'IANA. Il n'est pas approprié que l'IANA résolve les différends entre experts. Dans des situations extrêmes, telles qu'une impasse, l'organisme désignant peut avoir besoin d'intervenir pour résoudre le problème.

Si un expert désigné a un conflit d'intérêts pour un examen particulier (est, par exemple, un auteur ou un partisan important d'une spécification liée à l'enregistrement en cours d'examen), cet expert devrait se récuser. Dans le cas où tous les experts désignés sont en conflit, ils devraient demander qu'un expert temporaire soit désigné pour l'examen conflictuel. Le directeur de zone (AD) responsable peut alors nommer quelqu'un ou le directeur de zone peut gérer l'examen.

Ce document définit le mécanisme d'expert désigné uniquement par rapport aux documents du flux IETF (IETF stream). Si d'autres flux souhaitent utiliser des politiques d'enregistrement nécessitant des experts désignés, il appartient à ces flux (ou à ces documents) de spécifier comment ces experts désignés sont nommés et gérés. Ce qui est décrit ci-dessous, avec la gestion par l'IESG, n'est approprié que pour le flux IETF.

5.2.1. Managing Designated Experts in the IETF (Gestion des experts désignés à l'IETF)

Les experts désignés pour les registres créés par l'IETF sont nommés par l'IESG, normalement sur recommandation du directeur de zone (Area Director) concerné. Ils peuvent être nommés au moment où un document créant ou mettant à jour un espace de noms est approuvé par l'IESG, ou ultérieurement, lorsque la première demande d'enregistrement est reçue. Parce que les experts initialement nommés peuvent devenir indisponibles plus tard, l'IESG nommera des remplaçants si nécessaire. L'IESG peut retirer tout expert désigné qu'il a nommé, à sa discrétion.

Le processus d'appel normal, tel que décrit dans [RFC2026], Section 6.5.1, s'applique aux problèmes qui se posent avec l'équipe d'experts désignés. À cette fin, l'équipe d'experts désignés prend la place du groupe de travail dans cette description.

5.3. Designated Expert Reviews (Examens des experts désignés)

Au cours des années depuis la publication et l'utilisation de [RFC2434], l'expérience a conduit aux observations suivantes:

Un expert désigné doit répondre en temps opportun, normalement dans un délai d'une semaine pour les demandes simples à quelques semaines pour les plus complexes. Des retards déraisonnables peuvent causer des problèmes importants pour ceux qui ont besoin d'attributions, par exemple lorsque des produits ont besoin de points de code (code points) pour être expédiés. Cela ne veut pas dire que tous les examens peuvent être terminés dans un délai strict, mais ils doivent être commencés, et le demandeur et l'IANA devraient avoir une certaine transparence dans le processus si une réponse ne peut pas être donnée rapidement.
Si un expert désigné ne répond pas aux demandes de l'IANA dans un délai raisonnable, soit avec une réponse, soit avec une explication raisonnable du retard (certaines demandes peuvent être particulièrement complexes), et si cela devient un événement récurrent, l'IANA doit soulever le problème auprès de l'IESG. En raison des problèmes causés par les évaluations et les attributions retardées, l'IESG devrait prendre les mesures appropriées pour s'assurer que l'expert comprend et accepte ses responsabilités, ou nommer un nouvel expert.
L'expert désigné n'est pas tenu de supporter personnellement la charge d'évaluer et de décider de toutes les demandes, mais agit comme un berger (shepherd) pour la demande, sollicitant l'aide d'autres personnes si nécessaire. Dans le cas où une demande est refusée et que le rejet de la demande est susceptible d'être controversé, l'expert devrait avoir le soutien d'autres experts en la matière. C'est-à-dire que l'expert doit être capable de défendre une décision auprès de la communauté dans son ensemble.

Lorsqu'un expert désigné est utilisé, la documentation devrait fournir des directives claires à l'expert désigné, définissant les critères pour effectuer une évaluation et les raisons de rejeter une demande. Dans le cas où il n'y a pas de critères spécifiques documentés, la présomption devrait être qu'un point de code devrait être accordé à moins qu'il n'y ait une raison impérieuse du contraire (et voir également la Section 5.4). Les raisons qui ont été utilisées pour refuser des demandes incluent:

Rareté des points de code, où les points de code restants limités devraient être gérés prudemment, ou où une demande pour un grand nombre de points de code est faite alors qu'un seul point de code est la norme.
La documentation n'est pas suffisamment claire pour évaluer ou assurer l'interopérabilité.
Le point de code est nécessaire pour une extension de protocole, mais l'extension n'est pas cohérente avec l'architecture documentée (ou généralement comprise) du protocole de base étendu et serait nuisible au protocole si elle était largement déployée. L'intention n'est pas que les "incohérences" fassent référence à des différences mineures "de nature de préférence personnelle". Au lieu de cela, elles se réfèrent à des différences significatives telles que des incohérences avec le modèle de sécurité sous-jacent, impliquant un changement de la sémantique d'un type de message ou d'une opération existante, nécessitant des changements injustifiés dans les systèmes déployés (par rapport à d'autres moyens d'obtenir un résultat similaire), etc.
L'extension causerait des problèmes avec les systèmes déployés existants.
L'extension entrerait en conflit avec une extension en cours de développement actif par l'IETF, et avoir les deux nuirait plutôt que de favoriser l'interopérabilité.

Les documents ne doivent pas nommer le ou les experts désignés dans le document lui-même; au lieu de cela, tous les noms suggérés doivent être transmis au directeur de zone approprié au moment où le document est envoyé à l'IESG pour approbation. Cela se fait généralement dans le document shepherd writeup.

Si la demande doit également être examinée sur une liste de diffusion publique spécifique, son adresse doit être spécifiée.

5.4. Expert Reviews and the Document Lifecycle (Examens d'experts et cycle de vie des documents)

L'examen par l'expert désigné se fait nécessairement à un moment donné et représente l'examen d'une version particulière du document. Bien que les examens soient généralement effectués autour du moment de l'IETF Last Call, décider quand l'examen doit avoir lieu est une question de bon jugement. Et bien que des réexamens puissent être effectués lorsqu'il est reconnu que la documentation de l'élément enregistré a changé de manière substantielle, s'assurer que le réexamen se produise nécessite attention et soin.

Il est possible, par négligence, accident, inattention ou même mépris délibéré, que des modifications soient apportées après l'examen et l'approbation de l'expert désigné qui, si le document était réexaminé, amèneraient l'expert à ne pas approuver l'enregistrement. Il incombe à l'IESG, avec le jeton détenu par le directeur de zone responsable, d'être attentif à de telles situations et de reconnaître que de tels changements doivent être vérifiés.

Pour les enregistrements effectués à partir de documents sur la voie des normes (Standards Track), il y a souvent un examen d'expert requis (par la politique d'enregistrement) en plus du consensus IETF (pour l'approbation en tant que RFC sur la voie des normes). Dans de tels cas, l'examen par l'expert désigné doit être opportun, soumis avant que l'IESG n'évalue le document. L'IESG ne devrait généralement pas retarder le document en attendant un examen tardif. Il n'est pas non plus prévu que l'examen d'expert annule le consensus IETF: l'IESG devrait considérer l'examen dans sa propre évaluation, comme il le ferait pour d'autres examens de Last Call.