ietf
[Top] [All Lists]

Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

2008-04-24 08:49:49
Dear Jari;

Sorry I missed this on the 17th.

On Apr 17, 2008, at 3:39 AM, Jari Arkko wrote:

Marshall, Pekka,

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
systematically).

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.


I fully support your thinking here.

Maybe the text was just wrong. Here's a suggested edit:

OLD:
Changes that are clearly modifications to the intended consensus, or  
are
of major importance, should be Rejected
NEW:
Changes that are clearly modifications to the intended consensus, or
involve large changes, should be Rejected


I like this, but how about

s/involve large changes/involve large textual changes/

I am worried about cases like the one you mentioned above (or the  
infamous "missing not") where getting one character wrong or one word  
wrong makes
a huge difference. (In your checksum case, getting it wrong by one  
digit is as bad as getting it totally wrong.) That sounds like a  
proper errata to me.

Whereas, if the author says something like, "every mention of IS-IS  
should really be OSPF and Sections 4 and 5 need to be extensively  
rewritten to account for this,"
it may be an error, but it is not an errata.

Regards
Marshall


Jari


_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf