Re: [Gen-art] Genart last call review of draft-ietf-roll-useofrplinfo-25

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 11 April 2019 00:25 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68474120363; Wed, 10 Apr 2019 17:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93FHqWCU5_hw; Wed, 10 Apr 2019 17:25:31 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0A5120092; Wed, 10 Apr 2019 17:25:28 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [207.164.179.98]) by relay.sandelman.ca (Postfix) with ESMTPS id A51541F483; Thu, 11 Apr 2019 00:25:25 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id F2FC64291; Thu, 11 Apr 2019 01:43:22 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Russ Housley <housley@vigilsec.com>
cc: gen-art@ietf.org, roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org
In-reply-to: <155431284696.22772.5756397598445681320@ietfa.amsl.com>
References: <155431284696.22772.5756397598445681320@ietfa.amsl.com>
Comments: In-reply-to Russ Housley via Datatracker <noreply@ietf.org> message dated "Wed, 03 Apr 2019 10:34:07 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 10 Apr 2019 19:43:22 -0400
Message-ID: <23139.1554939802@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/FnrfXDQ4ZmGniUpa2y-qKA6bkOg>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-roll-useofrplinfo-25
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 00:25:38 -0000

Russ Housley via Datatracker <noreply@ietf.org> wrote:
    > Section 1 says:

    >    ... This document clarifies examples that intend to illustrate the
    > result of the normative language in RFC8200 and RFC6553.  In other
    > words, the examples are intended to be normative explanation of the
    > results of executing that language.

    > This set the wrong expectation for me.  What the document seems to be
    > doing is aligning with the recent normative change in RFC8200.  The
    > alignment could lead to a flag day, and this document suggests a way to
    > avoid a flag day.  It goes through a whole bunch of use cases to
    > illustrate the updates.

So, the actual order of operations was more like:
    - we aren't following 2460, so let's write down the right rules
    - oh, look, 2460bis is happening, can we get the rules changed?
    - cool, it happened, now what does that mean.

So I'll try to fix the text to match what a reader would now expect.
Can you help with that paragraph? How about:

    } This document provides a series of examples that align RFC6553
    } with the recent changes in processing described in RFC8200.  In other
    } words, the examples are intended to be normative explanation of the
    } results of executing that language.
    } Existing deployed networks may experience a flag day as a result of
    } some of the suggested changes, and this document provides a way
    } to mitigate such an occurance.


    > Nits:

    > In Table 6, please move some of the whitespace on the right to the
    > first column to avoid so many words being split across lines.

I don't think we control the table formatting, xml2rfc does.
I'll see if I can do something about that.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-