Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
L'articulation compliquée entre l'IETF qui produit les normes
TCP/IP et le RFC Editor qui les publie, n'a
jamais cessé de faire couler de l'encre (ou d'agiter des
électrons). Dans ce document, l'IAB décrit un modèle pour le
RFC Editor, modèle où les fonctions de ce dernier sont éclatées en
plusieurs fonctions logiques. Elles peuvent ainsi être réparties
entre plusieurs groupes. Ce RFC remplace le RFC 6635, avec peu de changements : c'est toujours le modèle
« v2 » du modèle RFC Editor.
Le document de référence actuel est le RFC 8729. Comme le rappelle la section 1, il décrit les tâches
du RFC Editor de manière globale, comme si c'était forcément une seule
entité (c'était, à l'origine, une seule personne, Jon
Postel). La section 2 note que la tâche de RFC Editor est
actuellement une partie de l'IASA (dont la récente
réforme, décrite dans le RFC 8711, a nécessité
ce nouveau RFC) et financée par son
budget.
La même section 2 s'attaque à la définition du rôle du RFC Editor
sous forme de fonctions séparées. Elles sont ici légèrement
modifiées, compte-tenu de l'expérience et des problèmes de
communication rencontrés, problèmes de communication qui
n'existaient évidemment pas lorsque Postel faisait tout lui-même. Le
terme de RFC Editor désigne collectivement toutes ces
fonctions. L'IAB voit maintenant trois fonctions (voir aussi
le dessin 1 de notre RFC) :
- Éditeur de la série des RFC,
- Producteur des RFC,
- Publieur des RFC,
- Enfin, l'éditeur des contributions indépendantes,
décrit à part, dans le RFC 8730.
Chaque section va ensuite détailler ces tâches. Il y a également des
rôles de supervision, tenus par l'IAB (RFC 2850) et l'IETF
LLC (RFC 8711).
L'Éditeur de la série des RFC (RFC Series
Editor, poste actuellement vacant depuis le départ
d'Heather Flanagan) est décrit en premier, en section 2.1. Il ou
elle est responsable du travail à long terme, il doit définir les
principes qui assurent la pérennité des RFC, réfléchir à la
stratégie, développer le RFC 7322, le guide de
style des RFC, de la langue des RFC, etc. Il sert aussi de
« visage » aux RFC, vis-à-vis, par exemple, des
journalistes. L'Éditeur est censé travailler avec la communauté IETF
pour les décisions politiques. Désigné par l'IAB, il ou elle sera
formellement un employé de l'IETF LLC, la structure administrative
de l'IETF.
Le RFC 8728 évalue la charge de travail à un
mi-temps, ce qui me semble très peu. Notre RFC décrit les
compétences nécessaires (section 2.1.6) pour le poste d'Éditeur de
la série des RFC, compétences en anglais et en Internet, capacité à
travailler dans l'environnement... spécial de l'IETF, expérience des
RFC en tant qu'auteur souhaitée, etc.
Le travail quotidien est, lui, assuré par le Producteur des RFC
(RFC Production Center) dont parle la section
2.2. C'est un travail moins stratégique. Le Producteur reçoit les
documents bruts, les corrige, en discute avec les auteurs, s'arrange
avec l'IANA pour l'allocation des numéros de
protocoles, attribue le numéro au RFC, etc.
Les RFC n'étant publiés que sous forme numérique, il n'y a pas
d'imprimeur mais le numérique a aussi ses
exigences de publication et il faut donc un Publieur des RFC
(RFC Publisher), détaillé en section
2.3. Celui-ci s'occupe de... publier, de mettre le RFC dans le dépôt où on les
trouve tous, d'annoncer sa disponibilité, de gérer
l'interface permettant de soumettre les errata, de garder à jour ces errata,
et de s'assurer que les RFC restent disponibles, parfois pendant de
nombreuses années.
Chacune de ces fonctions pourra faire l'objet d'une attribution
spécifique (à l'heure actuelle, les fonctions de Producteur et de
Publieur sont assurées par le même groupe à l'AMS). La liste à jour peut être
vue sur le site
officiel.
Un comité joue un rôle de supervision et de contrôle du RFC Editor :
le RSOC (RFC Series Oversight Committee) est
décrit en section 3.
Combien cela coûte et qui choisit les titulaires des différentes
fonctions ? La section 4 décrit ce rôle, dévolu à l'IETF LLC
( IETF Administration Limited Liability Company,
cf. RFC 8711). Le budget est publié en sur
le site de l'IETF LLC
et on y trouvera aussi les futures évaluations du RFC Editor. On peut aussi trouver cette
information, ainsi que plein d'autres sur le fonctionnement du
RFC Editor, via
le site officiel).
Comme indiqué plus haut, il n'y a pas de grand changement depuis
le RFC 6635, juste le remplacement de
l'ancienne IAOC par l'IETF LLC.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)