Mon blog

Écrire un protocole réseau n'est pas facile. La description doit être suffisamment rigoureuse pour qu'elle puisse être mise en œuvre sans ambiguïté et elle doit être suffisamment lisible pour être compréhensible par le lecteur pressé. Les implémenteurs des protocoles préfèrent la précision et l'exactitude, les simples lecteurs, par exemple ceux qui relisent le protocole avant sa publication, préfèrent un texte plus littéraire et de plus haut niveau. Ce RFC, publié par l'IAB, estime que les normes IETF, publiées dans les RFC, sont allées trop loin vers les besoins des seuls implémenteurs et que les RFC récents manquent d'un modèle, d'une description de haut niveau du protocole.

Les normes écrites par l'IETF et publiées dans les RFC sont toutes soumises à un examen public, avant leur officialisation. Relire des projets de RFC, comme l'explique la section 1, n'est pas une tâche facile. Si les RFC d'autrefois étaient courts et souvent écrits de manière assez littéraire, les RFC modernes sont bien plus longs, souvent écrits par plusieurs personnes et le style s'en ressent. Plus corrects dans leur description du protocole, ils sont bien plus difficiles à lire. Si on doit programmer le protocole en question, on doit lire tout le RFC de toute façon. Mais si on veut juste faire une analyse du document, il est pénible de « rétro-ingénierer » les concepts à partir du texte.

La section 2 explique donc qu'il faudrait, dans chaque RFC qui normalise un protocole, un modèle, qui décrive le protocole à un niveau plus élevé et qui permette de répondre à trois questions :

• Quel problème le protocole tente t-il de résoudre ?
• Quels messages sont transmis et quelle est leur signification ?
• Quelles sont les caractéristiques importantes du protocole ?

Le modèle doit se fonder sur les caractéristiques essentielles du protocoles. Par exemple, le fait que Kerberos (RFC 1510) utilise un système KDC (Key Distribution Center) est essentiel mais le fait que la syntaxe soit décrite en ASN.1 est un détail, les S-expressions auraient aussi bien convenu.

La section 3 décrit ensuite en quoi consiste un modèle. Le principe essentiel est que le modèle est plus court que le protocole complet. C'est une carte, pas un territoire. Il va donc abstraire le protocole et n'en garder que ce qui est essentiel.

La section 4 parle ensuite de l'écriture concrète de ces modèles. Elle recommande une approche très graphique, avec « des boîtes et des flèches » (même si la section 5 note que l'obligation de publier les RFC uniquement en texte brut en ASCII ne facilite pas les choses ; j'en profite pour signaler l'excellent outil Graph::Easy, pour générer des diagrammes en art ASCII à partir d'une description de haut niveau).

D'abord (section 4.1), le modèle doit décrire le problème qu'on essaie de résoudre. L'exemple que donne notre RFC est celui de STUN (RFC 3489), qui ne contient pas cette description. Notre RFC 4101 en propose donc une, avec un diagramme des différents composants des entités qui tentent de communiquer malgré le NAT et de leurs échanges.

Ensuite (section 4.2), le modèle doit donner une vue générale du protocole. L'exemple est pris dans le protocole DCCP (RFC 4340) dont RFC 4101 propose une telle vue de DCCP.

Enfin (section 4.3), le modèle doit pointer du doigt les caractéristiques importantes du protocole, surtout si elles ne sont pas évidentes à première vue. Ainsi, dans l'exemple de WebDAV, RFC 4918, contrairement à ce qu'on pourrait croire en lisant rapidement le RFC sur WebDAV, notre RFC 4101 montre qu'une discussion détaillée de la différence entre un renommage d'une ressource (commande MOVE de WebDAV) et sa copie suivie de la destruction de l'original (commandes COPY et DELETE de WebDAV) ne sont pas équivalents (mais le RFC sur WebDAV décrivant chaque commande séparément, ce n'est pas évident à voir).

La section 6 du RFC synthétise toutes ses recommandations en fournissant un exemple d'un modèle complet pour le protocole IKE (RFC 4306), l'un des plus complexes de l'IETF.

Si les auteurs de RFC suivent ces recommandations, les RFC deviendront encore plus lisibles et accessibles.