Skip to main content

Requirements for the Format for Incident Information Exchange (FINE)
draft-ietf-inch-requirements-08

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from inch-chairs@ietf.org to (None)
2007-04-06
08 (System) Ballot writeup text was added
2007-04-06
08 (System) Last call text was added
2007-04-06
08 (System) Ballot approval text was added
2007-04-06
08 (System) Document has expired
2007-04-05
08 Sam Hartman State Changes to Dead from Publication Requested by Sam Hartman
2007-04-05
08 Sam Hartman

I have chosen not to sponsor the requirements draft for publication as
an informational RFC.  I recognize that the requirements draft was
useful to the …

I have chosen not to sponsor the requirements draft for publication as
an informational RFC.  I recognize that the requirements draft was
useful to the inch community during the development of iodef.

However having reviewed that draft, I do not find that there is
sufficient content there that helps understand the context of iodef or
will help future extensions to iodef to justify archival publication.
2006-10-04
08 Dinara Suleymanova
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, …
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Roman Danyliw is the shepherd of this document. In my estimation and
supported by the WG last call, this draft is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been subjected to a breadth of the review coming from
inside the WG and from incident response teams that would be the end
consumers of this information.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

As a document in the security area, it should be scrutinized by security
experts.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.

There are no such issues.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The WG as a whole stands behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

There has been no such discontent.

(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

I have reviewed the document and have found no nits as documented by the
Editor.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document does split references into normative and information
categories. The single normative reference is an RFC (RFC2119).


(1.i) The IESG approval announcement

Technical Summary

This document describes the high-level functional requirements of
an abstract format, the Format for Incident information Exchange
(FINE), which will facilitate the exchange of incident information
among computer security incident response teams (CSIRTs) and
involved parties. A common and well-defined format will help in the
exchange of incident related information across different
administrative domains such as organizations, regions, and
countries. Implementations of FINE will also be useful for
reactionary analysis of current threats and support the proactive
identification of trends that can lead to incident prevention.

Working Group Summary

There is consensus in the WG to publish this document.

Document Quality


This draft has been reviewed by the WG and by members of the CSIRT
community that would adopt this format.
2006-10-04
08 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-07-12
08 (System) New version available: draft-ietf-inch-requirements-08.txt
2006-03-02
07 (System) New version available: draft-ietf-inch-requirements-07.txt
2005-12-21
06 (System) New version available: draft-ietf-inch-requirements-06.txt
2005-09-08
05 (System) New version available: draft-ietf-inch-requirements-05.txt
2005-05-10
04 (System) New version available: draft-ietf-inch-requirements-04.txt
2005-02-09
03 (System) New version available: draft-ietf-inch-requirements-03.txt
2003-10-28
02 (System) New version available: draft-ietf-inch-requirements-02.txt
2003-06-12
01 (System) New version available: draft-ietf-inch-requirements-01.txt
2003-02-27
00 (System) New version available: draft-ietf-inch-requirements-00.txt