Subject: [Rfcplusplus] problems and solutions

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jun 2018 12:07:41 -0600

(Just joined the list, sorry about the new thread.)

The primary problem folks here have pointed to is confusion among people
who write RFPs. Both Barry and Adam provided entertaining anecdotes, the
likes of which I've seen as well. However, those problems were solved
fairly easily by educating the customer (less easily, perhaps, in large
organizations with poor communication - what's new?).

To judge the proposal, could the proposers provide a basic cost-benefit
analysis, preferably including data and an accounting of risks?

As to solutions, Andrew Malis proposed some clearer boilerplate text at
the top of each document. Some years ago, we added text like this to
specs in the XMPP Standards Foundation's XEP series, and it helped to
educate people who were confused about document status. [1]

Peter

[1] Here is the text we use at the XSF...

For a Final XEP (like an Internet Standard RFC), green text stating:

NOTICE: The protocol defined herein is a Final Standard of the XMPP
Standards Foundation and can be considered a stable technology for
implementation and deployment.

example: https://xmpp.org/extensions/xep-0030.html

For a Draft XEP (like a Proposed Standard RFC), green text stating:

NOTICE: The protocol defined herein is a Draft Standard of the XMPP
Standards Foundation. Implementations are encouraged and the protocol is
appropriate for deployment in production systems, but some changes to
the protocol are possible before it becomes a Final Standard.

example: https://xmpp.org/extensions/xep-0176.html

For an Experimental XEP (like an Internet-Draft), red text stating:

WARNING: This Standards-Track document is Experimental. Publication as
an XMPP Extension Protocol does not imply approval of this proposal by
the XMPP Standards Foundation. Implementation of the protocol described
herein is encouraged in exploratory implementations, but production
systems are advised to carefully consider whether it is appropriate to
deploy implementations of this protocol before it advances to a status
of Draft.

example: https://xmpp.org/extensions/xep-0400.html

For a Humorous XEP (published on April Fool's Day), green text stating:

NOTICE: This document is Humorous. It MAY provide amusement but SHOULD
NOT be taken seriously.

example: https://xmpp.org/extensions/xep-0076.html

And so on...

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 19 Jun 2018 14:15:47 -0400

Needless to say, +1!

Cheers,
Andy

On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre <[email-masked]>
wrote:

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Jun 2018 13:16:43 -0700

> On Jun 19, 2018, at 11:15 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> Needless to say, +1!

I also agree, and would support clearer boilerplate.  This would do no harm, as compared to what is proposed in the BOF description that I think would create more confusion.

Bob

> 
> Cheers,
> Andy
> 
> 
> On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre <[email-masked]> wrote:

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2018 08:58:36 +1200

Yes. I put a rough and ready list of problems in
https://tools.ietf.org/html/draft-carpenter-request-for-comments-00#section-2
and I would expect a BOF to start by considering a complete problem
set and prioritising before trying to pick a solution.

https://www.brainyquote.com/quotes/h_l_mencken_129796

Regards
   Brian

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Jun 2018 16:47:53 -0600

On 06/19/2018 12:07 PM, Peter Saint-Andre wrote:
> ...

Published RFCs can not be edited, so, any "Final Standard" in the 
document text will be obsolete at some point. Is this just not kicking 
the can down the road a few more years?

Would it be a better solution to log them with something like an IANA 
registration? Perhaps grouped by area and protocol.

Documents intended to be standard would then just refer the reader to 
the standard registration page that would point to the latest hopeful 
document(s).

-- 

Doug Royer - (http://DougRoyer.US  http://goo.gl/yrxJTu )
[email-masked]
714-989-6135

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2018 11:18:34 +1200

> the standard registration page that would point to the latest hopeful 

We don't need to wake up IANA for this. We already have the STD designation,
which for some reason we've never chosen to use for the PS documents that
the Internet runs on. A proposal for this was made 14 years ago:
https://tools.ietf.org/html/draft-klensin-newtrk-std-repurposing
and not much has changed since then.

   Brian

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Jun 2018 17:45:44 -0600

> and not much has changed since then.

I used IANA as an example. I don't care if it is IANA or not. A live 
document would be great along with the prohibition of any future RFC 
calling itself a standard in its text or Category on the title page.

--

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Jun 2018 11:57:19 -0400

On Tue, Jun 19, 2018 at 7:45 PM, Doug Royer <[email-masked]> wrote:
> document would be great along with the prohibition of any future RFC calling
> itself a standard in its text or Category on the title page.
>

I like Peter's suggestion and think to solve the problems raised, we
just need to word this type of boilerplate carefully for the IETF
streams.

I am not in favor of an experiment that cannot be backed out of, so I
don't think RFC# assignments should stop during an experiment.  And
also feel strongly that we should be thinking more about the problem,
objectives, and how to measure to points already made on the various
threads.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jun 2018 14:18:47 -0600

> just need to word this type of boilerplate carefully for the IETF

Yes, this is a great bikeshedding opportunity. :-)

I suggest that we'd want boilerplate for all RFCs, not just those
produced in the IETF stream.

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2018 11:51:31 +1200

> produced in the IETF stream.

s/boilerplate/updated boilerplate/

We already have stream-specific boilerplate, so you must be referring
to re-bikeshedding it.

If there's a problem today, it proves that people either do not read
or choose to disregard the current boilerplate. I don't really see
how that will change if the documents are split into "Requests for
Comments" and "IETF Edicts", or whatever the new ones would be called.
If the RFC did a better job of describing what their customers wanted,
the vendors would implement the RFC instead of the Edict.

    Brian

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Thu, 21 Jun 2018 06:24:54 -0700

This ISE would not be opposed to a change in prominence and content of
streams boilerplate if anyone believes that would make them feel less
uncomfortable.

Maybe a little bit of a shame that it is only two years since 7841 and
possibly not enough people paid attention at that time (given that the
claim is that the problem is long-standing), but we're engineers, so if
something is broken, it should be fixed.

Adrian

-- 
Adrian Farrel (ISE),
[email-masked]