Dave CROCKER <dhc2@xxxxxxxxxxxx> wrote: > Jari Arkko wrote: > >> It is not news that what we proposed as a compromise position isn't >> optimal from some people's point of view. But a small number of voices >> should not drive the entire community's choice. > > We agree, yet oddly land on different sides. > > A review of the public record shows relatively minimal voiced support > for the IESG insistence that it be able to override the RFC Editor's > decision. Straw man alert! There has been "minimal voiced support" for that "insistence" because it simply doesn't exist. The IESG has suggested that if it comes to consensus that a IESG note be attached, the "RFC Editor" should respect that consensus. It has always been understood that further discussion of the wording of such a note is appropriate. The IETF-consensus that Jari tried to call was that the RFC Editor should document a disagreement with a proposed IESG note and be prepared to present that to the IAB if agreement can't be reached with the IESG. If I may digress, it is my strong opinion that should such a situation ever arise (it doesn't seem terribly likely!), it's nearly certain that the IAB should tell one or the other to "Stop doing that!"; and that only the IAB has enough clout to make that stick. > That is, my reading of the record says that the small number is on the > side of terminating the multi-decade RFC Editor independence. I'm not quite sure whether that's a straw-man. The IESG opinion isn't to "terminate" "independence"; so it's hardly surprising that few folks are speaking in favor of that. But it's quite possible that John Klensin, Brian Carpenter, and Dave Crocker see the IESG proposal as "terminating" "independence". There have been a number of voices favoring what Jari tried to call as consensus, and I'd like to add mine. If there was "independence" of the RFC Editor from IAB oversight, it's long gone, and good riddance IMHO. Jari's proposal included quite enough "independence" from the IESG, IMHO. Document Editors, in the IETF, are supposed to be seeking consensus; and I see no reason why the RFC Editor shouldn't share at least a bit of responsibility to seek consensus. > Perhaps my reading is wrong. I suspect, Dave, that you are reading something into Jari's proposal that isn't there. It might help if you tried the exercise of explaining _exactly_ what Jari is proposing -- not just what harm it would inflict upon your worldview of the ideal RFC Editor. > An accounting assessment of community views, justifying claims of > rough consensus, is the usual approach towards resolving this kind of > disparity. Well, I suppose you've been following IETF a lot more closely than I over the last twenty years; but that's not the "usual approach" I've been seeing. The "usual approach" I've seen is to start with a call of consensus and have anyone who disagrees state where s/he thinks the caller has gone wrong: the caller or a body hearing an appeal then reviews the record and states in considerably more detail what they see as the most likely consensus. Then discussion can continue, with much of the ambiguity brought out into the open. If the person who disagrees is not satisfied, higher-level appeals are available. I do not see "justifying" here: I see disambiguating. I do not see any claims that the whole "community" has been heard from: I see a record of considering the points raised by the subset that has been heard from. >> Also, I believe the first order of priority is to find out what the IETF >> and the larger community wants to do here. You're quoting Jari out of context. Let me restore the context: ] ] So, may I ask that if we propose some other resolution, we talk not ] just about why that's a great proposal, but also how the proposal ] addresses the diverging opinions from various sides of the argument? ] ... ] Also, I believe the first order of priority is to find out what the IETF ] and the larger community wants to do here. Lets do the right thing, and ] put the process questions (such as which RFC needs to be updated) aside ] for the moment. We will find a way to solve those things, they should ] not drive the big decisions. > In the face of a complex problem space, combined with a complex > solutions space, and controversy about both, the first priority > should be to establish rough consensus about the problem that is > intended to be solved. > > That hasn't been done. Indeed, it hasn't. It escapes me, however, _why_ we should take on such a task. The IESG and IAB are trying to implement changes to boilerplate, reflecting changes in the IETF community's views of the role of the IESG in non-IESG documents published by the RFC Editor. Changes to an old consensus are always difficult. There are a number of "problems" which led to this attempt to update. Documenting all of them would only serve to obfuscate. Progress so far in this task has reduced the role of the IESG in such documents. Tying this process in knots over details nobody claims are likely to arise in the near future doesn't strike me as helpful. > Get us to agree on the nature of the "problem" and its degree of > severity -- and therefore the dangers that come from not "solving" > it -- and we might be able to get some common perspectives on > solutions. That is not a reasonable request. The IESG has been trying to work from principles, not from a "problem statement." This process didn't start from a "problem" between the IESG and the RFC Editor -- there has been no "problem" there for several years at least. Problem Statements are something we ask of Working Groups when there is ambiguity in their charter. They take a long time to write, and they almost always turn up parts of "the problem" which the WG will end up unable to solve. I urge you to do as Jari asks: talk not just about why your proposal is good, but about how it addresses the diverging opinions expressed so far. If you're not willing to do that, please either file an appeal, or stop beating this "pining for the fjords" horse. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf