RE: "Discuss" criteria

More recalls?

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).

-----Original Message-----
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
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: "Discuss" criteria

Dave, Scott,

At the risk of repeating what a few others have said in 
different form, a few observations.  Please understand that 
these comments come from someone who has been more 
consistently and loudly critical about even a hint of IESG 
arrogance and assertions of their power than either of you 
and who has formally proposed a significant number of ways of 
dealing with those problems --real or imagined-- than, I 
think, anyone else in the community... none of which 
proposals have gone anywhere.

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 can't do 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 bad 
feeling in his or her gut... and pick people who will use 
that particular reason with considerable care and who will 
challenge each other and 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 
abuse (in 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 
circumstance or that give too strong a presumption to the 
wisdom of a too-homogeneous 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 (or every 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, 
historical rules 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 
change the 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 of people who are willing to serve.

The fact that my proposals for change have not been 
instituted tells 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 familiar and comfortable, I don't 
think that changes the conclusion: the community has ways, 
however unpleasant, for imposing changes that have community 
consensus but that it IESG doesn't like and has chosen to not 
use them.  I disagree, but I think the consensus-in-practice 
is 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 initiate 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 wrong things and thereby hurt the 
IETF and the Internet.

    john

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


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