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

[Toerless Eckert <[e-mail]>]

I am not aware of backroom dealings for non-editorial changes
during AUTH48. Examples would be useful to start having a more
educated opinion.

I do not think we should or could expect for parties currently
not involved in the AUTH48 process to start acting in the future as
additional accountable watchdogs just because we make AUTH48 communications
public. In the absense of knowing any specific examples, i can
only imagine that such an interest watchdog party might happen
if the IETF approved last draft was a very tough compromise and
a non-author party has severe concerns about abuse of AUTH48.

But in any such case i imagine that it should already be possible
to escalate such a situation after publication of the RFC and
demand for it to be taken down ("this RFC does not match functionally
the last draft and this AUTH48 change should have been IESG/WG discussed...")
If such a process is not well defined, then i think its better to do that
than to expect additional process for AUTH48. E.g.: 1 month of
"conditional publishing" of RFC in which time any such concerns
can be raised (non-editorial change from last draft during AUTH48).

That said, i am all for a real-time publically accessible
stream of AUTH48 communications. I just don't think we should
expect it to be used by our processes for anything but a)
openness and curiosity and b) reference reading for when the AUTH48
process does result in notification of IETF/WG for a required
change beyond AUTH48 purview.

Cheers
    Toerless

On Wed, Mar 02, 2022 at 04:14:48PM -0800, Christian Huitema wrote:
> On 3/2/2022 12:31 PM, Brian E Carpenter wrote:
> 
> > 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.
> 
> The request to make AUTH48  discussions public is rooted in the standard
> making requirements. RFCs coming out of the IETF streams are standard
> documents. The process must be fully transparent, if only to avoid
> appearances of last minute backroom dealing. The responsibility for ensuring
> the requiring transparency is squarely on the IESG and the IETF chair, not
> on the RSWG/RSAB or the RPC.
> 
> -- Christian Huitema
> 
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-- 
---
[e-mail]