Re: [Rfced-future] Comments on draft-iab-rfcefdp-rfced-model-12

[Peter Saint-Andre <[e-mail]>]

On 3/10/22 12:12 AM, Benjamin Kaduk wrote:
> Hi Eliot,
> 
> On Thu, Mar 10, 2022 at 07:56:18AM +0100, Eliot Lear wrote:
>> Hi Ben,
>>
>> On 10.03.22 07:00, Benjamin Kaduk wrote:
>>>
>>> Edge Cases
>>> ----------
>>>
>>> Section 3.1.2.2
>>>
>>>      If and when a new stream is created, the document that creates the
>>>      stream shall specify if a voting member representing that stream
>>>      shall also be added to the RSAB, along with any rules and processes
>>>      related to that representative (e.g., whether the representative is a
>>>      member of the body responsible for the stream or an appointed
>>>      delegate thereof).
>>>
>>> This document itself is creating a new stream.  Shouldn't we provide this
>>> information for the Editorial stream, just to avoid any ambiguity?
>>> In particular, is the RSCE supposed to represent the Editorial stream on
>>> the RSAB or play an independent role?
>>
>> The working group did discuss this and we had earlier versions that said
>> exactly that the RSCE represents the Editorial Stream, but we removed
>> that for other structural reasons involving the role and purpose of the
>> RSCE.
> 
> Okay, I'm happy to hear it was considered.
> I strongly suggest documenting the decision by clearly stating that the
> Editorial stream does not have a voting member representing it on the RSAB.

Good point.

I suggest adding the following sentence to Section 3.1.2.2:

"The RFC Series Consulting Editor (RSCE) is a voting member of the
RSAB but does not act as a representative of the Editorial Stream."

>>> Section 4.4
>>>
>>>      *  The disagreement might raise a new issue that is not covered by an
>>>         existing policy or that cannot be resolved through consultation
>>>         between the RPC and other relevant individuals and bodies, as
>>>         described above.  In this case, the RSAB is responsible for (a)
>>>         resolving the disagreement in a timely manner if necessary so that
>>>         the relevant stream document(s) can be published before a new
>>>         policy is defined and (b) bringing the issue to the RSWG so that a
>>>         new policy can be defined.
>>>
>>> I don't have to squint very hard for this to look like the RSAB setting
>>> policy, even though per §3.1.2.1 the RSAB "shall have no independent
>>> authority to formulate policy on its own".

I'm curious why you think so - the text seems clear to me that this is 
not a new policy but a one-off, temporary workaround to get the relevant 
IETF/IAB/IRTF/ISE RFC published before a new policy is defined in the RSWG.

>> There is formulating and interpreting; the former is proscribed, and the
>> latter is circumscribed to operational necessity. Consider this: the
>> RSWG operates by rough consensus.  If that consensus is not forthcoming,
>> without such a means to resolve ambiguities, drafts would sit and rot.
>> That is not fair to those who put the time in to write those documents.
>> Again, this was discussed at some length.
>>
>>
>>>
>>> Section 8
>>>
>>>      Updates, amendments, and refinements to this document can be produced
>>>      using the process documented herein, but shall be operative only
>>>      after (a) obtaining the agreement of the IAB and the IESG, and (b)
>>>      ensuring that the IETF LLC has no objections regarding its ability to
>>>      implement any proposed changes.
>>>
>>> This sounds like we can end up in a situation where a new RFC updating
>>> this one has been published but is not operative, which seems really bad.
>>> Can we make the gating function apply at a different point in time, i.e.,
>>> before publishing an RFC that is not implementable?
>>
>> I think the best way to address this is to simply say- "... shall be
>> operative *and published* only after..."
> 
> I might swap the order, for "published and operative", but that sounds good
> in principle.

WFM.

>>> Section 11

See elsewhere in this thread.

>>> Everything Else
>>> ---------------
>>>
>>> Section 3.1.1.4
>>>
>>>      Absent specific guidance in this document regarding the operation of
>>>      the RSWG, the general guidance provided in Section 6 of [RFC2418]
>>>      should be considered appropriate.
>>>
>>> (I feel like I saw some previous mention of this go by, but couldn't find
>>> it quickly just now.)  The generic 2418 procedures include a role for
>>> "Area Director", which presumably doesn't have a real analogue for the
>>> RSWG.  It seems okay to just accept that and not do anything, but I wanted
>>> to make sure it got noted before publication.
>>
>>
>> Yes, we went a few rounds on that point.

We trust that RSWG chairs and participants will use their common sense 
in such matters.

>>> Section 3.1.2.1
>>>
>>>      on its own.  It is expected that the RSAB will respect the rough
>>>      consensus of the RSWG wherever possible, without ceding its
>>>      responsibility to provide appropriate review of RSWG proposals.
>>>
>>> This "appropriate review" can only result in kicking proposals back to
>>> the RSWG, right?  Since the term "appropriate" is really vague and
>>> subjective, is there further guidance that could be given?  Perhaps just
>>> noting that it's limited to the set of things that are allowed for a
>>> CONCERN?
>>
>> The review criteria are explicitly laid out in Step 9 in Section 3.2.2:
> 
> It looks like we might be able to forward-reference 3.2.2, then (e.g.,
> "appropriate review of RSWG proposals, as described in Section 3.2.2").

Right. I suggest:

OLD

  appropriate review of RSWG proposals

NEW

  appropriate review of RSWG proposals as further described under 
{{workflow}}.

>>> Section 3.2.3
>>>
>>>      The RSAB is responsible for considering comments received during a
>>>      community call for comments.  [...]
>>>
>>> I thought that up in items 6-8 of §3.2.2, we said that there would be some
>>> RSWG/RSWG chair involvement in considering comments.  I guess the
>>> responsibility would still ultimately lie with the RSAB, per this?
>>
>> I think you are mostly referring to Step 8 here, which takes place when
>> the RSAB feels that substantial comments have been received by the
>> community.  This offers the RSWG the opportunity to make what changes
>> they desire to make in response to review. This is a little different
>> than how IETF last call works, because these are policy documents and
>> the document truly has to belong to the RSWG.

To clarify even further, there are two stages here: RSWG review and 
community call for comments. The RSWG chairs manage the first of these, 
the RSAB manages the second.

Peter