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]
