Russ Housley via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature
