Subject: Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Nov 2013 12:13:05 -0500

Closing the loop on this:

I see very strong and very broad agreement with taking this action:
reclassifying ADSP (RFC 5617) as Historic.

I see two objections:

One, by Hector, is that ADSP does have a lot of deployment: there's
code out there, both open source and commercial, that implements it,
and there are enough publications of ADSP records to demonstrate that
it's in use.

Another, by John Klensin and Alessandro, that making ADSP historic is
fine, but that it should be done with a document that explains the
deployment situation and explains why the reclassification is
appropriate despite that.  Alessandro also wants us to consider fixing
ADSP instead.

Hector is certainly correct that code was quickly written and shipped
to implement ADSP, so there is plenty of deployed code.  The
contention, though, is that ADSP is not providing the benefits it was
intended to, and is, in fact, actually causing harm due to misuse and
misconfiguration.  Those factors make it important for us to
officially recommend that it NOT be used -- hence the
reclassification.  I have asked for, and not seen, any real data
showing benefits from ADSP.

John has a reasonable point about writing up an explanation, and we
have had volunteers to do so.  The IESG will consider whether that is
a better approach than just changing the RFC's metadata.  As to
Alessandro's point about fixing ADSP, it's clear that there is no
community interest in doing that in a way that remains compatible with
RFC 5617's specification.

I see, therefore, clear consensus to make this status change, either
through a simple metadata change or accompanied by an explanatory
document.  The IESG will decide how to proceed.

Barry, Applications AD

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 09:25:09 -0800

On 11/20/2013 9:13 AM, Barry Leiba wrote:
>    it should be done with a document that explains the
> appropriate despite that.
...
> have had volunteers to do so.

The IETF has some history moving documents to Historic status.  I have 
not noticed that it has a track record of requiring documents to explain 
the actions for these earlier examples.

If indeed we've been doing it, what are these precedents?  If we 
haven't, why start now?

What is the compelling community requirement that demands this 
significant bit of extra work be imposed as a barrier to change in status?

Extra work needs to have compelling extra benefit.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 12:28:16 -0500

On Nov 20, 2013, at 12:25 PM, Dave Crocker <[email-masked]> wrote:
> What is the compelling community requirement that demands this significant bit of extra work be imposed as a barrier to change in status?

A third alternative would be to do the change, which has been declared to have consensus, and then also do an informational document that explains the change.   Aside from time spent, I don't see a downside to this approach (no AD hat, since it's not my consensus to call).

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 09:34:59 -0800

On 11/20/2013 9:28 AM, Ted Lemon wrote:
> A third alternative would be to do the change, which has been
> declared to have consensus, and then also do an informational
> document that explains the change.   Aside from time spent, I don't
> see a downside to this approach (no AD hat, since it's not my
> consensus to call).

The problem is that it is make-work.  There is no compelling requirement 
or benefit that can be pointed to and that has community agreement. 
That makes it an inherent downside.

Saying "aside from the time spent" essentially marginalizes the 
significant effort of producing and publishing a write-up -- involving a 
range of volunteers and IETF staff -- as if it were a free resource, 
which of course it isn't.

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Nov 2013 17:44:27 +0000

On 20/11/2013 17:25, Dave Crocker wrote:
> not noticed that it has a track record of requiring documents to 
> explain the actions for these earlier examples.
>
> If indeed we've been doing it, what are these precedents?
Yes, we do. For example RFC 6196. I only wanted to update IANA registry. 
I got push back without an RFC.
> If we haven't, why start now?
>
I think explaining decisions which might not be obvious to a person who 
was not around when the decision was made is a good thing. But yes, this 
is extra work.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 09:50:01 -0800

On 11/20/2013 9:44 AM, Alexey Melnikov wrote:
> was not around when the decision was made is a good thing.

Why isn't the IETF mailing list archive discussion about the status 
change sufficient as an archival record?

To be consistent, are we also going to need to publish an RFC that 
explains why an RFC should be promoted to full standard?  It's good to 
explain that decision too, isn't it?

d/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Nov 2013 13:01:51 -0500

> Why isn't the IETF mailing list archive discussion about the status change
> sufficient as an archival record?

More than that, actually: the current process has added a
pseudo-document that we use to manage the status-change process:

https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

That pseudo-document has the necessary information, but it not
published as an RFC.  I think that if the RFC metadata were modified
to point to the status-change document, so it's easy to find when one
is looking at the RFC, that should be all we need.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Nov 2013 13:02:46 -0500

> is looking at the RFC, that should be all we need.

(And, in fact, the datatracker header does point there.  See:
https://datatracker.ietf.org/doc/rfc5617/
)

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 10:12:24 -0800

> is looking at the RFC, that should be all we need.

What a nifty suggestion.

Thanks!

d/

ps.  FWIW, I apologize that I hadn't done the homework of searching the 
RFC archive for examples of these move-to-historic explanatory RFCs. 
There are surprisingly many of them.  That doesn't change my underlying 
concern about the burden, of course...

---

From: Bob Braden <[email-masked]>
Date: Wed, 20 Nov 2013 10:15:58 -0800

Dave,

The Historic status has always been the subject of some ambiguity and 
controversy, going back to the Founding Father. You have an opinion, 
some of us may have different opinions.  The appropriateness of moving 
documents to Historic will probably never be fully settled. Meantime, we 
should note that there is something special about Historic, that is not 
true of any of the other status values: Historic is a demotion and it is 
final.  So there is no consistency issue with asking for an explanatory 
RFC for Historic but not for full standard.

Here is a test: presumably somewhere somebody has a standard for 
acoustic couplers. This is obsolete technology, right? Do you expect 
that the owner of the standard will mark the standard "Obsolete"?  I 
would not expect it.

Bob Braden

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Nov 2013 19:17:32 +0100

Dave,

If someone is willing to write the document and explain why ADSP has
been moved to Historic, that's good for capturing lessons learned.  I
don't think it's required for the status change, but a bonus.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 14:07:03 -0500

On Nov 20, 2013, at 12:34 PM, Dave Crocker <[email-masked]> wrote:
> Saying "aside from the time spent" essentially marginalizes the significant effort of producing and publishing a write-up -- involving a range of volunteers and IETF staff -- as if it were a free resource, which of course it isn't.

IETF participant effort is not free, but neither is it fungible.   So when someone takes an interest and decides to work on something, it's not necessarily taking away from work they would otherwise be doing.   That said, I agree that if it is taking away from that work, it may not be worth doing.   Bear in mind though that the explanatory doc could be a survey that is submitted to the ISE, so it need not consume as much time as a standard with working group and IETF consensus would.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 14:08:56 -0500

On Nov 20, 2013, at 12:50 PM, Dave Crocker <[email-masked]> wrote:
> Why isn't the IETF mailing list archive discussion about the status change sufficient as an archival record?

Because it's hard to find this information in the IETF mailing list archive, and it's often not summarized (although in this case Barry's explanation of his consensus call might be sufficient).

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Nov 2013 14:09:23 -0500

> don't think it's required for the status change, but a bonus.

Do you think that more than this is necessary?:
https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

I should, in particular, direct that question to John, as he's the one
who brought up the question of documenting why... so I am adding John
to the "To" here.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 11:11:27 -0800

On 11/20/2013 11:08 AM, Ted Lemon wrote:
> Because it's hard to find this information in the IETF mailing list archive

uhhh...doesn't seem to be.

a google search of "rfc 5617 historic" produced ready access to the 
relevant part of the ietf list archive.

d/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Nov 2013 20:26:17 +0100

Well, I'll answer for myself:

Not necessary.  If someone wants to write a document, tho, I wouldn't
try to stop 'em.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2013 14:27:49 -0500

On Nov 20, 2013, at 2:11 PM, Dave Crocker <[email-masked]> wrote:
> a google search of "rfc 5617 historic" produced ready access to the relevant part of the ietf list archive.

Maybe so, but you just wrecked that, because what you just said and my reply will now show up as more relevant in the search results.   Which is why relying on google search for this, useful as I agree it is, is the wrong solution.

The datatracker is better, but I think it's relatively unusual for people to wind up in the datatracker or to know to go looking there for this sort of information.   A document that's listed in the metadata is clearly better, although possibly not _enough_ better to justify the effort.

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Nov 2013 16:28:55 -0500

--On Wednesday, November 20, 2013 14:09 -0500 Barry Leiba
<[email-masked]> wrote:

>> If someone is willing to write the document and explain why
>> ADSP has been moved to Historic, that's good for capturing
>> lessons learned.  I don't think it's required for the status
>> change, but a bonus.
> 
> I should, in particular, direct that question to John, as he's
> the one who brought up the question of documenting why... so I
> am adding John to the "To" here.

Barry, let me respond to that question as briefly as I can, with
the understanding that there are many separate issues involved
in this and the second it just the highest-level possible
summary of several of those.

(1) All other things being equal, the statement is about right.
However, if the real intent is to deprecate ADSP and advise
people to not use it, the way to do that, IMO, is to publish an
appropriate Applicability Statement that says "don't use this"
and identify 5617 as updated by that document.  If 5617 is moved
to "Historic" as part of that process, that is so much the
better.  By contrast, changing the document status from
"Proposed Standard" to "Historic" without documentation other
than a statement in the tracker and hoping that people will
somehow get the hint (or get curious enough to figure out how to
find the explanation in the tracker) doesn't really seem
appropriate to me.   It also doesn't seem inappropriate enough
to justify a big stink and I hope that neither my earlier
comment nor this note will be taken as such a stink or even part
of one.

(2) While I hope I can say this without associating myself with
those who are much more critical and feel much more strongly
about the subject than I do, DKIM is getting into a very funny
status in the IETF.  On the one hand, it is being treated as an
important standard and building block for other work, perhaps
even the proverbial hammer for hitting a large number of alleged
nails in and around email and the applications area more
generally.  On the other, much of the development came from
outside the IETF, the WG that did (or ratified) the foundational
work was hosted in Security, not Apps, the historical mailing
list for the WG isn't on the IETF site, the Chair of that former
WG is now moving DKIM work ahead as sponsoring AD, the number of
people actually pushing the work seems to be fairly small, those
people seem to draw together to reject the opinions of
dissenters, and so on.  None of that is unreasonable or in
violation of any of our procedures, so these comments fall short
of an objection.  On the other hand, it could be interpreted as
having something of a bad odor about it, especially for members
of a set of standards that are being proposed as the foundation
for additional work, so I would urge that some extraordinary
efforts to be sure that every DKIM-related action is open,
transparent, and well-documented would be in order.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Nov 2013 16:43:26 -0500

--On Wednesday, November 20, 2013 20:26 +0100 Eliot Lear
<[email-masked]> wrote:

> Not necessary.  If someone wants to write a document, tho, I
> wouldn't try to stop 'em.

If it would help get this resolved and Barry, Ted, or some other
AD who is interested in this would be willing to commit to
sponsor such a draft, I'd be willing to turn the statement in
the tracker into an I-D and get it posted.  

On the other hand, it would be better if someone who cares more
about DKIM than I do would produce that draft or, if there is no
real interest in it, I have other useful things to do with my
time than continuing to complain about this.  In addition, while
I'm willing to produce such an I-D, I'm not willing to spend a
lot of time and energy defending it or its exact wording.

   john

---

From: Hector Santos <[email-masked]>
Date: Wed, 20 Nov 2013 17:41:01 -0500

Hi,

As I explained a few times, IMO, the burden should be on the proposer 
to explain why ADSP investment should be abandoned, made obsolete and 
replaced with DMARC as the principle alternative advocated and 
pursued.  There is no coincidence that that proposer is the author of 
a DMARC BCP document [1].

We keep saying its unrelated, well, I hope it would be. But 
unfortunately it is not. I don't see it that way.  Two DMARC documents 
[1] [2] goes into using ADSP as a comparison and touts it as a better 
solution.

Overall, I'm all for a "better" solution,  but I don't see the 
difference in the overall proof of concept -- they are basically the 
same and they both have the same fundamental design barrier with a 
lack of Middle Ware support.  This is what has hurt ADSP adoption.

With DMARC be any different?  Why pull the investment plug that was 
already done if the key difference is the idea that MiddleWare 
operations will support DMARC?

If we are saying DMARC is better because there are key players willing 
to support this, then just say so but keep in mind, there was a huge 
investment in DKIM based policy security layers with at least 8-9 
years of exploration and concrete proof of concept established.  We 
need to establish why implementators (of all sizes) should drop all 
investment in ADSP and move it over to DMARC. I personally will not 
authorize any more work on DKIM or augmented security layers when 
DMARC has the same basic issue that ADSP did.  There is an IETF 
credibility problem with the next idea here to pursue.  Why bother 
with new work when the work can be totally lost without any real 
explanation -- just like that (snapping fingers).

Kill it, make it historic whatever, but convince me why I should 
invest again in new protocols which in this case, is not convincing 
will be any better other than perhaps be more popular and supportive 
by the key cogs involved with DKIM.

Thanks

--
HLS

[1] http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03
[2] http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01

-- 
HLS

---

From: "Bradner, Scott" <[email-masked]>
Date: Wed, 20 Nov 2013 22:48:21 +0000

it would seem to me to be a dereliction of duty to not publish a document that says why such a change
is made - 

	if ADSP is dangerous then say so in a way that people can understand

but if it is just competition to another protocol it does not  seem to paint the IETF in a good light to
not let the market decide what technology to use - i.e., I would not support the change
if it is just to benefit DMARC without there being a actual reason to not use ADSP

Scott

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Nov 2013 14:54:49 -0800

> if it is just to benefit DMARC without there being a actual reason to not use ADSP

Scott,

Before offering conspiracy theories, perhaps you could read (or read 
more carefully) the considerable IETF mailing list transcript that 
explains very thoroughly why the protocol should be deprecated.

And if that's too much effort, try the link that Barry provided:

And since even that seems to take too much effort a concise summary, yet 
again:  The protocol isn't used.  Someone trying to rely on a protocol 
that isn't used will suffer somewhere between zero and negative utility.

As for dereliction... wow.  Perhaps you can explain why the existing and 
easily-searchable public archive is insufficient and the effort to 
produce an obscure RFC that will likely never be read is better?

d/

---

From: "Bradner, Scott" <[email-masked]>
Date: Wed, 20 Nov 2013 23:00:25 +0000

so document it in a RFC - not a big task if the info is already there

future potential users might be able to find a RFC  - they would not be able to find a string of messages
on a mailing list

fwiw - this is not a new issue for me - going back to RFC 1923 I have felt that it is a must to tell
people why such a change is made

Scott

Scott Bradner

Harvard University Information Technology
Innovation & Architecture
+1 617 495 3864
1350 Mass Ave., Room 760
Cambridge, MA 02138
www.harvard.edu/huit

On Nov 20, 2013, at 5:54 PM, Dave Crocker <[email-masked]> wrote:

> Before offering conspiracy theories, perhaps you could read (or read more carefully) the considerable IETF mailing list transcript that explains very thoroughly why the protocol should be deprecated.
> 
> And since even that seems to take too much effort a concise summary, yet again:  The protocol isn't used.  Someone trying to rely on a protocol that isn't used will suffer somewhere between zero and negative utility.
> 
> As for dereliction... wow.  Perhaps you can explain why the existing and easily-searchable public archive is insufficient and the effort to produce an obscure RFC that will likely never be read is better?
> 
> 
> d/
> 
> 
> -- 
> Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Nov 2013 18:10:18 -0500

...
>    https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

Just to make this all very clear:

When we had no obvious "metadata", we would publish an RFC that said
that a previous RFC is now Historic, and we hoped that people would
see both and know what the situation was.

Then we established metadata that goes with an RFC, and the RFC's
status and the "obsoletes" and "updates" chains are part of the
metadata.  No need to hope any more: Anyone who looks at the
datatracker or tools versions of the RFCs will see that metadata, so
(1) we can now rely on having the "Historic" status be clear, and (2)
the RFC that updates or obsoletes the old one is now called out
clearly.

Then we set up special documents by which we process status changes.
The cited one above is one of them.  Those special documents are also
tied to the original document's metadata.

So here's the thing:

1. If RFC 9999 were to "obsolete" RFC 5617 and declare it Historic,
someone looking at the datatracker page for RFC 5617 would see (1)
that it's Historic and (2) that RFC 9999 obsoletes it.  They would,
therefore, know to look at RFC 9999 to understand what happened.

2. But if we just process this status change as currently proposed,
someone looking at the datatracker page for RFC 5617 would see (1)
that it's Historic and (2) that status-change-adsp-rfc5617-to-historic
made that status change.  They would, therefore, know to look at
status-change-adsp-rfc5617-to-historic to understand what happened
(and there's a convenient, clickable link).

If you want another example, look at RFC 6376:
https://datatracker.ietf.org/doc/rfc6376/
...and see how the status change document that made it Internet
Standard is clearly linked at the top of the page.  See how that
document contains the explanation for the action.

As we change our tools, we need to understand that the ways we used to
handle certain things are no longer necessary, because the improved
tools have made things better.  This is one of those situations.

So: Yes, we could publish an RFC that basically has the content that
status-change-adsp-rfc5617-to-historic now has, and that new RFC could
obsolete RFC 5617.  Personally, I don't see why that's necessary or
even useful.  We have a *new* tool for this, and we should use it.

That said, the IESG, not I alone, will decide, and will take all the
input y'all have given -- thanks for that input.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 Nov 2013 00:49:40 -0800

> therefore, know to look at RFC 9999 to understand what happened.

If the IESG decides it wants an RFC, I'll volunteer to do the editing if
nobody else wants to do it, unless John (or others) see me as part of some
kind of pro-DKIM cabal that's giving him the willies and we'd rather
someone else do it.  It's almost no work since the text is basically
already laid out.  Or maybe this would be a good opportunity for a relative
neophyte to IETF process to learn how something gets published; I'll
happily shepherd.

> document contains the explanation for the action.

That's true, but there are other sources of RFCs that don't contain such
information, such as http://www.ietf.org/rfc/rfc6376.txt and I think the
one at rfc-editor.org.  Someone grabbing the RFC from such sources (which
could easily be seen as official) would not be aware of the status change
or the reason for it.

-MSK

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Nov 2013 10:40:58 -0500

Disclaimer: This note has nothing to do with either ADSP or any
other variation or component of DKIM.  If any part of it appears
otherwise, I apologize for the unintended confusion.

--On Wednesday, November 20, 2013 18:10 -0500 Barry Leiba
<[email-masked]> wrote:

>>> it would seem to me to be a dereliction of duty to not
>>> publish a document that says why such a change
>>> is made -
> ...
> When we had no obvious "metadata", we would publish an RFC
> that said that a previous RFC is now Historic, and we hoped
> that people would see both and know what the situation was.
> 
> Then we established metadata that goes with an RFC, and the
> RFC's status and the "obsoletes" and "updates" chains are part
> of the metadata.  No need to hope any more: Anyone who looks
> at the datatracker or tools versions of the RFCs will see that
> metadata, so (1) we can now rely on having the "Historic"
> status be clear, and (2) the RFC that updates or obsoletes the
> old one is now called out clearly.
> 
> Then we set up special documents by which we process status
> changes. The cited one above is one of them.  Those special
> documents are also tied to the original document's metadata.

Moving to a very high level, it seems to me that what is wrong
with the above is that, while adding metadata and making it more
accessible are useful at best and harmless at worst, it seems to
me that you are making a leap from "the metadata are available
if you know where to look" (or use the right tools) to
"therefore it is reasonable to change the procedures by which
standards-affecting decisions are documented and to introduce
those procedures via a specific case".   It also seems to me
that this process involves doing that without any real
discussion of the procedural change independent of that case.
If we push all other issues aside, it is that change, without a
clear discussion or statement of what is being done, that is
troubling, not the particular action or documentation of one
particular case.  Suggestion below.
 
> So here's the thing:
> 
> 1. If RFC 9999 were to "obsolete" RFC 5617 and declare it
> Historic, someone looking at the datatracker page for RFC 5617
> would see (1) that it's Historic and (2) that RFC 9999
> obsoletes it.  They would, therefore, know to look at RFC 9999
> to understand what happened.

I note they they would also get that much information by looking
at the ASCII-text RFC Index.  I also note that we have not
obsoleted that index, nor have we included datatracker links in
it, nor attached a giant disclaimer to it that anyone interested
in what the published status information means needs to go to
the datatracker.
 
> 2. But if we just process this status change as currently
> proposed, someone looking at the datatracker page for RFC 5617
> would see (1) that it's Historic and (2) that
> status-change-adsp-rfc5617-to-historic made that status
> change.  They would, therefore, know to look at
> status-change-adsp-rfc5617-to-historic to understand what
> happened (and there's a convenient, clickable link).

As long as they look at the datatracker.   It is worth noting,
now that  
draft-resnick-retire-std1 has been approved, that STD 1 used to
be a place where what we now describe as metadata was supplied,
including requirement levels and some explanations of choices.
A glance through some of the earlier versions of STD 1, e.g.,
RFC 1360, are particularly illuminating in that regard.  I note
that  draft-resnick-retire-std1-01 doesn't say "you need to look
at the datatracker in order to find the status of a
specification".  Instead, it refers the reader to
http://www.rfc-editor.org/rfcxx00.html.  If one finds a protocol
there and uses the RFC references in it to retrieve the
document, none of the metadata other than maturity level will be
found (not even "updates") information.

That suggests to me that, if we are going to expect people to go
to the datatracker (or equivalent) in all cases, we have some
act-cleaning-up to do.

> Standard is clearly linked at the top of the page.  See how
> that document contains the explanation for the action.

Curiously, I think that example supports my point.  RFC 6410
explicitly provided for promotion of specifications to Internet
Standard without publication of a formal, archival, discussion
of why it was being done.  It also defines (partially by
reference) the criteria that one can assume if something is
designated as an Internet Standard.  It was posted as an I-D,
underwent significant community discussion about the procedural
change, and was formally adopted as reflecting community [rough
at least] consensus.

We do have examples of publishing tombstone documents for
specifications that are moved to Historic because they are not
implemented or not in use.  Perhaps RFC 4450 is the best example
of that simply because it covers a large group of RFCs.  It
seems to me that deprecating a specification that is claimed to
be implemented, in some use, and found to be undesirable should
require a higher and more formal degree of documentation.  It
also appears to me that the difference between those two sets of
cases invalidates any argument that there is only one use of
Historic.

Neither 6410 nor, AFAIK, anything anything published since RFC
2926, addresses moving of a document to Historic, nor does it
provide the precise definition of Historic that (as Bob Braden
pointed out) we've never had, nor does it provide an alternate
mechanism for saying "use Not Recommended" other than publishing
an Applicability Statement.  

> As we change our tools, we need to understand that the ways we
> used to handle certain things are no longer necessary, because
> the improved tools have made things better.  This is one of
> those situations.

Obviously I, and perhaps some others, see "no longer necessary"
and "one of those situations" as more controversial than you do.
I may be alone in this, but I see formalizing information in the
datatracker as having the same level of archival and reference
permanence as a rather big step with some interesting
side-effects [1].  But it seems to me that, if you want to make
the change you apparently believe is obvious because the tools
have changed, then let's have that discussion and see if the
community reaches that conclusion... just as we did with what
became RFC 6410.

best,
    john

[1] As an example, if another protocol came along that was
intended to replace one that had been move to Historic using
datatracker entries alone, would (and should) the RFC Editor
allow normative references to those datatracker entries?  Are we
sure that the relevant URLs are stable enough and will stay that
way?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Nov 2013 09:29:20 -0800

On 11/21/2013 12:49 AM, Murray S. Kucherawy wrote:
> n Wed, Nov 20, 2013 at 3:10 PM, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
>>     that it's Historic
...
> one at rfc-editor.org <http://rfc-editor.org>. Someone grabbing the RFC
> from such sources (which could easily be seen as official) would not be
> aware of the status change or the reason for it.

These other paths to an obsolete RFC will typically either not tell the 
reader that the RFC is obsolte or will tell the reader that the RFC is 
obsolete and will not point the reader to the fact that there is an RFC 
explaining that it is obsolete.  Having an explanatory RFC provides no 
incremental benefit.  (One exception is rfc-editor.org.)

For example:

      Using Digest Authentication as a SASL Mechanism
      http://www.rfc-editor.org/rfc/rfc2831.txt

is obsolete, but the pointer goes to a page that says it's standards 
track.

My search for rfc2831 on google points to the above, as a first 
reference, and therefore doesn't tell me that it's obsolete.

The second reference is:

      http://www.rfc-editor.org/info/rfc2831

which /does/ indicate it's obsolete, and yes it points to the 
explanatory RFC.

Gosh, I wonder whether it would be possible for the RFC Editor pages to 
point to the datatracker page instead?  Nah, that's probably too 
outrageous a request.

So, to find:

      "Moving DIGEST-MD5 to Historic", July 2011
      http://www.rfc-editor.org/info/rfc6331

You have to either already know it exists. Or use a search tool that 
points to it.  If you are using a search tool, it can also point to the 
datatracker entry.

The IETF spent quite a lot of money on the datatracker.  We should work 
to have it be the primary search result for RFCs.

d/

---

From: S Moonesamy <[email-masked]>
Date: Thu, 21 Nov 2013 10:18:43 -0800

>an Applicability Statement.

The last RFC to be reclassified as Historic is RFC 2050.  There is a 
RFC which obsoletes RFC 2050.  The last RFC requesting a 
reclassification to Historic is RFC 6563.  The document provides a 
summary of the issues and attempts to explain why what the (proposed) 
standard is no longer recommended.  It has been the recent practice 
to publish a RFC when a specification is not recommended or what the 
IETF considers as harmful.

>community reaches that conclusion... just as we did with what

It has been said that the work of the IETF is done through its 
mailing lists.  The decisions are documented in RFCs.  There has been 
a few cases of inconsistences between what is in the datatracker and 
the (email) messages the community might usually read.  I don't 
recall any formal discussion about formalize the information in the 
datatracker as the archival record (the discussion in August was informal).

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Nov 2013 17:05:18 -0800

On 11/21/2013 7:40 AM, John C Klensin wrote:
>    it seems to

Which is exactly the same model being applied when explanatory text is 
published through an RFC.

We not not make sure that someone seeking the original RFC will find the 
explanatory RFC concerning a move to history.

The much-maligned datatracker makes the link and the RFC Editor Search 
makes the link.  The former already also points to non-RFC discussion 
and the latter can easily be modified to do that too.

> those procedures via a specific case".

There is no such "procedure".

There is an occasional practice, but nothing codified.

Certainly there is no procedure that is documented by the IETF.  Not in 
RFC 2026.  And not in the obscure IESG Statement on the matter of moving 
to Historic:

      http://www.ietf.org//iesg/statement/designating-rfcs-as-historic.html

In fact, most RFCs that are moved to Historic do not publish an 
explanatory RFC, although yes, some do.

      If my count is correct[*], there have been 44 RFC published since 
2000 that were moved to Historic.  Of those, 6 have had explanatory RFCs 
published along with the move the Historic.  That's 14%.

      No doubt, once can play with the analysis to up the percentage, 
but the essential points are:

         1.  There is no established IETF (or IESG) rule about
             publishing explanatory text

         2.  There is no consistent practice in publishing
             explanatory text

>    It also seems to me
> particular case.

I agree.  So please stop trying to impose a new rule due to this one case.

>> So here's the thing:

The problem with the analysis that John then pursued is that he 
cherry-picked examples that suited his view and ignored the ones that 
are just as plausible but don't support that view.

> to the datatracker (or equivalent) in all cases, we have some

Isn't it nice that John and I still manage to find substantive points to 
agree on?  Like this one.

The IETF spent a ton of money developing the datatracker.  In a few 
places, we press for its use, but mostly we don't.

For example, it should always be the first returned entry when doing a 
google search for an RFC or Internet-Draft.

d/

ps.  Speaking of side-effects, although I didn't look carefully, a 
side-effect of the quick research to produce the data for this note 
causes me to suspect that I might hold the record for the most RFCs 
moved to Historic...

RFCs Moved to Historic -- Annotated with explanatory RFCs

> RFC 2673	Binary Labels in the Domain Name System	August 1999	
> RFC 2754	RPS IANA Issues	January 2000	RFC 6254
> RFC 2766	Network Address Translation - Protocol Translation
>                 (NAT-PT)	February 2000	rfc4966
> RFC 2776	Multicast-Scope Zone Announcement Protocol (MZAP)	
>                 February 2000	
> RFC 2831	Using Digest Authentication as a SASL Mechanism	
>                 May 2000	rfc6331
> RFC 2841	IP Authentication using Keyed SHA1 with Interleaved Padding
>                 (IP-MAC)	November 2000	
> RFC 2874	DNS Extensions to Support IPv6 Address Aggregation and
>                 Renumbering	July 2000	
> RFC 2885	Megaco Protocol version 0.8	August 2000	
> RFC 2886	Megaco Errata	August 2000	
> RFC 2908	The Internet Multicast Address Allocation Architecture	
>                 September 2000	
> RFC 2909	The Multicast Address-Set Claim (MASC) Protocol	
>                 September 2000	
> RFC 2965	HTTP State Management Mechanism	October 2000	
> RFC 3340	The Application Exchange Core	July 2002	
> RFC 3341	The Application Exchange (APEX) Access Service	July 2002	
> RFC 3342	The Application Exchange (APEX) Option Party Pack,
>                 Part Deux!	July 2002	
> RFC 3343	The Application Exchange (APEX) Presence Service	
>                 April 2003	
> RFC 3525	Gateway Control Protocol Version 1	June 2003	
>                 RFC 5125
>
> RFC 3627	Use of /127 Prefix Length Between Routers Considered
>                 Harmful	September 2003	RFC 6547
>
> RFC 3913	Border Gateway Multicast Protocol (BGMP): Protocol
>                 Specification	September 2004	
> RFC 4156	The wais URI Scheme	August 2005	
> RFC 4157	The prospero URI Scheme	August 2005	
> RFC 4351	Real-Time Transport Protocol (RTP) Payload for Text
>                 Conversation Interleaved in an Audio Stream	January 2006	
> RFC 4612	Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type
>                 Registration	August 2006	
> RFC 4693	IETF Operational Notes	October 2006	RFC 6393
>
> RFC 4743	Using NETCONF over the Simple Object Access Protocol
>                 (SOAP)	December 2006	
> RFC 4744	Using the NETCONF Protocol over the Blocks Extensible
>                 Exchange Protocol (BEEP)	December 2006	
> RFC 4870	Domain-Based Email Authentication Using Public Keys
>                 Advertised in the DNS (DomainKeys)	May 2007	
> RFC 4905	Encapsulation Methods for Transport of Layer 2 Frames over
>                 MPLS Networks	June 2007	
> RFC 4906	Transport of Layer 2 Frames Over MPLS	June 2007	
> RFC 5143	Synchronous Optical Network/Synchronous Digital Hierarchy
>                 (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation	February 2008	
> RFC 5412	Lightweight Access Point Protocol	February 2010	
> RFC 5413	SLAPP: Secure Light Access Point Protocol	February 2010	
> RFC 5414	Wireless LAN Control Protocol (WiCoP)	February 2010	
> RFC 5772	A Set of Possible Requirements for a Future Routing
>                 Architecture	February 2010	
> RFC 5773	Analysis of Inter-Domain Routing Requirements and
>                 History	February 2010	
> RFC 5806	Diversion Indication in SIP	March 2010	
> RFC 6037	Cisco Systems' Solution for Multicast in BGP/MPLS IP
>                 VPNs	October 2010	
> RFC 6101	The Secure Sockets Layer (SSL) Protocol Version 3.0	
>                 August 2011	
> RFC 6123	Inclusion of Manageability Sections in Path Computation
>                 Element (PCE) Working Group Drafts	February 2011	
> RFC 6348	Requirements for Point-to-Multipoint Extensions to the Label
>                 Distribution Protocol	September 2011	
> RFC 6529	Host/Host Protocol for the ARPA Network	April 2012	
> RFC 6587	Transmission of Syslog Messages over TCP	April 2012	
> RFC 6804	DISCOVER: Supporting Multicast DNS Queries	November 2012	
>
>
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Nov 2013 21:30:06 -0500

Further closing the loop:
On Thursday's telechat, the IESG approved the status change of ADSP to
Historic status, and the official announcement of that (which this is
not) will be posted early next week.  The IESG considers that it has
followed the process specified in RFC 2026, Section 6.4, with regard
to the status change.  It also considers that further documentation
than what already is and will be provided (in the status change
document, in the telechat minutes, and so on) is neither required nor
particularly necessary.  As Dave points out, some status changes have
come with associated RFCs, and some have not.

That said, a point was raised to me by Scott in an off-list exchange,
and indirectly on list by John: We do, indeed, have these nice, new
"status change" documents, but they are not RFCs and we have no
specification of the process by which they're approved and published.
I brought that point up, and the IESG will be discussing it in the
next few weeks.

My personal opinion on what we should do with that is a bit mixed: on
the one hand, these documents are tools to implement the discretion
the IESG already has according to RFC 2026, and their introduction
neither creates nor requires any change in process; on the other hand,
if we are, as I would like, to use them as permanent documentation for
our actions, some specification of how we use them might have value.

More on that, after the IESG has considered the question.

Separately, I will be asking the RFC Editor if they can include the
status change documents in their RFC metadata, adding one more place
where the right information can be found.

Barry, Applications AD

---

From: S Moonesamy <[email-masked]>
Date: Fri, 22 Nov 2013 07:58:35 -0800

Hello,
>not) will be posted early next week.  The IESG considers that it has

This is not an objection.

Section 5 of RFC 5617 created some namespaces [1] in the IANA 
registry.  These namespaces require IETF Review.  There is an easy 
way for the IESG to perform the registry clean-up.    The easy way 
might end up being problematic.

Regards,
S. Moonesamy

1. http://www.iana.org/assignments/adsp-parameters

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Nov 2013 12:36:45 -0500

> Section 5 of RFC 5617 created some namespaces [1] in the IANA registry.
> These namespaces require IETF Review.  There is an easy way for the IESG to
> perform the registry clean-up.    The easy way might end up being
> problematic.

I'm not sure I understand the question or the problem.  We normally
leave registries and registered entries alone.  What sort of cleanup
are you looking for?

We could put a notation in the registry that says it's historic, but
anyone looking at the registry's reference document will see that
anyway.

Barry

---

From: S Moonesamy <[email-masked]>
Date: Fri, 22 Nov 2013 11:01:28 -0800

Hi Barry,
>leave registries and registered entries alone.  What sort of cleanup

I am not looking for a cleanup.  I commented as I read the RFC and 
the IESG Evaluation record and I did not see any comment about the 
registries or the usual IANA comment in the datatracker.

Regards,
S. Moonesamy