On Sat, Apr 10, 2021 at 08:36:59AM +1200, Brian E Carpenter wrote: > On 10-Apr-21 04:05, Nico Williams wrote: > > My proposal, fleshed out: > > > > - direct the RSE to develop terminology standards; > > We don't yet know the future of the "RSE" role, but what is certain > is that the IETF can't "direct" that person in any plausible model. Tell me more. I mean, I don't buy this assertion. I'm quite certain that the IETF could impose some requirements on publication within the IETF stream. > > - direct the RPC to enforce the RSE's terminology standards; > > Generally speaking the RPC applies the agreed style guide, so > any terminology standards or guidelines would be part of the style > guide. We don't yet know the future of how the style guide is > maintained. Right, well, maybe TERM WG needs to provide input to the style guide. That's essentially what it would be doing as proposed, only without saying so. So I don't see the problem with phrasing it in this way (style guide update) instead. > > - whenever an author or authors, as well as the responsible AD, > > disagree with editorial changes made or proposed by the RPC, they may > > override the RPC's change, > > That's always been a matter of negotiation. I don't see that changing, > but if it does, it will be an RFC Series policy matter. We don't yet know > the future of how RFC Series policy is set. See above. > > - but if the RPC feels strongly about it, they may request a WG LC on > > this issue. > > That seems very weird. The RPC as an organisation has no standing in > the IETF process. They would be applying the style guide. > > - There would be no IESG or IETF involvement in resolving any such > > disputes. > > That's self-contradictory. You just suggested a WG LC, i.e. part of the > IETF process. And of course if a draft is changed after IETF LC, > it needs agreement from at least the AD, and possibly a repeat of the > IETF LC and IESG approval. To be more precise, the IESG as a whole would get no say apart from the responsible AD, and there would be no IETF LC. We're talking about a s/X/Y/g substitution that would be recommended or required by the STYLE guide and which may not get applied. The idea with eliding IESG approval and IETF LC at this stage is that if this was controversial, it would have been caught earlier, and to avoid divisive later controversy like what we're seeing. Nico --
