Mon blog

Le processus de production des normes par l'IETF suit de nombreuses étapes, toutes se déroulant en public. Il est en effet essentiel que de nombreux yeux puissent regarder les documents en voie de devenir des RFC. Et que de nombreux examens (reviews) aient lieu. Pour suivre ces examens, il est préférable de disposer d'outils et ce sont les futurs outils à développer que décrit ce RFC.

Parmi les équipes qui effectuent des examens des Internet-Drafts en cours d'avancement figurent Gen-ART et SecDir. Mais il en existe plusieurs autres, parfois très spécialisées, et qui n'examinent que les documents relevant de leur spécialité (par exemple les MIB par les MIB doctors ou bien les schémas YANG par les YANG doctors).

Les équipes en question doivent se tenir au courant des documents en cours, leur affecter un examinateur parmi ceux qui sont enregistrés pour cette tâche, fixer une date limite et relancer l'examinateur s'il est en retard, etc. Cela serait évidemment très pénible à faire à la main et ces équipes utilisent actuellement un outil, développé il y a longtemps. Du fait de son âge, il n'est pas bien intégré avec le principal outil de travail en groupe de l'IETF, le Datatracker. Par exemple, pour obtenir certaines informations, l'outil analyse des pages HTML du Datatracker :-) .

[Au passage, notez que le Datatracker est vraiment un excellent outil, qui facilite beaucoup la vie du participant à l'IETF. On voudrait tous avoir des outils de travail en groupe équivalents au bureau.]

Une meilleure intégration avec le Datatracker permettrait de simplifier l'accès à ces informations, et à d'autres qui ne sont pas utilisées actuellement, car trop pénibles à extraire. Ce nouveau RFC est le cahier des charges du futur outil (voir aussi le système de gestion de tickets de l'outil actuel).

Pour comprendre ce cahier des charges, il est utile de revenir sur l'utilisation actuelle de l'outil des examens (section 2 du RFC). Typiquement, l'équipe a un secrétariat qui, une fois par semaine environ, dresse une liste des documents qui sont prêts à subir un examen, par exemple parce qu'ils sont en IETF Last Call (dernier appel avant approbation) ou parce qu'ils sont sur l'agenda des réunions (virtuelles) de l'IESG.

Le secrétariat prend ensuite un examinateur parmi la liste des examinateurs possibles, en tenant compte de paramètres comme le fait qu'un auteur ne doit évidemment pas être examinateur de son propre Internet-Draft. L'idée est en général de prendre un examinateur qui a un regard neuf et n'a pas été impliqué dans le développement du document.

Les différentes équipes d'examen n'ont pas toutes le même fonctionnement. Certaines, comme indiqué plus haut, s'« auto-saisissent » alors que d'autres sont plutôt en mode « on examine si on nous le demande » (c'est le cas de l'équipe du routage, par exemple).

Les examinateurs eux-même n'utilisent pas en général l'outil directement : ils communiquent par courrier avec le secrétariat. Et c'est par courrier qu'ils envoient le résultat de leur examen, après avoir rempli un « courrier-type ». Voici par exemple l'examen fait par Gen-ART pour le futur RFC sur la QNAME minimisation ou bien celui de RTG-Dir pour un futur protocole d'HomeNet.

Voici donc le fonctionnement actuel. Pour le futur outil, les exigences sont dans la section 3 de notre RFC. D'abord, ce qui intéresse le secrétariat de l'IETF (section 3.1) :

• Le secrétariat doit pouvoir configurer une équipe,
• Et doit pouvoir effectuer toute action à la place du secrétariat de l'équipe (en cas de défaillance de celui-ci).

Plus importantes, les exigences pour le secrétariat de l'équipe d'examen (section 3.2), entre autres :

• Pouvoir voir quels documents sont dans un état donné (par exemple IETF Last Call),
• Possibilité de sélectionner les documents à examiner, soit automatiquement (« tous ceux qui sont sur l'agenda de l'IESG »), soit manuellement (ajouter explicitement un document intéressant),
• Permettre les accès concurrents à l'outil (une équipe peut avoir plusieurs secrétaires),
• Faciliter l'envoi des courriers, par exemple en remplissant automatiquement un gabarit, puis en permettant au secrétaire de faire des modifications, avant envoi,
• Pouvoir voir les examinateurs libres,
• Capacité à gérer les disponibilités des examinateurs (par exemple, on doit pouvoir indiquer « Machin ne sera pas libre avant le 2 février » et il ne doit alors pas être présenté dans la liste des examinateurs potentiels),
• Gérer automatiquement l'exclusion des examinateurs de certains documents. L'outil actuel utilise une expression rationnelle. M. Michu, examinateur qui est très investi dans le groupe de travail DPRIVE, aura une expression d'exclusion pour les documents nommés ^draft-(michu|ietf-dprive).*, l'excluant de ses drafts et de ceux de DPRIVE,
• Permettre le suivi des examens (certains examinateurs sont très occupés, peuvent « oublier » leur tâche, etc),
• Par la même occasion, l'outil doit permettre de suivre les « performances » des examinateurs (afficher le retard moyen...) de manière à détecter les « maillons faibles »,
• Autoriser le changement d'examinateur, l'ajout d'un examinateur...

Et pour l'examinateur lui-même, que doit savoir faire l'outil (section 3.3) ? Par exemple :

• Il doit permettre à l'examinateur d'indiquer ses disponibilités, à la fois en dates (« en vacances tout le mois d'août ») et en fréquence (« pas plus d'un examen de document par trimestre »), avec notification du secrétariat par courrier,
• L'examinateur doit avoir accès aux documents qui lui sont affectés, avec leur état, pour suivre son propre travail,
• Possibilité de rejeter une affectation, avec explication optionnelle (et, là aussi, notification du secrétariat),
• De même, l'examinateur doit pouvoir indiquer explicitement qu'il accepte une affectation,
• Rappels automatiques (« il te reste 24 h pour ton examen du draft draft-ietf-cuterabbit-security-analysis-09.txt »),
• Et bien sûr, puisque c'est le but de l'examen, l'examinateur doit pouvoir soumettre facilement le texte final, par un formulaire Web ou en téléversant un fichier, le texte étant alors automatiquement envoyé aux auteurs et au groupe de travail concerné,
• Et cette soumission doit aussi être possible par courrier, pour les examinateurs qui sont allergiques au Web (c'est possible avec les bons outils de gestion de tâche, comme RT).

Comme tout le monde aime les statistiques, et qu'il est bon de pouvoir évaluer si une équipe d'examen marche bien ou pas, l'outil devra également fournir des chiffres (section 3.5) :

• Pour une période donnée, indiquer combien d'examens ont été faits, combien sont en cours, combien ont été en retard et de combien, le temps moyen d'examen,
• Mêmes résultats, mais pour un examinateur donné,
• Ces chiffres doivent pouvoir être pondérés par des caractéristiques du document (notamment sa taille, mesurée en nombre de signes),
• Et, autant que possible, ces statistiques, par exemple le nombre d'examens faits par un examinateur par an devraient pouvoir tenir compte des périodes d'indisponibilité,
• Et si l'outil pouvait faire des jolis graphes avec les séries temporelles, ce serait encore mieux,
• L'accès à ces chiffres doit être limité : le secrétariat d'une équipe peut tout voir pour son équipe, un examinateur peut voir ses résultats, ou bien les résultats globaux de son équipe,

Les outils actuels de l'IETF sont écrits en Django. Pour rendre ce cahier des charges plus concret, l'annexe A fournit un modèle Django tout prêt. Par exemple, l'état d'un examen peut être :

 class ReviewRequestStateName(NameModel):
     """ Requested, Accepted, Rejected, Withdrawn, Overtaken By Events,
         No Response , Completed  """
      

Un examinateur est ainsi modélisé :

class Reviewer(models.Model):
     """
     These records associate reviewers with review team, and keeps track
     of admin data associated with the reviewer in the particular team.
     There will be one record for each combination of reviewer and team.
     """
     role        = models.ForeignKey(Role)
     frequency   = models.IntegerField(help_text=
                                   "Can review every N days")
     available   = models.DateTimeField(blank=True,null=True, help_text=
                         "When will this reviewer be available again")
     filter_re   = models.CharField(blank=True)
     skip_next   = models.IntegerField(help_text=
                          "Skip the next N review assignments")
      

Et une demande d'examen est :

 class ReviewRequest(models.Model):
     """
     There should be one ReviewRequest entered for each combination of
     document, rev, and reviewer.
     """
     # Fields filled in on the initial record creation:
     time          = models.DateTimeField(auto_now_add=True)
     type          = models.ReviewTypeName()
     doc           = models.ForeignKey(Document,
                            related_name='review_request_set')
     team          = models.ForeignKey(Group)
     deadline      = models.DateTimeField()
     requested_rev = models.CharField(verbose_name="requested_revision",
                             max_length=16, blank=True)
     state         = models.ForeignKey(ReviewRequestStateName)
     # Fields filled in as reviewer is assigned, and as the review
     # is uploaded
     reviewer      = models.ForeignKey(Reviewer, null=True, blank=True)
     review        = models.OneToOneField(Document, null=True,
                                                    blank=True)
     reviewed_rev  = models.CharField(verbose_name="reviewed_revision",
                                      max_length=16, blank=True)
     result        = models.ForeignKey(ReviewResultName)
      

Vous avez envie de réaliser cet outil ? L'annonce a été publiée le 28 décembre 2015 et vous avez jusqu'au 18 janvier 2016 pour proposer vos services.