Re: [Rfced-future] Comments on -07

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

Hi Mike, apologies for the delayed reply.

On 12/22/21 1:56 PM, Michael StJohns wrote:
> As I noted before, this is in pretty good shape excluding the RPC RSAB 
> membership stuff and maybe a few more things.
> 
> S 3.2.4 - "Appeals of RSWG decisions..." - The RSWG doesn't make 
> decisions, it comes to consensus and that consensus is judged by the 
> RSWG chairs.  So instead "Appeals of any decisions of the RSWG chairs, 
> including declining to decide an open issue in their purview after a 
> suitable period shall be made to the RSAB." Similarly in the next 
> sentence.  "Decisions of the RSWG chairs..." and later "... notice 
> having been given to the RSWG [mailing list | chairs]?" - I think this 
> is editorial.

Agreed, your text is clearer.

> S 4.3, bullet 8 - noted elsewhere, still haven't had an issue opened.  
> Question is whether this bullet is an "RPC MAY participate in the RSWG 
> as it needs to" or "RPC MUST participate".   Since the bullets open with
> 
>     More specifically, the RPC's responsibilities at the time of writing
>     include the following:
> 
>       it currently reads as a "MUST", and I'm not sure they are
>     resourced for it, nor whether this makes the most sense for their
>     current skillsets and staffing.   I'd be happy with clarifying this
>     is an optional (MAY) interaction, especially since we appear to have
>     settled on the RPC being a non-voting ex officio member of the
>     RSAB.  So text:
> 
>         8. The RPC may, as it determines necessary, participate within
>         the RSWG in the creation of new Editorial Stream RFCs,
>         especially those that might impact the RPC.

As to resourcing, I'd like to hear what Jay thinks but he is on vacation 
right now.

More generally, I don't see how we can expect good results if we don't 
ask for any input from the implementers (i.e., the RPC) until late in 
the process (via the RSAB). So it seems to me they need to participate 
to some extent in RSWG discussions.

>     I explicitly left out "advisory" here - I think the RSWG open group
>     model really should avoid restricting people to an advisory role. 

I think we (I?) meant that RPC should provide input about whether 
proposed policy changes can be implemented. Perhaps we should say 
exactly that:

    8.   Participating within the RSWG in the creation of new Editorial
         Stream RFCs that impact the RPC, specifically with respect to
         any challenges the RPS might forsee with regard to
         implementation of proposed policies.

>     That's left to the following proposed language:
> 
>         8.1 The RPC may participate in the RSAB as a non-voting
>         ex-officio member primarily as an advisor on RPC capabilities,
>         schedules, staffing and resources.

As mentioned, I think that's too late in the process. Now, if RPC folks 
want to raise concerns with the RSAB and ask RSAB members to bring those 
concerns to the RSWG list, I wouldn't have deep objections.

> S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of 
> the RSAB?  Shouldn't that be where this interaction mostly happens?  
> "Stream approving bodies" is different than "stream manager" and not 
> having a single POC might be problematic.  (Sorry - I see this change 
> was made -05 to -06, but there are a number of places in this document 
> where telling the RPC to talk to an organization is just a bad idea - 
> this comes under the heading of unintended consequences).

RFC 8729 says "there is a different approving body for each stream".

Our draft talks about stream representatives, who are the particular 
individuals serving on the RSAB for each stream.

I'm not overly worried about the difference, because there are instances 
where RPC folks might need to discuss matters with the bodies rather 
than the stream reps / RSAB members (e.g., there's an RPC liaison to the 
IESG) or with people who are active in that particular stream (e.g., WG 
chairs or document shepherds). Indeed, stipulating that RPC folks can 
talk only with the stream rep / RSAB member could be an unnecessary 
constraint: they should be able to talk with anyone who can help solve 
the problem at hand.

> S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing 
> some costs here, but claiming there are no new expenses is more probably 
> wrong that right. - nit.

ACK.

> S 5.3 - Reading this - is it possible for a temporary RSCE to be 
> appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his 
> short term as RSE?).  If a volunteer steps in temporarily, does that 
> change who gets to do the approvals?  Happy if the answer to "unpaid 
> volunteer" is no, but if yes, not sure why the LLC would need to sign off.

I'm skipping this one for purposes of this message, see elsewhere in 
this thread.

> S 6 - 2nd para - "The Editorial Stream will be used...." to "The 
> Editorial Stream shall be used..." - nit.

ACK.

> S 6.1 "These procedures need to also allow authors to indicate either no 
> rights to make derivative works, or preferentially, the right to make 
> unlimited derivative works from the documents." is probably to 
> specific.   I looked at this one and I think I see a land mine. We're 
> trying to specify legal language here and if not careful could conflict 
> with the language of 5378.  Instead:
> 
>     These procedures need to allow authors to indicate rights requests
>     consistent with BCP78 (currently RFC5378) or it successor.   The
>     publication of a successor document to RFC5378 and designation as
>     BCP 78 shall be effective on the Editorial Stream process as of the
>     BCP's publication date.
> 
> Or get a lawyer to craft this.

This text was copied verbatim (mutatis mutandis) from RFC 5744. If 
things have changed then, I suggest we ask Jay to look into it with counsel.

> S 7 - I'm mostly happy with the list, but I'm still unhappy there is no 
> language that the RSAB can use these items as part of their 
> determination as "harm to the system".  I'm afraid that the RSWG will 
> mostly ignore these as there really is no penalty for doing so, and the 
> RSAB won't have a leg to stand on to push back.  I'll shut up now.

We do say:

    3.  The RSWG shall then further discuss and develop the proposal.
        All participants, but especially RSAB members, should pay special
        attention to any aspects of the proposal that have the potential
        to significantly modify policies of long standing or historical
        characteristics of the Series as described under Section 7.

and

    In cases where a proposal has the potential to significantly modify
    policies of long standing or historical characteristics of the Series
    as described under Section 7, the RSAB should take extra care to
    reach out to even broader communities that make use of RFCs, such as
    scholarly researchers, procurement managers, and standards
    development organizations.

Do we need to say more?

> Good work to Peter dealing with all of this.

Thanks, Mike.

Peter