Subject: [Rfced-future] Comments on draft-saintandre-rfced-model

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Apr 2021 16:43:06 +0100

Hi all,

I have a number of relatively painless comments on the current (i.e.,
-00) version of draft-saintandre-rfced-model.

Feel free to open issues or handle these comments in any way you think
appropriate.

Best,
Adrian

===

Abstract

I think that the Abstract is too minimalist. The single sentence is a
fine thing to say, but the Abstract should contain some text similar to
that in 8728.

The Abstract should also include a statement of obsoleting 8728. So,
something like...

   Documents in the Request for Comments (RFC) series are published on
   behalf of the IETF, the IAB, the IRTF, and the Independent 
   Submissions Editor.  In order to provide a sustainable basis for 
   continued publication of the RFC series, this document describes
   Version 3 of the RFC Editor model, which divides the responsibilities
   for the RFC series among four primary functions: the IETF 
   Administration LLC (IETF LLC), the RFC Series Working Group (RSWG),
   the RFC Series Approval Board (RSAB), and the RFC Publication Center
   (RPC).

   This document reflects the experience gained with versions 1
   and 2 of the RFC Editor Model documented in RFC 5620 and RFC 8728,
   and obsoletes RFC 8728.

---

Introduction

I feel that the Introduction is a bit thin. While we probably don't need
a whole lot of text, some background about the series and the rfc editor
function is probably helpful. We can lean a lot on RFC 8729. We should 
also describe the manner of obsoleting RFC 8728 (i.e., the changes).

Something like... 

   Documents in the Request for Comments (RFC) series have been
   continually published since 1969 [RFC8700].  The RFC series is
   described in [RFC8729].  RFC 8729 uses the term  "RFC Editor
   function" or "RFC Editor" to identify the collective set of
   responsibilities for publishing documents in the RFC series.

   The processes and organizational models for publication of these
   documents 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].

   In order to provide a sustainable basis for continued publication of
   the RFC series, this document describes Version 3 of the RFC Editor
   model, which divides the responsibilities for the RFC series among
   four primary functions: the IETF Administration LLC (IETF LLC), the
   RFC Series Working Group (RSWG), the RFC Series Approval Board
   (RSAB), and the RFC Publication Center (RPC).  This revised model
   remains consistent with RFC 8729.

   This document obsoletes RFC 8728 by making a full update to the RFC
   Editor model, changing the responsibilities of existing bodies and
   functions, and introducing new functions.  Specific changes from the
   version 2 RFC Editor Model are presented in Section 7.
   
---

There are two cases of 2119 "MUST" in the document. I don't understand 
why those cases are specifically called out for special treatment when
other "must" and "should" remain in lower case. I would suggest moving 
everything to lower case and removing Section 2.

---

Section 3 has

   The IETF LLC shall also provide a structure for defining policies
   regarding the RFC series.  This document specifies such a structure
   through a new RFC Series Working Group (RSWG), which shall submit its
   policy proposals to a new RFC Series Approval Board (RSAB).

Well, either this document defines the structure (which is subject to
community consensus) or the LLC defines the structure. Maybe,

   The IETF LLC shall also facilitate and support a structure, specified
   in this document, for defining policies regarding the RFC series.  
   That structure is based on a new RFC Series Working Group (RSWG), 
   which shall submit its policy proposals to a new RFC Series Approval
   Board (RSAB).

---

Section 4

   Continuing publication of RFCs shall be handled by the RFC Production
   Center (RPC) function in accordance with current policies in force or
   future policies defined as specified in the next section of this
   document.

I stumbled over "policies defied as specified...". I think you mean 
"policies defined following the process specified...".

---

Section 4

   Community members who have concerns about the performance of the RPC
   can request that the IETF LLC look into the matter.  If the IETF LLC
   opts to delegate the oversight function, concerns can be raised with
   the IETF LLC.

I'm unclear whether this is intended to be a duplication of concern to 
be raised with the LLC, or to be raised with the delegated body. So it 
should be either:

   Community members who have concerns about the performance of the RPC
   can request that the IETF LLC look into the matter.  Even if the IETF
   LLC opts to delegate the oversight function, concerns should be
   raised with the IETF LLC.

or:

   Community members who have concerns about the performance of the RPC
   can request that the IETF LLC look into the matter.  If the IETF LLC
   opts to delegate the oversight function, concerns should be raised 
   with the delegee, but can also be raised with the IETF LLC.

---

5.1.1

   subject to intellectual property policies
   which must be consistent with those of the IETF [RFC8179]

Perhaps this should reference by BCP number (BCP79). Additionally, 
shouldn't we also mention BCP78 at the same time.

---

5.1.1

   The IETF Chair and the Independent Submissions Editor shall each
   appoint and oversee a co-chair of the RSWG.

I am OK with this very open process, but I wanted to check that the
group is content to leave it entirely up to each of those two people how
they make the appointment. Additional constraints might include:
- nominations period
- open feedback period
- length of term
- number of terms

This text might usefully include a reference to 8730.

---

5.1.1

   Members of the
   RSAB are also expected to participate actively in the RSWG so that
   they are fully aware of proposals early in the policy definition
   process.

I believe it was stronger than this. In particular, the discussion 
seemed to imply that the intention was that all issues that the RSAB
members might have would be raised during normal RSWG discussions and
not be "late surprises" in the RSAB review period. Thus...

   Members of the
   RSAB are expected to participate actively in the RSWG so that they 
   are fully aware of proposals early in the policy definition process
   and so that any issues or concerns that they have will be raised 
   during the development of the proposals and will not be left until
   the RSAB review period as described in Section 5.2.1.

---

5.1.2

   o  The RFC Series Editor/Advisor

I suggest a forward pointer to Section 6.

---

5.1.2

s/THE RSAB/The RSAB/

---

5.1.2

I would like to raise the issue of whether the designated voting members
may appoint delegates. For example (and not to imply anything about
anyone) the IETF chair might be considered to already be very busy with
enough tasks to occupy their time: they might prefer to be able to
appoint a delegate to fill this position for them.

(It is possible that this is contained int he existing OPEN ISSUE, but I
don't read it that way.)

---

5.2.2

s/A individual/An individual/

---

5.2.2

This all looks good, but I wonder whether the WG chairs should be 
additionally charged to advertise proposals that have been adopted to
specific communities where appropriate. This is suitable vague that it
doesn't place a heavy burden, but it does point up the responsibility to
cover odd cases. For example (fatuous example: please don't discuss!),
if there was a proposal to stop publishing RFCs that presented security
profiles preferred by specific governments, one might hope to involve 
the people who have previously authored such documents.

---

5.2.3

   The ISOC Board of Trustees MAY decide only whether a
   process failure occurred, and what if any corrective action should
   take place.

Notwithstanding my previous comment about 2119. This isn't a "MAY". It
could be shaped as "MUST only." Or simply "may".

---

Given that this document obsoletes RFC 8728, we need to be careful 
that we aren't discarding anything we really want to keep.

Seems to me that there is a fair amount of material about the RPC,
budget, IANA, and security that we want to retain.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Apr 2021 08:44:16 +0200

Opened as one issue (42) for now.  We can split out things people don’t agree on as we go on.

> On 21 Apr 2021, at 17:43, Adrian Farrel <[email-masked]> wrote:
> 
> Hi all,
> 
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Apr 2021 09:19:59 +0100

Ooooh, I get 42. I win!

Adrian