[rfc-i] Errata process

Nico Williams nico at cryptonector.com
Mon Apr 22 13:52:07 PDT 2013

On Mon, Apr 22, 2013 at 3:47 PM, Joe Touch <touch at isi.edu> wrote:
> 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.

This is silly.  If someone proposes a "significant" change (beyond
fixing a bug) in an RFC via errata we'll notice and do something about
it, like reject the proposed errata.  Yes, this requires paying

Please, we don't need an air-tight process.  We need a process that works.


More information about the rfc-interest mailing list