Résumé

  • Le groupe de travail IETF « grip » (G & R for Security Incident Processing) a fonctionné de février 1995 à décembre 2001, sous la présidence de Barbara Y. Fraser et Klaus-Peter Kossakowski.
  • Son produit principal, la RFC 2350 « Expectations for Computer Security Incident Response » (BCP 21), signée par Nevil Brownlee et Erik Guttman et publiée le 1er juin 1998, reste le seul et actuel RFC de la sous-série BCP 21, avec des errata recensés.
  • La vérification et le recours passent aujourd'hui par les enregistrements du RFC Editor et de l'IETF Datatracker, non par un groupe vivant ; le datatracker avertit lui-même que les données des groupes conclus sont « parfois incorrectes ».

Un groupe qui n'existe plus, une norme qui s'applique encore

Selon la fiche du groupe sur l'IETF Datatracker, le groupe de travail grip — « G & R for Security Incident Processing », nom complet « Guidelines and Recommendations for Security Incident Processing » — relevait de la zone Operations and Management et était co-arrêté par la zone Sécurité [^1]. Il y est listé comme « Concluded », avec la charte charter-ietf-grip-01 approuvée, présidé par Barbara Y. Fraser et Klaus-Peter Kossakowski, avec une liste de diffusion hébergée sur un domaine externe [^1]. La liste des groupes conclus lui assigne un démarrage en février 1995 et une conclusion en décembre 2001 [^2].

Deux précautions s'imposent. Premièrement, Datatracker précise que « les données des groupes conclus sont parfois incorrectes », ce qui s'applique aux dates de 1995-02 et 2001-12. Deuxièmement, le champ « Name » de la page (« G & R for Security Incident Processing ») diffère du nom complet donné dans la charte (« Guidelines and Recommendations for Security Incident Processing ») — une divergence non résolue dans les sources primaires [^1].

Ce que la norme exige, et de qui

La RFC 2350, « Expectations for Computer Security Incident Response », BCP 21, a été rédigée par N. Brownlee (Université d'Auckland) et E. Guttman (Sun Microsystems), publiée en juin 1998 comme Best Current Practice, à partir de la série draft-ietf-grip-framework-irt [^3] [^4] [^7]. Le document définit ce que les organisations peuvent attendre d'une équipe de réponse aux incidents (CSIRT) : un cadre de description, des niveaux de service déclarés et des limites explicites de responsabilité.

Le point de redevabilité est là : la norme demande à chaque CSIRT de rendre publiques ses propres attentes et limites. Elle ne crée pas d'organe de surveillance. La conformité repose sur la transparence déclarée, vérifiable par toute partie prenante, mais sans mécanisme de sanction.

Le groupe s'est conclu ; la norme est restée

La sous-série BCP 21 du RFC Editor ne contient qu'un seul RFC : RFC 2350 [^5]. Datatracker confirme son statut de Best Current Practice de juin 1998, issu de draft-ietf-grip-framework-irt, avec des errata recensés, sans document l'obsolétant [^4]. L'historique du document date sa publication au 1er juin 1998, à partir de la série de brouillons de septembre 1995 à septembre 1997 ; des opérations de maintenance des métadonnées datatracker y sont enregistrées aussi récemment que le 20 mai 2026 [^6].

Autrement dit : l'instance qui a écrit la définition mondiale des attentes envers les CSIRTs n'existe plus depuis fin 2001, et sa norme reste la pratique courante vingt-cinq ans plus tard. Qui répond de sa pertinence ? Personne, en tant que groupe. Le RFC Editor, l'IETF Datatracker et le processus d'errata portent aujourd'hui l'entier de la vérifiabilité [^4] [^5] [^6].

Ce que cela prouve — et ce que cela n'établit pas

Les faits vérifiés : identité du groupe, présidence, dates (sous réserve de l'avertissement du datatracker), paternité et statut de la RFC 2350. Ce qui reste incertain : la correspondance de l'identifiant numérique 1007 de l'API datatracker avec ce groupe n'a pas pu être confirmée directement, l'appel API n'ayant pas été récupéré [^8] ; et la divergence de nommage entre page et charte demeure.

L'absence de successeur actif n'est pas en soi une défaillance prouvée : conclure un groupe de travail après livraison est un fonctionnement normal de l'IETF. Mais lorsque la norme d'un domaine aussi sensible que la réponse aux incidents reste inchangée pendant un quart de siècle sans groupe propriétaire vivant, l'obsolescence silencieuse devient un risque opérationnel que les opérateurs doivent gérer eux-mêmes.

[^1]: IETF Datatracker, fiche du groupe grip — https://datatracker.ietf.org/wg/grip/about/ [^2]: IETF Datatracker, liste des groupes conclus — https://datatracker.ietf.org/group/concluded/ [^3]: RFC Editor, page info RFC 2350 — https://www.rfc-editor.org/info/rfc2350/ [^4]: IETF Datatracker, document RFC 2350 — https://datatracker.ietf.org/doc/rfc2350/ [^5]: RFC Editor, sous-série BCP 21 — https://www.rfc-editor.org/info/bcp21/ [^6]: IETF Datatracker, historique de rfc2350 — https://datatracker.ietf.org/doc/rfc2350/history/ [^7]: RFC Editor, RFC 2350 (texte) — https://www.rfc-editor.org/rfc/rfc2350.html [^8]: IETF Datatracker API, group/group/1007 — https://datatracker.ietf.org/api/v1/group/group/1007/