[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
- [mile] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
- Re: [mile] Ben Campbell's No Objection on draft-i… Panos Kampanakis (pkampana)
- Re: [mile] Ben Campbell's No Objection on draft-i… Ben Campbell