[netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08

Robert Sparks via Datatracker <noreply@ietf.org> Fri, 02 August 2019 20:10 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D678F120189; Fri, 2 Aug 2019 13:10:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: netmod@ietf.org, ietf@ietf.org, draft-ietf-netmod-artwork-folding.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <156477661481.21003.10781222745111642469@ietfa.amsl.com>
Date: Fri, 02 Aug 2019 13:10:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rqlk5ua7dGtWVy9zQu0H5yKXvzs>
Subject: [netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 20:10:15 -0000

Reviewer: Robert Sparks
Review result: Has Nits

Reviewer: Robert Sparks
Review result: Has Nits

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 primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document introduces no new security concerns for the Internet.
It aims to establish conventions for wrapping long lines in source code 
sections of RFCs.

It does have shell scripts embedded in the Appendix. I see no obvious
security issues with those scripts.

I strongly suggest this document proceed as Informational and not BCP. 
It's fine if some documents adopt the convention. Other conventions may
work better for other groups. See, for example, the <allOneLine> convention
described in section 2.1 of RFC4475. (No automated wrap/unwrap scripts
have been written for that convention to my knowledge, but it would
not be hard to create some.)


In your headers, you anticipate receiving a two digit BCP number. At the
moment, the next available BCP number has three digits. (We are well
into the 200s). You have header lengths that would need to be adjusted.

In 7.2.1 paragraph 5, I think you're saying to fail if any lines in the
input document already end with a \. I think you mean to say any lines
that you are considering wrapping. If I'm correct, the clarification may
also need to be applied in other places where you say "the text content"