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

[Marshall Eubanks <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf