[secdir] early review of draft-ietf-i2rs-problem-statement-09

Stephen Kent <kent@bbn.com> Thu, 28 January 2016 19:36 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 64A851B3601 for <secdir@ietfa.amsl.com>; Thu, 28 Jan 2016 11:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v7xTO9ZTiPGJ for <secdir@ietfa.amsl.com>; Thu, 28 Jan 2016 11:36:50 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179451B35FD for <secdir@ietf.org>; Thu, 28 Jan 2016 11:36:50 -0800 (PST)
Received: from ssh.bbn.com ([]:34255 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1aOsMl-000OzE-D5; Thu, 28 Jan 2016 14:36:27 -0500
To: secdir <secdir@ietf.org>, akatlas@juniper.net, tnadeau@lucidvision.com, wardd@cisco.com, jhaas@pfrc.org, shares@ndzh.com, Deborah Brungard <db3546@att.com>, Alvaro Retana <aretana@cisco.com>
From: Stephen Kent <kent@bbn.com>
Message-ID: <56AA6DBA.8040306@bbn.com>
Date: Thu, 28 Jan 2016 14:36:26 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------030605070703000805060701"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/3dcX1_eP6ocsxVYLkXoxetglvSs>
Subject: [secdir] early review of draft-ietf-i2rs-problem-statement-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2016 19:36:52 -0000

SECDIR early review of draft-ietf-i2rs-problem-statement-09

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.These comments were written with the intent of improving security 
requirements and considerations in IETF drafts.Comments not addressed in 
last call may be included in AD reviews during the IESG review.Document 
editors and WG chairs should treat these comments just like any other 
last call comments.

This is a relatively short document describing the problem being 
addressed by the I2RS WG, and establishing some requirements for 
solutions. I reviewed the -04 version of this document in December 2014. 
This version is slightly longer and is improved.

In my previous review I noted a coupe of typos that have been fixed in 
this version. I also suggested that the Security Considerations section 
be revised. Although this section is still only one paragraph, the 
authors have removed the odd language I cited and have provided a 
pointer to the I2RS arch document. Thus the section has been approved.

I have a few suggested edits:

    The penultimate paragraph on page 2 contains a sentence that runs
    on for over 8 lines! Please break this into 2-3 sentences.

    colocated within -> co-located within

    re-organize the document so that Figure 1 fits on a single page

    must select the suitable protocol(s) -> must select suitable protocol(s)

    between the I2RS Clients and I2RS Agent -> between I2RS Clients and
    I2RS Agents

    must identify or define is a set -> must identify or define a set

    the last paragraph on page 5 flips between data model (singular) and
    data models (plural). Make this consistent.

    The example for recursion in Section 3 (paragraph 1 is confusing, at
    least to me).

    may also need to be -> also may need to be