[secdir] Secdir telechat review of draft-ietf-netmod-rfc6087bis-18

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 22 February 2018 19:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBDE12DA40; Thu, 22 Feb 2018 11:58:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: secdir@ietf.org
Cc: ietf@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6087bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151932948231.8096.10376000064045374752@ietfa.amsl.com>
Date: Thu, 22 Feb 2018 11:58:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jnAnJVymlTlKmLrqNBIfntWdJ4c>
Subject: [secdir] Secdir telechat review of draft-ietf-netmod-rfc6087bis-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Feb 2018 19:58:02 -0000

Reviewer: Stephen Farrell
Review result: Ready


I reviewed the diff between -18 and RFC6087. [1]

   [1] https://www.ietf.org/rfcdiff?url1=rfc6087&url2=draft-ietf-netmod-rfc6087bis-18

I assume the security ADs were involved already in discussion about
the new security considerations template in 3.7.1 and the text there
does seem fine to me, so I won't even nit-pick about it:-)

I do have some other nits to note though.

- There are a number of URLs given for access to updated materials
that use http schemed URLs and that do not use https schemed URLs.
There was a recent IESG statement to the effect that those'd be better
as https URLs. The first such example is in 3.1. In fact that URL is
re-directed (for me) to https. I think a general pass to fix such URLs
to use https wherever possible would be easy and better practice.

- Some of the namespaces use http schemed URLs, for example in
section 4.2. I don't know if people are expected to de-reference such
URLs, but if they are then it'd be good to say if https is better to use
or not. (I'd argue it is.) If those URLs are not expected to be 
de-referenced, then saying that would be good. (Not that it'd stop 
people de-referencing 'em so the change is better in any case;-)

Cheers,
S.