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

John C Klensin <> Sun, 13 May 2018 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67BA912D94B for <>; Sun, 13 May 2018 08:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5IA_48Zrozao for <>; Sun, 13 May 2018 08:36:52 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0834A126D85 for <>; Sun, 13 May 2018 08:36:50 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1fHt3H-000Msb-OY; Sun, 13 May 2018 11:36:47 -0400
Date: Sun, 13 May 2018 11:36:42 -0400
From: John C Klensin <>
To: John Levine <>,
Subject: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic
Message-ID: <>
In-Reply-To: <20180512230614.0909C267893F@ary.qy>
References: <20180512230614.0909C267893F@ary.qy>
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
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 May 2018 15:36:53 -0000

--On Saturday, 12 May, 2018 19:06 -0400 John Levine
<> wrote:

> In article <>
> you write:
>> I would sure rather the justification were published as an
>> RFC so people can find the reasons in the future
> It's in RFC 6686, in the unlikely event that someone who cares
> didn't already know the answer.

Yeah, but, knowing that, my version of Scott's comment would
have been only slightly different.   (Almost) too late now, but
why wasn't this action taken as part of adopting 6686 and
documented there?  If that was an inadvertent omission, should
our review process (Last Call, Shepherd writeups, etc.) be
modified to lower the odds of future such omissions?  Either
way, when this action occurs, should it be noted as an omission/
erratum on 6686 to improve the relevant threading.

Personally, I'd much prefer to see these things described in the
RFC Series rather than assuming people will look at the
datatracker to find relevant information.  We at least used to
believe that RFC numbers were cheap, a lot cheaper than losing
important information or hiding it in obscure places  Part of
the reason for that is that the RFC Series is archival, existed
before the IETF, and is likely to continue to exist in some form
even after the IETF fades into history.  I have no such
confidence about the datatracker.  Consequently, I'd rather see
a one-page RFC that says what the proposed tracker note says and
that points to (and updates) 6686, rather than just the tracker
note.    But I (and Scott) seem to have lost that argument to a
series of IESG statements with some apparent ex cathedra
character to them.