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

[John C Klensin <[e-mail]>]

--On Monday, April 5, 2021 19:31 -0400 Michael StJohns
<[e-mail]> wrote:

> On 4/5/2021 7:11 PM, Michael StJohns wrote:
 
>...
>> Given the general language of RFC 2418, my best take is that
>> _*it's  inappropriate for the IETF to charter a working group
>> on this  topic*_.   It's not a technical topic, and it does
>> not fit the general  WG model.
>...
>  Joel H reminded me of Poised, Poisson
> of the previous century and Newtrk of the previous decade.  
> I'm sure there are others.

I know you remember and probably bear some scars, but, for those
who don't, POISED was very special, occurring when there was
very broad consensus that there was a problem that needed to be
solved in order for anything else to move forward in the IETF
ever again.  It defined the contemporary IETF and its structure
and, while I don't remember it being said explicitly, I think
there was fairly broad agreement that it was ok if people, even
fairly significant contributors, didn't like the result, went
away, and didn't come back.  

Independent of any other issues, I don't see there being
sufficient consensus over this issue that it is worth driving,
not just participants but  significant contributors, out of the
IETF would be an understatement.  More on that below.

There was also POISED95, which, among things, sorted out and
produced RFC 2026, 2027 (the foundation for the contemporary
NOMCOM model), 2028 (which we have never gotten around to
updating -- see the discussion at GENDISPATCH last month), and
2031 (which more or less defined the IETF-ISOC relationship
until the LLC came along).

Having co-chaired POISSON, while I would claim the effort was
mostly successful, it was also painful: the charter said "This
is therefore a slippery subject,
hence the name POISSON, which is French for fish." and I claim
that, like dead fish, some of the work took on a bad odor and
taught us the importance of the previous sentence of the
charter: "The tricky part of describing the IETF process,
certainly in the fast changing world of the Internet, is that
when you describe the process in too much detail, the IETF loses
its flexibility, when you describe to little it becomes
unmanageable." and, while, like its two predecessors, there was
strong consensus about the importance of the work and the desire
to get it done, I think, tuning aside, there was also fairly
strong consensus to tune existing procedures when necessary in
the future (the periodic revisions to the Nomcom and appointment
model are good examples) but to avoid taking on broad topics,
especially ones with the potential to seriously divide the IETF
and leave it divided or with people leaving, if at all possible.

I agree with Lucy about Problem Statement as well.  

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

>...
>> <minirant>Technical WGs at least have the possibility of
>> achieving  consensus based on the analysis of tradeoffs of
>> hard facts and good analysis.  A "WG" such as TERM may fail
>> of achieving even WG  consensus, let alone community
>> consensus (especially given the current ongoing discussions)
>> and there will be no fall back to fact analysis 
>> possible.   I can't see any way an appeal could be managed
>> in those  circumstances and I strongly suggest we do not try
>> to place this in  the WG model.</minirant>
>> 
>> 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.

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.

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

best,
   john