Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)
draft-ietf-mile-enum-reference-format-14

[Ballot comment]
This looks a bit random:

  The aggregate classes that constitute ReferenceName:

      ID
        One. ID. Name of the reference.

I see that it's analogous to similar statements in RFC 5070, but it would be nice if you wrote it out less tersely.  As written it looks like a mistake--like something got left out when the document was rendered.

[Ballot comment]
None of these comments are highly important, and none are meant to block the document.  Please consider these and discuss them with me if you think it's appropriate... but I'll leave it to the authors/shepherd/working group/AD to decide whether to make any changes.  Thanks.

I'm not happy with the 2119 "SHOULD"s in the Security Considerations.  None of them appear to be protocol-related: they're all sound advice, and such advice should definitely be given, but it would fit better with both 2119 and reasonable understanding if these were just put in terms of sage advice with reasons and consequences given (which you are giving; thanks).

In particular, "producers ... SHOULD be careful to ensure ..." is certainly not in compliance with 2119; I'd say "It is very important that producers of IODEF [IODEF] content ensure a proper mapping...."

I'm not sure what "SHOULD be preferred" even means, so I think fixing this one is important.  If what you mean is that if  is receiving enumeration reference IDs and has a choice between a trusted source and an untrusted one, it should use the trusted source, then please say it that way, and don't use passive voice.

Similarly, "trust SHOULD extend from... to...": this would be far better if we got rid of the passive voice and said that it's highly recommended that  use third parties for which there is a trust relationship .

In the IANA Considerations...

I note that you have ABNF grammar to define "abbreviation", and presume that grammar is for the designated expert's use, and not really aimed at IANA.  That's fine (just see below).

        Version: The version of the enumeration (i.e. the referenced
        specification) as a free-form string from the printable ASCII
        character set excepting white space.

It might be good, I think, to have ABNF here as well, also for the designated expert... lest some DE in the future wonder which characters are part of "the printable ASCII character set" and which are "white space".

Thank you for giving good instructions to the DE; that's important.

I would lost the "MUST", and just say that the designated expert will review any specification that is associated with the request.  Again, this isn't a protocol interop issue, which is what 2119 language is generally for.

[Ballot comment]


These are nits only, feel free to ignore entirely or
fix as you prefer.

- The write-up says that this updates 5070 but the
abstract says it does not. I'm fine either way but it's
a little confusing. (That is, I agree with Adrian.)

- Maybe expand IDS in abstract

- Maybe expand CVE, CCE etc too

- "readily apparent" makes me think I'm reading a
patent, and thus slightly less happy:-)

- I don't know what "trust SHOULD extend" might mean
(but it's harmlessly ok I think)

- I was surprised you didn't at least include the CVE
as an initial registration.

[Ballot comment]
In 3  Security Considerations

      Producers of IODEF [IODEF] content SHOULD be careful to ensure a
      proper mapping of enumeration reference ID elements to the correct
      SpecIndex. Potential consequences of not mapping correctly include
      inaccurate information references and similar distribution of
      misinformation.
     
I'm not understanding why SHOULD is appropriate. When would a producer not ensure a proper mapping?

("SHOULD be careful to" seems like "SHOULD" would be appropriate, but I'll leave that up to you)

[Ballot comment]
I have read and re-read the Abstract, Introduction, and shepherd
write-up.

I think the Abstract gives the false impression that this extension is
not to be used with IODEF v1. I believe it is your intention that this
feature should become selectively available in enhanced v1
implementations.

The confusion arises because of:

  While this memo does not update IODEV v1, this
  enumeration reference format is used in IODEF v2 and is applicable to
  other formats that support this class of enumeration references.

This sounds like, but does not say, the format is not to be used with v1
deployments. (NB "IODEV"???)

I think you need:

  While this memo does not update IODEF v1 because it is not necessary
  for IODEF v1 implementations to support the enumeration reference
  format, new or upgraded IODEF v1 implementation may include support
  for the format.  Furthermore, the enumeration reference format is
  used in IODEF v2 and is applicable to other formats that support this
  class of enumeration references.

This also (I think) helps explain why this is a stand-alone document and
not part of the 5070bis document.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mile-enum-reference-format-10. Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments, along with two questions:

IANA has a question about the request in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

IANA is to create a new registry called the Enumeration Reference Type Identifiers registry. The new registry will consist of the following fields:

Full Name: The full name of the enumeration as a string from the printable ASCII character set.

Abbreviation: An abbreviation may be an acronym - it consists of upper-case characters (at least two, upper-case is used to avoid mismatches due to case differences), as specified by this ABNF [RFC5234] syntax:

ABBREVIATION = 2*UC-ALPHA ; At least two
UC-ALPHA = %x41-5A ; A-Z

Multiple registrations MAY use the same Abbreviation but MUST have different Versions.

SpecIndex: This is an IANA-assigned positive integer that identifies the registration. The first entry added to this registry uses the value 1, and this value is incremented for each subsequent entry added to the registry.

Version: The version of the enumeration (i.e. the referenced specification) as a free-form string from the printable ASCII character set excepting white space.

Specification URI: A list of one or more URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. The URI SHOULD be a stable reference to a specific version of the specification. URIs that designate the latest version of a specification (which changes when a new version appears) SHOULD NOT be used.

IANA QUESTION --> Typically, a reference for registrations is included as one of the fields in a new registry. This field generally points to an RFC/I-D, the person who made the request, or a standards organization. Do you want a separate field for this, or would you prefer that the registry not include this information? Alternatively, would it be appropriate to label the field "Specification URI/Reference" and allow both URIs and other references there?

IANA understands that there are no initial registrations in the new registry. The new registry is to be managed through Specification Required as defined by RFC 5226.

IANA QUESTION -> Where should this new registry be located? Should it be placed at an existing URL? If not, does it belong in an existing category at http://www.iana.org/protocols, or a new one? If you'd like us to create a new webpage and/or a new category, please provide the titles of each.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IODEF Enumeration Reference Format) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document:
- 'IODEF Enumeration Reference Format'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Incident Object Description Exchange Format (IODEF) is an XML
  data representation framework for sharing information about computer
  security incidents.  In IODEF, the Reference class provides
  references to externally specified information such as a
  vulnerability, IDS alert, malware sample, advisory, or attack
  technique.  In practice, these references are based on external
  enumeration specifications that define both the enumeration format
  and the specific enumeration values, but the IODEF Reference class
  (as specified in RFC 5070) does not indicate how to include both of
  these important pieces of information.

  This memo establishes a stand-alone data format to include both the
  external specification and specific enumeration value, and
  establishes an IANA registry to manage external enumeration
  specifications.  While this memo does not update IODEF, it provides
  the ability for future revisions of IODEF to leverage the
  ReferenceName class herein described.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is David Waltermire. The responsible Area Director is Kathleen Moriarty.

The Incident Object Description Exchange Format (IODEF) provides a Reference class used to reference external entities (such as enumeration identifiers). However, the method of external entity identification has been left unstructured. This document describes a method to provide structure for referencing external entities for the IODEF Reference class and thus updates IODEF's ReferenceName. It defines an IANA registry that lists the identifiers of enumeration reference types that can be referenced from the Reference class. This is an important update to the base spec and it defines a format extension, so Proposed Standard is suitable. The working group is quite sure that this will be a useful Standards Track update to RFC5070.


2. Review and Consensus

This update is straightforward, and there was no difficulty coming to consensus on all points. The document received extensive review by the MILE working group since its first draft (published on September 1, 2012). The format of the identifier has been discussed and revised. Consequently, the structure of IANA registry has also been revised over time. All the discussion comments were reflected to the current version of the draft. The draft has completed WGLC and represents the consensus of the WG with no controversy. We believe the working group is solidly behind this. Expert review has been requested from the AppsDir to review the document, with a focus on the XML schema changes.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR issues so long as we can recognize.

4. Other Points

The document creates an IANA registry for identifiers to be referenced from IODEFF's Reference class subject to expert review and specification required.

Based on the last call, conducted in May 8-26, the authors have already published revised draft (draft-ietf-mile-enum-reference-format-05.txt).
The draft has reflected all the comments discussed during the last call period.