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
