Subject: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-03.txt

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2021 14:45:03 -0600

As promised. I won't submit a new version again until after our meeting
on September 28.

The primary changes in this version are:

- add boilerplate for the Editorial Stream
- add some text from RFC 8728 (e.g., more detailed information about RPC
responsibilities)
- harmonize with RFC 8729

-------- Forwarded Message --------
Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-03.txt
Date: Tue, 21 Sep 2021 13:41:47 -0700
From: [email-masked]
To: Peter Saint-Andre <[email-masked]>

A new version of I-D, draft-iab-rfcefdp-rfced-model-03.txt
has been successfully submitted by Peter Saint-Andre and posted to the
IETF repository.

Name:		draft-iab-rfcefdp-rfced-model
Revision:	03
Title:		RFC Series Policy Definition and Implementation
Document date:	2021-09-21
Group:		iab
Pages:		25
URL:
https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-03.txt
Status:
https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model
Diff:
https://www.ietf.org/rfcdiff?url2=draft-iab-rfcefdp-rfced-model-03

Abstract:
   This document describes updated processes for defining and
   implementing policies regarding the RFC Series as a whole and thus
   specifies version 3 of RFC Editor Model.  As specified here, the
   model divides the responsibilities for the RFC Series into two high-
   level tasks.  Policy definition is the responsibility of the RFC
   Series Working Group (RSWG), which produces policy proposals that are
   subject to approval by the RFC Series Approval Board (RSAB).  Policy
   implementation is primarily the responsibility of the RFC Production
   Center (RPC), under the ultimate authority of the IETF Administration
   Limited Liability Company (IETF LLC).

   This document obsoletes RFC 8728.

The IETF Secretariat

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Sep 2021 20:31:03 +0100

Hi,

A nit, perhaps, that’s been present since the -02 version but that I forgot to mention.

Section 6 says: "Documents pubished in the Editorial Stream shall have a status of Informational.  The Editorial Stream is not authorized to publish RFCs that are Standards Track or Best Current Practice, since such RFCs are reserved to the IETF Stream [RFC8729].” This does not mention Experimental RFCs. Should it? We’ve had "process experiments" in the past… 

Colin

> On 21 Sep 2021, at 21:45, Peter Saint-Andre <[email-masked]> wrote:
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

-- 
Colin Perkins
https://csperkins.org/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2021 13:44:51 -0600

> Section 6 says: "Documents pubished in the Editorial Stream shall have a status of Informational.  The Editorial Stream is not authorized to publish RFCs that are Standards Track or Best Current Pr…

The concern was that the Editorial Stream not publish RFCs that could be
construed as standards. One could imagine that we *might* want to do
experiments in the Editorial Stream, but some squinting is involved.
Thus personally I'd be fine with mentioning Experimental as well
(although, again, that was not the concern).

Peter

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Sep 2021 20:48:51 +0100

> On 22 Sep 2021, at 20:44, Peter Saint-Andre <[email-masked]> wrote:

Sure – I understand the concern.

I’d lean towards cannot publish Experimental RFCs on the Editorial Stream, as process experiments seem to be stretching the definition of experimental, but don’t have a strong opinion. I do think we should make a decision though.

-- 
Colin Perkins
https://csperkins.org/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2021 13:54:28 -0600

> I’d lean towards cannot publish Experimental RFCs on the Editorial Stream, as process experiments seem to be stretching the definition of experimental, but don’t have a strong opinion. I do think w…

+1 to no Experimental - make them all Informational and keep it simple.

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Sep 2021 16:25:51 -0400

--On Wednesday, September 22, 2021 13:54 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>>> On 22 Sep 2021, at 20:44, Peter Saint-Andre
>>> <[email-masked]> wrote: On 9/22/21 1:31 PM, Colin
>>> Perkins wrote:
>>>> Hi,
>>>> 
>>>> A nit, perhaps, that's been present since the -02 version
>>>> but that I forgot to mention.
>>>> 
>>>> Section 6 says: "Documents pubished in the Editorial Stream
>>>> shall have a status of Informational.  The Editorial Stream
>>>> is not authorized to publish RFCs that are Standards Track
>>>> or Best Current Practice, since such RFCs are reserved to
>>>> the IETF Stream [RFC8729]." This does not mention
>>>> Experimental RFCs. Should it? We've had "process
>>>> experiments" in the past… 
>>> 
>>> The concern was that the Editorial Stream not publish RFCs
>>> that could be construed as standards. One could imagine that
>>> we *might* want to do experiments in the Editorial Stream,
>>> but some squinting is involved. Thus personally I'd be fine
>>> with mentioning Experimental as well (although, again, that
>>> was not the concern).
>> 
>> 
>> I'd lean towards cannot publish Experimental RFCs on the
>> Editorial Stream, as process experiments seem to be
>> stretching the definition of experimental, but don't have a
>> strong opinion. I do think we should make a decision though.
> 

I am concerned that we may be setting a trap for ourselves
should a new stream come along, should the IETF community change
the names or definitions of its categories.  So, without
disagreeing about present-day substance, I'd prefer:

Old:
	The Editorial Stream is not authorized to publish RFCs
	that are Standards Track or Best Current Practice, since
	such RFCs are reserved to the IETF Stream [RFC8729].

New: 
	The Editorial Stream is not authorized to publish RFCs
	in any category that is reserved to the IETF Stream as
	described in RFC 8729 [RFC8729] or its successors.
	While publication of Experimental documents in the
	Editorial Stream is not anticipated, any such document
	must be approved by the IESG as unlikely to cause any
	confusion with the standards process.

Wordsmith as desired but the intent is that we future-proof the
situation without getting bogged down in details that might
change. In particular, should the IETF ever decide to separate
technical and procedural BCPs, sorting out the details of the
relationship of the Editorial Stream to the latter becomes a
matter for 8729bis, not something we need to think through or
for which this document would need to be revised.  We also
explicitly kick the "Experimental" question down the road,
thereby avoiding having those of us who might say "well maybe"
going looking for counterexamples, process experiment
possibilities, etc.  

   best,
    john

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Sep 2021 22:38:25 +0200

Aren't we going a long way to say that we should be publishing 
informational documents?

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Sep 2021 18:51:05 -0400

> Aren't we going a long way to say that we should be publishing

Eliot,

Maybe.

But our general position has been that Informational documents
carry little or no authority.  Historically, we have needed to
do a lot of explaining about Informational documents that
actually set out firm, nearly chiseled into stone, policies and
requirements that have substantive effects on what people can
do.  So, yes, we can (and have) published, e.g., style guides
and their predecessor "instructions to authors" documents as
announcements of rules that, if one does not follow, one is in
for at least delays and maybe pain.

Scott and others will probably remember better than I do (I've
completely forgotten) but I assume the decisions to publish IETF
procedural documents as BCPs were tied up with that distinction
between informative and authoritative documents.

And, also historically, the authority behind most such
Informational documents that did not emerge from the IETF/IESG
(and the pre-Kobe IAB) --and the ability to enforce whatever
they had to say -- has been extremely clear.  But, as we move
away from a powerful RFC [Series] Editor toward the more
complicated relationships the document lays out, there are, IMO,
no guarantees that things will remain equally clear.  If
"Informational" turns out to be inadequate, then we may need to
invent some sort of "Editorial Specification" or, were the IETF
to make the separation of procedural and technical BCPs, some
subcategory of however the former turns out to be organized.

And that, of course, interacts with the discussion about a
separate series for these documents.

So I'm just trying to see if we can write this document in a way
that does not require re-opening it --and restarting whatever
process is used to approve it-- should things not come together
the way according to our best predictions today.

   john

>> --On Wednesday, September 22, 2021 13:54 -0600 Peter
>> Saint-Andre <[email-masked]> wrote:
>> 
>>>>>> Section 6 says: "Documents pubished in the Editorial
>>>>>> Stream shall have a status of Informational.  The
>>>>>> Editorial Stream is not authorized to publish RFCs that
>>>>>> are Standards Track or Best Current Practice, since such
>>>>>> RFCs are reserved to the IETF Stream [RFC8729]." This
>>>>>> does not mention Experimental RFCs. Should it? We've had
>>>>>> "process experiments" in the past…
>>>>> that could be construed as standards. One could imagine
>>>>> that we *might* want to do experiments in the Editorial
>>>>> Stream, but some squinting is involved. Thus personally
>>>>> I'd be fine with mentioning Experimental as well
>> should a new stream come along, should the IETF community
>> change the names or definitions of its categories.  So,
>> without disagreeing about present-day substance, I'd prefer:
>> 
>> Old:
>> Wordsmith as desired but the intent is that we future-proof
>> the situation without getting bogged down in details that
>> might change. In particular, should the IETF ever decide to
>> separate technical and procedural BCPs, sorting out the
>> details of the relationship of the Editorial Stream to the
>> latter becomes a matter for 8729bis, not something we need to
>> think through or for which this document would need to be
>> revised.  We also explicitly kick the "Experimental" question
>> down the road, thereby avoiding having those of us who might
>> say "well maybe" going looking for counterexamples, process
>> experiment possibilities, etc.
>> 
>>     best,
>>      john
>> 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2021 17:32:32 -0600

> subcategory of however the former turns out to be organized.

Given that we're framing this new structure as a way to generate
series-wide policies, I could see adding a status of "Procedural" --
FWIW, over in the XSF we've long had such a status. [1] But I don't know
that we want to modify the list of RFC types at this point...

Peter

[1] https://xmpp.org/extensions/xep-0001.html#types-Procedural

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Sep 2021 19:53:00 -0400

--On Wednesday, September 22, 2021 17:32 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>>> Aren't we going a long way to say that we should be
>>> publishing informational documents?
>> 
>> Eliot,
>> 
>> Maybe.
>> 
>> actually set out firm, nearly chiseled into stone, policies
>> and requirements that have substantive effects on what people
>> can do.  So, yes, we can (and have) published, e.g., style
>> guides and their predecessor "instructions to authors"
>> documents as announcements of rules that, if one does not
>> follow, one is in for at least delays and maybe pain.
>> 
>> completely forgotten) but I assume the decisions to publish
>> IETF procedural documents as BCPs were tied up with that
>> distinction between informative and authoritative documents.
>> 
>> complicated relationships the document lays out, there are,
>> IMO, no guarantees that things will remain equally clear.  If
>> "Informational" turns out to be inadequate, then we may need
>> to invent some sort of "Editorial Specification" or, were the
>> IETF to make the separation of procedural and technical BCPs,
>> some subcategory of however the former turns out to be
>> organized.
> 
> Given that we're framing this new structure as a way to
> generate series-wide policies, I could see adding a status of
> "Procedural" -- FWIW, over in the XSF we've long had such a
> status. [1] But I don't know that we want to modify the list
> of RFC types at this point...

I haven't been following things closely enough, but I though
that we had more or less decided to not try modifying the list
of types as part of this effort.  All I'm trying to suggest is
that, insofar as possible, we write the document so that a
change or refinement of RFC types does not require reopening it.

Arguably conflating "status" and "RFC type" has been a
long-standing mistake. But I'd far prefer to hand that issue off
to the new arrangements rather than adding another can of worms
to the present task.

   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2021 18:05:53 -0600

> change or refinement of RFC types does not require reopening it.

I see your point. We could simply forbid anything reserved to the IETF
by RFC 8729 / RFC 2026. (For example, if we ever define version 4 of the
RFC Editor Model, then version 3 could be changed to Historic.)

Peter

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 23 Sep 2021 09:06:14 +0900

> Aren't we going a long way to say that we should be publishing 

It feels like this to me, too. So what about e.g.:

The RFCs published by the Editorial Stream are published as 
Informational to avoid any confusion with standards-track and related 
technical documents.

Actually, I'd like to add another sentence to this, to make sure that 
"Informational" isn't misunderstood (e.g. an author saying "well, the 
style guide is Informational, so it's okay to ingore it"), maybe close 
to the following:

Even though RFCs published by the Editorial Stream are labeled as 
Informational, they carry defining force in the relevant subject matter.

Regards,   Martin.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Scott Bradner <[email-masked]>
Date: Wed, 22 Sep 2021 20:17:03 -0400

> On Sep 22, 2021, at 6:51 PM, John C Klensin <[email-masked]> wrote:
> 

When I was tasked with what became RFC 2026 the question of how the RFC should be published
was not a part of the assignment 

background factoid - Jon had recently published RFC 1818 - BCP (with Yakov Rekhter who had
come up with the original idea as I recall)  

I had in mind folding RFC 1818 into what became RFC 2026 since it was part of the standards process
(see https://datatracker.ietf.org/doc/html/draft-ietf-poised95-std-proc-3-00 for the my first draft)

as I recall, the question of what the status of the process document (RFC 2026) should have came 
up in the WG since "informational" did not sound serious enough -  I think it was Jon
who suggested that the definition of BCP should be expanded to include that type of IETF process 
document and the WG agreed

the result was that draft 2 specifically included the IETF process documents in BCPs (see https://datatracker.ietf.org/doc/html/draft-ietf-poised95-std-proc-3-02) 

Scott

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 Sep 2021 20:44:59 -0400

--On Thursday, September 23, 2021 09:06 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

> Informational to avoid any confusion with standards-track and
> related technical documents.
> 
> Actually, I'd like to add another sentence to this, to make
> sure that "Informational" isn't misunderstood (e.g. an author
> saying "well, the style guide is Informational, so it's okay
> to ingore it"), maybe close to the following:
> 
> Even though RFCs published by the Editorial Stream are labeled
> as Informational, they carry defining force in the relevant
> subject matter.

Martin,

The reason I'm trying to dance around this is that I have no
trouble imagining documents being published in the Editorial
Stream that really are informational, i.e., that definitely do
not "carry defining force" about anything.  As a particular
handy example, while I hope we can leave it to the process to
sort out rather than working out in this group (and for this
document), do we continue to treat April 1 RFCs as Independent
Stream Informational documents?  Historically they have only
been identified that way for about a dozen years and have never
been handled as "ordinary" Independent Stream documents.
Indeed, before we moved toward the stream model, they were
simply RFC Editor Informational documents.  Might the process we
are setting up want to make them the responsibility of the RSAG?
I don't know.  I wouldn't predict it.  But, again, let's not
specify things so closely that we have to reopen this document
to make a change.

   john

---

From: Jay Daley <[email-masked]>
Date: Thu, 23 Sep 2021 13:52:37 +1200

> On 23/09/2021, at 10:51 AM, John C Klensin <[email-masked]> wrote:
> 
> carry little or no authority.  

"authority" as used here means what authority external implementers perceive the RFC to have, which in turn feeds into their decision on whether or not to implement the RFC.  In the case of editorial RFCs the only implementers are internal - the tools team, RPC, Secretariat and LLC - and they don’t make a decision on whether or not to implement an editorial RFC because they are simply required to implement them by other mechanisms, which makes the "authority" debate moot.

Additionally, people should be aware that in our model so far we have not given any body the power to obsolete an editorial RFC except by introducing a new editorial RFC that specifically obsoletes it.  So, if we were to introduce "historic" then there is no  body empowered to use it.  Again, no reason for anything more than "informational".

Jay

> Historically, we have needed to

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Sep 2021 14:42:39 +1200

I've read the thread but my comment is only on Colin's original post:

On 23-Sep-21 07:48, Colin Perkins wrote:
>>> Section 6 says: "Documents pubished in the Editorial Stream shall have a status of Informational.  The Editorial Stream is not authorized to publish RFCs that are Standards Track or Best Current Practice, since such 
RFCs are reserved to the IETF Stream [RFC8729].” This does not mention Experimental RFCs. Should it? We’ve had "process experiments" in the past… 
> I’d lean towards cannot publish Experimental RFCs on the Editorial Stream, as process experiments seem to be stretching the definition of experimental, but don’t have a strong opinion. I do think w…

We only have one RFC Series, so I don't think the idea of an experiment makes any sense. Suppose somebody proposed an experimental category of RFC's called "Whizzbang" and we published an Experimental RFC describing the 
Whizzbang category. Any Whizzbangs that we published would become permanently archived RFCs with their own DOIs and until the end of civilisation, 
they'd be there, clearly labelled "Whizzbang". If we terminated the "experiment" after 2 years, and even if we concluded that the Whizzbangs should have been called Damp Squibs, they would be Whizzbangs for ever.

So, experiments on an archival series really aren't reversible. Consider that we have 30+ RFCs in the "FYI" category. (See RFC1150 and RFC6360.)

Therefore, I think there is no value in labelling an editorial stream RFC 
"Experimental". Whatever it does has permanent effects.

(This is a very different case from RFC8989, which is an experimental process document, with time-limited effects.)

   Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2021 21:01:45 -0600

On 9/22/21 8:42 PM, Brian E Carpenter wrote:
> We only have one RFC Series, so I don't think the idea of an experiment makes any sense. 

Although I don't want to belabor the point, I'm not 100% sure. Consider
documents that specify series-wide rules and guidelines (see §4.4.4 of
RFC 8729), e.g. RFC 7997 on "The Use of Non-ASCII Characters in RFCs"
mentioned there. I could imagine the RSWG defining and the RSAB
approving an experiment related to, say, a new output format or improved
processing of errata, which could be applied temporarily in a way that
does not affect archival RFCs. If the experiment concluded successfully,
its results could be applied permanently to archival RFCs.

Peter