Suport technique et veille technologique
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.
- Novembre 2020 -
Tous les RFC ne viennent pas de
l'IETF. Certains sont publiés sur la
voie indépendante, sous la responsabilité de
l'ISE (Independent Submissions Editor). Certains
de ces RFC « indépendants » créent ou modifient des registres
IANA. Comment traiter ces demandes à
l'IANA ?
Ce travail de l'ISE (Independent Submissions
Editor, actuellement Adrian Farrel, l'auteur de ce RFC, et
également des contes « Tales from the wood ») est
documenté dans le RFC 4846. Cet ancien RFC (il
date d'avant la création de l'ISE, qui avait été faite par le RFC 5620, puis précisée par le RFC 6548 puis enfin le RFC 8730) ne donne que peu de détails sur les relations avec
l'IANA, nécessaires si le RFC « indépendant »
demande la création d'un nouveau registre, ou la modification d'un
registre existant. Ces registres IANA sont en https://www.iana.org/protocols
Pour les registres existants (section 2 du RFC), l'ISE est
évidemment tenu par ce RFC 8126. Si un RFC de
la voie indépendante ajoute une entrée à un registre IANA, il doit
suivre la politique qui avait été définie pour ce registre. Cela va
de soi. D'autre part, un RFC « indépendant » ne représente pas, par
définition, l'IETF, et ne peut donc pas créer d'entrées dans un
registre dont la politique est « Examen par l'IETF » ou « Action de
normalisation ». Pour la même raison, un RFC de la voie indépendante
ne peut pas changer la politique d'un registre qui n'avait pas été
créé par un RFC de la voie indépendante (section 3).
Et la création de nouveaux registres (section 4 de notre RFC) ?
En général, un RFC « indépendant » ne devrait pas le faire,
puisqu'il s'agit de documents qui n'ont pas bénéficié du même examen
que les RFC de la voie IETF. La seule exception est la possibilité
de créer un sous-registre s'il existe un registre à la politique
« ouverte » (« Spécification nécessaire », « Examen par un expert »,
« RFC nécessaire » ou « Premier Arrivé, Premier Servi ») et que le
sous-registre correspond à une entrée ajoutée par le RFC
indépendant. L'une des raisons de ce choix est d'éviter de donner
trop de travail à l'IANA, en multipliant les registres.
Certaines politiques d'allocation dans un registre IANA
nécessitent un expert. La section 5 de notre RFC précise que la voie
indépendante ne nommera pas d'expert et que donc aucun des
sous-registres éventuellement créés n'aura la politique « Examen par
un expert ».
Enfin, la section 6 traite le cas du transfert du contrôle d'un
registre. Il n'y aura jamais de transfert depuis la voie IETF vers
la voie indépendante (une fois qu'un registre est « officiel », il
le reste) mais l'inverse peut arriver, par exemple si un protocole
initialement décrit dans un RFC « indépendant » passe finalement sur
le chemin des normes.
