[DNSOP] Re: [Technical Errata Reported] RFC8945 (9014 )

On Tue, Jul 14, 2026 at 8:25 AM, Petr Špaček <[email protected]> wrote:

> On 25. 06. 26 8:14, [email protected] wrote:
>
> I don't think filling an errata is appropriate here. This errata falls
> under the following case [1]:
>
> "Changes that modify the working of a protocol to something that might be
> different from the intended consensus when the document was approved should
> generally be Rejected. Significant clarifications should not be handled as
> errata reports and need to be discussed by the relevant technical
> community."
>
> Process question.
>
> The above basically says:
> Erratum is not appropriate because WG agreed on something. Even if it has
> a security vulnerability in it - it is gold plated vulnerability with
> consensus, don't dare to touch it!
>
> At the same time, https://www.ietf.org/process/rfcs/vulnerabilities/
> suggests erratum might be appropriate response at times.
>
> Do we need a new errata state to acknowledge:
> "The correct text is different than WG agreed to, but the WG consensus
> turned out to be technically wrong"?
>
>
Personal view only:
Yes, errata should not be used to fix change WG consensus after the fact -
but what I think would be reasonable in situations like this is to mark the
errata as Verified, and change the errata text to something like:
"NOTE: This errata is a place holder.  A security issue was discovered
which is discussed below. A new document which updates this RFC is being
prepared to address this issue, please see draft-foo"

Yes, this is technically not the right way to use errata, but I think that
it falls into "do the right thing" territory. Obviously, confirming with
the RFC Ed that this won't make them sad seems like a good idea too...


W



Or if an erratum is not the right approach (why not?), do we need sort of
> bug tracker for protocol specs?
>
> Researchers and practitioners already have their own lists of deviations
> from spec because the spec if wrong/has invalid assumptions, and quite
> often going through full IETF process to change one word or add one
> sentence is often too much overhead.
>
> To me it seems like a bug record in bug tracker would be better, and then
> WG can take multiple reports at once and process them in batch once there's
> enough interest in doing a bis document.
>
> --
> Petr Špaček
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]