[RSAB: please scroll down] Paul,
As shepherd, you get to do what you want, but I fundamentally disagree that this "needs" to be brought to the RSAB. It is a last-minute policy change that could have been considered by the RSWG, but was not. It puts restrictions on the RSWG that have not ever been shown to be needed, and it confuses Editorial stream processing with IETF stream processing. As you can tell, I (as an individual in the RSWG) don't like it.
You're right; it wasn't considered by the RSWG. And that actually is the point: the development of these documents occurred in parallel and independently, and they have a relationship that (IMHO) hasn't been considered. We did discuss the relationship of what became RFC 9280 and RFC 2418 in terms of how the RSWG should be managed, leading to the text that is there; so the streams are already a bit mingled in this regard. Now that text has changed under foot with the impending approval of the modpod doc.
Having said that, if you as shepherd take it to the RSAB, and they think that we should stop processing the draft until it is resolved in the RSWG, I'll dutifully follow along (and list my misgivings about the proposed change on the RSWG). Until then, I will continue to process the AUTH48 stuff knowing that there might later be this change.
For efficiency's sake, since you've already brought the matter to the RSAB, let's just ask the questions here. To be clear, the text in the draft in question is the following:
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
And more generally:
The RSWG shall operate by rough consensus, a mode of operation
informally described in [RFC2418].
But draft-ietf-modpod-group-processes states the following:
* Updates Section 6.1 of [RFC2418], because the moderator team will
now work together with working group chairs to moderate disruptive
behavior.
This leaves a possible process hole in terms of potentially disruptive behavior. There is two questions for the RSAB:
* Does this issue warrant holding draft-editorial-rswg-rfc9280-updates for the RSWG to consider the issue? (Y/N/IDK) * In case of "I don't know", would you like to discuss the issue? One possibility is that we leave this for a short follow-up draft. Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
