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

From: Barry Leiba <[email-masked]>
Date: Thu, 10 May 2018 09:13:27 -0400

I fully agree with and support this status change.

Barry

On Wed, May 9, 2018 at 12:20 PM, The IESG <[email-masked]> wrote:
>
> The IESG has received a request from DMARC WG to make the
> following status changes:
>
> - RFC4405 from Experimental to Historic
>     (SMTP Service Extension for Indicating the Responsible Submitter of an
>     E-Mail Message)
>
> - RFC4406 from Experimental to Historic
>     (Sender ID: Authenticating E-Mail)
>
> - RFC4407 from Experimental to Historic
>     (Purported Responsible Address in E-Mail Messages)
>
> The supporting document for this request can be found here:
>
> https://datatracker.ietf.org/doc/status-change-change-sender-id-to-historic/
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-06-06. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> The affected documents can be obtained via
> https://datatracker.ietf.org/doc/rfc4405/
> https://datatracker.ietf.org/doc/rfc4406/
> https://datatracker.ietf.org/doc/rfc4407/
>
> IESG discussion of this request can be tracked via
> https://datatracker.ietf.org/doc/status-change-change-sender-id-to-historic/ballot/
>

---

From: [email-masked]
Date: Fri, 11 May 2018 15:49:02 -0700 (PDT)

Ditto. This change is if anything overdue.

				Ned

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 12 May 2018 09:28:51 -0700

> > > https://datatracker.ietf.org/doc/status-change-change-

Completely in favor as I had initially proposed this during IETF101.

--Kurt Andersen

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 12 May 2018 17:41:09 -0400

I would sure rather the justification were published as an RFC so people can find the reasons in the future

Scott

> On May 12, 2018, at 12:28 PM, Kurt Andersen <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 12 May 2018 19:06:13 -0400

>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.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 12 May 2018 19:57:53 -0700

> It's in RFC 6686, in the unlikely event that someone who cares didn't

And apparently the process for "moving to historic" does not involve an RFC
per se. There is a separate document covering the reason for the
deprecation.

--Kurt

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 May 2018 11:36:42 -0400

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

>> 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.

   john

---

From: "John R Levine" <[email-masked]>
Date: 13 May 2018 11:48:44 -0400

> documented there?  If that was an inadvertent omission, ...

My recollection is that our focus was on getting SPF but not Sender-ID 
from experimental to standards track.  At the time I think there was still 
some grousing that sender-ID wasn't entirely dead, and I don't think 
anyone was willing to engage in another fight to move it to historic.

It does seem wrong that 6686 doesn't say that it obsoletes 4405-4407. 
Perhaps that's the erratum.  The experient is over, so there's nothing to 
move to historic.

R's,
Johj

---

From: "John Levine" <[email-masked]>
Date: 13 May 2018 23:18:54 -0400

Those three RFCs are experimental, and RFC 6686 ended the experiment.
I'm not sure what if anything an historic experiment means.

I would suggest filing an erratum on 6686 so that it obsoletes
4405-4407 and leave it at that.  If we really want to make these three
historic, file a further erratum on 6686 which should have have said
so.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2018 04:54:20 -0400

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.

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.

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.

Barry

-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 May 2018 06:40:48 -0400

--On Monday, May 14, 2018 04:54 -0400 Barry Leiba
<[email-masked]> wrote:

> 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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 May 2018 11:48:00 +0100

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.

Barry

Barry

---

From: "John R Levine" <[email-masked]>
Date: 14 May 2018 08:55:37 -0400

> below.

The RFC production center has a database of documents that they use to 
produce the indexes and per-RFC web pages.  I know something about it 
because I added DOIs to it.  That database has slots for one RFC to 
obsolete or update another, which show up in those indexes and web pages. 
They don't point to the datatracker or arbitrary URLs.  One of the reasons 
we have tiny historicizing RFCs like 7805 and 7142 is to leave breadcrumbs 
to the RFCs that they affect.

For that reason I have a lot of sympathy for Klensin's preference for a 
small RFC that contains the paragraph from the datatracker.  At a minimum, 
we should file an erratum on 6686 so it obsoletes 4405-4407 and that 
goes into the indexes and web pages.

R's,
John

PS: For anyone who's about to argue that it's odd for our processes to 
depend on an old database managed with PHP scripts I wouldn't disagree, 
but I don't think a rewrite is on the schedule any time soon.  It does a 
lot of other stuff coordinating RFC production and it works well enough 
for its main purposes.