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'IETF, l'organisme qui écrit les
normes techniques de
l'Internet fait partie de la galaxie des
nombreuses organisations qui ont un rôle plus ou moins formel dans
le fonctionnement du réseau. Ce nouveau RFC décrit les relations de l'IETF avec
un autre de ces organismes, l'Internet
Society (ISOC). Ce RFC remplace le RFC 2031, notamment pour s'adapter à la nouvelle
structuration de l'IETF, dite « IASA 2 » (IASA veut dire
IETF Administrative Support Activity).
Historiquement, l'IETF n'était qu'un sigle et une idée. Il n'y
avait pas d'organisation formelle de l'IETF. Au début, cela
marchait bien comme cela, mais des inquiétudes se sont fait
jour. Si l'IETF n'existe pas juridiquement, qui est responsable
des RFC ? Si
une entreprise mécontente d'un RFC fait un procès, chose courante
aux États-Unis, à qui va-t-elle le faire ?
Aux individus auteurs du RFC ? C'est entre autres en raison de ce
genre de risques que l'IETF s'est mise sous un parapluie
juridique, celui de l'Internet Society
(ISOC), organisation créée pour donner une structure à l'Internet,
permettant par exemple d'avoir un budget, d'empêcher des escrocs
de déposer la marque « Internet », pour
faire du lobbying, etc. C'est donc l'ISOC qui est la
représentation juridique de l'IETF, mais aussi de l'IAB et de
l'IRTF. (Cela date de
1995, via un groupe de travail qui se
nommait Poised, qui a lancé l'effort de
formalisation des processus IETF.) Si une entreprise, motivée par
des juristes aussi méchants que dans un roman de
Grisham, veut faire un procès en raison
d'un RFC, elle
doit faire un procès à l'ISOC (qui a ses propres bataillons de
juristes).
La relation exacte entre l'IETF et l'ISOC était spécifiée dans
le RFC 2031. Depuis, a émergé le concept
d'« IASA » (IASA veut dire IETF Administrative Support
Activity), une structuration plus forte des activités
non techniques de l'IETF. Encore depuis, la création de « IASA
2 », dans le RFC 8711, a changé les
choses, nécessitant le remplacement du RFC 2031. L'IASA version 2 créé une nouvelle structure,
l'IETF LLC (LLC veut dire Limited Liability
Company), qui est une filiale de l'ISOC.
Assez d'histoire, voyons d'abord, les principes (section 2 de
notre RFC). L'ISOC a dans ses missions
d'encourager et d'aider le développement de normes techniques
ouvertes, ce qui correspond au rôle de l'IETF. Le but est donc
d'être efficace, et de produire des bonnes normes, librement
accessibles, et via un processus ouvert.
La section 3 précise la répartition des rôles : à l'IETF le
développement des normes, à l'ISOC la partie juridique et
financière. L'ISOC ne doit pas intervenir
dans les choix techniques.
Cela ne veut pas dire que l'ISOC se contente de regarder. La
section 4 du RFC rappelle qu'elle contribue au choix des membres
du NomCom (qui fait les nominations à certains postes, cf. RFC 8713), de l'IAB, et qu'elle sert d'appel
ultime en cas de conflit. D'autre part, l'ISOC est membre de
certaines organisations très formelles, comme l'UIT, et sert donc de relais pour
l'IETF auprès de cette organisation (RFC 6756).
L'ISOC a aussi un rôle de popularisation des technologies
Internet et de sensibilisation à certains enjeux. Par exemple, elle
a créé le programme Deploy
360, qui promeut notamment DNSSEC et
IPv6.
Et en sens inverse (section 5 du RFC), l'IETF a une
représentation au conseil d'administration de l'ISOC (RFC 3677).
Du point de vue juridique, rappelons que l'IETF LLC est
rattachée à l'ISOC comme décrit dans l'accord
entre l'IETF et l'ISOC d'août 2018 (oui, il a fallu du
temps pour publier ce RFC…) Notez que le RFC qualifie la LLC de
disregarded (ignorée, négligée) mais c'est en
fait le sens fiscal de disregarded qui compte :
la LLC ne paie pas d'impôts, l'ISOC le fait pour elle.
L'IETF a une structure pour gérer sa propriété
intellectuelle, l'IETF Trust, créée
par le RFC 5378, puis mise à jour dans les
RFC 8715 et RFC 8714. C'est l'IETF
Trust qui gère les marques, le
copyright, etc. C'est officiellement cet
IETF Trust qui vous donne le droit de lire et
de distribuer les RFC. La nouvelle structure ne change pas le
rôle de l'IETF Trust.
Enfin, le fric (qui fait tourner le monde). La section 7 du RFC
rappelle que c'est souvent l'ISOC qui finance les activités de
l'IETF. Les détails financiers sont en
ligne.
Voilà, cela fait déjà beaucoup de choses à savoir, et c'est
bien sûr encore pire si on inclut tous les RFC de la nouvelle
structuration IASA mais il faut se rappeler que cette complexité
est en partie volontaire. D'abord, il faut éviter la domination
d'une organisation unique qui contrôlerait tout, et ensuite
certaines organisations nécessitent des compétences spécifiques
(par exemple, à l'IETF, il faut être pointu sur les questions
techniques).
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 (...)