On 14. 07. 26 18:58, Warren Kumari wrote:
On Tue, Jul 14, 2026 at 8:25 AM, Petr Špaček <[email protected]
<mailto:[email protected]>> wrote:
On 25. 06. 26 8:14, [email protected]
<mailto:[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/
<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...
Wouldn't 'held for document update' accurately describe situation like this?
I understand why Verified is not an appropriate way to change WG
consensus, that's all clear. At the same time Rejected because it is
gold plated bug-in-spec also feels wrong, so the middle ground might fit
best?
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
