Summary
- The IETF working group grip ('G & R for Security Incident Processing', Operations and Management Area, co-chartered with the Security Area) started in February 1995 and is listed as concluded in December 2001; its chairs were Barbara Y. Fraser and Klaus-Peter Kossakowski (datatracker record, concluded-groups listing).
- Its principal product, RFC 2350 'Expectations for Computer Security Incident Response' (BCP 21), was authored by Nevil Brownlee (The University of Auckland) and Erik Guttman (Sun Microsystems) and published 1 June 1998, derived from the draft-ietf-grip-framework-irt series (RFC Editor info, datatracker record, history, full text).
- BCP 21 still contains exactly one RFC — RFC 2350 — so the document remains the current best practice, with errata, and no obsoleting or successor document (BCP 21 subseries).
- The authoring body no longer operates; verifiability and any remedy now run through RFC Editor and datatracker records rather than any convened group — datatracker metadata maintenance on RFC 2350 is dated as recently as 20 May 2026 (history).
A working group, its charter and its product
The datatracker record describes grip as a concluded working group in the Operations and Management Area, co-chartered by the Security Area, with charter charter-ietf-grip-01 approved and chairs Barbara Y. Fraser and Klaus-Peter Kossakowski; its mailing list ran on an external domain (record). The concluded-groups listing places the group's life from February 1995 to December 2001 (listing). That six-and-a-half-year window produced the document that still defines the vocabulary of incident response: the categories of expectations organisations may hold toward a CSIRT, from service definition through reporting channels to publicity control.
RFC 2350 itself went through eight drafts — draft-ietf-grip-framework-irt-00 in September 1995 through -07 in September 1997 — before publication as BCP 21 on 1 June 1998, authored by Nevil Brownlee and Erik Guttman (history, RFC Editor). The document's own header states it specifies an Internet Best Current Practice for the Internet community. Errata exist against it; none has produced a replacement. The BCP 21 subseries lists a single RFC, meaning the 1998 text is still the operative standard (subseries).
The gap the record shows
A BCP label signals to readers that the IETF community currently endorses a practice. But the machinery that would update, defend or interpret that practice — the working group — was wound up in December 2001. No successor document, no rechartered group and no named custodian appears in the primary records examined. What remains is documentary: the RFC Editor's info pages, the datatracker document and history records, and the errata system. Datatracker metadata maintenance on RFC 2350 is dated as recently as 20 May 2026 — record-keeping continues; stewardship does not (history).
Two data-quality caveats belong in any honest account. Datatracker itself warns that 'the data for concluded WGs is occasionally incorrect', which applies directly to the start and conclusion dates used here. And the record's Name field ('G & R for Security Incident Processing') differs from the charter's full name ('Guidelines and Recommendations for Security Incident Processing') — an unresolved rendering discrepancy in primary records (record). Additionally, the numeric mapping of datatracker API group id 1007 to the grip group could not be independently confirmed from the API endpoint itself, which was not directly retrieved; the group identity rests on the human-facing /wg/grip/ pages (API endpoint).
What this means
The finding is structural, not a criticism of individuals. The IETF's working-group model naturally dissolves groups when their charters are fulfilled. But the model assumed standards would be revised; BCP 21 was not. The result is guidance still labelled 'current best practice' whose prevention, detection and response expectations cannot be directed to any live body — the errata process and the RFC Editor are the only remedy pathways the record supports. Organisations citing RFC 2350 in contracts, policies or audits are citing a standard whose authoring institution no longer exists to answer questions about it.
This is the first BTW coverage of this subject; the delta here is the accountability story itself — who owned incident-response expectations, whether the owner still operates (it does not), and what remains verifiable for remedy today.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
