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

[Adam Roach <[e-mail]>]

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.