Re: [Errata-design] sanity notwithstanding...

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 28 December 2014 19:25 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: errata-design@rfc-editor.org
Delivered-To: errata-design@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 02595181C64 for <errata-design@rfc-editor.org>; Sun, 28 Dec 2014 11:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERPQrD76er_O for <errata-design@rfc-editor.org>; Sun, 28 Dec 2014 11:25:22 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by rfc-editor.org (Postfix) with ESMTP id 7321C18123F for <errata-design@rfc-editor.org>; Sun, 28 Dec 2014 11:25:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE439BED9; Sun, 28 Dec 2014 19:26:11 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sUpUSg5hM4M; Sun, 28 Dec 2014 19:26:08 +0000 (GMT)
Received: from [10.87.48.70] (unknown [86.41.56.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1768BED8; Sun, 28 Dec 2014 19:26:08 +0000 (GMT)
Message-ID: <54A0594E.6020606@cs.tcd.ie>
Date: Sun, 28 Dec 2014 19:26:06 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>, Pete Resnick <presnick@qti.qualcomm.com>
References: <5494555A.7010608@rfc-editor.org> <54949BFD.1040007@cs.tcd.ie> <54999DE8.7030104@rfc-editor.org> <CALaySJK09uEnaLQZT7XcaHVdZKB8-s8EeVMvfAE9StqQpoXKLw@mail.gmail.com> <5499AEBB.2050107@cs.tcd.ie> <54A0386B.5060002@qti.qualcomm.com> <CALaySJJpNoAc57-=gPVazo53zceNoTo9OTLRraJ2PyV1XWm7TA@mail.gmail.com>
In-Reply-To: <CALaySJJpNoAc57-=gPVazo53zceNoTo9OTLRraJ2PyV1XWm7TA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: errata-design@rfc-editor.org
Subject: Re: [Errata-design] sanity notwithstanding...
X-BeenThere: errata-design@rfc-editor.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <errata-design.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/errata-design>, <mailto:errata-design-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/errata-design/>
List-Post: <mailto:errata-design@rfc-editor.org>
List-Help: <mailto:errata-design-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/errata-design>, <mailto:errata-design-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Dec 2014 19:25:27 -0000


On 28/12/14 18:42, Barry Leiba wrote:
> Pete has stated my position very well indeed.

Close to mine too. But not quite identical.

I'd differ in that I think we don't need to classify what
kinds of commentary an RFC might attract ahead of time,
and it'd be a mistake to try as we'd get it wrong. So the
concept of marking comments as editorial, technical, change
request, etc is broken. I'd also prefer if we can have the
community establish which comments are important and not
have to depend on, or bother, anyone in "authority." Voting
up/down should work just fine for all kinds of comments I
reckon. Those that are really important will bubble up and
get known.

Lastly, there are also many unimportant RFCs for which I
don't think any of us ought spend time, regardless of whether
or not a comment identifies a real interop issue. For example,
I don't believe there are any implementations of RFC 3185,
(I'm a co-author, it was a tool that would have been needed
for a road-not-taken by Diameter,) and there don't appear to
be any interesting citations to it either from RFCs, or
according to google scholar -  so we ought not bother to do
anything at all if someone files an erratum or any kind of
comment on that - and if the idea in that RFC ever does get
important again then we can go back and fix our comment
dispositions later anyway.

The above assumes a basic level of comment-spam handling
but that can also be somewhat automated, e.g. there's an
anti-spam plugin for wordpress that is their most popular
plugin. I don't know what that does, but I'll bet a beer we
can get a long way with such existing tooling, whether
that one or some other.

Cheers,
S.


> 
> Barry
> 
> On Sun, Dec 28, 2014 at 12:05 PM, Pete Resnick
> <presnick@qti.qualcomm.com> wrote:
>> On 12/23/14 1:04 PM, Stephen Farrell wrote:
>>>
>>> The part I want to go away is that each posted erratum consumes
>>> effort for folks other than the poster. (Incl. me:-)
>>
>>
>> A slight addendum to this, with which Stephen may agree or disagree:
>>
>> I don't want errata to consume time and effort for folks other than those
>> who want to spend time and effort on it (including the poster).
>>
>> That is:
>>
>> - I don't care about pure typographical errors. I'm pretty sure Stephen
>> doesn't either. But maybe Heather does and wants to exert effort on them.
>> Maybe she wants to verify them and post official ones of which she approves.
>> Peachy. I don't care to know.
>>
>> - I like suggestions for changes to specs. They should be tracked, posted
>> publicly, and discussed by those who are interested in that spec. But they
>> shouldn't have to be marked as "Formally Approved By The Powers That Be",
>> and I shouldn't need to spend my time looking at them unless I'm interested
>> too.
>>
>> - If there's an overt error in a spec that causes implementation and/or
>> interoperability problems, *and it's non-obvious*, those should be called
>> out with red flags and fanfare in some well-known place that people know to
>> go to for such important information, and someone in a position of
>> responsibility should mark it as such.
>>
>> My sense is that part of the problem is that we've got once system to deal
>> with the above, so we all end up spending time and effort on all three of
>> the above. That's not good. The IESG (or chairs or whoever) *should* be
>> stuck with spending time or effort on the third, but not on the first two.
>> Maybe the RFC Editor should spend time or effort on the first, but the
>> getting the IESG involved is highly silly. If we dealt with these things
>> separately, I think overall happiness would be increased substantially.
>>
>> pr
>>
>> --
>> Pete Resnick<http://www.qualcomm.com/~presnick/>
>> Qualcomm Technologies, Inc. - +1 (858)651-4478
>>
>>
>> _______________________________________________
>> Errata-design mailing list
>> Errata-design@rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/errata-design