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

Ben Campbell <ben@nostrum.com> Tue, 29 August 2017 23:07 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A301326BB; Tue, 29 Aug 2017 16:07:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-iodef-guidance@ietf.org, mile-chairs@ietf.org, ncamwing@cisco.com, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150404804107.21445.3865722523779300659.idtracker@ietfa.amsl.com>
Date: Tue, 29 Aug 2017 16:07:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/jgIo6Kg41Bo_zckm7SMRPP3TCmM>
Subject: [mile] Ben Campbell's No Objection on draft-ietf-mile-iodef-guidance-10: (with COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 23:07:21 -0000

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