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

Robert Elz <kre@munnari.OZ.AU> Wed, 18 June 2008 18:01 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 266143A699C; Wed, 18 Jun 2008 11:01:20 -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 ABF8D3A68D2; Wed, 18 Jun 2008 11:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level:
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
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 uOdwifEBtWhD; Wed, 18 Jun 2008 11:01:18 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id 4D0FC3A67AC; Wed, 18 Jun 2008 11:01:18 -0700 (PDT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m5II0Xfl014077; Thu, 19 Jun 2008 01:00:33 +0700 (ICT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by epsilon.noi.kre.to (8.14.2/8.14.2) with ESMTP id m5IHxx5Z011635; Thu, 19 Jun 2008 01:00:05 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: debbie@ictmarketing.co.uk
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
In-Reply-To: <059901c8d132$d65df170$0a00a8c0@CPQ86763045110>
References: <059901c8d132$d65df170$0a00a8c0@CPQ86763045110> <8832006D4D21836CBE6DB469@klensin-sus.vbn.inter-touch.net><485590E2.3080107@gmal.com><p06250116c47c330c7dd0@[75.145.176.242] <4856DE3A.3090804@gmail.com> <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110> <23618.1213785541.031305@invsysm1>
Mime-Version: 1.0
Date: Thu, 19 Jun 2008 00:59:59 +0700
Message-ID: <13291.1213811999@epsilon.noi.kre.to>
Cc: 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

    Date:        Wed, 18 Jun 2008 12:02:44 +0100
    From:        "Debbie Garside" <debbie@ictmarketing.co.uk>;
    Message-ID:  <059901c8d132$d65df170$0a00a8c0@CPQ86763045110>

  | I see your point.

I doubt that you do.

  | I do think, assuming it is not already documented and
  | further assuming this is the whole point of the appeal, that the IESG could
  | create a general policy wrt BCP's.

No, you totally fail to understand.   The IESG's job is not to create
policies.   It is to implement the policies created by the IETF as
a whole.   That's kind of the point here, the IESG (or at least one
member of it) seems to want to create a new policy, or is somehow assuming
such a policy has already been created (by someone, it isn't clear who or
how.)   That's what I believe John's appeal is really about - the IESG
should not (not now, not ever) be attempting this kind of thing.

  | Shouldn't be too onerous.  That way
  | everyone knows in advance that they should follow a BCP unless they can show
  | reasonable cause not to

Not true in general.   You also clearly don't know what a BCP is all about.

If you're inferring things from the name, I'd suggest you go back to the
poised/poised95/poisson (whenever it was that these things were created)
mailing list archives, and observe all the discussions about the name, and
what people might incorrectly read into it.   We ended up with BCP as a name
largely because no-one was able to suggest anything better.

What those documents are however, is anything for which the IETF desires to
express that there is community consensus behind what is written (whatever
that is), but for which the standards process does not work (in that the
latter requires interoperable implementations, several of them, and some
things - like reserving a domain name - simply do not allow multiple
interoperable implementations.)

In this case, 2606 is a BCP merely to show (as its author stated a few days
ago) that there was community consensus to remove from allocation to "normal"
people/organisations a few particular domain names - that is, to convince
IANA to make that reservation.

That's it.

Having achieved that objective, I guess 2606 could now be made historic.

There neither is, was, or ever should be, any implication that anyone
necessarily should ever use those names for anything.   Of course,
in many situations using them makes sense.  In some it is a very very
intelligent thing to do (for example if you're distributing a sample
configuration file and you need to show the configuration to attach to
a particular (end user supplied) server, using server.example.com as the
domain name in the sample configuration would be a very wise choice.)
In other cases using those domain names is of no benefit at all, and worse,
may actually create confusion.

Which is the case here isn't really the point - that's already been decided
by both the working group, the previous standard (2881 to which this doc is
a fairly minor revision, if I understand it all correctly) and the IETF
last call processes for both 2881 and 2821bis.   The issue is why the IESG
is ignoring the demonstrated will of the IETF.

kre

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