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

\title{Développement de protocoles à l'IETF}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{Novembre 2007}

%\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}
\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 5092 : un schéma IMAP pour les URL (pour désigner un message
via un URL) (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{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->{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 xxx (pas encore paru mais déjà approuvé par l'IESG), 2007, 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, date inconnue, intégrera 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{État des lieux}
\begin{block}
{L'IETF reste (avec peut-être le W3C) 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}