On 10-Apr-21 09:39, Nico Williams wrote:
> 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.
Oh yes, but why wouldn't that happen before the draft goes to the
RFC Editor in the first place?
>
>>> - 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.
That would be fine, but the proposed future RFC model would
only treat that as input, not as a done deal.
>>> - 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.
That would definitely needs an update to RFC2026.
> 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.
It's much better for everybody, I think, if it was caught earlier.
But RFC8962 does not apply.
Brian
