Re: Last Call: draft-klensin-rfc2821bis

John C Klensin <john-ietf@jck.com> Fri, 28 March 2008 18:51 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA3828C4B3; Fri, 28 Mar 2008 11:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.653
X-Spam-Level:
X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 HWItSsxPml68; Fri, 28 Mar 2008 11:51:25 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5CD3A68BD; Fri, 28 Mar 2008 11:51:25 -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 B52343A68BD for <ietf@core3.amsl.com>; Fri, 28 Mar 2008 11:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 g6OZ5ecgT-v3 for <ietf@core3.amsl.com>; Fri, 28 Mar 2008 11:51:22 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 9EC583A685D for <ietf@ietf.org>; Fri, 28 Mar 2008 11:51:22 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JfJfY-000DY0-Lu; Fri, 28 Mar 2008 14:51:17 -0400
Date: Fri, 28 Mar 2008 14:51:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf@ietf.org
Subject: Re: Last Call: draft-klensin-rfc2821bis
Message-ID: <4961262A12739C761083D268@p3.JCK.COM>
In-Reply-To: <fsjcp3$mlo$1@ger.gmane.org>
References: <01MSXAA567SQ00007A@mauve.mrochek.com> <200803280038.m2S0cWLB029250@drugs.dv.isc.org> <01MSXBAMG25000007A@mauve.mrochek.com> <fsjcp3$mlo$1@ger.gmane.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
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-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 Friday, 28 March, 2008 19:20 +0100 Frank Ellermann
<nobody@xyzzy.claranet.de> wrote:

>> a move to draft is not the time to introduce new features.
> 
> It's a trick to keep wild and wonderful new features out.  For
> the IPv6-fallback discussed in this thread "getting it right"
> is more important than the status.  Ideal case, 2821bis is
> good as is, and can replace the relevant parts of STD 10 in
> two years.  
> 
> Worst case, we find that 2821bis should have no IPv6-fallback
> in two years, a 2821ter starting at PS would then take about
> five years before its successor can be at STD.  
>...

Frank,

As you and others have been repeatedly told on the ietf-smtp
list, if you have wild and wonderful new features, write drafts,
introduce them as separate, Proposed Standard, updates to 2821
that stand on their own, with their own justifications.  If that
had been done when the 2821bis effort started, or in the
subsequent months, if any of the supposed wonderful new features
introduced then had achieved interoperable implementations and
some deployment, it would have been perfectly reasonable to slip
them into 2821bis before the first Last Call a few months ago.

That approach is important because 2821 (and 2821bis),
independent of their formal status, are updates to a collection
of long-established and very widely deployed full standards.
Few people, other than the advocates of a particular wild and/or
wonderful idea, are going to be happy putting anything into it
--even at Proposed-- for which we do not have considerable
operational experience.  Those were essentially the rules for
DRUMS and they are the rules that Tony, Lisa, and myself have
been trying to apply to 2821 changes: we clarify, we correct
errors, but 2821[bis] is not the right place for wild and
wonderful ideas until they are thoroughly tamed.

Looked at a different way, the only advantage I can see of
stuffing a new idea into 2821bis and then cycling at Proposed
over writing the new idea up and processing it as a separate
update to 2821bis is the former would tend to hide from the
reader that it is a new idea and one that is less tested and
understood than the balance of 2821.  I don't believe the former
is a good way to proceed, but that is just my opinion.

So, with the understanding that this is just my opinion (but
that, as editor, I'm getting impatient with new ideas and
discussions surfacing during and after Last Call), let me repeat
my suggestion.  If you (or others, and you are clearly not the
worst offender) have new and/or wonderful ideas, write them up
in one or more I-Ds.  If they are good enough to stand on their
own, you should have no difficulty persuading an AD to process
them and getting them approved.  If they are not, then let's not
get involved with trying to insert them into 2821[bis] at the
last minute or later.   And, of course, if you are convinced
that there are enough wild and wonderful ideas to justify it, or
that circumstances have changed enough to justify redefining
Internet Mail, see if you can get tracking for a WG.  I'll wish
you well.

    john

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