Greboca  

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.

Blog de Stéphane Bortzmeyer  -  RFC 8718: IETF Plenary Meeting Venue Selection Process

 -  Février 2020 - 

La question de la sélection du lieu pour les réunions physiques de l'IETF a toujours suscité des discussions passionnées, d'autant plus que chaque participant, et son chat, a un avis. Il y a de nombreux critères (coût, distance, agréments du lieu, goûts personnels…) Ce nouveau RFC décrit le nouveau mécanisme par lequel est sélectionné un lieu, et les critères à respecter.

En théorie, venir aux réunions physiques n'est pas indispensable. L'IETF, organisme de normalisation technique de l'Internet, travaille, étudie les propositions, les amende, les approuve ou les rejette entièrement en ligne (avec l'aide de quelques outils comme le DataTracker). Ceci dit, en pratique, venir aux trois réunions physiques par an aide certainement à faire avancer son sujet favori. Ces réunions rassemblent des centaines de participants IETF pendant une semaine et sont l'occasion de nombreuses discussions. À noter que, pendant la réunion, une liste de discussion permet également des bavardages généralisés, où les conseils sur les bons bars et restaurants rencontrent les avis sur la meilleure route vers l'aéroport, et des récriminations sur les ascenseurs, l'air conditionné, le manque de cookies, etc. Ce RFC sort d'ailleurs au moment exact où l'IETF se déchire sur l'opportunité ou non de maintenir la réunion de Vancouver malgré l'épidémie.

La reponsabilité du choix d'un lieu pour les réunions incombe à l'IASA (IETF Administrative Support Activity, RFC 8711). Ce RFC ne lui supprime pas cette responsabilité mais lui fournit des éléments à prendre en compte. L'IETF a trois rencontres physiques par an, s'inscrivant dans le cadre de ses missions, qui sont décrits dans le RFC 3935. (Notez que certains participants contestent ces rencontres physiques, considérant qu'une organisation de normalisation des protocoles Internet pourrait se « réunir » en ligne.) La section 2 du RFC décrit les principes fondamentaux à prendre en compte pour le choix du lieu de la réunion :

  • Permettre la participation du plus grand nombre, quel que soit leur pays d'origine, ce qui implique que les pays ayant une politique de visa très restrictive, comme les États-Unis, sont déconseillés,
  • Et cela implique également que l'IETF préfère se tenir à l'écart des pays qui discriminent selon le genre, la couleur de peau, l'orientation sexuelle, etc ; c'est d'ailleurs un tel cas, soulevé par Ted Hardie, qui avait été à l'origine de la création du groupe mtgvenue, lorsque le choix de se réunir à Singapour avait été contesté en raison des lois homophobes de ce pays,
  • Un accès Internet de qualité est évidemment nécessaire, et non censuré ; cela avait donné lieu à de sévères discussions lors de la réunion (la seule jusqu'à ce jour) en Chine (le RFC note aussi, dans sa section 7, que la vie privée est importante et que les participants doivent être informés d'une éventuelle surveillance),
  • Le but est de travailler, et cela implique un environnement qui s'y prête bien, par exemple la possibilité de réunions informelles dans les environs, et dans de bonnes conditions (RFC 6771),
  • Le coût est un problème crucial, beaucoup de participants n'étant pas financés par une entreprise ou un gouvernement.

En revanche, la même section 2 cite des non-objectifs :

  • À part les cas de discrimination cités plus haut, qui concernent directement les participants à l'IETF, le choix du lieu de la réunion n'a pas pour objectif de valider ou de critiquer la politique du gouvernement local, ou les mœurs locales,
  • Avoir le maximum de participants n'est pas un but en soi, les réunions IETF n'ont pas un objectif commercial,
  • Et, évidemment, il n'y aura pas de critères touristiques (ah, les réunions à Minneapolis en hiver…)

Compte-tenu de ces objectifs de haut niveau, la section 3 du RFC liste les critères. D'abord, ceux qui sont impératifs :

  • L'endroit précis de la réunion (en général un grand hôtel, mais parfois un centre de conférences) doit fournir assez d'espace pour toutes les activités,
  • Il doit être accessible aux handicapés en fauteuil roulant (d'autres formes de handicap sont mentionnées plus loin, avec des critères moins stricts),
  • Il doit pouvoir être connecté à l'Internet dans de bonnes conditions (IPv4 et IPv6, pas de NAT, capacité suffisante, etc ; notez que, la plupart du temps, le lieu ne fournit pas cela par défaut et c'est à l'IETF de tout installer et configurer avant la réunion).
Il y a ensuite les critères importants. Évidemment, l'idéal serait de trouver un endroit qui satisfasse tous les critères mais, en général, ce n'est pas possible. Le choix sera toujours un compromis. Il faut donc déterminer quels critères on peut accepter de sacrifier, et c'est la raison pour laquelle il n'y a finalement que trois critères impératifs. Les critères importants mais non impératifs sont :
  • Le lieu doit être raisonnablement accessible d'un grand nombre d'endroits (la réunion de Buenos Aires, la seule qui se soit tenue en Amérique latine, avait été très critiquée de ce point de vue, le coût total et le temps total de voyage avaient été très importants, par rapport à, disons, New York ou Singapour),
  • Il doit être possible de trouver une organisation locale qui participe à l'organisation, et des sponsors qui acceptent de financer (les frais d'inscription, pourtant très élevés, ne couvrent pas tout le budget),
  • Les barrières à l'entrée (typiquement les visas) doivent être le plus basses possibles (là encore, cela dépend du participant : pour aller en France, la barrière pour un Slovène est basse, la Slovénie étant dans Schengen, celle pour un Malien est bien plus haute ; c'est donc le « coût » total qu'il faut considérer),
  • Le lieu doit offrir des conditions de sécurité acceptables (critère parfois subjectif, les États-uniens, par exemple, voient souvent le reste du monde comme une jungle, et des habitants de Chicago ou Los Angeles s'inquiètent parfois à l'idée d'aller à Yokohama…),
  • Par ailleurs, il faut suivre les principes (assez généraux) du RFC 8719.
  Il faut se rappeler que l'IETF est internationale, et que la notion de « lieu éloigné » dépend donc du participant, c'est le coût total de voyage qui compte, pas celui de telle ou telle personne, d'où la politique « 1-1-1 », une réunion en Amérique du Nord, puis une en Europe, puis une en Asie, politique qui vise à répartir les coûts sur les divers participants

Pour l'endroit exact de la réunion (en général un grand hôtel), il y a des critères supplémentaires :

  • De la place pour les réunions informelles (couloirs, annexes, bars et cafétérias, etc) et des endroits où se rencontrer dans les environs, puisque, comme souvent dans les réunions formelles, le travail le plus important se fait en dehors des salles de réunion (on voit souvent des petits groupes écrire des Internet-Drafts assis dans les couloirs),
  • Prix « conformes aux tarifs d'affaire habituels » (ce qui est déjà très cher, si on prend en compte les habitudes étatsuniennes).
Dans le cas typique, l'IETF se tient dans un grand hôtel pour hommes d'affaires riches. (La dernière (au moment de l'écriture de cet article) réunion, à Montréal, était au Fairmont.) Et les participants au budget voyage le plus important logent sur place. Il existe aussi des overflow hotels où logent les moins riches. Dans l'hôtel principal et, parfois, dans les overflow hotels, on dispose du réseau IETF même dans sa chambre. Ce réseau est installé par une équipe de volontaires de l'IETF avant la réunion (les réseaux des hôtels sont en général catastrophiques, pas d'IPv6, pas de DNSSEC, des ports filtrés, etc, une réunion à Paris avait battu les records). Beaucoup de participants vont chez Airbnb ou carrément en auberge de jeunesse et doivent alors se débrouiller pour le réseau.

Les ingénieurs et ingénieures sont des êtres humains et doivent donc manger. D'où des critères concernant nourriture et boisson :

  • Disponibilité de ressources alimentaires proches, pour tous les goûts, toutes les bourses, tous les critères, par exemple de santé ; j'ai déjà vu des conférences dans des resorts isolés, où on était obligés de se contenter de l'offre locale, souvent très chère,
  • Ces ressources doivent être disponibles sous forme de restaurants mais aussi de magasins pour ceux qui préfèrent ensuite aller manger dehors (il n'y a pas de repas servi, aux réunions IETF).
Enfin, il y a des critères sur des points variés :
  • Il est préférable que tout soit au même endroit, pour éviter les déplacements,
  • Il est préférable qu'on puisse revenir, et qu'il y ait des contrats pour plusieurs évenements, avec prix réduits.

Même si tous ces critères ne sont pas impératifs, mis ensemble, ils sont très exigeants. Des gens demandent parfois pourquoi, par exemple, il n'y a jamais eu de réunion de l'IETF en Inde, pays certainement important pour l'Internet. C'est entre autres en raison de spécificités locales, par exemple la difficulté d'obtention des visas. (Cf. cette discussion.)

On notera que les critères sont finalement peu nombreux. De très nombreuses autres propositions avaient été faites, qui risquaient de mener à un catalogue de critères, très épais et, de toute façon, impossibles à satisfaire simultanément. Le rapport « droits humains » notait que certains critères pouvaient être incompatibles entre eux (une personne aveugle voudrait pouvoir être accompagnée de son chien guide, et une autre personne est allergique aux chiens, voire en a une phobie.)

C'est ainsi que des critères comme la disponibilité d'une crèche ont été retirés (notez que le RIPE le fait et que l'IETF va tenter le coup), de même que la demande de toilettes non genrées, qui était dans certaines versions du projet de RFC.

Comme vous vous en doutez, la discussion à l'IETF sur ce RFC n'a pas été évidente. De toute façon, la décision sur le choix d'un lieu reviendra à l'IASA, sauf pour les critères impératifs, qui nécessiteront une discussion générale.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

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 (...)