[rfc-i] Errata process

Joe Touch touch at isi.edu
Mon Apr 22 13:47:44 PDT 2013



On 4/22/2013 1:41 PM, Nico Williams wrote:
> On Mon, Apr 22, 2013 at 11:46 AM, Joe Touch <touch at isi.edu> wrote:
>> On 4/22/2013 9:14 AM, Nico Williams wrote:
>>> It's all case-by-case.  In some cases the ambiguity and possible
>>> resolutions are too simple to bother with a new RFC just for that, yet
>>> the ambiguity is too serious to do nothing at all.
>>
>>
>> There's no such thing; anything that changes the CONTENT of an RFC needs to
>> be in a new RFC - excepting ONLY errors that were never intended in the
>> first place (e.g., a typo that changes code).
>>
>> All other attempts to clarify ambiguities need to be done by process as an
>> UPDATES or OBSOLETES - especially for standards.
>>
>> Otherwise, this is an end-run around IETF process, not simply a 'convenient
>> alternative'.
>
> You're arguing that there's no errata process, or there shouldn't be
> for anything but the most obvious issues.  I don't agree.

First, I'm arguing that if we have a process for errata, it needs to be 
discussed by the community and approved. What we have now is what the 
IESG has stated unilaterally.

And I disagree with the current statement.

I understand that others disagree with this, but nobody to date has 
explained how this isn't a full end-run around the RFC process, whereby 
changes to protocols are vetted by the community.

Joe


More information about the rfc-interest mailing list