[rfc-i] Errata process
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
>>> 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
>>> UPDATES or OBSOLETES - especially for standards.
>>> Otherwise, this is an end-run around IETF process, not simply a
>> 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