More new text for 2821bis (was: Re: Response to appeal from John Klensin dated 13-Jun-2008)

John C Klensin <john+smtp@jck.com> Wed, 09 July 2008 06:51 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m696pO29031045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 23:51:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m696pOEV031044; Tue, 8 Jul 2008 23:51:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m696pMVp031036 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <ietf-smtp@imc.org>; Tue, 8 Jul 2008 23:51:23 -0700 (MST) (envelope-from john+smtp@jck.com)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KGTWL-000BzQ-UK for ietf-smtp@imc.org; Wed, 09 Jul 2008 02:51:22 -0400
Date: Wed, 09 Jul 2008 02:51:20 -0400
From: John C Klensin <john+smtp@jck.com>
To: ietf-smtp@imc.org
Subject: More new text for 2821bis (was: Re: Response to appeal from John Klensin dated 13-Jun-2008)
Message-ID: <BB5CD720FD8C6AF403D37453@p3.JCK.COM>
In-Reply-To: <487368EA.1010500@isode.com>
References: <20080707170001.ECC4A28C0F7@core3.amsl.com> <48729A1B.7030104@att.com> <0dy8Zj+lByglnd12S+8PFA.md5@lochnagar.oryx.com> <487368EA.1010500@isode.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

Folks,

This is the "surprise" referred to in one of my earlier notes.

Just so everyone knows, the appeal response says, in part...

	"The IESG came to consensus that the use of non-example
	domain names should not prevent publication of
	RFC2821bis, even though the IESG finds this practice can
	cause harm. The arguments made in public list discussion
	of the appeal have been a factor in the IESG being able
	to come to consensus on this point."

I thought that wording was a little odd when I first read it
but, other than noting that the IESG "finding" of harm did not
appear to be consistent with community consensus, didn't pay a
lot of attention to it.

However, while it is apparently not final and still has not
appeared in the tracker (see
https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
the apparent intent of the IESG, reflected in the ballot at
https://datatracker.ietf.org/idtracker/ballot/2471/, is to add
an IESG note to the front of the document that reads:

	"The IESG notes the use of several non-example domains
	(see RFC2606) in examples in this document.  These
	domains appear in the same examples in RFC2821.  RFC2821
	will continue to exist although its status will be
	marked as obsoleted by this document.  Thus, the IESG
	estimates that use of these particular examples in a
	revision to RFC2821 causes less harm than the good done
	by publishing this revision."

I presume that this text has been signed off on by all of those
listed as "Yes" or "No-Objection" on the ballot and note that
their numbers are sufficient to have a Protocol Action notice
issued.

I'm going to avoid making editorial comments on that text at
this time.  I do note, however, that this sort of note has never
before been applied to a document that does not use 2606 names.
I also note that the IESG has made no attempt to engage in a
dialog on the subject of whether a note or this sort should be
added, or about what it should contain with either this list or
the IETF list.   

I can also find no authority, in RFC 2026 or elsewhere, for the
IESG adding text to a Standards-track document without such
consultation.  In particular, while Section 6.1.2 of RFC 2026
contains an extended discussion of the IESG changing categories,
forming WGs, etc., it appears clear that the IESG is to "approve
or disapprove", not to start adding text reflecting its own
observations, observations that may or may not represent
community consensus.

Advice or instructions welcome.

      john