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

Someone poked me offlist and asked for an example — I figured I'd include
it here:
https://errata.rfc-editor.org/search/?rfc_number=5702

Here is another example, where I rejected the Errata, but left a note for
future readers:
https://errata.rfc-editor.org/search/?rfc_number=9460&presentation=records

W



On Tue, Jul 14, 2026 at 2:26 PM, Warren Kumari <[email protected]> wrote:

> I had originally said Verified at one point some tooling wouldn't show the
> Errata tag for HFDU, but it looks like that is not the case to DT now — see
> e.g: RFC9910 - "Registration Data Access Protocol (RDAP) Regional
> Internet Registry (RIR) Search"
> <https://datatracker.ietf.org/doc/rfc9910/>
>
> HFDU works too — but the core principle being "We are not changing the WG
> consensus, we are simply (ab)using the Errata process to draw attention to
> something important. Making a whole new "type" of Errata to me doesn't
> really seem worth it for how seldom this happens, and because we have this
> sort of option.
>
> I will also point at https://www.ietf.org/process/rfcs/vulnerabilities/ ,
> which speaketh thusly:
> "For published RFCs (files named RFC####), these are completed, community
> reviewed documents.  If the working group that produced the RFC is still
> active, it will work to vet the issue with you and decide the appropriate
> way to address the issue.  If confirmed, the vulnerability might be
> addressed via an errata, an updated protocol specification document, or an
> entire new document to handle the issue.  For closed working groups, the
> severity of the issue will determine the next steps.  Minor issues can be
> covered with errata.  For more significant updates, the corresponding Area
> Directors may charter a new working group to address the issues or
> individually sponsor an update."
>
> W
>
>
> On Tue, Jul 14, 2026 at 2:16 PM, Petr Špaček <[email protected]> wrote:
>
> 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]