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

Thank you Adam. All addressed. Will be in the next upload coming soon.

The only thing not addressed so far is the nit checker complaints about long lines. I think that will not be an issue in the end. 

-----Original Message-----
From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Thursday, August 31, 2017 12:28 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-iodef-guidance@ietf.org; mile@ietf.org; mile-chairs@ietf.org
Subject: [mile] Adam Roach's No Objection on draft-ietf-mile-iodef-guidance-10: (with COMMENT)

Adam Roach 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 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.

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