The Incident Object Description Exchange Format
draft-ietf-inch-iodef-14

[Ballot discuss]
*Extensions and validation*

The guideline in section 5.2:

  3.  Implementations MUST NOT validate the schemas that they do not understand

... needs to be made more clear.  (a) Schemas aren't validated, documents are validated against one or more schemas.  (b) "Don't understand" is very casual. (c) It's not clear which implementation is subject to this requirement and the others in this section. 

The real, underlying problem here, is that if a document has an extension schema that the consumer of that document doesn't have, then the consumer cannot validate the document at all (unless it could somehow download the extension schema, and we've already discussed the problems with that.)  XML Extensions are surprisingly incompatible with validation, and this document is still unclear in its requirements to implementors around that issue.

*Language tagging*

Section 6: language tagging requirements use the "lang" attribute that is standard for XML, but do not use the correct namespace -- it should be "xml:lang".  See section 2.1 of http://www.w3.org/TR/REC-xml/. 

*Namespace*

Section 4.2

  "The IODEF schema declares a namespace of "iodef-1.0" and registers it
  per [4]." Each IODEF document MUST use the "iodef-1.0" namespace in
  the top-level element IODEF-Document.  It can be referenced as
  follows:

    does not mention registering anything.  It's RFC3553 which discusses registering in "urn:ietf:params". Strictly speaking, the namespace registered is "urn:ietf:params:xml:ns:iodef-1.0", not "iodef-1.0" (the shorter string is a sub-namespace or identifier). 

The explanation of how the namespace "can" be referenced is a passive non-normative statement.  IODEF needs to be absolutely clear whether incident reports MUST provide the schema location in addition to the implied requirement of declaring the namespace. 

The prefix "xsi" is not declared here.  The version value is unusual; it's usually "1.0".  Since I believe version comparisons may be string comparisons, this is probably important. 

*Schema Availability*

Has IANA agreed to host a schema *live* at the URL that this document
implies one can find the schema?

*Restriction handling*

Section 3.2, restriction definition:  This specification does not indicate how to handle restrictions, particularly with inheritance involved.  It's not specified what it means to "honor" a restriction. 
- MUST a recipient strip out restricted elements nested within unrestricted elements before forwarding or publishing?  Or does the presence of any restricted elements mean that the entire document MUST NOT be forwarded or published? The granular privacy features seem like a probable pain point to me -- too flexible to be sanely implemented.
- What's the meaning of something that's of restriction "public" within a container of restriction "private"?  That nesting doesn't make sense to me.
- "need to know" is not defined, there's only a suggestion of what it *might* mean.

  Thus, when the Security Considerations section says that "this approach only serves as a guideline" and that the issue of enforcement is not a technical problem, it's even worse than that -- the feature doesn't even serve as a usable guideline in many situations.

*Contact recursion* (COMMENT)

Section 3.7 says

    "When Contact elements are
      defined recursively, only the leaf instances (those Contact
      instances not containing other Contact instances) represent actual
      points of contact."

The example in section 7.2 has a Contact node containing another Contact node:

     
        CSIRT for example.com
        contact@csirt.example.com
        +1 412 555 12345
       
       
          Joe Smith
          smith@csirt.example.com
       
     

The spec text about leaf instances encourages implementations to ignore data that has been overridden in a nested Contact: in this example, the top-level ContactName and Email would be ignored if it's strictly treated as "not an actual point of contact".  Yet presumably the information is valid, and useful.  I do see that if the incident report is forwarded publicly the "need-to-know" restriction might imply that the forwarder would strip out the internal Contact, leaving only the external Contact and now the top-level ContactName and Email are used.    However, in order to deduce this I'm  making a number of assumptions that may or may not be right and are probably insufficiently supported by the spec.

[Ballot discuss]
*Extensions and validation*

The guideline in section 5.2:

  3.  Implementations MUST NOT validate the schemas that they do not understand

... needs to be made more clear.  (a) Schemas aren't validated, documents are validated against one or more schemas.  (b) "Don't understand" is very casual. (c) It's not clear which implementation is subject to this requirement and the others in this section. 

The real, underlying problem here, is that if a document has an extension schema that the consumer of that document doesn't have, then the consumer cannot validate the document at all (unless it could somehow download the extension schema, and we've already discussed the problems with that.)  XML Extensions are surprisingly incompatible with validation, and this document is still unclear in its requirements to implementors around that issue.

*Language tagging*

Section 6: language tagging requirements use the "lang" attribute that is standard for XML, but do not use the correct namespace -- it should be "xml:lang".  See section 2.1 of http://www.w3.org/TR/REC-xml/. 

*Namespace*

Section 4.2

  "The IODEF schema declares a namespace of "iodef-1.0" and registers it
  per [4]." Each IODEF document MUST use the "iodef-1.0" namespace in
  the top-level element IODEF-Document.  It can be referenced as
  follows:

    does not mention registering anything.  It's RFC3553 which discusses registering in "urn:ietf:params". Strictly speaking, the namespace registered is "urn:ietf:params:xml:ns:iodef-1.0", not "iodef-1.0" (the shorter string is a sub-namespace or identifier). 

The explanation of how the namespace "can" be referenced is a passive non-normative statement.  IODEF needs to be absolutely clear whether incident reports MUST provide the schema location in addition to the implied requirement of declaring the namespace. 

The prefix "xsi" is not declared here.  The version value is unusual; it's usually "1.0".  Since I believe version comparisons may be string comparisons, this is probably important. 

*Restriction handling*

Section 3.2, restriction definition:  This specification does not indicate how to handle restrictions, particularly with inheritance involved.  It's not specified what it means to "honor" a restriction. 
- MUST a recipient strip out restricted elements nested within unrestricted elements before forwarding or publishing?  Or does the presence of any restricted elements mean that the entire document MUST NOT be forwarded or published? The granular privacy features seem like a probable pain point to me -- too flexible to be sanely implemented.
- What's the meaning of something that's of restriction "public" within a container of restriction "private"?  That nesting doesn't make sense to me.
- "need to know" is not defined, there's only a suggestion of what it *might* mean.

  Thus, when the Security Considerations section says that "this approach only serves as a guideline" and that the issue of enforcement is not a technical problem, it's even worse than that -- the feature doesn't even serve as a usable guideline in many situations.

*Contact recursion* (COMMENT)

Section 3.7 says

    "When Contact elements are
      defined recursively, only the leaf instances (those Contact
      instances not containing other Contact instances) represent actual
      points of contact."

The example in section 7.2 has a Contact node containing another Contact node:

     
        CSIRT for example.com
        contact@csirt.example.com
        +1 412 555 12345
       
       
          Joe Smith
          smith@csirt.example.com
       
     

The spec text about leaf instances encourages implementations to ignore data that has been overridden in a nested Contact: in this example, the top-level ContactName and Email would be ignored if it's strictly treated as "not an actual point of contact".  Yet presumably the information is valid, and useful.  I do see that if the incident report is forwarded publicly the "need-to-know" restriction might imply that the forwarder would strip out the internal Contact, leaving only the external Contact and now the top-level ContactName and Email are used.    However, in order to deduce this I'm  making a number of assumptions that may or may not be right and are probably insufficiently supported by the spec.

[Ballot discuss]
This is not necessarily intended to block the document, but as this targets Proposed Standard I would like to understand how interoperability was tested and how will the document be advanced on the standards track.

There is a terminology problem here with the terminology used here being inconsistent with the one in RFC 3444. What is called here an Abstract Data Model seems to be an Informational Model according to RFC 3444. One may argue that 3444 targets management information, but I do not really see the difference. It would be more clear I believe to align terminology.

Whatever it is named this part cannot be considered normative text and tested for interoperability. Actually it is the XML schema that is the core of the normative text, and this needs to be made clear. But how is this document supposed to be progressed on standards track? I suppose people would run interoperability testing on a SOAP transport over BEEP or HTTP/TLS using the XML schema. This is where the text in
4.3 concerns me, as it seems to leave room to different implementations at the application level and it is not clear how interoperability can be proved.

  'There are
  numerous data dependant definitions in the data model that cannot be
  easily encoded in the schema.  They must be handled by additional
  logic in the parser.'

I need some clarification here and maybe the text needs some clarification as well to what is the normative and interoperable part.

[Ballot discuss]
Section 2.9., paragraph 1:
>    A timezone offset from UTC is represented by the TIMEZONE data type.
>    It is formatted according to the following regular expression:
>    "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".

  DISCUSS: Regexps aren't sufficiently standardized to usefully describe
  what format timezone and portlist strings can have. Suggest to use
  ABNF to describe their format.

[Ballot comment]
Section 2 defines Bytes (octets are encoded using base64) and
  Hexadecimal Bytes (octets are encoded as a character tuple
  consisting of two hexadecimal digits), but neither of these
  are used in the schema.

IANA Last Call Comments:

Upon approval of this document, the IANA will perform
the following Actions:

Action 1:

Upon approval of this document, the IANA will make the
following assignments in the "IETF XML Registry"
registry, subregistry "ns", located at

http://www.iana.org/assignments/xml-registry/ns.html


ID URI Registration Template Reference
-- --- --------------------- ---------
iodef-1.0 urn:ietf:params:xml:schema:iodef-1.0
[iodef-1.0 Section 10]  [RFC-inch-iodef-11]



Action 2:

Upon approval of this document, the IANA will make
the following assignments in the "IETF XML Registry"
registry, subregistry "schema", located at

http://www.iana.org/assignments/xml-registry/schema.html


ID URI Filename Reference
-- --- -------- ---------
iodef-1.0 urn:ietf:params:xml:schema:iodef-1.0
[iodef-1.0 Section 8]  [RFC-inch-iodef-11]


We understand the above to be the only IANA Actions
for this document.

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?

As the working group chair is the author of this draft, Kathleen Moriarty
ran the WG last call and judged consensus. This delegation was announced
on the list:

https://listserv.surfnet.nl/scripts/wa.exe?A2=ind06&L=inch&O=D&P=6764

A successful resolution of all issues was declared:

https://listserv.surfnet.nl/scripts/wa.exe?A2=ind06&L=inch&O=D&P=7881

(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. In addition
to review by individuals in and out of the WG, the document has benefited
from seven independent implementations and an inter-op event.

(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. Furthermore, its specification of a Schema would dictate that
an XML expertise would also be required.

(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 (chair and co-author) have reviewed the document for any idnits.

(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. All normative references are in a well-defined state: RFCs,
W3C Recommendations, or ISO standards.

(1.i) The IESG approval announcement

Technical Summary

The Incident Object Description Exchange Format (IODEF) defines a
data representation that provides a framework for sharing information
commonly exchanged by Computer Security Incident Response Teams
(CSIRTs) about computer security incidents. This document describes
the data model for the IODEF and provides the associated XML Schema.

Working Group Summary

There is consensus in the WG to publish this document.

Document Quality

There are seven implementations of the IODEF that provided useful
feedback on the completeness and quality of the specification. These
implementations come from CERT-Verbund (SIRIOS), Cooper-Cain Inc.*
(Anti-Phishing WG), Cyber Solutions Inc.*, DFLabs*, eCSIRT.net, MIT
Lincoln Labs*, and NTT*. Furthermore, a subset of these organizations
(noted via an asterisk) participated in a semantics inter-operability
event that also yielded additional feedback on the data model.