On Thu, Jul 23, 2020 at 11:08 AM Michael StJohns <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> 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
