Re: 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)

[Brian E Carpenter <[e-mail]>]

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:
> So, just to keep people at least sort of "in the loop" ...
> 
> On Mon, May 14, 2018 at 7:55 AM, John R Levine <[e-mail]> 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
>