Re: [rsab] RSAB document approval process

[Eliot Lear <[e-mail]>]

Very nicely done, Mirja.  Sounds like a good way forward. 

Eliot

On 13 Mar 2024, at 12:59, Mirja Kuehlewind (IETF) <[e-mail]> wrote:



Hi all,

Here are a couple of more details on the proposed approval process. For you reference find the steps that are concerning RSAB in the workflow as specified in RFC9280 at the bottom if this email.

Approval requested by RSWG chairs:

The process starts for us with an indication from the RSWG chairs that a draft is ready for approval (step 5 in RFC9280). I was assuming we have a button for this in the datatracker but I don’t see it yet. However, no matter what this should create a email to RSAB.

Question: do we want to have any kind of write-up from RSWG e.g. about the consensus process? I don’t have anything extensive in mind but maybe a short summary of the wg process as a note in the approval request? Also do we need an IPR check for the editorial stream?

RSAB shepherd:

When we receive such a request I propose to assign a shepherd. We can start with the RSAB chair for the first document but otherwise I propose we set a random order and then use round robin. Of course if a certain person would like to shepherd a certain document, I think we can accommodate for that as well. I propose that the assignment will be done by the secretariat aka Cindy. If someone wants to volunteer for a specific document, this person has to speak up quickly after the approval request is received, or let Cindy even know in advance.

Step-wise process:

If we agree to assign a shepherd, I would see the following step-wise process:

1. The secretariat assigns a shepherd.

2. The shepherd makes an initial review. This is mainly to check formalities, e.g. idnits, confirm authorship, double-check normative references or updates of other RFCs. If any problems are detected the shepherd will work with the authors and RSWG chairs to address them. This step is not explicitly described in RFC9280 but from the experience in the IESG I think it really makes sense to have a first check before we start any calls. If the document is ready, the shepherd will tell the secretariat to start the community call by changing the RSAB state in the datatracker to “community call requested”. The shepherd is also responsible to check if any “extra care” is needed (see Alexis mail and RFC9280 3.2.3) and additional mailing lists should be added in the community call. If the shepherd believes this is needed, he/she should reconfirm by email with RSAB and ensure the secretariat is aware by using the comment field in datatracker when changing the state.

3. The secretariat sends out all emails for the community call (see further details below) and sets the datatracker state to “in community call"

4. By default the community call ends after 2 weeks. Then the secretariat updates the datatracker state and notifies the shepherd. The shepherd will review all comments and again work with the RSWG and authors to address them. The RSWG list should be cc’ed (except for minor edits that could also be addressed during the publication process at the end). In this step the shepherd could also send the draft back to RSWG if needed and the process start again. When all comments are addressed, the shepherd starts the ballot process by setting the RSAB state to “RSAB evaluation” and notifies the RSAB (the datatracker should send a note to the RSAB and RSWG lists on state change).

5. As soon as the document is in RSAB evaluation, all RSAB members have 2 (?) weeks to enter their ballot position (see below and RFC9280 for details) in the datatracker. Any comments or CONCERN are sent to the RWSG list. 

6. After two weeks if the document is approved (no CONCERN and everybody entered a position), the shepherd can do a final review and inform the secretariat that the document is ready by setting the datatracker state to “Approved - announcement to be sent”. 

7a. If approved, the secretariat sends a email to RSWG (and eventually other lists, see below) and informants the RPC and updates the document state according (not sure which state that is?). RPC then starts the processing (publication as well as as the implementation of any actions specified in the doc).

7b. If the document has a CONCERN, the secretariat will schedule an RSAB call in roughly two weeks time based on availability. In parallel, the shepherd will work with the concern holder(s), the RSWG chair, and the authors to address the CONCERN. Emails should be cc’ed to RSWG. I guess we need a datatracker state for that?

If the concern is addressed before the call, the shepherd can set the datatracker state to “Approved- announcement to be sent” at any time and cancel the call. If the call happens, the document can either be approved with the CONCERN due to 3 YESes (see below and RFC9280) or is sent back to the RSWG and the process starts again.

Community call:

The community is describes in RFC9280 in section 3.2.3 the following way:

"The RSAB should actively seek a wide range of input. The RSAB seeks such input by, at a minimum, sending a notice to the rfc‑interest@rfc‑editor.org email discussion list or to its successor or future equivalent. RSAB members should also send a notice to the communities they directly represent (e.g., the IETF and IRTF).”

I propose to send the call (by default if no extra care is needed) to the following lists:

- rfc‑interest@rfc‑http://editor.org" rel="nofollow">editor.org (for broader RFC community)

- [e-mail] (for IETF community), note that [e-mail] is only used for last call discussion in the reply-to but we want to use rsab@ as proposed below

- https://www.irtf.org/mailman/listinfo/irtf-announce" rel="nofollow">[e-mail] (for IRTF) or maybe also [e-mail]?

- no extra list for ISE

- [e-mail] and the IAB will add this document to the next business call agenda for awareness not discussion

- and [e-mail] I guess

The reply-to will be set to [e-mail]

This is my proposed announcement text:

———

The RSAB has received a request from the RFC Series WG (RSWG) to

approve the following document as informational RFC on the editorial stream:

<name>

The RSAB solicits final comments from a wide range of communities.

Please send substantive comments to the [e-mail] mailing lists

by XXXX-XX-XX. Please retain the beginning of the Subject line to allow

automated sorting.

Abstract

  <abstract>

A URL of this Internet-Draft is:

  <url>

———

I guess we could add something like a short write-up/note from the shepherd or RSWG, however, I think it okay to have that as an optional field if needed.

Approval announcement:

The approval announcement should be send to RSWG. Not sure we want to send it anywhere else? If so, I propose [e-mail] and [e-mail], maybe also rfc‑interest@rfc‑http://editor.org" rel="nofollow">editor.org. Or do we need something new like [e-mail]?

Here is my proposed announcement text:

———

The RSAB has approved the following document as 

informational RFC on the editorial stream:

<name>

Abstract

  <abstract>

A URL of this Internet-Draft is:

  <url>

———

Again, optionally the shepherd could add a RSAB note.

That’s it! Any comments? Are people okay with this process?

Mirja

---------------------------

Steps 5-14 from RFC9280, section 3.2.2:

5. After a comment period of suitable length, the RSWG Chairs will determine whether rough consensus for the proposal exists (taking their own feedback as individuals into account along with feedback from other participants). If comments have been received and substantial changes have been made, additional Last Calls may be necessary. Once the chairs determine that consensus has been reached, they shall announce their determination on the RSWG email discussion list and forward the document to the RSAB.
6. Once consensus is established in the RSWG, the RSAB shall issue a community call for comments as further described in Section 3.2.3. If substantial comments are received in response to the community call for comments, the RSAB may return the proposal to the RSWG to consider those comments and make revisions to address the feedback received. In parallel with the community call for comments, the RSAB itself shall also consider the proposal.
7. If the scope of the revisions made in the previous step is substantial, an additional community call for comments should be issued by the RSAB, and the feedback received should be considered by the RSWG.
8. Once the RSWG Chairs confirm that concerns received during the community call(s) for comments have been addressed, they shall inform the RSAB that the document is ready for balloting by the RSAB.
9. Within a reasonable period of time, the RSAB will poll its members for their positions on the proposal. Positions may be as follows:

YES: the proposal should be approved

CONCERN: the proposal raises substantial concerns that must be addressed

RECUSE: the person holding the position has a conflict of interest

Any RSAB member holding a CONCERN position must explain their concern to the community in detail. Nevertheless, the RSWG might not be able to come to consensus on modifications that will address the RSAB member's concern.

There are three reasons why an RSAB member may file a position of CONCERN:

The RSAB member believes that the proposal represents a serious problem for one or more of the individual streams.

The RSAB member believes that the proposal would cause serious harm to the overall RFC Series, including harm to the long-term health and viability of the Series.

The RSAB member believes, based on the results of the community call(s) for comments (Section 3.2.3), that rough consensus to advance the proposal is lacking.

Because RSAB members are expected to participate in the discussions within the RSWG and to raise any concerns and issues during those discussions, most CONCERN positions should not come as a surprise to the RSWG. Notwithstanding, late CONCERN positions are always possible if issues are identified during RSAB review or the community call(s) for comments.

10. If a CONCERN exists, discussion will take place within the RSWG. Again, all RSAB members are expected to participate. If substantial changes are made in order to address CONCERN positions, an additional community call for comments might be needed.
11. A proposal without any CONCERN positions is approved.
12. If, after a suitable period of time, any CONCERN positions remain, a vote of the RSAB is taken. If at least three voting members vote YES, the proposal is approved.
13. If the proposal is not approved, it is returned to the RSWG. The RSWG can then consider making further changes.
14. If the proposal is approved, a notification is sent to the community, and the document enters the queue for publication as an RFC within the Editorial Stream.

--
RSAB mailing list
[e-mail]
https://mailman.rfc-editor.org/mailman/listinfo/rsab