IETF

Fin juin 1985, six hôtes, trois horloges de référence et plusieurs liaisons devaient composer avec l’insertion d’une seconde intercalaire. Certaines voies transportaient également des données ordinaires. Les expérimentateurs devaient séparer l’écart de l’horloge, celui de sa référence et celui du trajet réseau.

Approuvée le 8 octobre, la nouvelle charte énumère les tâches de découverte sur un ou plusieurs liens et maintient les changements généraux du DNS hors du mandat du groupe.

Interroger sans cesse un équipement ou récupérer une liste entière pour quelques lignes : deux habitudes peuvent coûter cher en ressources. Le nouveau calendrier de NETCONF remet leurs alternatives à l'ordre du jour.

Le 8 octobre, l’IESG a approuvé la charte d’Agentproto et fixé à décembre 2026 le premier jalon : l’adoption d’un document informatif sur les cas d’usage. Une version mise à jour le 15 octobre figure déjà dans la liste des documents associés à l’IETF, mais sa fiche la classe encore comme Internet-Draft individuel. Une date de dépôt récente ne vaut pas décision d’adoption du groupe de travail.

Le NomCom 2026–2027 de l’IETF a accordé deux semaines supplémentaires pour accepter les candidatures. Pourtant, sa page de référence conserve les anciennes dates de clôture, de finalisation de la liste et d’entretiens : deux calendriers publics ne concordent plus.

Avant que le BGP n’entre dans un RFC, des implémentations existaient déjà pour les routeurs Cisco et les Nodal Switching Systems de NSFNET. Le texte de juin 1989 décrit un protocole encore en chantier ; un an plus tard, sa version révisée devient une norme proposée qui invite explicitement les retours du terrain.

Le Datatracker indiquait zéro erreur et zéro avertissement YANG pour la révision 44. Pourtant, le RFC-to-be 10057 restait en révision finale, avec deux approbations d’auteurs non enregistrées et un possible blocage de cluster.

Une même valeur peut circuler de RADIUS aux listes de contrôle d’accès. La RFC 10065 ne fixe ni la définition des groupes ni la correspondance locale entre un identifiant et le trafic.

L’IESG a approuvé la charte que PROCON avait soumise à examen en septembre. La nouvelle version fixe deux objectifs d’envoi en novembre et un troisième en décembre; elle confie un travail au groupe, sans modifier encore les règles de l’IETF.

Dans une réunion de l’IETF, un hum pouvait rendre audible la tendance d’un groupe. Il n’était pas censé trancher une question technique au volume sonore. En 2014, le RFC 7282 a précisé ce que le consensus approximatif devait exiger : faire émerger les objections, les examiner et rendre le jugement du président compréhensible.

Usenet devait permettre aux logiciels de distinguer une décision de modération d’une contribution ordinaire. Le champ `Approved:` rendait cette décision visible dans l’article, mais il n’authentifiait pas la personne indiquée. Cette nuance comptait d’autant plus que la même mention pouvait accompagner des commandes qui modifiaient la liste des groupes distribués.

Usenet devait permettre aux logiciels de distinguer une décision de modération d’une contribution ordinaire. Le champ `Approved:` rendait cette décision visible dans l’article, mais il n’authentifiait pas la personne indiquée. Cette nuance comptait d’autant plus que la même mention pouvait accompagner des commandes qui modifiaient la liste des groupes distribués.

En 1981, IPv4 a reçu un petit champ permettant de noter où et quand un paquet avait été traité. Il ressemble à un journal de route, mais ne fournit pas un chronomètre synchronisé de la latence réseau.

Le champ UDP de 16 bits distinguait deux cas souvent confondus : un résultat de calcul nul et l’absence de calcul. Introduite dans la spécification de 1980, cette convention a ensuite rencontré des règles IPv6 plus strictes.

En 1989, une norme rendit l’adhésion au multicast visible aux routeurs voisins par un signal économe : un rapport pouvait représenter tout un groupe local, tandis que le silence après un départ devait expirer avec le temps.

Trois noms de serveurs faisant autorité ne donnaient pas trois chemins indépendants vers une zone. En 1997, le BCP 16 a intégré la géographie et la topologie du réseau au choix des serveurs secondaires.

En 1995, l’enjeu n’était pas seulement de placer un serveur moins chargé en tête de liste. Il fallait le faire sans modifier le protocole DNS déjà largement installé. RFC 1794 décrit un compromis : l’autorité pouvait classer les adresses, mais elle ne décidait pas à la place de chaque client.