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