Subject: [apps-discuss] Early Appsdir review of draft-ietf-mile-enum-reference-format-08

From: [email-masked] (Henry S. Thompson)
Date: Fri, 12 Sep 2014 17:59:41 +0100

I have been selected as the Applications Area Directorate reviewer for
this draft.

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your WG chairman(s)
before posting a new version of the draft.

Document: draft-ietf-mile-enum-reference-format-08
Title: IODEF Enumeration Reference Format
Reviewer: Henry S. Thompson
Review Date: 2014-09-12
Summary: This draft has a serious structural problem, which needs to
be resolved before it can progress

Major Issues:

This draft identifies a problem with _The Incident Object Description
Exchange Format_ (IODEF) [1] as regards the means provided to specifiy
references to IDS alerts etc., and proposes changes to the Reference
class in IODEF [2] and to its XML serialization.

The proposal as such is fine, but the draft does not adequately
address the question of how the proposed change is to be integrated
into the existing definition of the XML serialization, as specified in
the XML schema given in IODEF [3].

The schema given in IODEF puts the (original) ReferenceName element in
the IODEF namespace, urn:ietf:params:xml:ns:iodef-1.0.  The schema
given in the draft at hand puts the new one in a new namespace,
urn:ietf:params:xml:ns:iodef-enum-1.0 .

This means that the example Reference serialization given in section
2.1 cannot be validated successfully, either against the IODEF schema,
or the one in this draft, or a combination of the two.

I note that IODEFv2 [4] has no changes in this regard either.

I think this needs to be coordinated with IODEFv2, so that it contains
a revised schema for the IODEF namespace.  There a number of ways this
could be done, depending on the approach you jointly agree to take wrt
backwards compatibility.  Assuming you want backward compatibility,
i.e. you want existing IODEF XML serializations to be valid against
the schema in IODEFv2, then you will want

 a) To make the example explicit wrt namespaces:

      <iodef:Reference xmlns:iodef-enum="urn:ietf:params:xml:ns:iodef-enum-1.0"
                      xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
         <iodef-enum:ReferenceName specIndex="1">
            <iodef-enum:ID>CXI-1234-XYZ</iodef-enum:ID>
         </iodef-enum:ReferenceName>
         <iodef:URL>http://cxi.example.com</iodef:URL>
         <iodef:Description>Foo</iodef:Description>
      </iodef:Reference>

 b) To modify the IODEFv2 schema along the following lines:

    <xs:import namespace="urn:ietf:params:xml:ns:iodef-enum-1.0"/>

    ...

    <xs:element name="Reference"
                xmlns:iodefEnum="urn:ietf:params:xml:ns:iodef-enum-1.0">
      <xs:complexType>
        <xs:sequence>
          <xs:choice>
            <xs:element name="ReferenceName"
                        type="iodef:MLStringType"/>
            <xs:element ref="iodefEnum:ReferenceName"/>
          </xs:choice>
          <xs:element ref="iodef:URL"
                      minOccurs="0" maxOccurs="unbounded"/>
          <xs:element ref="iodef:Description"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>

Minor Issues:

1) Please clarify whether the 'abbreviation' field in the registry is
   required or optional, and include an 'abbreviation' in the example
   registry entry.

2) Please explain what the 'version' entry in the registry is for --
   version of what?  If it's a version of the specification, how is
   that not covered by the 'specification' field?  The reader finds
   the use of 'version: any' in the registry example completely
   baffling. . .

3) Broken record time: The lack of any specified mapping from the (to
   my mind) unnecessary level of indirection from integers via
   registry entries to URIs which would actually give _access_ to such
   entries is irritating at least.  Can't we at least _ask_ that IANA
   provide such a mapping, along the lines of

   http://www.iana.org/assignments/enumeration-reference-type/abbrev_version

Nits:

The subsections of section 2 must not be marked up properly, as they
don't make it into the index.

[1] https://tools.ietf.org/html/rfc5070
[2] https://tools.ietf.org/html/rfc5070#section-3.9.1
[3] https://tools.ietf.org/html/rfc5070#section-8
[4] http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-08.html

-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: "Black, David" <[email-masked]>
Date: Fri, 19 Sep 2014 12:38:03 -0400

Henry,

Thank you for this review, and on the major issue, namely use of this schema
by IODEF, this draft is guilty as charged ;-).

The current intent (as I understand discussion in the mile WG) is that the
existing IODEF schema (RFC 5070) will not be updated, but a future version
of the IODEFv2 draft will use this reference format via reference to the
schema in this draft.

On the first two registry issues:
	- All the fields are mandatory, including abbreviation, which
		is used in the schema.
	- Version is the version of the referenced specification.
We'll make all of this clear in the revised draft.

>    http://www.iana.org/assignments/enumeration-reference-type/abbrev_version

So, for a reference to version 2.5 of the CXI spec, the URI would be:

http://www.iana.org/assignments/enumeration-reference-type/CXI_2.5

Is that what you envision?

If so, the current allowance for all printable ASCII characters in version
strings will require percent-encoding in those URIs, e.g. if a '/' is embedded
in a version string.

Thanks,
--David

> -----Original Message-----
> From: Henry S. Thompson [mailto:[email-masked]]
> Sent: Friday, September 12, 2014 1:00 PM
> To: [email-masked]; draft-ietf-mile-enum-reference-
> [email-masked]; [email-masked]
> Cc: Melnikov Alexey <[email-masked]> Takeshi Takahashi; S Moonesamy;
> Claudio Allocchio
> Subject: Early Appsdir review of draft-ietf-mile-enum-reference-format-08
>