--On Thursday, March 27, 2014 17:55 -0500 Pete Resnick
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com> 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(_at_)anvilwalrusden(_dot_)com> 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