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

Robert Elz <kre@munnari.OZ.AU> Mon, 16 June 2008 19:12 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 6EA0D28C123; Mon, 16 Jun 2008 12:12:51 -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 AEA3C3A6A64; Mon, 16 Jun 2008 12:12:49 -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 U8+l5q9AS-zR; Mon, 16 Jun 2008 12:12:48 -0700 (PDT)
Received: from jade.coe.psu.ac.th (unknown [202.28.99.196]) by core3.amsl.com (Postfix) with ESMTP id CE60228C123; Mon, 16 Jun 2008 12:12:39 -0700 (PDT)
Received: from epsilon.noi.kre.to (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id m5G8qDnJ003020; Mon, 16 Jun 2008 15:52:21 +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 m5G8pFr0000673; Mon, 16 Jun 2008 15:51:15 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
In-Reply-To: <4855C090.6040203@gmail.com>
References: <4855C090.6040203@gmail.com> <8832006D4D21836CBE6DB469@klensin-asus.vbn.inter-touch.net> <485590E2.3080107@gmail.com> <4855A969.2090703@dcrocker.net>
Mime-Version: 1.0
Date: Mon, 16 Jun 2008 15:51:15 +0700
Message-ID: <9469.1213606275@epsilon.noi.kre.to>
Cc: John C Klensin <john-ietf@jck.com>, ietf@ietf.org, dcrocker@bbiw.net, iesg@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:        Mon, 16 Jun 2008 13:23:28 +1200
    From:        Brian E Carpenter <brian.e.carpenter@gmail.com>
    Message-ID:  <4855C090.6040203@gmail.com>


  | Which, in fairness, the IESG has documented, in the DISCUSS criteria
  | document and generally in practice, over the last several years.

The IESG is free to document their own procedures, that's a good thing.

They're not free to invent rules for the IETF, that's for the IETF as
a whole.   What gets a document approved is IETF rough consensus, that's
been the IETF rule for years.   If there's any real question whether this
revision has IETF consensus or not, then it should be blocked.   If there's
no question as to that, then it should be approved - after all, the IETF
would (under that assumption) have approved it, along with all of its
examples.   If the example domain names were really an issue to anyone,
that would have been raised during last call.   At that point, whether or
not rough consensus existed to continue with the doc as it was could have been
judged.

Even if we had a rule that all domain names in RFCs must be from the reserved
set (which we do not) the IETF has the power to change its rules.   That can
be done in general, or on a case by case basis.   Raising the issue during
last call, and having the IETF decide to ignore the problem for the doc in
question would be all that is required to set aside the rule for that doc.

But we have no such rule, there's never been a last call on anything that
says that all domain names in examples in RFCs must be from the set
documented in 2606, so the issue should not even arise.   If there ever were
such a last call, you can expect I'd be an vociferous opponent, as rules
like that make no sense at all.   There are perfectly good reasons for those
domains to exist, and very definitely places where they should be used,
but this is not one of those cases.

  | I don't think that changing foo.com to foo.example.com would
  | destabilise the email system too much.

Of course it wouldn't break e-mail, but it would make following the RFC
sequence, and working out what changed, and why, much more difficult.

Further, when dealing with something which necessarily deals (or should)
deal with many different domain names (like e-mail does), constraining
the examples to be from just a small set or (seemingly relayed) names would
do a disservice.   Sure, you and I know that the "example" in foo.example.com
is meant to be ignored, and isn't there for any particular purpose, but can
you expect that every reader of the doc will understand that.

Even if there was an "only those domain names" rule, and there was a good
reason for having that (neither of which is actually the case), there would
be a good case for ignoring it for this one doc.   If the "real" domain names
used in this doc are a problem to the owners of the domains, I have no real
doubt but they would be changed upon request, so that straw-man objection
can be ignored.

I have no idea which AD has the arrogance to put their own view of what
the IETF rules should be above the stated desires of the IETF as a whole
(as determined by the last call), but whoever that is really ought to
consider resignation as an honourable way out of the mess they're creating.

kre


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