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

["Martin J. Dürst" <[e-mail]>]

Hello Joel, others,

On 2022-03-03 04: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.

That should indeed not be what's going to happen.

But there will be some exceptions, or borderline cases, and some of them 
may make sense. In particular:

- It may be a good idea if the RSWG starts out with one or a few
   "low hanging fruit" to get a feel for the process. Such "low
   hanging fruit" will tend to be tactical rather than strategic.

- For big, serious policy items, it may be difficult to get any
   consensus without also hashing out quite a few of the minor details.

- For some somewhat minor things that require coordination between the
   RPC, the streams, and the LLC, it may be easier to discuss them in
   the RSWG and write them down as an RFC even if strictly speaking,
   they are more tactical than strategic.

Regards,   Martin.


> 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.