Incident Object Description Exchange Format Usage Guidance
draft-ietf-mile-iodef-guidance-11

I'll also echo Ben / Benoit's comments and also thank Qin Wu for the OpsDir review. I've just seen that you have responded to it, thank you.

I especially don't understand the:
"Interoperability between RID agents and the standards, Use of  [RFC6545] and [RFC6546], were also proven in this exercise." -- is the "Use of" superfluous? I *think* so, and removing it fixes it, but I'm not quite sure what was intended.

Many of the nit checker things seem simply to solve (like the use of non-documentation addresses) - these should be addressed. 

In addition I have some nits:
Section3.1.  
"Minimal IODEF document IODEF includes one mandatory classes. "
s/classes/class/


Section 3.2.  Information represented
" The implementer should  carefully look into the schema and decide classes to implement (or not)." -- I think this is missing a "which" between "decide" and "classes".

I agree with the other comments that this reads like a BCP, and should probably be re-characterized.

The diagram in section 3.1 (which I would like to refer to by number but cannot -- consider adding figure numbers) appears to be using UML. While many software engineers will be familiar with this notation, it's likely that many also will not. A citation to ISO/IEC 19501:2005 to explain the meaning of the various symbols may be appropriate.

Section 3.1 says "Implementers can refer to Appendix B and Section 7 of [RFC7970]..." which is ambiguous: it reads as if it is directing readers to Appendix B of RFC7970. I think it means Appendix B of this document. Suggest: "Implementers can refer to Section 7 of [RFC7970] and Appendix B...".

Section 3.2 refers to the use of external schemata for reporting certain types of events. I would have expected to see guidance here (and/or in Section 4.2) indicating that the event report should be useful even for those implementations that don't comprehend these external schemata (unless this guidance already exists in the base IODEF definition; in which case, feel free to silently ignore this comment).

It would be useful to provide a definition of the term "spear-phishing."

____

I assume the version of the ID Nits tool used to check this document varies from the one at <https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mile-iodef-guidance-10.txt>. The following issues appear to be legitimate problems in need of addressing. If formatting of the XML documents without adding line breaks is considered critical (which seems possible but unlikely), consider base64-encoding them.

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 28 instances of too long lines in the document, the longest
     one being 53 characters in excess of 72.

  ** The abstract seems to contain references ([RFC7970]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  == There are 2 instances of lines with private range IPv4 addresses in the
     document.  If these are generic example addresses, they should be changed
     to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
     198.51.100.x or 203.0.113.x.

I think this is a useful document, but agree that this document's use of RFC 2119 is a bit handwavy in some places.

I agree with Ben in that the content is better suited for a BCP.

I'm confused by the use of 2119 language in this document. Some of it seems to restate requirements already defined elsewhere. Some of it seems too vague  for 2119 keywords (e.g. "SHOULD consider"). The rest seems like BCP material rather than informational, since it seems to say that we recommend people do certain things rather than describe choices and consequences. The latter is reasonable for an informational RFC, but the former belongs in standards track documents or BCPs. I suggest that the 2119 language be removed, the 2119 boilerplate be replaced with something that more accurately describes the intended meaning of MUST and SHOULD,  or that you reconsider the intended status.

IDNits calls out some issues that should be considered. (e.g. lack of an IANA considerations section.)

Otherwise, I have a number of editorial comments:

- General: This draft uses a lot of words (and repetition) to convey some very basic concepts. A good part of it could be summarized as "Don't include objects you don't need".  Please consider editing for conciseness.

- Title: Please expand IODEF in the title.

- Abstract: It's only necessary to expand CSIRT on the first mention in the abstract.

-1, first paragraph: Please mention the acronym IODEF the first time you expand it.

-3, first paragraph: " It is important for IODEF implementers to be able to distinguish how
   the IODEF classes will be used in incident information exchanges.  To
   do that one has to follow a strategy according to which of the
   various IODEF classes will be implemented.

I don't understand the point of the second sentence.  It seems to restate the idea from the first sentence in a more complicated way.

-3.3, 2nd paragraph: I have trouble following the first sentence. I _think_ this paragraph seeks to distinguish attempted attacks from successful attacks, without actually using those terms. 

-4, section title: What kind of considerations? I assume the entire document is about considerations of one form or another.

-4.1: s/cary/vary

-4.1, 3rd paragraph: "IODEF implementers SHOULD NOT consider using"
Does this mean "SHOULD NOT use"? (we can't really mandate what they consider.)

-4.4 "SHOULD be treated carefully": That's vague for a 2119 keyword--can you offer more concrete guidance? (Or avoid the keyword?)
"SHOULD consider" - also vague.

-5.1: It's not clear whether "section 7" refers to this document or to [implementreport].

-5.2: Please expand RID on first mention. s/compteting/competing

I noted the exact same point as Ben regarding the intended status.
This is really a BCP, right? https://tools.ietf.org/html/rfc2026#section-5
However, I believe the combination of BCP and RFC2119 language is fine.
If I take a single sentence, as an example:

   An IODEF document MUST include
   at least an Incident class, an xml:lang attribute that defines the
   supported language an the IODEF version attribute.

Is this a specification coming from RFC 7970 (which I could not find, by browsing for a few minutes)?
Or is this is a new specification of this "BCP"?

See also Qin's OPS DIR feedback.

* Please use example IP addresses from one or more of the documentation blocks in RFC6890 exclusively instead of using RFC1918 private addresses mixed in (e.g. 10.1.1.1)