Subject: [Rfcplusplus] Qualified labels

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2018 14:23:57 +1200

Hi,

I don't think there's any disagreement that better labels are
desirable. I do think this would all be a lot simpler if we
could just agree to move to a single-stage standards track,
but since we must support status changes within the standards
track, including obsoletion, we are forced to have external
labels that are not in the archived format. That's an opportunity
as well as a challenge. So here's a proposal:

1) Continue to use the RFC series as today for multiple purposes.
But recognise more clearly that the number is an archival reference.

2) For all normal purposes, including citations, use a *qualified*
label. Rather than writing a formal definition, there's an example
of each qualifier below.

An advantage is that this can be retrofitted straightforwardly
to *all* RFCs, indexes, citation libraries, etc. And it
could be removed just as easily if it proves to be a problem
rather than a solution.

RFC8200-STD (or RFC8200-STD86)
RFC8414-PS
RFC5681-DS
RFC2026-BCP (or RFC2026-BCP9)

RFC7557-EXPT
RFC8394-INFO  (for IETF informationals) 
RFC7663-IAB
RFC7575-RSCH  (for IRTF informationals)
RFC8351-INDEP (for Independent informationals)

RFC2460-OBS
RFC1128-UNK
RFC1130-HIST

Regards
    Brian

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Jul 2018 21:44:22 -0500

On 7/9/18 9:23 PM, Brian E Carpenter wrote:
> to *all* RFCs, indexes, citation libraries, etc.
If we were to pursue this path:

That's not quite straightforward. It's easy if you just snapshot the 
current qualifiers, but if you want to be historically correct, it's 
going to take some non-straightforward work. It would also need a 
decision about edges like the following (both for handling what has 
happened, and what could happen in the future):

Would RFC5249-INFO and RFC5249-PS be different documents, or aliases for 
the same document? (I assume having RFC5249-INFO disappear from the 
archival record would be unacceptable). How would a user finding 
RFC5249-INFO learn about RFC5249-PS? (And a string of very familiar 
questions would follow here).
>   And it
> _______________________________________________
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus

---

From: Robert Sparks <[email-masked]>
Date: Mon, 9 Jul 2018 21:49:51 -0500

_sigh_ - even after carefully trying to point to a particular edge, I 
transcribed the number incorrectly.

Please substitute 5289 for all the rfc number examples I pointed to below.

RjS

p.s. 
<https://datatracker.ietf.org/doc/status-change-uplifting-rfc5289-to-ps/>

On 7/9/18 9:44 PM, Robert Sparks wrote:
> Would RFC5249-INFO and RFC5249-PS be different documents, or aliases 
> for the same document? (I assume having RFC5249-INFO disappear from 
> the archival record would be unacceptable). How would a user finding

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2018 16:53:42 +1200

> Please substitute 5289 for all the rfc number examples I pointed to below.

Right. My thinking is that the label would indeed need to be ephemeral
in case a document changes status, and I guess that would lead to
tombstones in the citation libraries. Or to put it another way,
a document would have a label stack, with the current label on top,
but the previous ones still there for the sake of previous citations.
So the label stack for RFC5289 should** be

1. RFC5289-PS
2. RFC5289-INFO

and that for RFC2460 should be

1. RFC2460-OBS
2. RFC2460-DS

** However, you have hit upon a bug. The IESG may believe that
they upgraded RFC5289, but it seems that nobody told the RFC Editor,
since it is still officially listed as Informational. Even the tracker
is confused. So we have a procedural glitch in this area already.

   Brian

---

From: Alice Russo <[email-masked]>
Date: Tue, 10 Jul 2018 11:40:57 -0700

> is confused. So we have a procedural glitch in this area already.

Indeed.

I am taking a look at what happened here and will report back.

Thank you.
RFC Editor/ar

---

From: Alice Russo <[email-masked]>
Date: Tue, 10 Jul 2018 12:35:51 -0700

Reporting back re: RFC 5289.

[FYI, the IESG has been sent this information separately.]

We received the Protocol Action mail 20 March 2017 to change RFC 5289 to Proposed Standard, but the status change was not carried out. I apologize for this mistake. 

At this point, the underlying data and derived displays have been updated. The info page [1] and the list of all RFC status changes [2] show "March 2017" for this change. However, if the preference is "July 2018" to reflect when the RFC's metadata was updated, please let me know.

We'll review the mails re: status changes received thus far and revise the process for handling them (as necessary) to prevent this in the future.

Typically, a notification mail is sent to rfc-dist and ietf-announce when an RFC moves up in the Standards Track (in this case, onto the Standards Track). We'll send that shortly.

Thank you.
RFC Editor/ar

[1] https://www.rfc-editor.org/info/rfc5289 
[2] https://www.rfc-editor.org/status_changes.php 

> On Jul 10, 2018, at 11:40 AM, Alice Russo <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jul 2018 11:30:44 +1200

Thanks Alice!

Actually this glitch makes me think that completely regardless of
the imminent BOF, we need some sort of shared format for the
ephemeral "wrapping" of an RFC including current and previous
status, and dates. Not a topic for this list, however.

Regards
   Brian