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

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]