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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf