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

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"?

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]