Subject: Visibility of current RFC Maturity Levels (and how they got there (was: Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 14 May 2018 10:25:34 -0500

So, just to keep people at least sort of "in the loop" ...

On Mon, May 14, 2018 at 7:55 AM, John R Levine <[email-masked]> wrote:

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

Even as an AD starting his sixth year on the IESG, I didn't have a clear
picture of how visible maturity level changes are to the community, but I
have processed status change documents for some RFCs, so I went to look at
RFC 3540 (published at Experimental, but moved to Historic).

Just based on what I'd expect to get if I googled RFC3540,  I'd most likely
be looking at  https://tools.ietf.org/html/rfc3540.

That page does reflect the current Maturity level (Historic), because it
inserts dynamic metadata at the top of the first page.

It doesn't say, on that page, how the RFC got to that Maturity level.

If I click on [Tracker], I get https://datatracker.ietf.org/doc/rfc3540/,
which DOES say "Status changed by
status-change-ecn-signaling-with-nonces-to-historic", with a link to
https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/
.

That's not great, but maybe not everyone needs to know how an RFC got to
its current Maturity level.

Of course, if I happen to be looking at
https://www.rfc-editor.org/rfc/rfc3540.txt, I don't see any of this. The
invariant text form of the RFC would like me to believe it's still
Experimental. That's what you get from the datatracker, when you click on
"plain text".

Clicking on "TXT" on the HTML version from the tools page gets me a
different resource, https://tools.ietf.org/rfc/rfc3540.txt, but that
resource also says "Experimental".

I rarely go straight to the RFC Editor page (just because I spend almost
all my time on drafts that aren't RFCs yet), but if I searched for 3540 on
the RFC Editor page, I get
https://www.rfc-editor.org/search/rfc_search_detail.php?rfc=3540&pubstatus%5B%5D=Any&pub_date_type=any,
which says "Historic (changed from Experimental November 2017)", and if I
click on "November 2017", I get a pointer to
https://mailarchive.ietf.org/arch/msg/ietf-announce/NPX38P5447i8DwYN7Ijf0t0JJEQ,
the IETF-Announce "Document Action: Robust Explicit Congestion Notification
(ECN) Signaling with Nonces to Historic" e-mail.

That e-mail does provide a link to the status change document (
https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/
).

I have opinions about all of this, and I shared them with the IESG and IAB
during our annual retreat last month, but wonder if anyone else does ...

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 May 2018 12:17:11 +1200

Top posting to note that if you find the RFC via its DOI you
also get the correct status first. I think the RFC Editor has
done the best they can, consistent with the policy that the
bits in the canonical form of an RFC never change.

Regards
   Brian

On 15/05/2018 03:25, Spencer Dawkins at IETF wrote:
> ..

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 May 2018 11:09:36 -0500

> bits in the canonical form of an RFC never change.

That touches on John Klensin's question about where people would
reasonably expect to find things (RFCs and metadata about them).

For me as an AD, I am either looking at the tools.ietf.org HTML
version or the datatracker page, or I am lamenting Google's
algorithm that placed me somewhere else.  But I don't know what
"people in general" are "reasonably expecting" to do; perhaps the
RFC Editor's plain-text repository remains canonical in usage as
well as in archival status, even if it is not for me.  (It's also
unclear how useful http/rsync/etc access logs would be for trying to
answer this question.)

-Ben

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 May 2018 17:16:25 +0100

Well, if people are really going to the .txt files on rfc-editor.org,
then nothing we do in the process of changing an RFC's status will
help them, and it doesn't matter whether we use "obsoletes" or not.

If they're using most other means, they will see the current state of
"Historic", and they will have a way to navigate to the status-change
document.  Because of that, having an RFC that uses "obsoletes" seems
mostly unnecessary, except that the "obsoleted by" pointers might be a
little easier to find, depending upon the access mechanism you're
using.

My sense is that someone who cares enough to want to find out why the
RFC is Historic is likely to be able to handle the navigation.

Barry

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

---

From: "John R Levine" <[email-masked]>
Date: 15 May 2018 12:21:01 -0400

> unclear how useful http/rsync/etc access logs would be for trying to

I use rsync and find stuff using rfc-index.txt and rfc-index.xml.  Those 
have the obsoletes and updates links but no URLs.  Dunno how typical it 
is, but it's very convenient.  The full archive including all the bulky 
postscript is about .5GB, not much these days.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "tom p." <[email-masked]>
Date: Tue, 15 May 2018 17:27:43 +0100

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
Sent: Tuesday, May 15, 2018 5:16 PM

Barry

I do indeed go to the underlying .txt files, every week - rfc-index.txt!
It is so much easier to search, to navigate than HTML.  And it tells me
the Status.

I think that HTML only works if the underlying data model has been
thought through and can then be translated into anchors and such like.
Otherwise you may be better off with the sort of fuzzy search that the
likes of Google offer (or rfc-index.txt and a text editor)..

Tom Petch

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 May 2018 18:32:31 +0200

On 2018-05-15 02:17, Brian E Carpenter wrote:
> ...

In the hopefully not so distant future, the RFC Editor will also serve 
HTML. As that is *not* the "canonical" version, it could dynamically 
insert current metadata (such as demonstrated in various places, for 
instance <https://tools.ietf.org/html/rfc2616> or 
<https://greenbytes.de/tech/webdav/rfc2616.html>).

To make this work *well*, the RFC Editor should publish the metadata 
*per* RFC in a machine readable (XML or JSON) and web-friendly (CORS) way.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 May 2018 17:41:18 +0100

Hi, Tom.

> It is so much easier to search, to navigate than HTML.  And it tells me

I was referring to using the .txt files for the RFCs; yes, the index
contains the status.  But if you go directly to, say, rfc3540.txt, it
won't tell you that it's Historic.

b