It seems to me that the first place to do this is in I-Ds, even if we do
not have strict enforcement mechanisms. And if it is to be done in
I-Ds, it is up to the individual streams to do so. Having the IETF
discuss doing this for IETF i_Ds seems a really effective and sensible
starting point.
Yours,
Joel
On 7/23/2020 2:31 PM, Michael StJohns wrote:
On 7/23/2020 2:20 PM, Ted Hardie wrote:
On Thu, Jul 23, 2020 at 11:08 AM Michael StJohns <mstjohns@xxxxxxxxxxx
<mailto:mstjohns@xxxxxxxxxxx>> wrote:
On 7/23/2020 1:54 PM, Ted Hardie wrote:
Howdy,
On Thu, Jul 23, 2020 at 10:36 AM Michael StJohns
<mstjohns@xxxxxxxxxxx <mailto:mstjohns@xxxxxxxxxxx>> wrote:
Hi -
I support the general goals you've stated below, but I have a
few problems with how you're (IESG) suggesting we approach
them. Two in particular:
1) The onus for implementing whatever we end up deciding will
be on the RFC Editor and the RPC - that argues that the
primary driver of the language effort should be rooted over
on the rfc-interest mailing list, and driven by the RSE (or
the temporary equivalent) and not as part of the general
area. I'm not sure why this even needs to run past Dispatch?
For what it's worth, I disagree with this. The primary mode of
implementation here for new work will be a change in community
practice, not a set of changes implemented at the end of the
process by the RSE or RPC. It also seems to clear to me that it
would be valuable for the other streams to consider the same
issues, but I don't believe that changing the IETF's practice
requires the consensus of the other streams to change.
Hi -
I'm actually surprised that you think its a good idea to do this
on a stream basis rather than on a community basis. Regardless,
the draft cited is pretty clear that it wants to add constraints
to the RFC process:
Just above the text you cite is this:
Authors SHOULD: * Replace the excluding term "master-slave" with more
accurate alternatives, for instance from the list of Section 3.1. *
Replace the excluding term "blacklist-whitelist" with more accurate
alternative, for instance from the list of suggested alternatives at
Section 3.2. * Reflect on their use of metaphors generally * Use the
neutral "they" as the singular pronoun, and * Consider changing
existing exclusive language in current (reference) implementations
[socketwench] * Consult the style sheet maintained by the RFC editor.
Note the above does not say "IETF Stream Authors SHOULD".
Getting the cultural shift to this reflection on the consideration
means that it will be rare that the RFC editor will need to offer
alternatives. It also means the language in I-Ds and working group
discussion will avoid the terms early, rather than expecting a
post-facto adjustment by an expert. A BCP covering the IETF practice
here seems to me a useful thing to do, even if all the other streams
come to very similar practices.
I don't disagree with the first or second sentence, but this is not an
IETF Stream nor an IAB Stream nor an IRTF Stream nor an Independent
Stream issue, but a community issue directly related to the publication
of RFCs. If you set requirements for the RFCs, they flow back into the
submissions from the streams.
This is not a IETF BCP issue - except as the RFC style guide might be
adopted as a BCP. E.g an update to RFC7322.
Later, Mike
Adjustment of the language of the draft to reflect that targeting
would, of course, be fine by me.
regards,
Ted Hardie
