Pekka, you wrote:
I do not understand an errata that suggests changing the defined
process should be Archived. Shouldn't this be flat out Rejected?
Right, this seems to be a bug in the text.
The problem I see with this proposed errata process is that "Archived"
tries to fill the gap for the need of an issue tracker for substantial
change suggestions (today these are sent to a subset of authors, WG
chairs, and/or WG mailing list if active, but are rarely tracked
I don't think the errata process should be used to track substantial
change proposals. That procedure needs to be separate from the errata
process, and it the best place for it would probably be at @ietf.org.
Indeed. But please note that the satement is not to be taken as a
recommendation that substantial change proposals be submitted as errata.
You are quite correct that they should be pursued as WG work, as BOFs,
drafts be written, etc. However, in the event that someone does send an
errata about the redesign of the protocol we need to know how to deal
with it :-)
Marshall you wrote:
Are you intending to say that only unimportant errata will be accepted ?
No, that was not the intent. What we wanted to convey was that the
magnitude of some changes may be inappropriate for being done as an
errata. A big redesign requires careful thought, review, probably a
number of revisions of proposals, last call review, etc. As an example,
one of my RFCs has a mistake where it uses the wrong protocol number
constant in a checksum calculation. The authors, RFC Editor, and IANA
failed to catch this error when the number allocations were done. This
is clearly an important issue, and getting it wrong would completely
prevent interoperability. But its also something that can be easily
fixed with an errata. But if we wanted to do something bigger, say,
remove a feature or redesign some aspect of the security solution it
would be inappropriate to do so in an errata.
Maybe the text was just wrong. Here's a suggested edit:
Changes that are clearly modifications to the intended consensus, or are
of major importance, should be Rejected
Changes that are clearly modifications to the intended consensus, or
involve large changes, should be Rejected
IETF mailing list