Subject: [Rfced-future] Issue 35: RFC 5742 and reviews

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Sep 2021 09:38:57 +0200

Hi John,

This has to do with whether RFC 5742 requires an update and how to 
handle the new stream.

> Action required: Once we determine whether there will be a
> separate stream and how it is managed, come back to the
> question of whether there should be formal documents reviews
> by the IESG, IAB, and/or some other body or bodies.

We now do create a new stream, and we have considered and documented the 
approval process, including leaving it to stream managers to address how 
they manage their representation on the RSAB.  In my view, this only 
impacts the single new stream, and therefore does not impact RFC 5742.  
Does anyone else disagree? If not we can probably close this issue.

Eliot

---

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Sep 2021 14:55:38 +0300

Hi,

On 2021-9-6, at 10:38, Eliot Lear <[email-masked]> wrote:
> We now do create a new stream, and we have considered and documented the approval process, including leaving it to stream managers to address how they manage their representation on the RSAB.  In my view, this only impacts the single new stream, and therefore does not impact RFC 5742.  Does anyone else disagree? If not we can probably close this issue.

what types of documents does the new stream intend to publish? If it intends to publish Standards Track documents or BCPs (and I think we intend to do the latter), a 5742 review step is IMO warranted, similar to how 4844 requires this for the IAB stream.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Sep 2021 14:58:11 +0300

Hi,

> what types of documents does the new stream intend to publish? If it intends to publish Standards Track documents or BCPs (and I think we intend to do the latter), a 5742 review step is IMO warrant…

sorry, I think I had (all my) two synapses fire at the same time :-) What I meant to write was:

If it intends to publish Standards Track documents or BCPs (and I think we intend to do the latter), an approval process per Section 5.1.1 in 4844 is IMO warranted, similar to how that is required this for the IAB stream.

Thanks,
Lars

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2021 09:52:59 -0400

--On Monday, September 6, 2021 09:38 +0200 Eliot Lear
<[email-masked]> wrote:

> Hi John,
> 
> This has to do with whether RFC 5742 requires an update and
> how to handle the new stream.
> 
> We now do create a new stream, and we have considered and
> documented the approval process, including leaving it to
> stream managers to address how they manage their
> representation on the RSAB.  In my view, this only impacts
> the single new stream, and therefore does not impact RFC
> 5742.  Does anyone else disagree? If not we can probably
> close this issue.

Eliot,

Both for this specific case (for the reasons you mention) and
because of my concerns about overspecifying things, I agree.

   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2021 12:58:29 -0400

--On Monday, September 6, 2021 14:55 +0300 Lars Eggert
<[email-masked]> wrote:

> what types of documents does the new stream intend to publish?
> If it intends to publish Standards Track documents or BCPs
> (and I think we intend to do the latter), a 5742 review step
> is IMO warranted, similar to how 4844 requires this for the
> IAB stream.

Lars,

As part of my campaign to avoid overspecifying things it may be
worth remembering that the idea of IESG review of documents of
non-IETF origin goes back long before 4844.  The principle was
established sometime in the early 1990s or earlier (possibly
along with the POISED work, but I can't remember the exact
sequence) that publishing a document that caught the IESG by
surprise was a bad idea, especially if it might cause confusion
with IETF work or problems in the standards process.  The
language in 4944 derives from that principle with, as you point
out, Standards Track and BCP documents explicitly called out.

For the present situation and the new Editorial stream, as I
understand it, documents don't get published without the RSAG
having a look.  At that point, nothing prevents the IESG's
representative on that body from saying "hey, the IESG should
have a look at this" whether the reason is the that document is
proposed as a BCP or for any of a series of reasons we might be
able to imagine.   Nothing prevents the authors of such a
document from asking the IESG to take a look either.   I suggest
that if anyone involved ignored such a request, we would have a
much more serious situation on our hands than the review (or
not) or any particular document.  

So, the question for me is not "should the IESG review relevant
documents from the Editorial Stream?" but "do we need to write
more down than is there already?"  And the argument against
writing things down is, again, that it is not hard to imagine
documents that the IESG should review that are not BCPs and that
text that called out BCPs could easily be used to start a fight
about IESG of those other documents. 

And, of course, if the IESG wanted to do so, nothing would
prevent it from developing a document like RFC 5742 to describe
what it would do if asked to review a document from the
Editorial Stream.

My hope is that, for a broad range of cases like this, we can
count on existing bodies and the new ones we are creating or
redefining as part of the RFC Editor Function to Do the Right
Thing.  And I suggest that, if they don't, cures for the
problems are outside the scope of this group.

best,
   john

---

From: Scott Bradner <[email-masked]>
Date: Mon, 6 Sep 2021 13:21:59 -0400

fwiw - I was in the loop on one incident that resulted in an agreement between Jon & 
the IESG for the IESG to review IDs prior to non-IETF RFC publication

it was not part of the the POISED work

I do not recall the specific document but Jon published an RFC that overlapped some IETF
WG work & the IESG got kinda bent out of shape - I (and likely others) talked with Jon
and he agreed to let the IESG take a look before he published non-IETF documents
(other than IANA/RFC-editor produced documents) - the review agreement was not
open ended - Jon agreed to let the IESG review those documents that he felt might
overlap IETF work

the agreement is documented in RFC 2026 - see section 4.2.3

Scott

> On Sep 6, 2021, at 12:58 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Sep 2021 20:25:06 +0300

Hi,

> not) or any particular document.

I'm sorry if I didn't tease apart my two issues in the earlier emails. Let me try again.

The first issue is that at the moment, no stream other than the IETF stream can publish Standards Track documents (that includes BCPs) [1]. I'd much prefer if this new stream was not permitted to do that, either. If there is a desire for something more authoritative-sounding than "Informational" for documents on the new stream, I'd prefer defining a new document status over reusing standards track designations such as BCP.

The second issue is how IESG review of these documents is managed. At least for me, this is tied to the first issue. If the intent is for this stream to be able to publish BCPs (i.e., standards track documents), I believe a formal IESG step is required, just as we do for ISE and IRTF documents that may have impact on IETF standards work. If the intent is that the new stream cannot publish BCPs or other standards track documents, we can discuss a much more informal commenting approach, as you outlined above. (I'd probably ask for datatracker tooling support so that the reviews get managed alongside the IESGs regular document review process, just so ADs don't need to start managing two separate processes.)

Thanks,
Lars

[1] Between 2000-2005, the IAB stream published several BCPs (https://www.rfc-editor.org/search/rfc_search_detail.php?pubstatus%5B%5D=Standards+Track&std_trk=Any&pubstatus%5B%5D=Best+Current+Practice&pubstatus%5B%5D=Historic&pubstatus%5B%5D=Unknown&pub_date_type=any&stream_name=IAB). I checked a few, all of which had been balloted on by the IESG.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Sep 2021 20:46:17 +0200

Hi Lars,

> The first issue is that at the moment, no stream other than the IETF stream can publish Standards Track documents (that includes BCPs) [1]. I'd much prefer if this new stream was not permitted to d…

Let's take "standard" out of the picture.  As to BCP or Informational or 
something else, it seems to me more important that only the editorial 
stream be used to govern the RFC editor process, and that the editorial 
stream be only used to update the RFC editor process.  That is why we 
are here.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Mon, 6 Sep 2021 16:13:15 -0400

On 9/6/2021 2:46 PM, Eliot Lear wrote:
>> The first issue is that at the moment, no stream other than the IETF 
>> stream can publish Standards Track documents (that includes BCPs) 
>> [1]. I'd much prefer if this new stream was not permitted to do that, 
>> either. If there is a desire for something more 
>> authoritative-sounding than "Informational" for documents on the new 
>> stream, I'd prefer defining a new document status over reusing 
>> standards track designations such as BCP.
>
> Let's take "standard" out of the picture.  As to BCP or Informational 
> or something else, it seems to me more important that only the 
> editorial stream be used to govern the RFC editor process, and that 
> the editorial stream be only used to update the RFC editor process.  
> That is why we are here.
>
> Eliot
>
>
>

The Editorial stream will (exclusively?) definitely publish Normative 
documents that affect the process of publishing RFCs. Is there any 
reason for publishing non-normative documents?  Or for that matter 
experimental documents?

Let's create the "Editorial Practices" flavor for the Normative 
Editorial Stream equivalent of BCPs.   We can reuse the Informational 
and Experimental(maybe?) tags for non-normative editorial stream 
documents if there's ever a need for them. (e.g. RFC templates might be 
Informational vs EP, but I can't right now think of an experimental 
document that would make sense in this stream given the vast investment 
costs to actually implement them)

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Sep 2021 11:57:01 +1200

> The first issue is that at the moment, no stream other than the IETF stream can publish Standards Track documents (that includes BCPs) [1]. I'd much prefer if this new stream was not permitted to d…

Yes. If a document from the Editorial stream does in fact need to formally Update or even Obsolete an IETF-approved process BCP, that can only happen if the document is *also* taken through the IETF process. Otherwise, they're going to be Informational (or conceivably Experimental) as far as the existing meta-data options are concerned.

The present RFC Editor documents are Informational but in the IAB stream. That seems to have worked well enough. The new ones can be Informational but in the Editorial stream.

There might be some corner cases (e.g. the RSWG and RSAB want to declare an old informational RFC obsolete or Historic) but do we really to legislate for that?
 
> The second issue is how IESG review of these documents is managed. At least for me, this is tied to the first issue. If the intent is for this stream to be able to publish BCPs (i.e., standards track documents), I believe a formal IESG step is required, just as we do for ISE and IRTF documents that may have impact on IETF standards work. 

That's not even logically possible under RFC2026. The only option is full IETF process. Let's not go there.

> If the intent is that the new stream cannot publish BCPs or other standards track documents, we can discuss a much more informal commenting approach, as you outlined above. (I'd probably ask for datatracker tooling support so that the reviews get managed alongside the IESGs regular document review process, just so ADs don't need to start managing two separate processes.)

Sure, but IMHO it's a courtesy review. RFC5742 is intended to prevent end runs around the technical standards process. I think one sentence saying that the IESG is invited to comment at the same time that a draft goes before the RSAB would cover it. The tooling could indeed be borrowed from RFC5742.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 8 Sep 2021 16:24:56 +0200

Coming back to this issue,

> Sure, but IMHO it's a courtesy review. RFC5742 is intended to prevent end runs around the technical standards process. I think one sentence saying that the IESG is invited to comment at the same ti…

I would like to highlight that RFC 5742 is an IESG process document.  
It's what the IESG does.  My suggestion is fourfold:

 1. The IESG is already in a position to raise concerns about any
    document produced through this process through their delegate.
 2. They can create whatever process they wish to govern how that
    delegate engages.
 3. I don't think we need to do that for them, and if we think we do, it
    is probably something that could be pursued outside of our group
    here now.
 4. We *should* make sure that the editorial series has a crisply
    defined and well bounded remit.  Nobody here thinks that the new
    process should be used to create standards or supplant in any way
    the authority of the other streams, except as relates to the
    strategic management of the RFC series itself.  We can probably do a
    better job of saying that.

It is this latter point that I think should address most concerns.  Am I 
wrong?

Eliot

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2021 10:27:34 -0400

(combining several responses because I've been away from the
thread for a while)

First, Scott, thanks for your much better memory about the
origins of IESG review of documents that did not originate in
the IETF.  My memory is consistent with your report, I just
could not remember the timing or sequence of events.

Lars, your separating the issues is very helpful, at least to
me.  See below.

--On Tuesday, September 7, 2021 11:57 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>> have a look at this" whether the reason is the that document
>>> is proposed as a BCP or for any of a series of reasons we
>>> might be able to imagine.   Nothing prevents the authors of
>>> such a document from asking the IESG to take a look either.
>>> I suggest that if anyone involved ignored such a request, we
>>> would have a much more serious situation on our hands than
>>> the review (or not) or any particular document.
>> 
>> The first issue is that at the moment, no stream other than
>> the IETF stream can publish Standards Track documents (that
>> includes BCPs) [1]. I'd much prefer if this new stream was
>> not permitted to do that, either. If there is a desire for
>> something more authoritative-sounding than "Informational"
>> for documents on the new stream, I'd prefer defining a new
>> document status over reusing standards track designations
>> such as BCP.

Strongly agreed.  One way to do that would be to clarify that
only the IETF stream can create BCPs or (other) Standards Track
documents and leave any other categories for future work.  If we
are going to get into that space, I strongly recommend that the
IESG move to separate IETF procedural documents from BCPs that
affect the technical workings of the Internet.  Combining them
into one category has been a source of confusion in the past
and, if we are going to treat BCPs as part of, rather than an
adjunct too, the Standards Track, that is more reason to make
the separation.  Clearly (at least to me) not an RFC Editor
Function problem, but the use of BCPs to update Proposed or
Internet Standards, thereby avoiding the two-step process is
another complication there.

> Yes. If a document from the Editorial stream does in fact need
> to formally Update or even Obsolete an IETF-approved process
> BCP, that can only happen if the document is *also* taken
> through the IETF process. Otherwise, they're going to be
> Informational (or conceivably Experimental) as far as the
> existing meta-data options are concerned.

Agreed,  But that is another reason to separate process BCPs
from technical/ operational ones because we could quickly end up
with

 -- documents about "best" Internet network operational
	or technical issues.
 -- documents about IETF procedures (this might include
	editorial or similar specifications for the IETF Stream,
	IETF stream IPR policies, etc.)
 -- documents about editorial and related norms applying
	to the entire RFC Series or Function.
 -- documents, presumably informational, in which other
	streams stated their policies about, e.g., adoption of
	versions of IETF IPR procedures.
   
> The present RFC Editor documents are Informational but in the
> IAB stream. That seems to have worked well enough. The new
> ones can be Informational but in the Editorial stream.

Actually, how well it has worked is questionable.  Independent
of details of the approval process that have varied over time,
we have some extremely normative documents ("we are doing it
this way and, if you don't like it, take your <whatever>
elsewhere") as Informational in addition ro many reports and
other things that really just for information is just not
helpful to those trying to understand or utilize the categories.
Little or no confusion among insiders, but rather confusing if
one does not know what is going on,

> There might be some corner cases (e.g. the RSWG and RSAB want
> to declare an old informational RFC obsolete or Historic) but
> do we really to legislate for that?  

For the purpose of this Program and its outputs, I'd like to
"legislate" as little as possible, relying on common sense and
our ability to specify particular cases later if need be.   But,
again, separating process BCPs from technical ones and getting
per-stream normative documents out of "Informational", would
probably help a lot.

>> The second issue is how IESG review of these documents is
>> managed. At least for me, this is tied to the first issue. If
>> the intent is for this stream to be able to publish BCPs
>> (i.e., standards track documents), I believe a formal IESG
>> step is required, just as we do for ISE and IRTF documents
>> that may have impact on IETF standards work. 
> 
> That's not even logically possible under RFC2026. The only
> option is full IETF process. Let's not go there.

Concur.  I also note that the ISE and IRTF are not allowed to
publish Standards Track (or BCP) documents -- the most they can
do it to throw a document over the wall to the IETF with a
recommendation that it be considered for standardization. Also,
the ISE gets advice from the IESG about Independent Stream
Informational or Experimental documents.  THey are not required
to follow   that advice.   I think that is fine and agree with
Brian about full IETF process and about not going there.

>> If the intent is that the new stream cannot publish BCPs or
>> other standards track documents, we can discuss a much more
>> informal commenting approach, as you outlined above. (I'd
>> probably ask for datatracker tooling support so that the
>> reviews get managed alongside the IESGs regular document
>> review process, just so ADs don't need to start managing two
>> separate processes.)

> Sure, but IMHO it's a courtesy review.

That is certainly what RFCs 4844 and 4846 intended.

> RFC5742 is intended to
> prevent end runs around the technical standards process. 

RFC 5742 is the IESG's statement, presumably with IETF consensus
approval, of how the IESG intends to handle the courtesy reviews
specified in the earlier documents.  The fact that it is a BCP
while the "real" controlling documents are Informational is an
example of my reason for believing that it is time to do some
extension and redefinition of the categories.

> I think one sentence saying that the IESG is invited to comment
> at the same time that a draft goes before the RSAB would cover
> it. The tooling could indeed be borrowed from RFC5742.

I am very reluctant to add more work, especially work that will
mostly be unnecessary, on the General Area AD (if the RFC Editor
feels a need to publish documents that relate to one Area only,
I think we would have other problems).  So why not just
generalize that and say that any RSAB member can request that
any stream be invited to comment on any draft going before the
RSAB.  I can as easily imagine Editorial stream documents that
would benefit from a courtesy IAB or ISE review as ones that
would benefit from IESG review.   If the IESG has too much time
on its hands and wants to do a review of every potential
Editorial stream document, so be it, but let's not make them.
And if one of the streams abuses that process (which I consider
very unlikely) let's deal with that later rather than making
problems for ourselves.

best,
    john

---

From: Lars Eggert <[email-masked]>
Date: Wed, 8 Sep 2021 17:29:44 +0300

Hi,

On 2021-9-8, at 17:24, Eliot Lear <[email-masked]> wrote:
> 	• We should make sure that the editorial series has a crisply defined and well bounded remit.  Nobody here thinks that the new process should be used to create standards or supplant in any way the authority of the other streams, except as relates to the strategic management of the RFC series itself.  We can probably do a better job of saying that.
> It is this latter point that I think should address most concerns.  Am I wrong?

that would certainly help.

(And I agree that me mixing 5742 into this was confusing. I tried to use it as an example, but it's clearly not helping.)

I would also suggest we explicitly say that the new stream cannot publish Standards Track and BCP documents. With that, I think having an IESG appointee on the RSAB should give enough review potential.

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Wed, 8 Sep 2021 16:31:13 +0200

> I would also suggest we explicitly say that the new stream cannot publish Standards Track and BCP documents. With that, I think having an IESG appointee on the RSAB should give enough review potent…

Does anyone object to Lars' proposal?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 8 Sep 2021 10:37:06 -0400

If we say that the new stream can not publish BCPs (it clearly shouldn't 
/ can't publish Standards Track documents) how do we plan to make clear 
that the new stream documents are binding on the RPC and authors of 
RFCs?  Informational status does not send that message.  (Arguably, this 
is a problem with our subsets, and relates to the problem of BCP 
covering MANY things that John raised.  But I would like to know how we 
plan to solve it.

It seems that the simple move of putting in boilerplate creates an 
apparent conflict that can easily confuse readers.

Yours,
Joel

On 9/8/2021 10:31 AM, Eliot Lear wrote:
>> I would also suggest we explicitly say that the new stream cannot 
>> publish Standards Track and BCP documents. With that, I think having 
>> an IESG appointee on the RSAB should give enough review potential.
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2021 10:37:08 -0400

--On Monday, September 6, 2021 20:46 +0200 Eliot Lear
<[email-masked]> wrote:

>...
> Let's take "standard" out of the picture.  As to BCP or
> Informational or something else, it seems to me more important
> that only the editorial stream be used to govern the RFC
> editor process, and that the editorial stream be only used to
> update the RFC editor process.  That is why we are here.

Noting that, if "standards track" or "standard" includes BCPs,
per Lars's note or at least my understanding of it, then "as to
BCP" makes no sense.

I think I agree completely with what I think you were trying to
say, but, as the note I posted a few minutes ago tries to
indicate and Lars more or less suggested, I think we (possibly
not this Program, but the broader community) have a choice
between cleaning up those categories and their definitions
somewhat or trying to deal with many special cases and fine
distinctions. 

Thought experiment: suppose neither this Program or anyone else
does anything before the new RFC Editor process is firmly in
place.  Then the RSAG/RSWG (or whatever they are called)
conclude that badly overloading the BCP and Informational
categories is bad for the Series and its readers and generates a
draft document.  I am guessing that, if it were done carefully,
such a document --and new categories and boundaries-- would be
possible without modifying, e.g., RFC 2036.  So, how would you
think such a document would best be processed? 

best,
   john

---

From: Lars Eggert <[email-masked]>
Date: Wed, 8 Sep 2021 17:42:51 +0300

Hi,

> per Lars's note or at least my understanding of it, then "as to

I wanted to quickly point to https://tools.ietf.org/search/rfc4844#section-5.1.1 which - although Informational? - says:

   The IETF document stream includes IETF WG documents as well as
   "individual submissions" sponsored by an IESG area director.  Any
   document being published as part of the IETF standards process must
   follow this stream -- no other stream can approve Standards-Track or
   Best Current Practice (BCP) RFCs.

Thanks,
Lars

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2021 10:52:41 -0400

--On Wednesday, September 8, 2021 16:31 +0200 Eliot Lear
<[email-masked]> wrote:

>> I would also suggest we explicitly say that the new stream
>> cannot publish Standards Track and BCP documents. With that,
>> I think having an IESG appointee on the RSAB should give
>> enough review potential.
> 

Eliot,

With the understanding that today's notes from you, Lars, and
myself seem to be saying almost the same thing (which I hope is
a good sign), I object to one thing about Lars's proposal, but
the objection is only a matter of phrasing and principle.

I would much rather say "only the IETF Stream can publish
Standards Track and BCP documents".  That does not single out
the Editorial stream (whatever it is called) from others,
future-proofs us against new streams (if they did need to
publish such things, we could deal with it with a real case in
front of us), and is consistent with the status quo where the
IAB, IRTF, and ISE don't publish Standards Track or BCP
documents either.  And, as Lars suggested earlier, if we need
any of those streams to publish documents that are BCP-like,
let's call them something else.

I share Joel's concerns, but I think the solution is a new
category that only the Editorial stream can use, not specifying
what the Editorial stream cannot do.  That would, I think,
address Mike's concern as well: If the Editorial stream can
publish its own normative documents and we do not prohibit their
publishing Informational (or, in principle, Experimental) ones,
then we can move on and let the RSAG/RSWG sort o8t details as
they arise and when they have real cases in front of them.

best,
   john

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2021 10:57:12 -0400

--On Wednesday, September 8, 2021 17:42 +0300 Lars Eggert
<[email-masked]> wrote:

>> per Lars's note or at least my understanding of it, then "as
>> to BCP" makes no sense.
> 
> I wanted to quickly point to
> https://tools.ietf.org/search/rfc4844#section-5.1.1 which -
> although Informational? - says:
> 
>    The IETF document stream includes IETF WG documents as well
> as    "individual submissions" sponsored by an IESG area
> director.  Any    document being published as part of the IETF
> standards process must    follow this stream -- no other
> stream can approve Standards-Track or    Best Current Practice
> (BCP) RFCs.

Lars,

Thanks.  And, of course, unless we mess with that text in 4844,
most of the recent discussion (other than your, IMO very
usefully, opening the door to some new categories) is a no-op.
If "no other stream can approve", then we don't need to do
anything that treats the new Editorial one as special.

best,
     john

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Sep 2021 14:58:16 +0000

---

From: Lars Eggert <[email-masked]>
Date: Wed, 8 Sep 2021 18:00:41 +0300

Hi,

On 2021-9-8, at 17:52, John C Klensin <[email-masked]> wrote:
> Standards Track and BCP documents".

I'm fine with that phrasing.

Thanks,
Lars

---

From: Scott Bradner <[email-masked]>
Date: Wed, 8 Sep 2021 11:05:19 -0400

agree

Scott

> On Sep 8, 2021, at 11:00 AM, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 8 Sep 2021 17:17:26 +0200

Ok.  I have also asked how difficult it would be to create a new 
category.  The thing I would like the group to consider in doing so is 
whether they think there would be tooling issues beyond the IETF.  
Nobody has greased categories.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 8 Sep 2021 15:52:59 -0400

>Nobody has greased categories.

Administratively, the IAB need only wave their wand. 

The tooling that the RPC uses is a mix of python, php, and shell
scripts some of which are decades old. It works but it is fragile.
While it is possible to change it, as I did to add DOIs, it's a fair
amount of work and every hack makes it more fragile. 

It'd also need changes to the XML vocabulary and xml2rfc which, again, is
not all that hard, but presents stability issues since I would really like
to keep changes to the XML vocabulary to a minimum.

There is a lot of other stuff I would also like to do, e.g., getting
Google Scholar to index our RFCs, and better editing and review tools
for our XML format.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Sep 2021 16:57:23 -0400

--On Wednesday, September 8, 2021 15:52 -0400 John Levine
<[email-masked]> wrote:

>> Ok.  I have also asked how difficult it would be to create a
>> new  category.  The thing I would like the group to consider
>> in doing so is  whether they think there would be tooling
>> issues beyond the IETF.   Nobody has greased categories.
> 
> The tooling that the RPC uses is a mix of python, php, and
> shell scripts some of which are decades old. It works but it
> is fragile. While it is possible to change it, as I did to add
> DOIs, it's a fair amount of work and every hack makes it more
> fragile. 
> 
> It'd also need changes to the XML vocabulary and xml2rfc
> which, again, is not all that hard, but presents stability
> issues since I would really like to keep changes to the XML
> vocabulary to a minimum.
> 
> There is a lot of other stuff I would also like to do, e.g.,
> getting Google Scholar to index our RFCs, and better editing
> and review tools for our XML format.

The one thing I can think of that John didn't mention is that,
if one decided to make changes retroactively. For example, if
there is a special category for the Editorial stream, should RFC
7322 be grandfathered into it?  4844-4856?   tThose are probably
easy if we decided to do it.  On the other hand, identifying and
reclassifying all of the IETF procedural documents from BCP to a
new category would be a bigger deal.

And, John, some questions prompted by your description above:
With the understanding that I assume deciding would be out of
scope for this group, if the current tooling is really that
fragile, should someone be thinking about recoding/ replacing
it?  Does such a recommendation need to be made by the final
process, or is that something about which you or the RPC could
be, and should be, starting a discussion now?

bestm
   higb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Sep 2021 10:29:45 +1200

> be, and should be, starting a discussion now?

I'm not John Levine, but given some recent discussion around
draft-kuehlewind-update-tag, I think it's clear that some tool
work is needed anyway. However, let's not make our current draft
dependent on non-existing tooling for its own implementation.
(In other words, let's punt the question of new formal categories
to the RSWG and RSAB.)

I agree of course that the clear statement from RFC4844 must
be confirmed.

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Wed, 8 Sep 2021 19:04:17 -0400

> (In other words, let's punt the question of new formal categories

Which begs the question:   What tag(s) will be used for Normative 
documents (including this one) published within the Editorial Stream 
until we stop punting?  The IESG doesn't want us using BCP.  Standard is 
definitely out.  Informative is - well - non-normative.  Experimental 
probably doesn't apply?  Historical?

What tag(s) will be used/permitted for non-Normative documents?

While I understand the desire to kick the can down the road, doing it 
for this seems remarkably short sighted and a bit lazy.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Sep 2021 11:25:36 +1200

> for this seems remarkably short sighted and a bit lazy.

I'm going by John Levine's statement that the necessary tooling is
old and fragile. So whatever we might want remains aspirational.

I'm also going by the debates about draft-kuehlewind-update-tag.
Getting to "yes" in a metadata discussion is a very long-winded
process.

So I suggest that following the existing precedent (Informational
documents to define the RFC Editor process) is the most pragmatic
approach. "Must" still means "must". The nice thing about meta-data
is that it can be added later to existing documents.

Rgds
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Sep 2021 08:50:28 +0200

Brian, Mike,

You raise good points, which leads me to another one (everyone join in 
the refrain): is this a matter that needs to be addressed by us now or 
is it something that could be addressed by the new group (whatever name 
we decide)?  What are the parameters for the decision?

I think the current plan is to publish this draft as an Informational, fwiw.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Sep 2021 08:52:32 -0400

--On Thursday, September 9, 2021 08:50 +0200 Eliot Lear
<[email-masked]> wrote:

> Brian, Mike,
> 
> You raise good points, which leads me to another one (everyone
> join in the refrain): is this a matter that needs to be
> addressed by us now or is it something that could be addressed
> by the new group (whatever name we decide)?  What are the
> parameters for the decision?
> 

Eliot,

While noting John Levine's concerns, I observe that the category
of an RFC appears on that RFC and hence, unless assorted
databases, is metadata we cannot change.  If our intention is
that the Editorial stream be a separate stream, then I would
rather have this draft be the first (new) one in the new
category.  Unless the code is not merely fragile but truly
horrible, adding, or patching in, that new category name should
not be a huge deal even if doing so leaves loose ends to be
cleaned up later.  So I would suggest breaking things up as
follows:

(1) We decide on whether there is going to be a new category for
normative Editorial Stream documents and we decide what to call
it as part of defining that stream.  I don't see how we can
really define the scope of the new structure without doing that
unless we are willing to create a nasty race condition.

(2) We leave sorting out the various databases; the questions
about whether to classify Informational, or only partially
normative, documents in the new stream; what, if anything to do
with older documents that would have been in the stream had it
been defined; etc., to the new structure.  For this purpose,
"new structure" includes the RSED (or whatever we call that
role) if one is appointed soon enough and the LLC (in its
contracting role).

(3) And, whether people agree with the above or not, we had best
start making an explicit and public list of what we are leaving
unresolved and with which we are tasking the next structure as
soon as it can cope.

   Just my thoughts,
    john

(2)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2021 10:36:51 +1200

On 10-Sep-21 00:52, John C Klensin wrote:
> category.

That it should be the first one in the new *stream* is beyond
doubt in my mind. (That means that it needs to define its own
boilerplate - perhaps a new Appendix.)

It doesn't follow that it needs to be in a new *category*.
That fails at the first hurdle with current tools:
INPUT(14): Error: Invalid attribute category for element rfc, at /rfc

Perhaps John Levine can tell us whether a new stream (+ boilerplate)
is a separate tooling problem from a new category? They are usually
bound together in XML2RFC, but I suppose the RFC Editor can override
the boilerplate manually.

> Unless the code is not merely fragile but truly

That was my reason for asserting that metadata can be changed later.
But if we did want a new category shown in the RFC text itself,
of course you are correct.

> unresolved and with which we are tasking the next structure as

Yes. Maybe even as an appendix in the document itself.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Sat, 11 Sep 2021 17:09:05 +0200

Based on earlier discussion,

Here then is a proposal to address Issue 35 and 63:

> Peter would make a change to the text that states that the new series, 
> and only the new series, will only be used to specify and update the 
> strategy, policy, and procedures of the RFC series itself.  No other 
> use of the stream is authorized by this memo.  This policy may only be 
> changed by agreement of the IAB, IESG, and IETF LLC.

No updates will be made to RFC 5742 at this time.  It is left to the 
IESG to do so if they wish, and other streams to conform or not.

It has been noted that it would be quite difficult for all three of the 
above organizations to agree on something.  But the likelihood of a 
process failure seems similarly quite small.  It would require, amongst 
other things, the RSAB not functioning, and the IESG, IAB, IRTF, and ISE 
not taking appropriate action to correct the matter.  We are putting our 
faith in those people to see that this doesn't happen, but that seems 
like a low risk.

Would people like to wordsmith the above or offer replacement text?

Eliot

ps: no I don't mention Internet standards, but I prefer "permit lists" 
rather than "block lists" since it is possible for us to leave something 
out.  And we wouldn't want this series to usurp the roles of the other

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Sep 2021 11:21:09 -0400

That seems to work for me.  As far as I can tell, anything we can 
practically do has some risk of confusing people, so this is as good as 
it gets.

Yours,
Joel

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Sep 2021 16:32:39 -0400

Mike and all:

>> Let's take "standard" out of the picture.  As to BCP or Informational or something else, it seems to me more important that only the editorial stream be used to govern the RFC editor process, and that the editorial stream be only used to update the RFC editor process.  That is why we are here. 

Currently, RFC Editor documents are Informational but in the IAB stream. RFC 8700 is a great example.  This approach has worked.  I think our document should simply explain that history and say that going forward such documents will be Informational RFCs on the new Editorial stream.

It is hard to imagine an end run around the technical standards process that meets the subject matter of the Editorial Stream, but I agree with the suggestion by Brian to include a sentence saying that the IESG is invited to comment at the same time as the rest of the community.

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2021 16:35:43 -0600

Sorry, I meant to reply-all...

---------- Forwarded message ---------
From: Peter Saint-Andre <[email-masked]>
Date: Mon, Sep 13, 2021 at 2:46 PM
Subject: Re: [Rfced-future] Issue 35: RFC 5742 and reviews
To: Russ Housley <[email-masked]>

[ no hats ]

What Russ says seems sensible. What's wrong with an Informational document
in the Editorial Series?

Peter

On Sat, Sep 11, 2021 at 2:32 PM Russ Housley <[email-masked]> wrote:

> stream can publish Standards Track documents (that includes BCPs) [1]. I'd
> much prefer if this new stream was not permitted to do that, either. If
> there is a desire for something more authoritative-sounding than
> "Informational" for documents on the new stream, I'd prefer defining a new
> document status over reusing standards track designations such as BCP.
> >>
> or something else, it seems to me more important that only the editorial
> stream be only used to update the RFC editor process.  That is why we are
> here.
>
> Currently, RFC Editor documents are Informational but in the IAB stream.
> RFC 8700 is a great example.  This approach has worked.  I think our
> document should simply explain that history and say that going forward such
> documents will be Informational RFCs on the new Editorial stream.
>
> It is hard to imagine an end run around the technical standards process
> that meets the subject matter of the Editorial Stream, but I agree with the
> suggestion by Brian to include a sentence saying that the IESG is invited
> to comment at the same time as the rest of the community.
>
> Russ
>
> --