--On Thursday, May 9, 2019 11:16 -0500 Adam Roach
<adam@xxxxxxxxxxx> wrote:
> To be clear, what I'm trying to establish is an expectation
> that these issues won't block publication, which is a rather
> different thing than suggesting that they not be raised. At
> the same time, Joel Halpern put his finger on the heart of the
> matter, which is that one of the major reasons we don't
> produce bis documents as frequently as would benefit
> implementors is a fear of late surprise during IESG review on
> the basis of unchanged text. Consequently, we really need a
> pretty strong signal that using the process described in this
> document is unlikely to result in such a situation.
Adam,
That piece of analysis (and Joel's comments to which you refer)
suggests something else and opens up another can of worms
(although neither a new can nor new worms).
Suppose we have a technical specification and it contains three
kinds of sections:
(i) Those (the majority) that are just fine.
(ii) Those in which we've discovered glitches that are in need
of clarifications or adjustments to make implementations of the
protocol interoperate well, at least most of the time, and for
which we have consensus on fixes.
(iii) Some truly nasty issues, probably associated with edge
cases, for which we have rough consensus that there are
problems, but they are problems only in rare circumstances and
we have no consensus at all about how to fix them.
Now, if only cases (i) and (ii) exist in a particular document,
I think creation of a replacement draft and application of a
procedure similar to the one you describe should work well.
However, if some of that third case exists -- whether they are
known when writing starts or uncovered only during IETF Last
Call on the new "bis" document, it is not clear to me how we
should proceed. If I correctly understand this I-D, the answer
is to leave the original (iii)-type text intact, to not list it
as changed, and to avoid discussing it when the "bis" I-D is
reviewed. Fine plan, except that it would deceive the reader
about the state of the (new) specification and would violate our
long-standing rule against publishing standards-track
specifications that contain known technical defects.
If the idea is that the "bis" document should either contain a
health warning or incorporate or reference an Applicability
Statement about the problem feature or cases, it seems to me
that the I-D should discuss those options.
And, of course, none of that addresses the cases in which other
documents exist that normatively reference the original RFC and
whether they are automagically treated as referencing the
replacement document (works for some types of changes that might
be covered by your I-D but not others) or continuing to
reference the older, now-obsoleted one.
john
