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

Michael Richardson <> Thu, 11 April 2019 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68474120363; Wed, 10 Apr 2019 17:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 93FHqWCU5_hw; Wed, 10 Apr 2019 17:25:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B0A5120092; Wed, 10 Apr 2019 17:25:28 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id A51541F483; Thu, 11 Apr 2019 00:25:25 +0000 (UTC)
Received: by (Postfix, from userid 179) id F2FC64291; Thu, 11 Apr 2019 01:43:22 +0200 (CEST)
From: Michael Richardson <>
To: Russ Housley <>
In-reply-to: <>
References: <>
Comments: In-reply-to Russ Housley via Datatracker <> 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: <>
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-roll-useofrplinfo-25
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Apr 2019 00:25:38 -0000

Russ Housley via Datatracker <> 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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-