Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

John C Klensin <john-ietf@jck.com> Wed, 02 October 2013 18:50 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3940121F9FA4 for <ietf@ietfa.amsl.com>; Wed, 2 Oct 2013 11:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODU3-XBoc6Yt for <ietf@ietfa.amsl.com>; Wed, 2 Oct 2013 11:50:34 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7740F21F938E for <ietf@ietf.org>; Wed, 2 Oct 2013 11:46:14 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VRRR2-000L1e-Nx; Wed, 02 Oct 2013 14:46:08 -0400
Date: Wed, 02 Oct 2013 14:46:03 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net
Subject: Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Message-ID: <6D80EE3E9D28D2F9CB34E260@JcK-HP8200.jck.com>
In-Reply-To: <524C5B77.9000002@dcrocker.net>
References: <20131002144143.20697.85830.idtracker@ietfa.amsl.com> <7102E82AB09013B67371807F@JcK-HP8200.jck.com> <524C5B77.9000002@dcrocker.net>
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
Cc: Barry Leiba <barryleiba@computer.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 02 Oct 2013 18:50:47 -0000

I assume we will need to agree to disagree about this, but...

--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
<dhc@dcrocker.net> wrote:

> If a spec is Historic, it is redundant to say not recommended.
> As in, duh...

"Duh" notwithstanding, we move documents to Historic for many
reasons.  RFC 2026 lists "historic" as one of the reasons a
document may be "not recommended" (Section 3.3(e)) but says only
"superceded... or is for any other reason considered to be
obsolete" about Historic (Section 4.2.4).  That is entirely
consistent with Maturity Levels and Requirement Levels being
basically orthogonal to each other, even if "Not Recommended"
and "Internet Standard" are presumably mutually exclusive.

> Even better is that an applicability statement is merely
> another place for the potential implementer to fail to look
> and understand.

Interesting.   If a potential implementer or other potential
user of this capability fails to look for the status of the
document or protocol, then the reclassification to Historic
won't be found and this effort is a waste of the community's
time.  If, by contrast, that potential user checks far enough to
determine that the document has been reclassified to Historic,
why is it not desirable to point that user to a superceding
document that explains the problem and assigns as requirement
status of "not recommended"?  

The situation would be different if a huge amount of additional
work were involved but it seems to me that almost all of the
required explanation is already in the write-up and that the
amount of effort required to approve an action consisting of a
document and a status change is the same as that required to
approve the status change only.  If creating an I-D from the
write-up is considered too burdensome and it would help, I'd be
happy to do that rather than continuing to complain.

> ADSP is only worthy of a small effort, to correct its status,
> to reflect its current role in Internet Mail.  Namely, its
> universal non-use within email filtering.

If the specification had been universally ignored, I'd think
that a simple status change without further documentation was
completely reasonable.  However, the write-up discusses "harm
caused by incorrect configuration and by inappropriate use",
"real cases", and effects from posts from users.  That strongly
suggests that this is a [mis]feature that has been sufficiently
deployed to cause problems, not someone that is "universally
non-used".  And that, IMO, calls for a explanation --at least to
the extent of the explanation in the write-up-- as to why ADSP
was a bad idea, should be retired where it is used, and should
not be further deployed.  

best,
   john