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

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.

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 <some entity> 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 <entity> use third parties for which there is a trust relationship <that meets these criteria>.

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.

opsdir review looked fine

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)

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.

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.