On Fri, 10 May 2019 23:32 UTCDavid Noveck <davenoveck@xxxxxxxxx>
wrote:
>...
> I have a couple of issues with the doument that I'd like to
> bring to your attention. They concern the use of the term
> "bis documents" and some apparent assumptions about how
> easy/diffcult it might be to get to a usable base document to
> which desirted cghanges might be made. Details below.
David,
I have several difficulties with the document, ones that overlap
with your only slightly. I'm trying to compose a response that
reflects those but, in the interim, I want to address two of
your points.
> - It has the unfortunate effect of obscuring what you have
> done, which is provide a way to do something desirable,
> that had not been possible before. Instead, it treats your
> work as merely providing a new procedure for doing
> something that has been done all along. In fact, the procedure
> for making major updates remains as it was, while you have
> provided a usable procedure for doing something that has,
> practically speaking, for many working groups, not been
> possible before, i.e. as your title indicates, it provides
> "A Process for Handling Non-Major Revisions to Existing
> RFCs"
I think your "not possible before" may be correct but am not
sure. If it is correct, it changes the I-D from the relatively
minor bit of procedural tuning that I believe Adam thinks it is
to an actual procedural change that would require updating RFC
2026 or some related document. If that is the case, the comment
I made earlier that, based on how other procedural documents
intended as small patches have been handled by the IESG, I
expect to see a proposal for a WG-forming BOF on this area and a
separate mailing list and expect that we should have seen at
least the latter before this.
> - Delete Section 4.
(Section 4 is "Implications for Other Documents")
If this is really something that could not be done before, then
it seems to me that a careful explanation of when it should or
should not be used and what mechanisms it replaces is absolutely
critical. If it could be done before and this is merely
providing guidance, they it is equally important.
More generally, my sense of the way IETF technical
specifications that have been around for a long time and that
have evolved and been corrected several times is that the case
Adam seems to have in mind in this specification, and, if I
understand your comments correctly, the case you are concerned
about with NFSv4.x, may be the exception rather than the rule.
A somewhat different set of cases involves a base RFC for which
there are multiple errata, multiple documents that correct or
extend the protocol, other documents (perhaps even some non-IETF
ones) that point to the base one without specific awareness of
those corrections or extensions (perhaps because they precede
the latter), and so on. In some cases, "bis" and even "ter"
documents have been produced to replace the original RFC and
draw things together, but the documents that normatively
reference (and, by definition depend on) the earlier one(s) are
still out there. That suggests a situation of considerable
complexity, one in which it is very difficult for a typical
reader to figure out just what the standard is, especially if
some of the newer documents override sections of the older ones
to which intermediate documents refer but are not simultaneously
changed. If a new "bis" (or whatever one wants to call it)
document can take the position that there are some known issues
in the original one that are known but not fixed, it both
increases the difficulty of an implementer (or someone
evaluating an implementation) figuring out the IETF actual
intent and the long-standing rule (from 2026 and earlier) that
we try to avoid publishing standards-track specs with known
omissions or deficiencies.
In addition to an assortment of individual proposals, the IETF
had at least one WG that tried to address these issues. It
concluded that a new class of documents were needed to draw
things together and discuss relationships even though some of
that work could be done with Applicability Statements (a
mechanism I believe we have used too little in recent years).
The reason that WG's work didn't go anywhere is part of a
separate discussion, but I don't see any practical way to
discuss and build on this I-D without the type of material that
appears in Section 4... and, indeed, rather more of that
material rather than eliminating it.
best,
john
