RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

John C Klensin <john-ietf@jck.com> Thu, 19 June 2008 18:23 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5404A3A682F; Thu, 19 Jun 2008 11:23:06 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BF33A682F; Thu, 19 Jun 2008 11:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waXgvfONqbVC; Thu, 19 Jun 2008 11:23:03 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 45E143A681A; Thu, 19 Jun 2008 11:23:03 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1K9OnU-000Ojb-Pm; Thu, 19 Jun 2008 14:23:49 -0400
Date: Thu, 19 Jun 2008 14:23:47 -0400
From: John C Klensin <john-ietf@jck.com>
To: debbie@ictmarketing.co.uk, 'Dave Cridland' <dave@cridland.net>
Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Message-ID: <939E706761CC64A67D89C422@p3.JCK.COM>
In-Reply-To: <069801c8d185$56f8a350$0a00a8c0@CPQ86763045110>
References: <8832006D4D21836CBE6DB469@klensin-us.vbn.inter-touch.net> <485590E2.3080107@gmalcom> <p06250116c47c330c7dd0@[75.145.176.242]<4856DE3A.3090804@gmail.com> <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110> <23618.1213785541.031305@invsysm1> <059901c8d132$d65df170$0a00a8c0@CPQ86763045110> <23618.1213788490.265871@invsysm1> <069801c8d185$56f8a350$0a00a8c0@CPQ86763045110>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: 'Pete Resnick' <presnick@qualcomm.com>, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
<debbie@ictmarketing.co.uk> wrote:

> Maybe I and a few others thought a BCP was worth something.
> Apparently not. Unlike the authors of these documents I am not
> privy to the reasoning behind them  I am just privy to the
> document itself.  Neither are countless other people who
> observe IETF BCP's. Perhaps I should not bother recommending
> BCP 47 (full of MAY's and SHOULD's) anymore or indeed
> contributing to the IETF LTRU process.  It obviously is not
> worth the digital paper it is printed on.

Debbie,

Please take the time to read the relevant documents, starting
with the full text of the appeal and then the text of "the BCP"
before making comments like this.   RFC 2606/BCP32 very clearly
makes the names available for use where authors find them
useful.  It does not require them, specify that they SHOULD be
used, or call for a community consensus process to determine the
cases in which they might or might not be used.  The author of
that document has commented on this list that nothing else,
especially an implicit requirement, was intended.  And no one
else has been able to cite text in RFC2606/BCP32 that imposes a
requirement.   But you apparently did not read those notes
either (in addition to not reading the document to which you
claim to be "privy").

The only published requirement for the use of these names is in
the "ID Checklist" (IDNits).  That document is not a BCP.  It is
not even an IETF consensus documents.  It is an IESG statement
about what the IESG intends to look at.  And it says "SHOULD
preferably".    Traditionally in the IETF, "SHOULD preferably"
is a WG (or author and editor) decision as to whether there are
grounds for doing something other than what the SHOULD
recommends.  For the IESG to block a document on that basis
turns a SHOULD into a "MUST unless we choose to grant an
exception".  And, in any event, IDNits is not a BCP of any
flavor - there is no evidence of community consensus for
applying IDNits this way.

> A sad day for IETF in my book.

They are always sad days for the IETF when people comment
passionately on documents they haven't read and clearly don't
understand and when they fail to read and consider other
comments in a discussion thread before posting remarks of their
own that could have been informed by those comments.

    john

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf