Re: [mile] Ben Campbell's No Objection on draft-ietf-mile-iodef-guidance-10: (with COMMENT)

Thank you for the detailed review Ben.

About the normative language, we went and removed all the uses of uppercase normative language as we are not defining any new requirements for the protocols themselves. We used lowercase language that reiterates the "Informational" draft suggestions this document is making. I expect that there will be text in the Status of the Memo section saying "This document is not an Internet Standards Track specification; it is published for informational purposes." in the published informational doc. Xml2rf was not adding it automatically. 

Also removed references of 2119. 

We also rephrased or deleted a couple of sentences that you correctly pointed out were not clear.

The rest of the issues and nits you pointed out are fixed as well, except for the RID one because RID was expanded above in the doc. 

The -11 version will be updated this week. 

-----Original Message-----
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Tuesday, August 29, 2017 7:07 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-iodef-guidance@ietf.org; mile@ietf.org; mile-chairs@ietf.org
Subject: [mile] Ben Campbell's No Objection on draft-ietf-mile-iodef-guidance-10: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-mile-iodef-guidance-10: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

_______________________________________________
mile mailing list
mile@ietf.org
https://www.ietf.org/mailman/listinfo/mile