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

Kent Watsen <> Mon, 05 August 2019 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 071291200C5; Mon, 5 Aug 2019 12:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eL67Uu8uHxjl; Mon, 5 Aug 2019 12:30:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1744120048; Mon, 5 Aug 2019 12:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1565033442; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MIa1rijkblopES+qh5UhSADGDShf7ppBDXXBiaI63hc=; b=G5i8PVpqxMOR0OI+T6098Hcad3PxSH3vDk/j1guLnQ7vRbeQJyBkq/EBq8e4ndhM VQjt61FWnTiIqvpxxLndgODEYM3RqXGfJk9a2UjrWfoHqEqQLDjDCnPQdIkFO4JxcVU 45p5C7qr1P5MuUFyGBci00yup0lFAj+UCyrOoDmo=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F666228C-C399-4535-A1A2-AC8B9803A80A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 05 Aug 2019 19:30:42 +0000
In-Reply-To: <>
Cc:,, "" <>,
To: Robert Sparks <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.05-
Archived-At: <>
Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-artwork-folding-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Aug 2019 19:30:49 -0000

Hi Robert,

I'm glad that you reviewed this draft, as I envision backend Datatracker integration may be desired (as we discussed in the Code Sprint before).

> On Aug 2, 2019, at 4:10 PM, Robert Sparks via Datatracker <> wrote:
> 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.)

The BCP status was recommended by the WG.  I'll defer my own opinion at this time.

Regarding <allOneLine>, I think that you're actually making a case for why this should be a BCP    ;)

FWIW, the NETMOD WG (and it's sister WG, NETCONF) have a long history of using XML-based inclusions in RFCs.

> Nits: 
> 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.

Good catch. this has been fixed in my local copy.

> 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"

Updated.  My local copy now reads:

      Scan the text content to ensure no existing lines already end with a
      backslash ('\') character, as this could lead to an ambiguous result.
      If such a line is found, and its width is less than the desired maximum,
      then it SHOULD be flagged for forced folding (folding even though
      unnecessary). If the folding implementation doesn't support forced
      foldings, it MUST exit.</t>

The symmetric text in Section 8.2.1 already followed this form.

Kent // as co-author