Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)

[Brian E Carpenter <[e-mail]>]

Joel's concern is reasonable but I think the boundary between policy and
operations will always be hard to fix precisely.

That said, I slightly disagree with Lars. It's *exactly* because the
policy requirements might differ between streams that the RSWG/RSAB
structure is the right place to discuss this. To be specific, the
lack of public debate about non-editorial changes at AUTH48 is of
real concern in the IETF standards process, but might be considered
a non-issue for the Independent Stream. And the desired settings might
be different for the other three streams (including the new Editorial
stream). That - public debate during AUTH48 - would be a policy issue.
The details of which mailing lists and/or version management systems
are used is operational.

    Brian

On 03-Mar-22 08:33, Joel M. Halpern wrote:
> I have rather the opposite concern about this conversation.  We seem to
> be moving in a direction where the RSWG is responsible for managing all
> aspects of the RPC operation.  Tactical as well as strategic.  That does
> not match what I thought we agreed.
> 
> Yours,
> Joel
> 
> On 3/2/2022 2:22 PM, Michael Richardson wrote:
>>
>> Lars Eggert <[e-mail]> wrote:
>>       > I thought about this a bit, and it's not immediately obvious to me that
>>       > procedures for AUTH48 handling are under the purview of the RSWG.
>>
>> I don't mind if AUTH48 options are under the purview of the RSWG.
>> That might require that we ask the RSWG to amend itself, and I'm okay with that.
>>
>>       > could see an argument being made that they are under the purview of the
>>       > individual streams. There are already minor differences between the
>>       > streams, for example, the IRSG is in the loop for AUTH48 exchanges or
>>       > the IRTF stream, but the IESG is not for the IETF stream.
>>
>> It seems that there are a few boolean options that different streams might
>> want to turn on off, and at the least, we should say what they are.
>> In the end, it might be that things are the way they are because the
>> different stream managers were ignorant of the options.
>>
>>       > It's true that so far, all streams have used - more or less, see above
>>       > - the same process for handling AUTH48 processing. If that is intended
>>       > to be one of the invariants of the RFC series, I agree that any changes
>>       > would be under the purview of the RSWG, and any changes would then also
>>       > apply to all streams.
>>
>> I would prefer that AUTH48 process didn't varry much, or at all.
>>
>>       > But I could also see a future where one stream would want to revise how
>>       > AUTH48 should be handled for their documents. If this is something we
>>       > would like to allow - and personally (with no hats) I think that could
>>       > be attractive - then I don't see how this could be under the purview of
>>       > the RSWG, given that they are setting policies for the series (but not
>>       > the individual streams).
>>
>> I guess the only reason I think that we should allow variances is so that
>> smaller groups can try something new, innovate, and then report their
>> results.   It otherwise seems like change for change's sake to me.
>>
>>
>>
>>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>              Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>>
>> _______________________________________________
>> rfc-interest mailing list
>> [e-mail]
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>