Re: Comments on draft-roach-bis-documents-00

[David Noveck <[e-mail]>]

>>    - Delete Section 4.

> (Section 4 is "Implications for Other Documents")

Oops.   What I intended was to delete the to-Do section, which is section
5.  Sorry about that.

On Wed, May 15, 2019 at 1:08 AM John C Klensin <[e-mail]> wrote:

> On Fri, 10 May 2019 23:32 UTCDavid Noveck <[e-mail]>
> 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
>
>