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

Barry Leiba <> Mon, 14 May 2018 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1646812E6D7 for <>; Mon, 14 May 2018 03:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P1WweDpm_2VR for <>; Mon, 14 May 2018 03:48:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEDEE12E03B for <>; Mon, 14 May 2018 03:48:13 -0700 (PDT)
Received: by with SMTP id e12-v6so14611417iob.8 for <>; Mon, 14 May 2018 03:48:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7fLQ9hYPoe45UcR/lhVXmPWnjYS62ABmN0xe1c55Tk=; b=VBAsO+3ZVTmMeKnZMoSz3vCzPnR6xSnYQNFirlgSIN2aT4I6DphH04FErWi034/fbl KynQaxoZ54JX6X/aOVpVrk2Hn5TxmJDYqO0mRQekbBatBTkYcnLdv54LExphyeuD2y5W SaSrCV4UKHQ9Tnc0jV5umswrxNkLxduCDKu77jRdNnBryuV2MXDDTAp/dN52s7po1IQQ btQJieMcSjZ2t3agRa0mfH1leElY4goKm6LOoMvaFJ0k9nH81pCzR4v8K5c255XjrdLf W/Kb5mkBURZNenWVvDkwv89O6ioAD7pNXNsuBQgNyr8pOgoY8LHm/tqc58A0C1xjY5nx QOaQ==
X-Gm-Message-State: ALKqPwcpt1WjHWsesYUABswIOlJYTkGb+LsRifo05cDzfEbnUEUGPaIT sin3fUa9sptroskjvl9Bv3djnIym17W2iijvprfEIA==
X-Google-Smtp-Source: AB8JxZrwU+tEHyQHMiJpfKUDsjvjwgU2FHFH0+lI4DQGqarSCmFq8rd7HjDjGA0hMx7WLlsk5YTAM8LscriFwMxNQxQ=
X-Received: by 2002:a6b:39d4:: with SMTP id g203-v6mr10605719ioa.165.1526294892838; Mon, 14 May 2018 03:48:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <20180514031854.ED51426858FB@ary.qy> <> <D16F6317605491B34CDB2D7F@PSB>
In-Reply-To: <D16F6317605491B34CDB2D7F@PSB>
From: Barry Leiba <>
Date: Mon, 14 May 2018 11:48:00 +0100
Message-ID: <>
Subject: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic
To: John C Klensin <>
Cc: IETF discussion list <>, John Levine <>
Content-Type: multipart/alternative; boundary="000000000000e90466056c28387b"
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: Mon, 14 May 2018 10:48:25 -0000

When the status change document is published, the metadata for RFCs 4405,
4406, and 4407 will point to the status change document, as you request
below.  It isn’t necessary to try to kludge an errata report on 6686.
Further, it’s not correct that this was an uncaught error in 6686: the
issue was discussed at the time, and it was decided NOT to conflate the
approval of that document with this status change.


On Mon, May 14, 2018 at 11:41 AM John C Klensin <> wrote:

> --On Monday, May 14, 2018 04:54 -0400 Barry Leiba
> <> wrote:
> > Documents are obsoleted by other documents.
> > Protocols and technologies become historic by the fact that
> > they're not/no longer in use.
> > There is a difference between "obsolete" and "historic".  It
> > makes perfect sense to say that the technologies described in
> > RFCs 4405-4407 are historic, as they're no longer in use; the
> > fact that if was an experimental technology isn't relevant to
> > that.  And RFC 6686 did not make that (Sender ID becoming
> > historic) happen.
> Barry,
> I'm glad that distinction is completely clear to you.
> Especially given the history or application of those terms, it
> is less clear to me and more than one attempt to get the IESG to
> clarify it (or initiate a community effort to clarify it) and
> get it written down in clear form has been met with silence.
> To this specific case...
> > It's true that 6686 could have requested that the IESG change
> > the status of Sender ID to Historic.  It didn't.  And this
> > situation is exactly what the "status change" document set was
> > created for: to perform these sorts of status changes without
> > having to publish new RFCs.  There's no reason to use errata
> > for this sort of thing.
> I suggested adding a erratum, not to "do this sort of thing" but
> to provide a pointer, more or less attached to 6686 and/or the
> original documents, pointing to the status change document.
> Why?  Because, which the "status change" document set (itself an
> interesting assertion) may be intended for the purpose of
> reclassifications, I suggest that almost no one who knows about
> and looks at the RFC Series is away of that collection, much
> less where to find them.  Granted, only a slightly larger
> fraction of the RFC Series audience knows to look for, and where
> to find, errata, but it would at least be a more serious attempt
> than marking the documents "Historic" in the index and leaving
> people to guess.
> Is it really an error?   Probably not, even though it is
> possible to stretch things a bit and claim that it was an
> inadvertent omission from 6686.  But, unless we either abandon
> this "put a note about a status change somewhere handy like in
> the tracker" stuff and publish RFCs or resurrect the part of the
> xx00 documents (see RFC 7100) that was essentially a summary of
> status changes, it is probably the best answer we have.
> > We have what we need to do the right thing, and we're doing
> > it.  Let's not make it more complicated than it needs to be.
> Working on that, but, IMO, "the right thing" includes leaving
> clear tracks and pointers to descriptions of actions where
> people would reasonable expect to find them.
> best,
>     john
> --
Barry Leiba  (