Re: "Discuss" criteria

On Wednesday, January 03, 2007 10:49:33 PM +0000 Dave Crocker 
<dhc2(_at_)dcrocker(_dot_)net> wrote:
> C.  PROCEDURAL BREAKAGE
> -----------------------
>
> > * IETF process related to document advancement was not carried out;
> > e.g.,  there are unresolved and substantive Last Call comments which the
> > document  does not address...
IMHO, this particular situation is more than just "procedural breakage". 
If a document reaches this point with outstanding last call comments, then 
there is a more basic failure.  Such a document should not have reached the 
point where a DISCUSS is required to keep it from progressing long enough 
for the comment to be addressed.



> D.  CONSTITUENCY MISMATCH
> -------------------------
>
> > * The IETF as a whole does not have consensus on the technical
> > approachor  document. There are cases where individual working groups or
> > areas have  forged rough consensus around a technical approach which
> > does not garner IETF consensus. An AD may DISCUSS a document where she
> >  or he believes this to be  the case. While the Area Director should
> > describe the technical area where  consensus is flawed, the focus of the
> > DISCUSS and its resolution shouldbe on how to forge a cross-IETF
> >  consensus.
> Presumably, the working group has been populated by people interested in
> using
> the specification in the near-term. If no such people are active in the
> working group, then why has a standards effort been pursued?
>
> The above criterion says that these motivated participants' concerns are
> not sufficient, when weighed against the more detached desires of the
> active IETF community.
>
> Asserting this criterion seems to represent an IETF failure at so many
> different
> levels, that it raises fundamental questions about the nature and purpose
> of the
> IETF.  By implication, it says that we do not care as much about the
> people who are going to depend upon the protocol, as we do about those
> who won't.
Not necessarily.  It may say that the members of the working group have 
consensus to break the Internet in order to sell more of their product. 
The people who invented a thing, developed it, and depend on its acceptance 
in the marketplace for their livelyhood may be tempted to overlook any 
number of significant problems.  Part of the job of the IESG is to prevent 
such people from using the IETF to make the Internet worse instead of 
better.
Now, I'll agree that an objection on this basis indicates a failure.  But 
the failure is often the working group's in not understanding the bigger 
picture, not asking for help in doing so, or not caring about it. 
Sometimes, the failure is not that help was not requested, but that it was 
not given, or not useful.  However...


The IETF process is a cooperative process toward a common goal, not an 
adversarial process.  Our common goal is to make the Internet better; if 
your goal is to rubber-stamp your pet proposal or market your product 
whether it makes the Internet better or not, you don't belong here.
Arguments like "no one warned my about this issue before, so it wouldn't be 
fair to hold back my document now until it's fixed" manage to completely 
miss the point.  If fixing the problem before the document is published 
advances the goal, then that is what we should do.  If publishing the 
document without the fix advances the goal, then _that_ is what we should 
do.  Sometimes, the right answer is to do both!
If an IESG member places a DISCUSS on a document, and your response is "you 
don't have sufficient grounds for a DISCUSS" or "please tell me what change 
to make to my document to make the DISCUSS go away", then you are totally 
missing the point.  The correct response is "please help us to understand 
your concern so that we can work toward a resolution".  Sometimes that 
resolution will in fact be a simple and obvious change to the document. 
Sometimes it will involve pointing out the obvious reason why there is not 
really a problem.  Usually it will be somewhere in between.  It may involve 
publishing a document which has a known problem because doing so advances 
the goal more than fixing the problem would.  It may involve scrapping the 
whole document and starting over.  Usually, it will be somewhere in 
between.  Often, the way forward will not be immediately obvious to anyone 
involved.  THIS IS NOT A FAILURE.  It is the system working the way it is 
supposed to, with people working together to produce high-quality standards 
that improve the Internet.

So, is "constituency mismatch" a failure of the IETF?  Quite often, yes.
Does it indicate a fundamental flaw in the process?  NO.
It means that the process did not get followed, and in particular that a 
group failed to work with the community to produce a document which the 
IETF as a whole could support.
That may be because someone doesn't "get it", and thus wasn't aware of who 
they needed to work with or what they needed to do or how to ask for help. 
We should work with such people, both to help them "get it" and to help 
them get their work to a state where it is ready for publication.  Some 
time may be lost, but everything has a learning curve, including working in 
the IETF.  The failure is when such people _don't_ learn and continue to 
make the same mistakes, and _that_ failure is on the part of the people who 
do "get it".
It may be because someone believes their proposal is so urgent that there's 
not time to get wider review, or to fix the problems.  Very occasionally, 
there is a real urgency _for the Internet_ to get something out sooner 
rather than later.  In other cases, well, you probably should have known 
better (but see above).
It may be because someone is acting in bad faith.  That may not be the 
people who developed the proposal in question; it may be the proponents of 
some competing proposal, or some other adversary.  Obviously, it does not 
advance the goal to allow someone who is acting in bad faith to force 
publication of a "bad" document, nor to prevent publication of a good one. 
Fortunately, we have piles of documents describing process for dealing with 
this when it comes up.  And yes, there are even ways to deal with a DISCUSS 
placed on a document by someone acting in bad faith.  Hopefully, that will 
never become a problem.
Finally, it may indicate there was a genuine attempt to work with the 
community, and that resulted in a technical disagreement that could not be 
resolved, even under the "rough consensus" model.  If that happens, there 
may well be a real problem, but it is not a failure of the process.  If we 
cannot reach consensus on something, then we should not publish it; after 
all, when all is said and done, our documents are supposed to represent the 
consensus of the IETF.  They should consist of the things we have agreed to 
say, not the things we haven't agreed not to say.


> There certainly are times that the nature of Internet architecture permits
> fielding only one proposal.  However there are plenty of examples of
> fielding multiple solutions, and letting the market choose among them.
I fully agree with this.  I have seen some arguments that the IETF should 
only standardize one way of doing any particular thing.  While that is a 
good rule at some levels, it is unnecessary at others.  Often there are 
multiple approaches to doing something which make different but more or 
less equally valid tradeoffs, and any of which would improve the Internet. 
In such cases, we should not be adverse to standardizing multiple 
approaches, unless doing so would be contrary to the goal.  So, the 
required consensus is (or should be) that publication of a document is good 
for the Internet, not that it represents the _only_ approach that is good 
for the Internet.  If someone has another approach that they think would be 
better, but fails to convince the WG or anyone else, then they are in the 
rough.  It should be quite rare indeed for the IETF to come to consensus 
that an alternate approach is _so_ good that not only should it be done, 
but the approach sitting in last call should not be published.
Similarly, I don't think we should necessarily require a large display of 
support to charter a working group.  Certainly, there should be enough to 
suggest that, if chartered, the group would actually be productive.  But if 
20 people believe that something is worth doing, then they should not be 
told "no" for no better reason than that out of 100 people attending a BOF, 
only those 20 raised their hands and said they'd participate.  Of course, 
it's a different story if the work is out of our scope, or more suited to 
another SDO, or could never result in an IETF consensus (and sometimes we 
even charter those).

> So the
> above
> criterion would seem to impose a universal requirement for unanimity that
> was
> most definitely not part of the IETF model, for example, 10-15 years ago.
I don't believe unanimity is required, but rough consensus is.  Of course, 
a large number of last calls go by with no comment at all.  That's OK, 
because to a certain extent "consensus" means that people were given an 
opportunity to object and did not do so.  It would still bother me if I 
thought we were publishing lots of documents without any review, but I 
don't think that's the case -- part of the IESG's job is to perform such 
review and/or find others to do so, so that the rest of us _don't_ have to 
read every document that goes by.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf