Subject: [httpapi] Linkset draft: move from informational to proposed standard?

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Jan 2022 20:48:40 +0000

One of the area reviewers questioned why the linkset document is informational rather than proposed standard.  The doc authors and the chairs had some off-line discussion about this, and we should bring this one to the group.

The difference among the standards types can be opaque to many, including those active on documents.  :)  The official definition is found in RFC 2026 [1], but that document has been updated by about a dozen RFC’s since then. The two that are most applicable here are RFC 6410 [2] and RFC 7127 [3].
I don’t expect you to read them! Even the biggest IETF nerd-heads aren’t familiar with all their nooks and crannies. Darrel points out an excerpt of 2026 that (although a bit outdated), still mostly holds; it can be found at [4], and just ignore the title. I recommend [3] gives the most valid content per byte of any of the links below. :)

It’s important to know that what working groups produce are “proposed standards”  Later on the working group can ask the IESG to take a “standards action” to move it through the phases of Draft Standard and eventually to Internet Standard. Often, however, Proposed Standard is good enough. I’ll point out that TLS never been promoted to an Internet Standard. My suggestion to the working group is don’t worry about it. You can find the list of standards, draft standards, and proposed standards at [5].

What we do here is not intended to be just documented for posterity, but is designed to be implemented, interoperable, and hopefully achieve common deployment and has no explicit criteria to measure success or failure. By those criteria, which happen to match the list in [1], [4].  Put noather way: “[This] specification is stable, has resolved known design choices, has received significant community review, and appears to enjoy enough community interest to be considered valuable.” [3].

There are two questions I’d like the WG to consider:

  *   A. Should the “linkset” draft be a Proposed Standard?
  *   B. Should we assume everything we do is Proposed Standard unless otherwise discussed?

Please post your thoughts about A and/or B within the next two weeks.

Thank you!

[1] https://www.rfc-editor.org/info/rfc2026
[2] https://www.rfc-editor.org/info/rfc6410
[3] https://www.rfc-editor.org/info/rfc7127
[4] https://www.ietf.org/standards/process/informational-vs-experimental/
[5] https://www.rfc-editor.org/standards

---

From: Erik Wilde <[email-masked]>
Date: Fri, 21 Jan 2022 13:53:46 -0800

hello.

thanks for providing so much context, rich!

> Please post your thoughts about A and/or B within the next two weeks.

my answer to both of these is an emphatic "yes". we have worked on 
linkset for five years now, and bringing it to the working group has 
helped to make it better by providing more visibility and review. my 
main hope for the working group in general is that this is what it will 
do for every spec that it works on: make building blocks more visible 
and provide a forum to have consensus around their design.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Herbert Van de Sompel <[email-masked]>
Date: Fri, 21 Jan 2022 23:08:21 +0100

On Jan 21, 2022, at 22:54, Erik Wilde <[email-masked]> wrote:
> my answer to both of these is an emphatic "yes". we have worked on linkset for five years now, and bringing it to the working group has helped to make it better by providing more visibility and review. my main hope for the working group in general is that this is what it will do for every spec that it works on: make building blocks more visible and provide a forum to have consensus around their design.
> 

I am totally with Erik on this.

Cheers

Herbert

> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi

---

From: Darrel Miller <[email-masked]>
Date: Fri, 21 Jan 2022 22:40:00 +0000

Speaking as an individual, my answers to the questions are yes and yes.

Darrel

From: Salz, Rich<mailto:rsalz=[email-masked]>
Sent: January 21, 2022 3:49 PM

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 22 Jan 2022 12:04:30 +0900

> Speaking as an individual, my answers to the questions are yes and yes.

Our charter says:

Its output can include the following:

• Specifications for HTTP extensions that relate to HTTP APIs 
(typically, new HTTP header and/or trailer fields)

• Specifications for new message body formats, or conventions for their 
use in HTTP APIs (e.g., patterns of JSON objects)

• Best practices and other documentation for HTTP API designers, 
consumers, implementers, operators, etc.

It's quite clear that the first two bullet points should result in 
Proposed Standards, and the last one in BCP. Experimental or 
Informational may be used if something is in an early design/use phase.

So my answers would be: A: Yes, B: Mostly yes, but see above.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 22 Jan 2022 14:16:51 +1100

My .02 -

While 2026 et al imply a gradation of "trying it out" and "we mean this" between "full" and Proposed Standard, the practicality of it is that only the most advanced, venerable specifications make it to full Internet Standard. The bulk of IETF specifications in use on the Internet today are Proposed Standard.

So, if we want to retain a signal of "this is a proposal, let's see how it goes" vs. "we really mean this", I'd suggest we use Informational for the former and Proposed for the latter (as Martin alludes to below). Upgrading from Informational to Proposed Standard is (AIUI) fairly easy to do, with coordination by the AD.

That's rather important for this group IMHO, because we're still building a community and we want to make sure that we're not overstating the authority of what we come up with. 

What we should *not* do is use Proposed Standard in the hope that it will foster more usage / attention on the spec. In other words, the document status should reflect the breadth of review and consensus, not be aspirational.

So my answers would be:

A. I'm neutral here -- it depends on how sure we are that this represents broad consensus in the industry.
B. Definitely not.

Cheers,

> On 22 Jan 2022, at 2:04 pm, Martin J. Dürst <[email-masked]> wrote:
> 
> • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields)
> 
> • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects)
> 
> • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc.
> 
> It's quite clear that the first two bullet points should result in Proposed Standards, and the last one in BCP. Experimental or Informational may be used if something is in an early design/use phase.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jan 2022 15:04:30 +0000

Discussion on this seems to have died down. We had several experienced members give opinions, and they all seem to agree:

  *   Okay for linkset to move to proposed standard
  *   Not okay to assume all new drafts are proposed standard. One major reason cited for the assumption is that the IETF does not want to create a standard that is not implemented.

If you disagree with this, please speak post within a few days.

From: Rich Salz <[email-masked]>
Date: Friday, January 21, 2022 at 3:48 PM
To: "[email-masked]" <[email-masked]>
Cc: Francesca Palombini <[email-masked]>
Subject: Linkset draft: move from informational to proposed standard?

Thank you!