Jari (and Brian), Many messages have gone by since the one below, but it seems like the right one to which to respond nonetheless. Inline... --On Tuesday, April 13, 2021 19:44 +0300 Jari Arkko <jari.arkko@xxxxxxxxx> wrote: > Brian, > >> 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. > > I think that's a good question. > > I have a view on that, and interestingly I came to a different > conclusion than you did. Perhaps it would be useful to talk > about this a bit further. > > So, my reasoning is that the right place for most IETF > decisions is at the working groups. (Subject to some common > policies and full IETF review, of course, as discussed in the > other thread…) So, should a WG doing technical/substantive work have responsibility for the documents it is producing (subject to your qualifications)? Absolutely and I don't think anyone has proposed otherwise. I think this is correct for IETF technical work, i.e., about Internet protocols and related work to make the Internet work (or work better). But this topic and the proposed TERM WG do not fall into that category. I've described the problem in the context of the RFC Editor Future discussions as one of expertise: it is much better if work is done by, and evaluated by, people who actually have expertise in the subject matter (and who know what they don't know) rather than perhaps only having strong opinions. As an extreme example, if someone came to the IETF and said, "We need to standardize treatment regimes for COVID-19 and databases for keeping track of vaccinations and disease patterns. Because the data will be transmitted over the Internet, we think the work should be done in the IETF". I hope (and believe) we would say "insufficient expertise about the subject matter here" and encourage them to go elsewhere or, if there were special, Internet-specific issues, we would try to work out some arrangement by which we could advise, e.g., WHO without needing to develop expertise in (that type of) viruses or medicine. We would not be having a discussion about exactly what words to put in a charter, especially a charter for a WG whose creation seems to be assumed in the way the discussion was framed. The situation with TERM is, I hope obviously, not quite as extreme as the medical one but it seems too close for comfort. > I could imagine RFC Editor adjusting text in a security > considerations section that talked about some filtering and > used older versions of "denylist" in the text. But I'm > not sure I'd want the RFC Editor to adjust a major term > picked by a working group in their protocol, particularly when > the change may cause differences between a new RFC and older > RFCs to occur. I'd want the WG to make that determination. > For an example, see > https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#secti > on-1.2 > <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#sect > ion-1.2> I share your concern for the RFC Editor simply adjusting text. But I don't think anyone who has thought this through seriously considers what were described several days ago as applying s/bad-term/new-term/ changes globally. Instead, I would expect something much closer to what I have experienced for years (and assume you probably have too): notes saying in some way "would this be better if we replaced <term-or-phrase-A> with <term-or-phrase-B>?" followed, if needed, by a discussion. Would it be better to get a collection of problem terms into some sort of list with possibly better ones and attach that to the style manual in the hope (and expectation, however unrealistic) that WGs (or other document sources) would sort things out long before they got to the RFC Editor? Yes, of course. But that is really no different from a preference for good-quality American English over a variety of other languages and dialects that approximate such English, documents that are then dumped on the RFC Editor: If those things get through IETF LC and the IESG signs off, the "editing" process includes a good deal of discussion between RPC staff and authors and, often, WG Chairs and ADs and, at the discretion of those in the IETF sign-off chain, the WGs themselves [1]. > All this leads me to believe that the WGs are and should be in > charge of the bigger modifications. Ok. But that is really no different from any other problematic language, document organization, or phrasing. For whether the WGs should be more involved in that part of the editing process rather than implicitly delegating it to authors as has been usual in the past, see note [2]. > This still leaves room for: > > - a new terminology working group to provide guidance & > principles And I thought that was what we are talking about here, except that I would have preferred that you say "terminology effort". See below. - RFC editor to check and adjust text (and possibly > highlight issues back to the authors)* Right. See above. >... > *) Lars' working group proposal does not involve the working > group actually developing a list of terms. That too could > possibly be a thing that the RFC Editor could do. But of > course the community could do it also, as volunteers in some > design-team like activity, or we could find an entirely > external resource that is updated with information. Yes. But, if the TERM WG neither develops a list of terms (see below) nor has responsibility for document-by-document decisions about terminology (which would make it less a WG than some sort of special committee of the IESG and/or the RFC Editor of the likes we have never had before), why do you think a WG is the right structure for that work? Put differently, if the core things TERM is going to do could be done by a "design-team like activity", what do we need TERM for. There is no evidence that the participants such a WG would attract would be expert in choices of terminology or in balancing tradeoffs unique to the IETF or particular protocols or documents. If the main task is to gather up vocabularies and mapping thesauri compiled by others, that doesn't sound to me like a task for an open WG in which anyone can voice their opinions and/or the perceived grievances of others. Instead, it would seem much better and more efficient to do exactly what you suggest-- appoint a group with a reasonable balance of expertise --whether we call that a design team, a short-lived directorate, or something else-- make sure the RFC Editor (including both the Production Center and whatever substitute we might temporarily invent for an RSE) is represented in those discussions, and then produce recommendations and how those should be made available to the community. At least today, I'd personally favor extending the Style Manual and I note that even new versions of the style manual get community requests for input and review. If the real value of a WG is that the IESG gets final say on its output... well, with no disrespect to their skills in other areas, it is not clear either that the IESG has the necessary expertise in this area or even that it falls within their charter. best, john p.s. I think the view expressed above is somewhat different from Stewart Bryant's in https://mailarchive.ietf.org/arch/msg/ietf/WASouhKP24ay_n2GtrxP2YRj718 but they probably lead in the same direction. [1] I think one result of this effort, with or without the TERM WG (or an alternative) and whatever they might propose, is going to be more work for the IESG, the RFC Editor process, or both. I hope we are all ready for that, including the LLC for the financial implications and for the IESG having to make decisions that balance reviews for better terminology with consideration of technical quality issues that would exist regardless of the terminology. [2] Do I think many more documents should be sent back to WGs by either the IESG or the RFC Editor with "please sort this out" notes? Do I think that changes "approved" in AUTH48 ought to go back for a check on WG Consensus and maybe even IETF Last Call far more often than we do that? Yes to that to. But it seems to me that we should strive to keep those separate subjects even if I think you suggestion about WG control leads quickly in that direction.
