Re: WG Review: Effective Terminology in IETF Documents (term)

["Joel M. Halpern" <[e-mail]>]

While this (terminology) could be handled on a series-wide basis, it 
does not have to be.  The IETF can adopt policies for conent of the IETF 
stream that are more restrictive than the RFC Editor.  While I think 
getting the eventual RFC Series quasi-wg to look at this is worth-while, 
I do not see why that should gate the IETF looking at the quesiton.

Yours,
Joel

On 4/6/2021 4:58 PM, Brian E Carpenter wrote:
> Nico raises a point that has been in my mind: why is this an IETF issue,
> since presumably it applies to all RFC streams?
> 
> I believe that the charter is good enough as it is, but I also believe
> that the IESG should consider not only whether there is consensus on the
> charter text, but also the basic question whether this issue should be
> handled by the IETF at all, rather than by the RFC Editor. There is a
> strong case for the latter.
> 
> Regards
>     Brian Carpenter
> 
> On 07-Apr-21 03:29, Nico Williams wrote:
>> On Tue, Apr 06, 2021 at 12:08:55AM -0400, John C Klensin wrote:
>>> [...]
>>
>> I think this is the most helpful message yet on this topic.  I'm afraid
>> that my saying so might cause others to ignore it, but I hope that's not
>> the case.
>>
>>> Despite having community consensus that the problems it intended
>>> to address were important, I watched NEWTRK leave scars that
>>> have not healed.  Others would probably disagree, but I suggest
>>> it demonstrated the willingness of the IESG to decide that its
>>> experience and perspective in IETF process matters were more
>>> valid and important than the consensus of the WG, so much so
>>> that there was no reason to try to ascertain IETF rough
>>> consensus before dismissing the WG's key results without an IETF
>>> Last Call.  I have no reason to believe the current IESG would,
>>> or even might, do that but, to the extent to which the IESG has
>>> proposed this as a WG, if it is going to be chartered as a WG,
>>> it would be very desirable to design a different mechanism for
>>> managing Last Calls and evaluating community consensus than the
>>> same IESG.    And that is probably just another argument for
>>> "not as an IETF WG".
>>
>> There is a big difference between the IESG saying "we will not go
>> forward with this work in spite of it having WG and possibly IETF
>> consensus" and the IESG saying "we must go forward with this work in
>> spite of it lacking consensus".  The former is painful but within the
>> IESG's privilege.  The latter is outside the by-laws of the
>> organization.  The IAB would be a better body for pursuing publication
>> of work that lacks IETF consensus, would it not?
>>
>>>>> Since the proposed charter for Term will effect more than
>>>>> just the  standards process (e.g. it potentially effects all
>>>>> of the current and  future RFC streams), it would appear this
>>>>> should be handled either as  an IAB activity (either
>>>>> authored, or referred to a workshop), or  deferred until the
>>>>> RFCED group completes its work and can have this  assigned as
>>>>> a work item.
>>
>> Ah, I'm hardly the first to think the IAB is a better home for this.
>>
>>> I would go a bit further.  Because responsibility for
>>> determining the appropriateness of vocabulary in the RFC Series
>>> has traditionally been the responsibility of the RFC [Series]
>>> Editor (going more or less back to the beginning of Jon Postel's
>>> administration and continuing through Heather's), launching this
>>> effort now would likely have the effect of adding an unneeded
>>> additional impediment to the RFCED group reaching consensus on
>>> its core tasks and/or setting us up for additional future work
>>> to harmonize the two.
>>
>> Yes.  I would be perfectly happy and content with the RSE questioning
>> the use of the terminology in question in I-Ds on the RFC-Editor queue.
>> I would be perfectly happy and content with the RSE disallowing the use
>> of various terminology in I-Ds on the RFC-Editor queue.
>> And I've said so before.
>>
>> One of the many reasons to prefer this approach is that it allows the
>> RSE great flexibility, which -considering how painful this process has
>> been thus far- should be highly desired as new terminology controversies
>> arise.
>>
>>>>> My first preference is to do this as an IAB Workshop report
>>>>> with no  BCP tag and with as dispassionate an analysis and
>>>>> output language as  possible.  E.g. explanatory language vs
>>>>> directive.
>>>
>>> Agreed.  There is no doubt in my mind that we have language and
>>> terminology problems, especially when those are considered
>>> broadly and cross culturally.  I think it is reasonable and
>>> appropriate that we do as much as possible to educate the
>>> community, and especially would-be I-D or RFC authors, about the
>>> issues.  That requires analysis, explanation, and guidance, not
>>> directions or rules (and especially not directions or rules on
>>> which we will not be able to agree and that will cause further
>>> divisions in the community because of the lack of agreement.  I
>>> think it is also reasonable and appropriate for people who find
>>> what they think is inappropriate language in a draft in a WG or
>>> submitted for Last Call to raise those issues, both in the hope
>>> of getting the language fixed and to facilitate education of the
>>> authors.   But, if there are any lessons from any of our recent
>>> efforts in WGs designed to specify important aspects of the
>>> standards process or from the intensity and tone of the recent
>>> discussions of terminology on the IETF list, those lessons are
>>> that there is no community consensus (even rough consensus) that
>>> this work should be done in a way that would (or might)
>>> establish specific directions for vocabulary or behavior and
>>> that, absent such consensus, the results are as likely to be
>>> destructive as helpful.
>>
>> +1
>>
>> Nico
>>
>