Subject: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model-03

From: Russ Housley <[email-masked]>
Date: Mon, 4 Oct 2021 15:04:47 -0400

While I was doing the completeness review, I found a few other things that deserves consideration.  These are essentially the things that would come up in a Gen-ART Review,

Section 1 says:

   The processes and organizational models for publication of RFCs have
   changed significantly over the years.  Most recently, in 2009
   [RFC5620] defined the RFC Editor Model (Version 1) and in 2012
   [RFC6635] defined the RFC Editor Model (Version 2), since modified
   slightly in 2020 by [RFC8728].

   This document reflects experience gained with version 1 and version 2
   of the Model, and therefore describes version 3 of the Model (see
   Section 7 for a summary of the changes) while remaining consistent
   with [RFC8729].

I think that bullets would present the history a bit more cleanly, perhaps with a final bullet representing this document.

Also, Section 7 does not list the changes.  They are listed in Appendix B.

Also, this raises a question about the title of this document.  This text says that this document is Version 3 of the RFC Editor Model.  Given the titles of [RFC5620] and [RFC6635], why is this not RFC Editor Model (Version 3)?

Section 1 says:

   This document obsoletes RFC 8728.

I think this paragraph should also talk about the updates to RFC 7841 and RFC 8729.

Section 2 says:

   Discussion within the RFCED-Future Program has led in the direction
   of a more consensus-oriented framework (similar in some respects to
   the structure of technical work within the IETF or IRTF) that retains
   roles for specialized expertise in document editing and publication.

I suggest that we drop this paragraph.  Without a lot more context about the RFCED-Future Program, this will not mean anything in a few years.

Section 3.2.3 says that the community call for comment must include:

   o  A URL for the proposal document

Does it have to be an Internet-Draft?  I hope so.  The RPC does not really have a process for other things, like a Google Doc.

Section 3.2.5 says:

   See also [RFC7154], [RFC7776], and [RFC8716].

Since this is a section about expected behavior of RSWG participants, it is not clear what "see also" is imposing on the participants.

EDITORIAL NITS

General: The document uses "RFC Series" and "RFC series".  I think we should capitalize "Series" throughout.

Section 3.1.2:

   The RSAB shall annually choose a chair from among its members using a
   method to be determined by the RSAB.

Cleaner to say:

   The RSAB shall annually choose a chair from among its members using a
   method of its own choosing.

Section 3.2.1:

   If (following procedures for rough consensus) the chairs ...

Is that really parenthetical?

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Oct 2021 14:57:30 +1300

Russ,

We owe you for the effort of producing this review and your preceding message. I'm not sure when we'll meet again, but you deserve a beer or two.

Thanks
   Brian Carpenter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Oct 2021 17:10:02 -0600

Hi Russ, thanks for the extra feedback. In what follows I've elided 
straightforward editorial issues (or things I'd already noticed and 
fixed in my working copy) so that we can focus on topics that might need 
discussion on list.

> Also, this raises a question about the title of this document.  This text says that this document is Version 3 of the RFC Editor Model.  Given the titles of [RFC5620] and [RFC6635], why is this not…

At the time I changed the title, we were discussing on list various 
kinds of confusion about what "RFC Editor" means. But I tend to agree 
that for the sake of continuity it's probably best to change it back.

> I suggest that we drop this paragraph.  Without a lot more context about the RFCED-Future Program, this will not mean anything in a few years.

I suggest instead to retain a modified version of this text:

By contrast, Version 3 of the RFC Editor Model, specified here,
provides a more consensus-oriented framework (similar in some
respects to the structure of technical work within the IETF or
IRTF) that retains roles for specialized expertise in document
editing and publication.

> Does it have to be an Internet-Draft?  I hope so.  The RPC does not really have a process for other things, like a Google Doc.

I'll change that to:

* A URL to the Internet-Draft that defines the proposal

(In §3.2.2 we say that proposals need to be Internet-Drafts.)

> Since this is a section about expected behavior of RSWG participants, it is not clear what "see also" is imposing on the participants.

I see your point. Although those references could be informative for 
readers, I'm not confident that the specific procedures for enforcing 
the IETF anti-harrassment policy (e.g., the Ombudsteam) could or should 
also apply to the RSWG/RSAB. Can someone enlighten us in this regard?

Peter

---

From: Colin Perkins <[email-masked]>
Date: Thu, 7 Oct 2021 12:53:58 +0100

> On 7 Oct 2021, at 00:10, Peter Saint-Andre <[email-masked]> wrote:
> 
> Hi Russ, thanks for the extra feedback. In what follows I've elided straightforward editorial issues (or things I'd already noticed and fixed in my working copy) so that we can focus on topics that might need discussion on list.
> 
...
> I see your point. Although those references could be informative for readers, I'm not confident that the specific procedures for enforcing the IETF anti-harrassment policy (e.g., the Ombudsteam) could or should also apply to the RSWG/RSAB. Can someone enlighten us in this regard?

If the ombudsteam are willing, it probably makes it easier for everyone if the new group uses the same anti-harassment policy and reporting procedures as the IETF. The IETF policy is good enough, and there’s enough overlap in participation that having a different policy will only lead to confusion.

The IRTF follows the IETF policy in this regard, for similar reasons.

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Oct 2021 14:14:13 +0200

Hi

> The IRTF follows the IETF policy in this regard, for similar reasons.
The references are simply about the definition of the term and how to 
report.  To me they are appropriate.  If Russ prefers, we could expand 
"see also" to "for further information about these policies, see...".  
The obligations are written pretty clearly in the draft.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 7 Oct 2021 07:20:10 -0600

> On Oct 7, 2021, at 6:14 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi
> 
> The references are simply about the definition of the term and how to report.  To me they are appropriate.  If Russ prefers, we could expand "see also" to "for further information about these policies, see...". 

WFM

Peter

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Oct 2021 14:34:40 -0400

> On Oct 7, 2021, at 9:20 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

WFM too.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Oct 2021 14:36:36 -0400

Peter:

> At the time I changed the title, we were discussing on list various kinds of confusion about what "RFC Editor" means. But I tend to agree that for the sake of continuity it's probably best to change it back.

That will be an improvement in my mind.

> IRTF) that retains roles for specialized expertise in document

That is much better.  Thanks.

> (In §3.2.2 we say that proposals need to be Internet-Drafts.)

That is much more clear to me.

> I see your point. Although those references could be informative for readers, I'm not confident that the specific procedures for enforcing the IETF anti-harrassment policy (e.g., the Ombudsteam) co…

This one was already resolved.

Russ