--On Sunday, June 9, 2019 16:29 -0700 Christian Huitema
<huitema@xxxxxxxxxxx> wrote:
> On 6/7/2019 11:51 AM, Michael Richardson wrote:
>
>> As far as I can see, 8540 was produced by the tsvwg, and went
>> through IETF process. Yes, it's informational, rather than
>> standards track ("Updates"), but that seems somewhat
>> immaterial to me.
>
> I have read both John's draft and RFC 8450. John makes
> essentially two points: that informational documents should
> not "informally" update standard track documents, and that
> structuring a document as a catalog of erratas and updates
> makes for hard to read text.
>
> I would agree with John on the first point. The document
> status is important. RFC 8450 should have been published in
> the standard track, and it should have formally updated RFC
> 4960. If it had, people reading 4960 would immediately notice
> the "updated by" reference, but currently they don't.
>
> As for the second point, I think it a classic trade-off between
> timeliness and quality. This is best judged by the WG and the
> AD.
Christian,
Thanks. I'm trying to avoid discussing this non-IETF document
on the IETF list, but an observation about that tradeoff.
Assuming standards track, I think there is actually a three-way
tradeoff among:
(1) A list of so-called "verified" errata in the form taken by
8540.
(2) A list of changes (or, as some might say, patches) that have
IETF consensus, in the form of, e.g., RFC 4815 if the list is
intended to be comprehensive. Absent a desire to be
comprehensive, most of our "updates" documents fall into this
category as well and there is a potentially large range between
an update or two and a comprehensive patch list.
(3) A revised document that replaces the original one. That is
our classic "obsoletes" case and, with, AFAICT, a small
variation on draft-roach-bis-documents.
I see many tradeoffs between the variations on (2) and (3) and
agree with you that the choice is best judged by the WG and the
AD. However, the first raises some other issues. In no
particular order, the two most important are that it does not
reflect well on the IETF to publish documents in the RFC Series
that are not internally consistent or that otherwise create
confusion about what the actual content of a standard is. And
we actually have a rule (in RFC 2026) about known omissions: an
errata list cannot be comprehensive because whether or not
errata are filed is a bit serendipitous and different
corrections to the same section of text that are not obviously
consistent are certainly an omission of the language needed to
resolve those inconsistencies (8540 basically tells users to
sort it out themselves. In addition, if you look at the
ballots for 8540, you will see places where one or more ADs
claimed that the solutions in the listed errata are incorrect
and proposed others. That is a "known omission" if I've ever
heard of one and may be evidence of lack of IETF (not just WG)
consensus. Now, 2026 allows the IESG to waive that "no known
omissions" rule. If there were clear text in a standards track
version of 8540 that identified what was unresolved and the IESG
approved a waiver on that basis, I'd think that publishing it
would be a reasonable judgment call on the WG's part and,
assuming IETF consensus, that of the IESG. But I think not
otherwise.
best,
john
