--On Thursday, March 27, 2014 17:55 -0500 Pete Resnick <presnick@xxxxxxxxxxxxxxxx> wrote: > Oh, don't get me wrong. When I say "fix it", I don't mean that > they necessarily need to fix the protocol the approach. I > simply mean fix the document, which may amount to the WG > getting sufficient text in to say, "This is only useful in X Y > and Z circumstances and is otherwise a bad idea and you > shouldn't do it." We are happy to publish all sorts of > applicability statements that say, "This is stupid in all but > these circumstances." I just don't want the IESG to have to > write it up. The WG should make their document reflect what > the community wants. --On Thursday, March 27, 2014 19:41 -0400 Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: >> >> The sad truth is, the IESG no longer has the spare cycles >> to "Just say No." > > I was on the receiving end of an IESG that simply stalled a > document until the WG changed its approach, because of IETF > concerns, so I disagree with that claim. But if it is true, > then we might as well give up. If there's weak IETF consensus > (with some strong objections) to a document that comes from a > WG and has strong consensus inside the WG, the _only_ people > who can say no are the IESG; and they must. Hi. Two observations: (1) If the IESG were to ever reach the point that it doesn't have the cycles to properly evaluate community consensus about a document and to make sure that the document reflects that consensus before it is published, then they, and we, are in bad trouble. That is one or only two key parts of the IESG job (the other being WG oversight). If the IESG doesn't have the cycles do that that and still do anything else, then the "anything else" should go. If doing this type of work is still not possible, I'd expect to see the IESG giving serious consideration to procedural changes that would reduce their workload [1], reducing the number of WGs to what they can handle [2], or resigning in the hope that the Nomcom can find people with either the cycles or the willingness to make changes. (2) Like Pete, I strongly prefer getting a document to the point where it is consistent with community consensus by having the responsible WG and document editors make changes rather than using IESG statements. The latter should, IMO, be reserved for the most unusual situations if they are used at all. But the priority should be that we never publish an IETF-stream document, especially a standards track one, that doesn't reflect community consensus without its being very clear about that. (3) If a WG and the community run out of cycles to get a document right, then the document ought to be dead, especially if it is proposed for standards track. Too bad, but,... (4) Some of the notes in this thread -- and some IESG actions in the past-- have implied that at appropriate goal of the IESG review process is to find compromise positions that make everyone more or less happy. IMO, if we ever reach the point where we believe that, we will have given up everything that makes IETF standards superior to those of SDOs who believe that something produced by a WG, or even seriously proposed to one, is entitled to standardization. Our standards, and the Internet itself, work because we have focused on good, workable, solutions -- ideally with a minimum of options that could lead, intentionally or not, to lack of interoperability-- not compromises among ground who want "their" ideas standardized and the resulting "almost anything conforms" standards. john we should expect to see a lot of resignations (1) If we reach the point that either the IESG [1] (there has been no shortage of such proposals