Subject: [Roll] Genart last call review of draft-ietf-roll-useofrplinfo-25

From: Russ Housley via Datatracker <[email-masked]>
Date: Wed, 03 Apr 2019 10:34:07 -0700

Reviewer: Russ Housley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-roll-useofrplinfo-25
Reviewer: Russ Housley
Review Date: 2019-04-03
IETF LC End Date: 2019-04-11
IESG Telechat date: unknown

Summary: Ready with Nits

Major Concerns:

None.

Minor Concerns:

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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Apr 2019 19:43:22 -0400

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

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.

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 30 Apr 2019 14:53:09 -0400

Russ, thank you for your review. Michael, thank you for your response. I entered a No Objection ballot.

Alissa

> On Apr 10, 2019, at 7:43 PM, Michael Richardson <[email-masked]> wrote:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art