Re: "Discuss" criteria

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wednesday, January 03, 2007 10:49:33 PM +0000 Dave Crocker <dhc2@xxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]