Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic

John C Klensin <john-ietf@jck.com> Wed, 20 June 2018 16:08 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 EBC02130DE7; Wed, 20 Jun 2018 09:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrzKCJQTUwvd; Wed, 20 Jun 2018 09:08:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BB7131123; Wed, 20 Jun 2018 09:08:23 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fVfed-000G1u-Pq; Wed, 20 Jun 2018 12:08:19 -0400
Date: Wed, 20 Jun 2018 12:08:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, S Moonesamy <sm+ietf@elandsys.com>, iesg@ietf.org, ietf@ietf.org
Subject: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic
Message-ID: <98F610E618E18B07B96C3BE8@PSB>
In-Reply-To: <404d054e-d963-dd70-c9ae-f6ae4666797b@isode.com>
References: <152588285893.3989.7909763661642193132.idtracker@ietfa.amsl.com> <6.2.5.6.2.20180619151759.0bf2c2b0@elandnews.com> <3679f35a-f6a8-47e9-9c0a-84b99a388855@isode.com> <6.2.5.6.2.20180620062609.08678c98@elandnews.com> <404d054e-d963-dd70-c9ae-f6ae4666797b@isode.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_f_eXMJAUfrfglsIG543wNK0GdA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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, 20 Jun 2018 16:08:49 -0000


--On Wednesday, June 20, 2018 14:59 +0100 Alexey Melnikov
<alexey.melnikov@isode.com> wrote:

> Hi SM,
>...
>> Not taking any action to update the registry defeats the
>> purpose of  having the registry.
> Adding a note about the extension being moved to Historic is
> reasonable. Removing the entry is not.

While I agree that adding a note is reasonable and that
providing a reference to current status (as viewed from the
IETF's perspective) is probably more so, I think "defeats the
purpose" is wild hyperbole or worse.  There are actually two
goals of this registry.  One is simply to avoid inadvertent name
collisions and that certainly is not facilitated by hiding or
dropping names unless we somehow want to encourage their reuse.

The other is to allow the client maintainers who see a service
extension announcement (or server maintainers who, in violation
of 5321, see a service extension request) to easily look that
purported extension up and see what it is about.   Unless the
IESG has a magic wand that will cause any and all uses of
Sender-ID to disappear the instant that this action is taken, it
is _very_ important that the registry entry remain and that it
point to useful information, both about what Sender-ID is/was
and why the IETF now claims it is Historic and, presumably, is
making a "NOT RECOMMENDED" (see 2026) statement about it.

At the risk of kicking a dead horse, the above is precisely why
I prefer to see RFCs published to cover cases like this (as
Applicability Statements for present or former standards track
documents) rather than simple tracker notes.   I don't actually
care about Sender-ID or friends.  The original documents were
Experimental, an explanation has been published about why the
experiment was concluded and these approaches were not viable,
and, if the tracker note is sufficiently clear about why the
action is being taken _and_ registries updated with appropriate
"HISTORIC" and "don't use this" notations and references, I
think this approach is probably ok (although not my first
preference).   However, I recommend we use this discussion as
motivation to discourage tracker-style reclassifications to
Historic for standards-track documents when the intent is to
convey a "don't start using this is you are not and, if you are,
please start phasing it out" sort of recommendation.

>>   I suggest considering Section 2.2 of RFC 5321.
> 
> I am happy to be proven wrong, but I don't think it covers the
> case of an SMTP extension being made historic.

I think that section is irrelevant to this discussion except to
the degree that it explains the reasons for having registry
entries (and keeping them there and keeping them up to date).
If someone thinks that is not explained adequately, please file
an erratum -- I still assume that the time will come in which a
replacement to 5321 will be appropriate and, while I'm keeping
notes and a working version of a revision, relying entirely on
that is probably not wise.

best,
   john