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 ...

[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:

  <iodef-document <br=""/>      version="1.00" lang="en-US"
      xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
      xsi:schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd"

The document at [4] <http://www.w3.org/TR/REC-xml-names/> 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:

      <contact role="creator" type="organization">
        <contactname>CSIRT for example.com</contactname>
        <email>contact@csirt.example.com</email>
        <telephone>+1 412 555 12345</telephone>
       
        <contact role="tech" type="person" restriction="need-to-know">
          <contactname>Joe Smith</contactname>
          <email>smith@csirt.example.com</email>
        </contact>
      </contact>

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 ...

[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:

  <iodef-document <br=""/>      version="1.00" lang="en-US"
      xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
      xsi:schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd"

The document at [4] <http://www.w3.org/TR/REC-xml-names/> 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:

      <contact role="creator" type="organization">
        <contactname>CSIRT for example.com</contactname>
        <email>contact@csirt.example.com</email>
        <telephone>+1 412 555 12345</telephone>
       
        <contact role="tech" type="person" restriction="need-to-know">
          <contactname>Joe Smith</contactname>
          <email>smith@csirt.example.com</email>
        </contact>
      </contact>

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.