Subject: [Rfced-future] Completeness Review

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

At the interim, I was asked to go through draft-iab-rfcefdp-rfced-model-03 and make sure that it covers all of the topics in RFC 8782.  I bring my findings to the mail list for consideration.

RFC 8728 says, "The IAB maintains its responsibilities as defined in [RFC2850]."  If this document is approved, that will not be the case.  I think that a section about the IAB should appear in Appendix B.

RFC 8728 explain what a stream is, but the new document assumes this is already known to the reader.  I think this text can be added to the Introduction to close this gap:

   In this model, documents are produced and approved through multiple
   document streams.  The stream manager for each stream is responsible
   for the content of that stream.  The RFC Editor function is responsible for
   the packaging and distribution of the documents.  As such, documents
   from these streams are edited and published by the Production Center.

RFC 8728 says, "The four streams that now exist are described in [RFC8729]."  I thin the Introduction should says this, and then immediately introduce the addition of the Editorial Stream.

RFC 8728, Section 1.1 includes:

   In undertaking this evolution, the IAB considered
   changes that increase flexibility and operational support options,
   provide for the orderly succession of the RFC Editor, and ensure the
   continuity of the RFC Series, while maintaining RFC quality,
   maintaining timely processing, ensuring document accessibility,
   reducing costs, and increasing cost transparency.  The model set
   forth below describes the internal organization of the RFC Editor,
   while remaining consistent with RFC 8729.

There is nothing in the new document that lays out similar principles.

Clearly, orderly succession of the RFC Editor is quite different in the new model, but I hope that we are trying to preserve the other things listed here.

RFC 8728, Section 1.1 includes:

   Note that RFC 8729 uses the term "RFC Editor function" or "RFC
   Editor" as the collective set of responsibilities for which this memo
   provides a model for internal organization.  This memo defines the
   term "RFC Series Editor" or "Series Editor" for one of the
   organizational components.

This would be a good addition to Section 3.1 of the new document.

RFC 8728, Section 2.1.1 talks about how the RSE provides strategic leadership and management.  Some of this falls the the IETF Admin LLC, but strategic direction comes from community proposals to the RSWG. Something should be said in Appendix B.

RFC 8728, Section 2.1.2 talks about how the RSE represents the RFC Series.  Representation does not get assigned to any role.  If that is the intent, then something should be said in Appendix B.

RFC 8728, Section 2.1.3 talks about how the RSE develops the RFC Production Center.  This falls to the IETF Admin LLC, I think. I cannot find anything to confirm that opinion.  We need to add something to cover it.

RFC 8728, Section 2.1.4 talks about how the RSE supports development the RFC Series.  The RSCE offers advice on this topic, but I think, this falls to the RSWG. I cannot find anything to confirm that opinion.  We need to add something to cover it.

RFC 8728, Section 2.1.4 talks about RSE and Conflict of Interest.  This text or something like it should apply to the RSCE too.

RFC 8728, Section 4.2 says:

   The RSE is responsible for managing the RFC Editor function to
   operate within those budgets.

This is no longer the case, but I do not see anything in the RPC section that says it needs to operate within the IETF LLC-provided budget.

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 5 Oct 2021 19:40:01 -0600

Hi Russ, thanks for your review. Comments inline.

(Meta point for the chairs: should we open GitHub issues to track these?)

> RFC 8728 says, "The IAB maintains its responsibilities as defined in [RFC2850]."  If this document is approved, that will not be the case.  I think that a section about the IAB should appear in App…

Good point. Here is proposed text:

Under earlier versions of the RFC Editor Model, the IAB was
responsible for oversight of the RFC Series and acted as a body
for final conflict esolution regarding the Series. The IAB's
uthority in these matters is described in the IAB's charter
{{RFC2850}}. Under version 2 of the Model, the IAB delegated some
of its authority to the RFC Series Oversight Committee (see below).
Under version 3 of the Model, authority for policy definition
resides with the RSWG as an independent venue for work by members
of the community (with approval of policy proposals as the
responsibility of the RSAB, representing the streams and the RSCE),
whereas authority for policy implementation ultimately resides with
the IETF LLC.

> RFC 8728 says, "The four streams that now exist are described in [RFC8729]."  I thin the Introduction should says this, and then immediately introduce the addition of the Editorial Stream.

Agreed.

> Clearly, orderly succession of the RFC Editor is quite different in the new model, but I hope that we are trying to preserve the other things listed here.

This is somewhat conjectural, but here is proposed text:

In 2020, following up on meetings led by the RFC Series Editor
in 2019, the IAB formed an open program to conduct a community
discussion and consensus process for the further evolution of
the RFC Editor model. Under the auspices of this program, the
community considered changes that would increase transparency
and community input regarding the definition of policies for
the RFC Series as a whole, while at the same time ensuring the
continuity of the RFC Series, maintaining RFC quality,
maintaining timely processing, ensuring document accessibility,
and clarifying lines of authority and responsibility.

> This would be a good addition to Section 3.1 of the new document.

I think this is covered by text in the appendix describing changes to 
the RFC Editor Model (which, following a suggestion from John Klensin, 
will be rearranged and rewritten compared to -03 of the draft):

## RFC Series Editor

Implied by the changes outlined in the previous section, the
responsibilities of the RFC Series Editor (RSE) as a person or
role (contrasted with the overall "RFC Editor function") are now
split or shared amongst the RSWG, RSAB, RPC, and IETF LLC (alone
or in combination). More specifically, the responsibilities of
the RFC Series Consulting Editor (RSCE) under version 3 of the RFC
Editor Model differ in many ways from the responsibilities of the
RFC Series Editor under version 2 of the Model. In general,
references in existing documents to the RSE can be taken as
referring to the "RFC Editor function" as described herein, but
should not be taken as referring to the RSCE.

> RFC 8728, Section 2.1.1 talks about how the RSE provides strategic leadership and management.  Some of this falls the the IETF Admin LLC, but strategic direction comes from community proposals to t…

As above, here is proposed text from my working copy (this section goes 
directly before the one about the RSE):

## RFC Editor Function

Several responsibilities previously assigned to the "RFC Editor"
or, more precisely, the "RFC Editor function" are now performed
by the RSWG, RSAB, RPC, and IETF LLC (alone or in combination).
These include various aspects of strategic leadership (Section
2.1.1 of {{RFC8728}}), representation of the RFC Series (Section
2.1.2 of {{RFC8728}}), development of RFC production and
publication (Section 2.1.3 of {{RFC8728}}), development of the
RFC Series (Section 2.1.4 of {{RFC8728}}), operational oversight
(Section 3.3 of {{RFC8729}}), policy oversight (Section 3.4 of
{{RFC8729}}), the editing, processing, and publication of
documents (Section 4.2 of {{RFC8729}}), and development and
maintenance of series-wide guidelines and rules (Section 4.4 of
{{RFC8729}}). In addition, various details regarding these
responsibilities have been modified to accord with the new
framework defined in this document.

> RFC 8728, Section 2.1.2 talks about how the RSE represents the RFC Series.  Representation does not get assigned to any role.  If that is the intent, then something should be said in Appendix B.

I think we agreed to text like this:

 From time to time, individuals or organizations external to the IETF
and the broader RFC Series community may have questions about the RFC 
Series. Such inquiries should be directed to the 
[email-masked] email alias and then handled by the 
appropriate bodies (e.g., RSAB, RPC) or individuals (e.g., RSWG chairs, 
RSCE).

> RFC 8728, Section 2.1.3 talks about how the RSE develops the RFC Production Center.  This falls to the IETF Admin LLC, I think. I cannot find anything to confirm that opinion.  We need to add somet…

I'm not quite sure where this falls. Some of it might fall to the LLC, 
but I strongly suspect that some of it falls to the RPC itself (i.e., in 
the form of self-development). I'll try to craft some text.

> RFC 8728, Section 2.1.4 talks about how the RSE supports development the RFC Series.  The RSCE offers advice on this topic, but I think, this falls to the RSWG. I cannot find anything to confirm th…

By my reading, §2.1.4 defined aspects of the RSE's relationship with the 
community. But the RSWG *is* the community, so there's no longer any 
relationship to develop.

> RFC 8728, Section 2.1.4 talks about RSE and Conflict of Interest.  This text or something like it should apply to the RSCE too.

Good catch, I'll add the text from §2.1.7 (changing RSE to RSCE).

> This is no longer the case, but I do not see anything in the RPC section that says it needs to operate within the IETF LLC-provided budget.

We have several sentences on this:

All matters of budget, timetable, and impact on its performance
targets, are between the RPC and IETF LLC.

And:

The IETF LLC develops the work definition (the Statement of Work)
for the RPC and manages the vendor selection process.  The work
definition is created within the IETF LLC budget and takes into
account the needs of stream managers as well as community input.

And:

The expenses discussed in this document are not new expenses. They
have been and remain part of the IETF LLC budget.

The RFC Series portion of the IETF LLC budget shall include funding
to support the RSCE, the RFC Production Center, and the Independent
Stream.

The IETF LLC has the responsibility to approve the total RFC Editor
budget (and the authority to deny it). All relevant parties must work
within the IETF LLC budgetary process.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Oct 2021 07:48:22 +0200

With two exceptions, as discussed in my comments below, your proposed 
edits do not involve normative text, so I'd propose that they get 
handled editorially.  Comments below.

On 06.10.21 03:40, Peter Saint-Andre wrote:
>> At the interim, I was asked to go through 
>> draft-iab-rfcefdp-rfced-model-03 and make sure that it covers all of 
>> the topics in RFC 8782.  I bring my findings to the mail list for 
>> consideration.
>>
>>
>> RFC 8728 says, "The IAB maintains its responsibilities as defined in 
>> [RFC2850]."  If this document is approved, that will not be the 
>> case.  I think that a section about the IAB should appear in Appendix B.
>

^^Expand RSWG, RSAB, RSCE on first use

vvv

>> RFC 8728 explain what a stream is, but the new document assumes this 
>> is already known to the reader.  I think this text can be added to 
>> the Introduction to close this gap:
>>
>> RFC 8728 says, "The four streams that now exist are described in 
>> [RFC8729]."  I thin the Introduction should says this, and then 
>> immediately introduce the addition of the Editorial Stream.
>
> Agreed.

This requires a one line add in the introduction along the lines of

   "The four streams that now exist are described in [RFC8729]. An 
additional editorial stream is defined in this document."

>> Clearly, orderly succession of the RFC Editor is quite different in 
>> the new model, but I hope that we are trying to preserve the other 
>> things listed here.
>

ok by me.

> should not be taken as referring to the RSCE.

yes

>
>> RFC 8728, Section 2.1.1 talks about how the RSE provides strategic 
>> leadership and management.  Some of this falls the the IETF Admin 
>> LLC, but strategic direction comes from community proposals to the 
>> RSWG. Something should be said in Appendix B.
>
> As above, here is proposed text from my working copy (this section 
> goes directly before the one about the RSE):
>
> ## RFC Editor Function
>

LGTM.

>
>> RFC 8728, Section 2.1.2 talks about how the RSE represents the RFC 
>> Series.  Representation does not get assigned to any role.  If that 
>> is the intent, then something should be said in Appendix B.
>
> appropriate bodies (e.g., RSAB, RPC) or individuals (e.g., RSWG 
> chairs, RSCE).

Yes, and we specifically chose not to address outreach at this time.

>
>> RFC 8728, Section 2.1.3 talks about how the RSE develops the RFC 
>> Production Center.  This falls to the IETF Admin LLC, I think. I 
>> cannot find anything to confirm that opinion.  We need to add 
>> something to cover it.
>
> but I strongly suspect that some of it falls to the RPC itself (i.e., 
> in the form of self-development). I'll try to craft some text.

I'm not sure what "develops" means either, and I propose that the text 
in 8728 should simply be dropped (no change to the draft). This could be 
viewed as a normative decision.

>
>> RFC 8728, Section 2.1.4 talks about how the RSE supports development 
>> the RFC Series.  The RSCE offers advice on this topic, but I think, 
>> this falls to the RSWG. I cannot find anything to confirm that 
>> opinion.  We need to add something to cover it.
>
> By my reading, §2.1.4 defined aspects of the RSE's relationship with 
> the community. But the RSWG *is* the community, so there's no longer 
> any relationship to develop.

My suggestion is a slight mod to the bullet list in the introduction as 
follows:

OLD

    o  The RSWG proposes policies that govern the RFC Series as a whole,
       with input from the community, the RSAB, and the RSCE.

NEW

    o  The RSWG proposes policies that govern development and evolution 
of the RFC Series as a whole,
       with input from the community, the RSAB, and the RSCE.

Eliot

>
>> RFC 8728, Section 2.1.4 talks about RSE and Conflict of Interest.  
>> This text or something like it should apply to the RSCE too.
>
>> This is no longer the case, but I do not see anything in the RPC 
>> section that says it needs to operate within the IETF LLC-provided 
>> budget.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Oct 2021 07:55:45 -0600

>> On 10/4/21 1:03 PM, Russ Housley wrote:

<snip/>

>        with input from the community, the RSAB, and the RSCE.

Although this is likely wordsmithing, I'm not sure if all of the RFCs 
published in the Editorial Series have to do with "development" and 
"evolution" (consider, for instance, the Style Guide). But I'm fine 
either way.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Oct 2021 08:28:57 -0600

<snip/>

> the form of self-development). I'll try to craft some text.

Proposed text:

The RPC and IETF LLC should consult regularly on ways to further
develop and improve the implementation of RFC policies. This effort
must include the dimensions of document quality, timeliness of
production, and accessibility of results. It must also specifically
take into account issues raised by the IETF community through the
RSWG and by the streams themselves through the stream managers.

Peter

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Oct 2021 10:34:58 -0400

Peter:

You direction looks right to me, but I have some suggestions.

>> I'm not quite sure where this falls. Some of it might fall to the LLC, but I strongly suspect that some of it falls to the RPC itself (i.e., in the form of self-development). I'll try to craft some text.
> 
> Proposed text:
> 

s/IETF community/community/

s/and by the streams themselves through the stream managers/and by the stream managers/

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 6 Oct 2021 11:37:53 -0600

> s/and by the streams themselves through the stream managers/and by the stream managers/

That's better, yes.

Peter

---

From: Jay Daley <[email-masked]>
Date: Thu, 7 Oct 2021 08:05:53 +1300

> On 7/10/2021, at 3:28 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

I can live with this.  It would perhaps reflect the rest of the document better if the RPC were charged with this and the LLC were charged with ensuring they do it as part of its contract oversight role, but as I said this text is fine.

Jay

> 
> Peter
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

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

> I can live with this.  It would perhaps reflect the rest of the document better if the RPC were charged with this and the LLC were charged with ensuring they do it as part of its contract oversight…

Your framing is better, so I'll wordsmith it.

Peter

---

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

> On Oct 5, 2021, at 9:40 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

I think that this should be expanded to indicate that the IAB still handles appeals

Also:
s/esolution/resolution/
s/uthority/authority/

> and clarifying lines of authority and responsibility.

The first line is not a complete thought.  The rst look fine to me.

> I think this is covered by text in the appendix describing changes to the RFC Editor Model (which, following a suggestion from John Klensin, will be rearranged and rewritten compared to -03 of the draft):
> 
> ## RFC Series Editor
> 

Look good to me.

> As above, here is proposed text from my working copy (this section goes directly before the one about the RSE):
> 
> ## RFC Editor Function
> 

I think this is fine, but "accord" does not seem like the right word in the last sentence.  Maybe it should be "align".

> and the broader RFC Series community may have questions about the RFC Series. Such inquiries should be directed to the [email-masked] email alias and then handled by the appropriate bodies (e.g., RSAB, RPC) or individuals (e.g., RSWG chairs, RSCE).

Look good to me.

> I'm not quite sure where this falls. Some of it might fall to the LLC, but I strongly suspect that some of it falls to the RPC itself (i.e., in the form of self-development). I'll try to craft some…

Yes, I agree with that approach.  I'm looking forward to the text.

> By my reading, §2.1.4 defined aspects of the RSE's relationship with the community. But the RSWG *is* the community, so there's no longer any relationship to develop.

I think that is right with one possible point of clarification.  Suppose the Foo Forum wishes to publish their documents as RFCs. This might lead to a new stream.  How does the Foo Forum ask the community to consider this request?

> Good catch, I'll add the text from §2.1.7 (changing RSE to RSCE).

Thanks.

> within the IETF LLC budgetary process.

Okay.  Maybe an item in 4.3 to summarize, perhaps with pointers.

Russ