\include{parameters}
\usetheme{AFNIC}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{bortzmeyer-utils}

\title{Développement de protocoles à l'IETF ; les RFC}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{8 juillet 2009}

%\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} 
% \setlength{\parskip}{15pt} 
\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}[fragile]
 Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License \url{http://www.gnu.org/licenses/licenses.html#FDL}, Version 1.2
      or any later version published by the Free Software Foundation;
      with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.  
\end{frame}

\begin{frame}
\frametitle{Le monde merveilleux de la normalisation}
\begin{itemize}
\item W3C
\item OASIS
\item ISO (et ANSI et AFNOR)
\item IEEE
\only<1>{\item IEC
\item ECMA
\item ETSI}
\item ITU
\item IETF\ldots
\end{itemize}
\only<2->{Ces SDO sont très différentes en rapidité,
      ouverture, formalisme, statut, elles se distinguent aussi par
      leur périmètre d'activité\ldots}

\end{frame}

\begin{frame}[fragile]
\frametitle{Mon standard est plus ouvert que le tien}
\only<1-2>{Tout le monde sait ce qu'est un logiciel libre.}

\only<2->{Et une norme ouverte ? PDF, C\#, MP3, MPEG4, 3G, SQL, ouverts ?}

\only<3->{Critères possibles :}
\begin{itemize}
\item<4->Texte librement disponible
\item<5->Implémentable sans problème
\item<6->Déjà mis en \oe{}uvre en logiciel libre
\item<7->Développement et évolution de la norme de manière ouverte 
\end{itemize}
\only<8->{Mais il n'y a pas encore de consensus.}
\end{frame}

\begin{frame}
\frametitle{IETF}
\begin{block}
{Internet Engineering Task Force}
{Responsable de la plupart des protocoles Internet dans les couches 3
à 4 (« TCP/IP »). Également active dans la couche 7.}
\end{block}
\url{http://www.ietf.org/}
\end{frame}

\begin{frame}
\frametitle{RFC}
Le produit de l'activité de l'IETF : les \foreign{Request For
Comments}. 

\only<2>{Quelques exemples :\begin{itemize}
\item RFC 1 : logiciel des machines non-routeuses (à l'époque où les
adresses étaient sur 5 bits)
\item RFC 791 : IPv4
\item RFC 1034/1035 : DNS
\item RFC 1149 : IP sur pigeons voyageurs
\item RFC 3031 : MPLS
\item RFC 5585 : vue générale du protocole de signature du courrier DKIM (le
dernier RFC paru à ce jour).
\end{itemize}}

\only<3->{Distribués librement et redistribuables, lisibles, ils sont un des
principaux facteurs du succès de TCP/IP.}
\end{frame}

\begin{frame}
\frametitle{Les RFC ne sont pas toujours des normes}
Les RFC ont un statut, « \emph{chemin des normes} », mais aussi « pour
information », « expérimental », etc.

Sur le chemin des normes, il y a trois étapes : proposition, projet et
norme. L'avancement n'est pas automatique et dépend du travail de
volontaires intéressés.

Les RFC sont écrits (pour la plupart) par l'IETF mais publiés par le
\foreign{RFC editor}.

\end{frame}

\begin{frame}
\frametitle{Licence des RFC}
RFC 5377 et 5378
\begin{itemize}
\item<2->Librement distribuable et traduisible
\item<3->Librement implémentable (sauf brevets)
\item<4->\emph{Non} modifiable. Plus exactement, seul le \emph{code}
est modifiable (ce qui permet son intégration dans les logiciels
libres) pas le texte (la séparation est une nouveauté du RFC 5377,
avant rien n'était modifiable).
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Bureaucratie}
\only<2-4>{L'IETF n'existe pas.}

\only<2->{Aucune personne morale ne porte ce nom. L'IETF est une
étiquette, posée sur une activité de l'ISOC.}

\only<3->{Tout le monde peut adhérer, puisqu'il n'y a pas
d'adhésion. Je suis donc \emph{membre de l'IETF}.}

\only<4->{L'administration est assurée par le Secrétariat, supervisé
par l'IAOC. Contrairement au W3C, il n'y a pas de permanents.}

\only<5->{La propriété intellectuelle est gérée par l'\foreign{IETF
trust}, organisme ISOC/CNRI.}

\end{frame}

\begin{frame}
\frametitle{Structuration}
Le travail est découpé en \emph{secteurs} (\foreign{areas}).

Exemples : Secteur Routage, Secteur Sécurité, Secteur
Applications\ldots

Chaque secteur a deux directeurs.

Les directeurs forment l'IESG, qui supervise le travail technique.

\end{frame}

\begin{frame}
\frametitle{Les groupes de travail}

Chaque secteur est à son tour découpé en \emph{groupes de travail}
(\foreign{WG, Working Group}). C'est là que sont développés les
protocoles.

\only<1>{La création d'un groupe est souvent précédée d'une BoF (session
informelle) et est approuvée par l'IESG.

Chaque groupe a deux présidents.}

\only<2>{Par exemple, le secteur Applications comporte, entre autres :

\begin{itemize}
\item le groupe LTRU (\foreign{Language Tag Registry Update}), étiquettes
de langue)
\item le groupe SIEVE (langage de filtrage du courrier Sieve)
\item le groupe HTTPBIS (révision du protocole HTTP 1.1)
\end{itemize}
}

\only<3->{Les groupes ont une durée de vie limitée, bornée par les
jalons inscrits dans
leur charte.}
\end{frame}


\begin{frame}
\frametitle{L'IAB}

L'IESG travaille au quotidien, à superviser la production de normes.

L'\foreign{Internet Architecture Board} (IAB) regarde de haut et
essaie de voir loin.

C'est l'IAB qui impulse les grands travaux et écrit les RFC solennels
comme le 4924 sur la \emph{neutralité du réseau}.
\end{frame}

\begin{frame}
\frametitle{Fonctionnement}
Un groupe de travail, c'est surtout une liste de diffusion. Le travail
se fait là.

Les documents commencent leur vie comme \foreign{Internet-Draft}. Tout
le monde peut en écrire un.

L'I-D a plusieurs versions, avec un numéro qui augmente (par exemple
\path{draft-ietf-simple-xml-patch-ops-04}).

Après beaucoup de discussions, l'I-D peut être
\emph{adopté} par le groupe, ou bien rester document
\emph{individuel}.
\end{frame}

\begin{frame}
\frametitle{Fonctionnement, suite}
Après un \foreign{working group last call}, le document passe à
l'IESG, qui peut faire un \foreign{IETF-wide last call}.

Une fois approuvé par l'IESG, il est envoyé au \foreign{RFC editor}
pour publication.

\begin{block}
{Il n'y a pas de vote}
{\foreign{We reject presidents, kings and voting. We believe in rough consensus and running code.}}
\end{block}

\end{frame}

\begin{frame}
\frametitle{Les outils de travail}
\begin{itemize}	
\item Les listes de diffusion (publiques et archivées)
\item Les réunions physiques (en théorie facultatives)
\item Un peu d'IM 
\item \url{http://tools.ietf.org/}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les exemples de groupes}
Quelques activités intéressantes\ldots
\end{frame}

\begin{frame}
\frametitle{NCP}
\only<-3>{Problème : le DNS permet l'échange de \emph{données} entre les
serveurs de noms d'un domaine mais pas l'échange de
\emph{configuration}. Si je crée un nouveau domaine, je dois le
configurer sur tous les serveurs faisant autorité.}

\only<2->{Solution : un nouveau protocole. La question a été lancée dans le
groupe de travail \emph{dnsop} (secteur Gestion \& Opérations). Un I-D
a été écrit.}

\only<3->{Les présidents l'ont trouvé trop prématuré $\rightarrow$ renvoyé à un
petit \foreign{design team} pour proposer mieux.}

\only<4->{\foreign{Draft} du \foreign{design team} adopté par le
WG. Travail encore en cours.}

\end{frame}

\begin{frame}
\frametitle{Cosmogol}
Problème : les RFC utilisent souvent des automates à états finis. Mais
il n'existe pas de langage formel pour cela. Ils sont en général
décrits en art ASCII.

\only<2->{Solution : un langage,
Cosmogol. \url{http://www.cosmogol.fr/}}

\only<3->{Une BoF a eu lieu pour le discuter. Pas assez d'intérêt dans
l'IETF.}

\only<4->{Projet aujourd'hui en sommeil}

\end{frame}

\begin{frame}
\frametitle{ABNF}
\only<1-2>{L'IETF utilise beaucoup des grammaires formelles, écrites en ABNF.}

\only<2->{
\begin{enumerate}
\item Préhistoire, chaque RFC définissait sa BNF,
\item RFC 2234, novembre 1997, proposition de norme,
\item RFC 4234, octobre 2005, projet de norme,
\item RFC 5234, janvier 2008, norme.
\end{enumerate}}

\only<3->{Le processus a été long et sa dernière étape a nécessité un
examen des implémentations, avec un rapport public.}

\end{frame}

\begin{frame}
\frametitle{Étiquettes de langue}
\only<-2>{Plusieurs protocoles ou formats ont besoin d'indiquer la langue comme
XML avec \path{xml:lang} ou HTTP avec \path{Accept-Language}.

La langue est représentée par une \emph{étiquette de langue} comme
\path{fr} ou \path{ar-EG} ou \path{az-Latn-IR}.}

\only<2->{\begin{itemize}
\item RFC 1766, mars 1995
\item RFC 3066, janvier 2001
\item RFC 4646, septembre 2006. Marque la création du registre des
langues et l'ajout des dialectes et des écritures.
\item RFC 4646bis, approuvé mais pas encore publié, date inconnue, intégre les macrolangues.
\end{itemize}}

\only<3->{Un travail du groupe LTRU.}

\end{frame}

\begin{frame}
\frametitle{MARID}
\only<1-3>{Problème : authentifier le courrier électronique, de manière plus
légère qu'avec PGP. }

\only<2->{Propositions sur la table : SPF, Sender-ID}

\begin{enumerate}
\item<2-> Avril 2004 : création du groupe de travail MARID.
\item<3-> Mai 2004 : le groupe se dispute sur le brevet PRA de Microsoft
et sur le choix technique de l'identité à tester.
\item<4-> Juillet 2004 : beaucoup d'acteurs extérieurs ont une autre
solution à proposer et attaquent MARID.
\item<5-> Septembre 2004 : les discussions sur la licence du brevet PRA
n'aboutissent pas. Le groupe est dissous d'autorité par l'IESG.
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{DNSSEC et la sécurité du DNS}
\only<1-2>{Le DNS n'est pas sûr, on le sait et il est trop facile
d'\emph{empoisonner} un résolveur DNS (faille Kaminsky).

Comment le sécuriser ?}

\begin{enumerate}
\item<2->Sécuriser le canal entre serveurs de noms, pour être sûr de
bien parler avec le bon serveur ?
\item<3->Sécuriser les données DNS transportées, pour être sûr
qu'elles ont bien été émises telles quelles par l'origine ? (DNSSEC,
RFC 4033)
\end{enumerate}

\only<4>{Le débat existe pour tous les protocoles (PGP vs. SMTP+TLS
pour le courrier).}

\only<5->{L'IETF (groupe de travail \foreign{DNS extensions}, alias \foreign{namedroppers})a toujours privilégié DNSSEC, se méfiant même des
solutions partielles comme les \foreign{cookies}.}
\end{frame}

\begin{frame}
\frametitle{Contournement des NAT}
\only<1-2>{Les routeurs NAT (\foreign{Network Address Translation}) sont une des
plaies de l'Internet. Fragiles, lents, ils perturbent beaucoup de
protocoles (pair-à-pair, VoIP, \ldots).}

\only<2>{L'IETF a historiquement estimé qu'ils devaient disparaître, balayés
par IPv6.}

\only<3->{IPv6 n'ayant pas décollé, les NAT sont restés. Et l'IETF a fini, non
sans douleur, par accepter un groupe de travail « Contournement du
NAT », le groupe Behave.}

\only<3->{
\begin{itemize}
\item RFC 5389, STUN (trouver son adresse IP publique),
\item RFC 5128, documentation des techniques utilisées par les
logiciels pair-à-pair pour fonctionner malgré le NAT,
\item RFC 4787, comportement des routeurs NAT pour ne pas trop gêner
UDP.
\item \ldots
\end{itemize}}

\end{frame}

\begin{frame}
\frametitle{Brevets}
Toutes les SDO sont confrontées au problème des brevets. Faut-il
normaliser une technologie brevetée ?

\only<2>{Du fait de l'existence des \emph{brevets futiles}, tout est
breveté, dans au moins un pays. Si on refuse de normaliser ce qui est breveté, on ne
normalise plus rien.}

\only<3->{La politique de l'IETF sur ce point est
de \emph{publication} :
\begin{enumerate}
\item Si un participant à l'IETF connait un brevet, il doit le dire.
\item L'IETF publie la liste des brevets connus, pour chaque RFC
\end{enumerate}
L'implémenteur doit ensuite consulter son propre avocat :-(
}
\end{frame}

\begin{frame}
\frametitle{État des lieux}
\begin{block}
{L'IETF reste (avec peut-être le W3C et Oasis) l'organisation de normalisation
la plus ouverte, à la fois dans son processus et dans ses résutats.}
\only<2->{Mais l'évolution de l'Internet lui échappe largement. Les vendeurs et FAI
déploient le NAT, modifient les réponses DNS pour rediriger vers leur
serveur de pub, malgré l'absence de normalisation, ou même en dépit
des protestations de l'IETF. À l'inverse, IPv6 n'est pas déployé,
malgré les travaux et proclamations de l'IETF.}
\end{block}
\end{frame}

\begin{frame}
\frametitle{Conclusion}
\begin{block}
{L'IETF, c'est vous}
\only<2->{Le processus est très ouvert, n'hésitez pas à participer. Devenez
membre, relisez les \foreign{Internet-Drafts}, écrivez-en.}
\end{block}
\end{frame}

\end{document}
