RE: IESG Success Stories (was: "Discuss" criteria)
That would be a subjective judgement.
Until recently the overriding assumption in the security area was that the
worst thing we could possibly do is to deploy a broken protocol.
That is empirically not true. At this point we have precisely two cryptographic
security protocols that can be regarded as a success: SSL and WEP. And the
original design of both was botched.
If the IESG had stopped SSL 1.0 from going ahead it would clearly have been a
success, but what if we had done the usual thing of delaying SSL 2.0 till it
provided perfect forward secrecy and we were absolutely convinced that there
were no problems of any kind whatsoever?
Excessive caution can be worse than suck-it-and-see.
Designing a security protocol is the easy part, we can all do that tollerably
well. Certainly we can all do it well enough to get to the point where the
crypto is not the weakest link in the chain.
The typical Internet user assumes that the Internet is secure in ways that it
Members of the IESG appear to have a very different view of what it is doing to
what I see in the working groups. In every working group I have been a part of
the IESG has been generally considered to be a procedural obstacle to be gamed
rather than a partner to work with.
The Internet is changing the way we view knowledge. The IETF constitution
pretty much reflects the logical positivist view that was the norm amongst
engineers in the 1980s/1990s. Today we live in the post-modern world of
Wikiality. Knowledge claims are viewed as being intrinsically provisional
rather than extrinsically authoritative.
I think that as with the fear 'don't ever deploy crypto, we might get it wrong'
many of the concerns on which the IETF structure are designed to address are
actually obsolete. In this case made obsolete by the effects of the technology
the organization is helping to create.
Does it matter to the organization if a WG produces a baddly written spec? Does
it harm anything other than their own chances of success?
From: Michael Thomas [mailto:mat(_at_)cisco(_dot_)com]
Sent: Saturday, December 30, 2006 10:09 AM
To: Hallam-Baker, Phillip
Cc: John C Klensin; dcrocker(_at_)bbiw(_dot_)net; sob(_at_)harvard(_dot_)edu;
Subject: IESG Success Stories (was: "Discuss" criteria)
So what occurs to me is that a reasonable question to ask is
whether there are some legitimate success stories where a
DISCUSS has actually found big or reasonably big problems
with a protocol that would have wreaked havoc had they not
been caught. I ask because it seems to me that the main
things that wreak havoc with protocols tend to be rather
subtle and not likely to be very visible to someone whose sum
experience with the work is their assignment to read the
current draft. That's not a slap at the people whose job is
to review, only that it seems to me to be asking for
From my limited experience with DISCUSS -- and last call for
that matter -- is that the focus is far more geared toward
wordsmithing than actual mechanics of the protocol (from
relatively disinterested parties, that is). While I have no
issue with tightening up drafts for publication, it doesn't
seem reasonable to be holding up the works for endless
amounts of time _just_ because somebody -- or some faction
of bodies -- isn't convinced that a draft is the prose they
The other thing that occurs to me -- and I know this has been
brought up in many different forms -- is that if an AD _was_
following the working group to some degree, why is it
legitimate for them to wait for IESG evaluation to voice
comments that affect the protocol's operation? That is, why
aren't they held just like anybody else to voice those in WG
last call when the WG is far more responsive to dealing with
issues? These "IESG Surprises" really hurt the community by
leading to the general perception that the IESG is capricious
in a royally anointed kind of way.
Hallam-Baker, Phillip wrote:
How many have we had?
I looked into what it would take to engage the recall
process. I don't think it is possible to use it without
tearing the whole organization appart.
With reference to John's recent campaigns I note that we
still have a situation where IETF practice is to employ a two
stage standards process but the process documents describe a
mythical three stage process.
The IESG appears to be unwilling to either change the
process document to reflect reality or to begin applying the
three stage process. And I don't even have visibility into
the process to know which individuals are the holdouts. The
only response I am ever going to get back is the passive
voice 'people on the IESG were not happy with the proposal'.
This is a real business issue for me, not a theoretical
one. I spend too much time having to counter FUD claims that
some IETF protocol or other is 'merely' draft and that it
should not therefore be considered. People in the Internet
area understand the mendacity but this is not the case in
banking. I can explain the fact that according to the IETF
HTTP 1.1 is still a draft standard but in doing so I have to
conceed the fact that the IETF processes are broken at which
point the proprietary FUD peddled chips in.
There are cases where consensus does not work. This is one
of them. There is clearly no consensus in the IESG to either
follow the process document or to fix it to match current
practice. So we have the organization stuck in a decade long deadlock.
This is where you need to have leadership (another thing
that the NOMCON process is expressly designed to exclude).
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Saturday, December 30, 2006 8:57 AM
To: dcrocker(_at_)bbiw(_dot_)net; sob(_at_)harvard(_dot_)edu
Subject: Re: "Discuss" criteria
At the risk of repeating what a few others have said in different
form, a few observations. Please understand that these
from someone who has been more consistently and loudly
even a hint of IESG arrogance and assertions of their power than
either of you and who has formally proposed a significant
ways of dealing with those problems --real or imagined-- than, I
think, anyone else in the community... none of which
I believe that, ultimately, the IETF has to pick IESG
members who can
do the job of evaluating documents and consensus about it and then
let them to do that job. And we had better pick people to do that
job who technical judgment and good sense we trust. If we
that, then we are in big-time, serious,
trouble: trouble from which no set of rules or procedures can
rescue us. Much as it makes me anxious, I think we ultimately
need to let an AD raise a Discuss because he or she has a
in his or her gut... and pick people who will use that particular
reason with considerable care and who will challenge each
work to understand the objection and either better document it or
remove it as appropriate.
If that discussion is abused in particular cases, I think it means
that we need more appeals and, if there is a pattern, more
recalls. In a long-term tradition of the IETF that we seem to
be losing, we may also need more specific, focused, public
plenaries and otherwise) from the community, not just from
regular complainers and microphone-hogs. What we don't need is
more rigid rules that either try to anticipate every
that give too strong a presumption to the wisdom of a
WG, especially at a time when fewer and fewer documents seem to be
getting widespread community review during Last Call.
In that context, I can only applaud this document, not as a set of
rules that the IESG has to follow, but as one that informs the
community about the mechanisms the IESG is using.
Information is good. And, if the IESG discovers that it needs to
update that information every time its membership changes
time they discover something isn't working and make an adjustment
according), I'd consider that a sign of good health:
at least it would show that, at least in this area,
and behavior patterns are not constraining current thinking to the
extent that replacing IESG members doesn't bring about change.
At the risk of giving a sales pitch, my other proposals have been
intended to reinforce the model above: I think it is
always going to
be hard, in our community, to find IESG members who are
good at doing
these kinds of technical evaluations and sensitive to the issues
involved and who are also outstanding managers, cat-herders,
bureaucrats, finance experts, and experts on
organizational behavior. So I have sought to separate some of
those roles. I think that long terms on the IESG tend to breed
detachment from the community and a tendency to put IESG judgment
ahead of that of the community and I don't think we can solve that
with more rules about IESG behavior.
So I have sought to give Nomcoms guidance about terms, to
nomination/appointment model, and to make the recall mechanism
more effective in practice. And I have sought ways to simplify
the job and reduce the workload in the hope that we can go back to
treating a term or two on the IESG as an obligation that the right
sorts of people owe the community, rather than a position to be
sought and in the more general hope of broadening the pool
who are willing to serve.
The fact that my proposals for change have not been
me that the community does not see a serious problem and doesn't
believe that changes are needed. While I believe that the lack of
acceptance of changes has been IESG recalcitrance and efforts to
protect the authority and ways of working with they are
comfortable, I don't think that changes the conclusion:
has ways, however unpleasant, for imposing changes that have
community consensus but that it IESG doesn't like and has
not use them. I disagree, but I think the
fairly clear and I have to accept that.
To me, it is in the areas of adjusting IESG scope, responsiveness,
and membership that we need to do our tuning, not by trying to
restrict the IESG to particular ways of doing its technical
evaluations or the statements ADs can make about specifications
submitted for approval and especially what arguments an AD can use
for forcing the rest of the IESG to take a harder look and
an in-depth discussion (internally and, if appropriate, with the
community). More hard rules about how the IESG does its technical
evaluation work won't, IMO, help us in the common, ordinary, cases
and, when an exceptional one arrives, such rules are
likely to force
the IESG into making the wrong decisions and doing the
and thereby hurt the IETF and the Internet.
Ietf mailing list
Ietf mailing list
Ietf mailing list