Subject: I-D ACTION:draft-ietf-problem-process-00.txt

From: [email-masked]
Date: Tue, 13 May 2003 08:00:25 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Problem Statement Working Group of the IETF.

	Title		: IETF Problem Resolution Processes
	Author(s)	: M. Wasserman
	Filename	: draft-ietf-problem-process-00.txt
	Pages		: 28
	Date		: 2003-5-12
	
This document suggests processes to address the problems identified
in the IETF Problem Statement.
This document decomposes each of the problems described in the
problem statement into a few areas for improvement, categorizes
those areas into longer-term and near-term problems, and suggests
processes to address each area.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-problem-process-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-problem-process-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-problem-process-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 15 May 2003 11:35:26 -0400

Well, since no one else has jumped in, I guess I will...

There are several open issues raised in the process document
that will require discussion and resolution by the WG.

I have opinions about how we should resolve these issues,
and I'll offer my opinions now.  Others should feel free to
chime in with either agreement or dissent.

I will raise each issue in a separate message, in an
attempt to promote threading...  Please try to respond to
individual issues in their appropriate threads, so that
I can keep better track of the discussion and reflect it
in the document.

Thanks,
Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 14:49:20 +0200

Generally I like this draft. I will comment separately on
Margaret's open issues threads.

> 2  IETF Core Values

I'm surprised not to find self-governance listed as a core value. 

...
> 5.1 Near-Term Improvements
...
>          5. Modify IESG-internal processes to make it impossible for one
>             or two IESG members to block a document.

There is a strong implication here that ADs might do this for
spurious reasons. But if one or both Security ADs are deeply
convinced that a draft constitutes a major security risk, or one
or both Routing ADs are convinced that a draft will lead to routing
loops, isn't it quite appropriate for them to block the document?
Such cases suggest failures much earlier in the process, not 
misbehaviour by the IESG. So I don't think we should fix this, 
because it is actually a vital back-stop, not a bug.

...
> 5.2.1.1 Working Group Charter and Deliverables
...
>     Although the IETF Improvement WG will ultimately be responsible for
>     determining what improvements are required, it should be clear that
>     this WG is empowered to make changes to the IETF organizational
>     structure and processes, subject to approval by the appropriate
>     oversight body (see below), such as:
> 
>          - Updates to RFC 2418, the Nomcom processes and the IESG and
>            IAB charters (as needed) to define a more scaleable and
>            effective organizational structure for the IETF.

I have some difficulty with this. It's inconceivable to me to make
changes to the IAB charter, or to create an IESG charter, without
the overwhelming support of the current IAB or IESG respectively. So
I don't agree that the proposed WG can be "empowered" for this. It could
be chartered to make concrete proposals to the IAB|IESG but the only
workable outcome is consensus between the WG and IAB|IESG.

>          - Updates to RFC 2026 and other published processes to build
>            an effective multi-level standards-track and to reflect any
>            new organizational roles.

Please specifically exclude updates to IPR policy, since we have just
reached consensus over in IPRWG not to do this.

...
>  5.2.2.1 IESG-Directed Approach
> 
>     One possibility is that we could use the IETF WG and document
>     processes defined in RFCs 2418 and 2026 [RFC2418, RFC2026] for the
>     oversight of the IETF Improvement WG.
> 
>     In particular:
> 
>          - The WG would be formed in the General Area of the IETF, with
>            the General AD serving as the "responsible AD".
>          - The documents would be submitted to the IESG for approval
>            and publication, according to the usual IETF processes.
>          - If necessary, any appeals based on the processes or output
>            of this WG would be handled according to the appeals
>            procedures defined in RFCs 2418 and 2026.

A very important step is missing here. All IETF process documents need
to be formally accepted by the ISOC Board, to ensure that we have the
necessary chain of authority to validate the liability insurance.

>  5.2.2.2 ISOC-Directed Approach
> 
>     Another approach would be to ask the ISOC President and the ISOC
>     Board of Trustees (ISOC BoT) to assume responsibility for the
>     oversight of the IETF Improvement WG, similar to our current
>     Nominations Committee processes, as defined in RFC 2727 [RFC2727].
> 
Although I am currently an ISOC Trustee, I certainly can't speak for
the ISOC on this. However, I wouldn't advocate it. Only a few members
of the ISOC Board are truly familiar with the IETF's internal workings.
Having the Board accept the final documents, as noted above, is enough.

  Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 16 May 2003 09:05:03 -0400

Hi Brian,

>I'm surprised not to find self-governance listed as a core value.

Explain to me what it is, and if there is agreement, I'll add
it!

>because it is actually a vital back-stop, not a bug.

I agree.  On the poised list, John Klensin suggested some IESG
charter wording that does a much better job of explaining what
should happen than I have.  In particular, he suggested adding
the following wording to the "AD review" process:

"The responsible ADs are expected to complete this review on a
timely basis and, if a significant review period is
required, to make the reasons for the delay public on an
ongoing basis. WGs or document authors or editors may
appeal unreasonable delays to the IETF Chair and, if
necessary, to the full IESG, as described in BCP 9 and may,
on that basis, request that the document be assigned to a
different (or additional) AD."

This is really what I'm trying to say...  The processes
should be changed so that it isn't possible for a document
to get _stuck_ in the IESG (either in AD review or IESG
review) for a lengthy period without a response.

The I-D tracker has helped, because WG chairs can now
detect when this is happening and figure out who to
ask...  But, some things still linger.

BTW, I think that the IESG should retain control of its
own internal processes and consider changes to correct
this, not that the IETF should impose processes on the
IESG.

>workable outcome is consensus between the WG and IAB|IESG.

I agree, but others do not.  This disagreement could not be resolved
insider our own editorial team, which is why the current document
contains two different choices for WG oversight.

Once we choose one type of WG oversight to pursue (which I hope happens
fairly soon), it will be easier to make the rest of this section clearer.

>reached consensus over in IPRWG not to do this.

This raises sort of an interesting larger question...  We have current
efforts underway regarding our IPR policy (ipr WG) and our Nomcom
process (nomcom WG).  To what extent should the agreements of those
groups be binding on the outcome of this WG?  How would conflicts
between the outcomes of those WGs and the recommendations of the
improve WG be handled?

>necessary chain of authority to validate the liability insurance.

Is this documented somewhere?  If so, let me know and I will refer
to it.  If not, can you explain in more detail how this works and
when the ISOC board enters the process, etc.

Thanks,
Margaret

---

From: Eric Rosen <[email-masked]>
Date: Fri, 16 May 2003 11:09:25 -0400

...
>             or two IESG members to block a document.

Brian> There is a strong implication here that ADs might do this for
Brian> spurious reasons. 

Well, yes, that's the "problem".

Brian> But if one or both Security ADs are deeply
Brian> convinced that a draft constitutes a major security risk, or one
Brian> or both Routing ADs are convinced that a draft will lead to routing
Brian> loops, isn't it quite appropriate for them to block the document?
Brian> Such cases suggest failures much earlier in the process, not 
Brian> misbehaviour by the IESG. So I don't think we should fix this, 
Brian> because it is actually a vital back-stop, not a bug. 

You  can't remove a  problem by  declaring it  not to  be a  problem; that's
called  a "whitewash".  And  the fact  that the  ADs sometimes  act properly
doesn't mean that they don't sometimes act improperly. 

The problem  is that there  is no effective  and open process by  which such
decisions can be reviewed and evaluated to determine whether they are proper
or improper.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 16 May 2003 10:22:09 -0500

Dear Margaret,

Actually, I thought the NEXT working group was supposed to 
do the Real Core Values, and the list in this draft were 
a placeholder from Harald's presentations on the subject.

Was this not the plan?

I'm still trying to figure out what "cares for the Internet" means
in concrete terms, right?

If we ARE going to have a "Real Core Values" section in the
current draft, we sure haven't had much input on the subject
yet...

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 17:22:46 +0200

> Explain to me what it is, and if there is agreement, I'll add

Self-governance

The IETF is not controlled by a higher authority. The community, i.e.
the group of engineers actively participating as individuals, appoints 
the Chair and the main committees (currently the IESG and IAB) by a 
process agreed by the community itself. Although the lack of a formal
membership structure means that this process cannot be based on formal
voting, it is designed to be as open and democratic as reasoanbly
possible. It includes appropriate checks and balances against abuse
of power within the IETF.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 17:27:04 +0200

...
> between the outcomes of those WGs and the recommendations of the

I think improve should be excluded by charter from changing the IPR and
Nomcom results for some period of time (at least a year). It would be
foolish to have spent a lot of effort on those two topics and then not
even take the time needed to see if the next documents actually fix the
known problems in the old ones.

   Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 16 May 2003 11:22:39 -0400

Hi Spencer,

>a placeholder from Harald's presentations on the subject.

Good point.  I guess that the WG should decide what we
want to do about this...

>in concrete terms, right?

Ask Harald?

>current draft, we sure haven't had much input on the subject

Actually, we haven't had much input on the process parts of
the document either.  People barely responded to my earlier
requests on the list and to my WG presentation.  I am hoping
we'll get more input on the process now that there is a
strawman available, and (today, at least) that seems to be
working.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 May 2003 17:42:12 +0200

> when the ISOC board enters the process, etc.

I don't think it is documented. In the past, the ISOC VP Standards has
simply forwarded the RFCs concerned to to the ISOC Board and requested
that they be accepted, resulting in a Board resolution such as

> Resolution 96-11. Adoption of POISED Documents
> 
>       RESOLVED, that the Board accept the POISED Documents: The Organisations Involved in the IETF Standards Process, IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, and The Internet Standards Process -- Revision 3, and accept the responsibilities of ISOC as described in these documents.

I think it would be good to document the fact this should be done, for
any process document that might affect the chain of responsibility
for liability insurance purposes. 

    Brian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 16 May 2003 11:15:29 -0500

On 5/16/03 at 2:49 PM +0200, Brian E Carpenter wrote:

>spurious reasons.

I don't think it makes a difference to the issue, but let's even 
assume that it is *not* done for spurious reasons.

>But if one or both Security ADs are deeply convinced that a draft 
>constitutes a major security risk, or one or both Routing ADs are 
>convinced that a draft will lead to routing loops, isn't it quite 
>appropriate for them to block the document?

Absolutely not, but *not* because the document shouldn't be stopped. 
The ADs who think that there is a serious problem with a document 
should convince the rest of the IESG that the document is a bad idea. 
Then, the IESG can come to consensus (or unanimity) to reject a 
document (or at least stop it until the problem is fixed).

The problem with the current process (as I understand it) is that it 
allows documents to be blocked by one or two IESG members without the 
consensus of the group. The current procedure assumes that one or two 
IESG members must be able to block a document because the rest of the 
IESG is so stupid or ignorant that they cannot be convinced that the 
document is a bad idea, even if one or two experts on the IESG know 
that it is. If that were actually the case, it points to a much worse 
state of affairs, where IESG members don't trust each other to do the 
right thing.

>misbehaviour by the IESG.

For  case where the entire IESG comes to consensus that a document 
should be stopped, yes, that suggests a very early process failure. 
But cases where it is required that one or two IESG members can, 
without consensus, block a document, suggests serious misbehavior on 
the part of the rest of the IESG.

>So I don't think we should fix this, because it is actually a vital 
>back-stop, not a bug.

We already have a backstop for each of the cases:

1. In the case of a bad document, the IESG can come to consensus that 
a document is bad.

2. In the case of a bad document where one or two IESG members can't 
convince the rest of the IESG, the one or two members can appeal, or 
initiate recall procedures on the rest of the IESG.

I really wish someone could explain to me why we think it is 
necessary to have IESG members vetoing each other's decisions as a 
backstop.
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 May 2003 14:48:14 -0400

> consensus of the group. 

I don't see this as a problem at all.  Many of the issues that hold up
document publication are not easily understood without expertise in that
particular area.  Also, IESG does not "block" documents, it explains
what is wrong with them and sends them back to the working group.  It's
simply infeasible to expect all of IESG to reach consensus on every
issue that requires a change to a document. For a deep technical issue,
there *might* be four people on IESG who really have enough appreciation
for that issue to express an informed opinion - and two of those might
have to stretch to understand it.

> the part of the rest of the IESG.

No, it just means that a wide range of expertise is required to evaluate
all of the proposals that come through IETF.

> necessary to have IESG members vetoing each other's decisions as a 

It's a misleading to think of a vote as a veto, particularly when most
of the votes are usually "no objection".   Usually you vote "no
objection" when you recognize that you don't have enough expertise to
evaluate the proposal.   A common case is to have one or two Yes votes,
one or two Discuss votes, and the rest No Objection. That's not a case
of one or two people holding up the document against an overwhelming
majority. It's more like a tie.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 May 2003 12:13:58 -0700

Folks,

PR> The ADs who think that there is a serious problem with a document
PR> should convince the rest of the IESG that the document is a bad idea.
PR> Then, the IESG can come to consensus (or unanimity) to reject a 
PR> document (or at least stop it until the problem is fixed).

Exactly right.

No matter how stellar the expertise of someone, if they cannot convince
others that their views are correct, something is very, very wrong.
Permitting them to single- (or double-) handedly block something removes
the the incentive for that person to work at convincing others.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "Daniel O. Awduche" <[email-masked]>
Date: Fri, 16 May 2003 15:52:24 -0400

I concur with the sentiments... 

Granting an individual (who purports to be an expert) the authority to 
block a document (that has passed through WG consensus) without a clear,

convincing, and rational explanation demeans the entire process.

Cheers,
/Dan 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave
Crocker
Sent: Friday, May 16, 2003 3:14 PM
To: [email-masked]
Subject: Re: Document Blocking (Was:
I-DACTION:draft-ietf-problem-process-00.txt)

Folks,

PR> The ADs who think that there is a serious problem with a document 
PR> should convince the rest of the IESG that the document is a bad 
PR> idea. Then, the IESG can come to consensus (or unanimity) to reject 
PR> a document (or at least stop it until the problem is fixed).

Exactly right.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>  Sunnyvale, CA
USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 May 2003 17:13:42 -0700

Brian,

>>             or two IESG members to block a document.
BEC> There is a strong implication here that ADs might do this for
BEC> spurious reasons.

At base, the reasons do not matter.  It simply is not reasonable for any
one (or two) people to weild that much power.  A group based on Rough
Consensus should rely on those having a point of view being able to
recruit others to support that view.  If they cannot succeed in their
recruitment effort, there is something wrong with their view.

We believe in technical expertise, not technical deities.

Expertise is compelling, when the expertise is real. Only deities
warrant individual veto authority in this community.

BEC> But if one or both Security ADs are deeply
BEC> convinced that a draft constitutes a major security risk, or one
BEC> or both Routing ADs are convinced that a draft will lead to routing
BEC> loops, isn't it quite appropriate for them to block the document?

If they cannot convince others of the correctness in their views, then
no.  The failure to make a compelling case strongly suggests that the
case is itself problematic.

BEC> A very important step is missing here. All IETF process documents need
BEC> to be formally accepted by the ISOC Board, to ensure that we have the
BEC> necessary chain of authority to validate the liability insurance.

Thanks for catching this.

>>     Nominations Committee processes, as defined in RFC 2727 [RFC2727].
BEC> Although I am currently an ISOC Trustee, I certainly can't speak for
BEC> the ISOC on this. However, I wouldn't advocate it. Only a few members
BEC> of the ISOC Board are truly familiar with the IETF's internal workings.
BEC> Having the Board accept the final documents, as noted above, is enough.

The idea is to model the process after the ISOC portion of the Nomcom
process.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 May 2003 16:36:53 +0200

below...

> decisions can be reviewed and evaluated to determine whether they are proper

This generated its own sub-thread, but I want to say here that Eric's
response clearly indicates that point 5. quoted above is *not* the actual
issue. The actual issue is
             5. Modify IESG-internal processes to make reasons for the IESG's
                blocking of a document visible to the public.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 May 2003 16:41:13 +0200

Dave Crocker wrote:
...
> The idea is to model the process after the ISOC portion of the Nomcom

Bad idea. That works essentially as a process check, since most ISOC Board
members don't know most of the IAB nominees. We need more than a process
check in this case, imho.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 May 2003 11:25:34 -0400

--On Friday, 16 May, 2003 17:13 -0700 Dave Crocker 
<[email-masked]> wrote:

> At base, the reasons do not matter.  It simply is not
> reasonable for any one (or two) people to weild that much
> power.  A group based on Rough Consensus should rely on those
> having a point of view being able to recruit others to support
> that view.  If they cannot succeed in their recruitment
> effort, there is something wrong with their view.
>
> Expertise is compelling, when the expertise is real. Only
> deities warrant individual veto authority in this community.

Dave, I agree with all of this, except that there is a conflict 
of roles (if not of interest) built into the process.  I believe 
that we either need to eliminate that conflict (which would, I 
suspect, require some really radical changes) or that we need to 
be very careful about how far we go in the direction you (and 
the document) are suggesting.

Explanation...

We expect an AD to take a the lead role in creating a WG, to 
appoint its leadership, and to maintain oversight management on 
its work.  We also expect that AD to carry the WG's work into 
the IESG and to strongly advocate the WG's results.  If I 
remember correctly, current IESG procedures won't permit a WG 
document to advance unless the AD responsible for that WG is on 
record as favoring it.  The portion of the community who believe 
that a WG should be able to determine what becomes a standard 
and whether issues raised from other perspectives are important 
enough to justify revisions would presumably consider a 
responsible AD to be derelict in his or her duties if there 
wasn't strong advocacy for the WG position.

That sets up a poor environment for prohibiting the type of 
substantive "even if this is fine from the perspective of X, it 
will wreck global routing and those issues need to be at least 
addressed" stopping rules that Brian is advocating.

I think that there are several other, less risky, solutions for 
the problem you are concerned about.   The first, and most 
important, is much more openness about what is happening -- any 
action within the IESG that is likely to produce a long delay 
should be required to be accompanied by a public explanation 
(see my suggestion on the Poised list about IESG Charter 
language).  The IESG should be able to approve more time for 
processing a document --or convincing each other-- when 
specific, but not-yet-convincing, objections are raised from one 
area about a proposal from another, but that approval should be 
accompanied by a public statement about what is going on and 
what the objection-placeholder text is.

Finally, procedurally, I don't think we have a mechanism for a 
veto today so there really shouldn't be a discussion about ways 
to eliminate that mechanism.  What we have instead are 
circumstances in which there is a potential for a de facto veto 
when procedures are not followed and a tolerance for that 
behavior based partially on an IESG dynamic of "we have to work 
together tomorrow regardless of what happens to this document, 
and therefore must defer when one of us feels strongly".   That 
dynamic is natural, and we shouldn't try to change it 
significantly -- but it can also be used to cover up, or even 
encourage, well-meaning but pathological behavior... and we need 
to explore ways to stop that set of cycles.

     john

---

From: Keith Moore <[email-masked]>
Date: Sun, 18 May 2003 12:36:07 -0400

On Sunday, May 18, 2003, at 11:25  AM, John C Klensin wrote:

> Finally, procedurally, I don't think we have a mechanism for a veto 
> today so there really shouldn't be a discussion about ways to 
> eliminate that mechanism.  What we have instead are circumstances in 
> which there is a potential for a de facto veto when procedures are not 
> followed and a tolerance for that behavior based partially on an IESG 
> dynamic of "we have to work together tomorrow regardless of what 
> happens to this document, and therefore must defer when one of us 
> feels strongly".   That dynamic is natural, and we shouldn't try to 
> change it significantly -- but it can also be used to cover up, or 
> even encourage, well-meaning but pathological behavior... and we need 

this dynamic works both ways - sometimes it causes a document to be 
delayed without what looks like a good reason, but in my experience far 
more often it causes a bad document to get approved despite good 
reasons to not approve it.  both of these should IMHO be viewed as 
undesirable.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 May 2003 09:56:30 -0400

> assume that it is *not* done for spurious reasons.

I have to say something here, as this issue keeps being brought
up. Reading this list, one could easily get the idea that the ADs love
to block documents, usually don't have a good reason for doing so (and
thus fall back to procedural tricks), and that the ADs actually are
hostile towards each others with tit-for-tat happening if one AD
blocks a document belonging to someone else.

That is not the IESG I know or that I would want to be a part of.

It is my assumption and belief that when an AD puts in a discuss,
other ADs _do_ support that. [Note: this is a topic I will bring up
explicitely within the IESG, in case I'm totally clueless about how
others really feel here.] When this isn't the case, the shepherding AD
will object, argue the issue isn't worth pushing back on, or provide
other context for why raising the issue doesn't make sense. Then there
is discussion and give and take. Sometimes the objecting AD will
withdraw their discuss, sometimes not. In fact, it is quite common for
other ADs to agree, but to explicitely NOT put in a formal discuss,
trusting the one AD to deal with the issue satisfactoraly and not
wanting to add more process overhead (i.e., another AD that must clear
their discuss). One of the common "votes" that happens during the
telechats is "no further objection" which formally means "no
objection" but in practice means "I agree with others, but don't have
more to add and don't need to be in the process loop to see that the
document gets fixed".

Forcing the IESG to have "consensus" or "unanimity" (those words have
been used on this thread) on all discusses procedurally seems like a
high overhead approach for dealing with a particular problem.

I'd actually like to better understand how much of a REAL problem it
is that individual ADs are impropropely blocking documents with the
"single AD veto". There are many comments that imply it happens "all
the time" and that "everyone has examples". But I wonder sometimes if
we are all thinking of the same document from 3 years ago. We can't
fix what happened 3 years ago, but we can fix things that are broken
_today_.

> should convince the rest of the IESG that the document is a bad

This in effect is happening AFAIK. The IESG does support the security
ADs when this happens.

> document (or at least stop it until the problem is fixed).

I think it would be inefficient at best to force this level of process
onto discusses.

> allows documents to be blocked by one or two IESG members without the 

In theory, yes. But in practice? It would be instructive for the IESG
to ask itself where this has happened, and I will bring up the
topic. My sense is very rarely, but I could be wrong.

But at least some on the community assume this happens often enough
that we need more procedure to prevent it from happening. Concrete
examples would be useful to provide context.

> The current procedure assumes that one or two IESG members must be
> able to block a document because the rest of the IESG is so stupid
> or ignorant that they cannot be convinced that the document is a bad
> idea, even if one or two experts on the IESG know that it is.

That is one way to look at it, but it would be inconsistent with my
understanding of things. The way I see it is is that when someone
raises an issue, and the IESG supports the objection, a one-person
discuss is the staightforward way to deal with the problem. Should
responses to every discuss get reviewed by the entire IESG? There is a
scaling issue here...

> If that were actually the case, it points to a much worse state of
> affairs, where IESG members don't trust each other to do the right
> thing.

This is not the case, from what I know.

Note: This note might come across as sounding like I don't think there
are any problems that need fixing. There are. But I am unconvinced
that the "one AD veto" is one of the real problems. Given that at
least some in the community appear to think it is a problem, I'd
really appreciate some concrete examples. My suspicion is that if we
look at specifics, the reality may be quite a bit different than the
appearance.

Thomas

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 19 May 2003 09:21:20 -0500

Thomas has good instincts for research design.

I'm remembering from the book "Flaws and Fallacies in Statistical Thinking"
about the estimates of the rat population in New York during the 1970s,
when someone finally figured out that if a researcher saw a rat on the third
floor of a slum, and a rat on the seventh floor, and a rat on the ninth
floor,
they could all be the same rat...

Spencer

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
To: "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 19, 2003 8:56 AM
Subject: Re: Document Blocking (Was:

> we are all thinking of the same document from 3 years ago.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 20 May 2003 13:39:11 -0700

On 5/19/03 at 9:56 AM -0400, Thomas Narten wrote:

>I have to say something here, as this issue keeps being brought up. 
>Reading this list, one could easily get the idea that the ADs love 
>to block documents, usually don't have a good reason for doing so 
>(and thus fall back to procedural tricks), and that the ADs actually 
>are hostile towards each others with tit-for-tat happening if one AD 

On the first two points (that ADs "love to block documents" and that 
they "usually don't have a good reason"), I think that you are simply 
caricaturing what's been said. I think everyone who has commented on 
this believes that ADs put discusses on documents almost always with 
all good intentions, and I think they believe that they usually do it 
with good reasons. For the most part, people are complaining about 
the (relatively few) instances where good reasons haven't been given 
or haven't been communicated well enough to the WG.

However, on the last point, that ADs are hostile towards each other, 
I think you will see in the archive of this list several examples of 
former ADs saying exactly that. We have had people say that people 
will put trivial discusses on documents because putting a substantive 
discuss would get retaliation, that one or two ADs must have the 
power to stop a document without the other ADs signing on, etc. This 
isn't coming from folks who've never been on the IESG; it's coming 
from your former colleagues. Perhaps the current IESG doesn't have 
these problems; that would be really good.

But all that aside, what I think you are seeing overall is:

- Past history where it *appears* as if documents have been 
blackholed by a single AD during IESG review (whether or not it has 
actually happened);

- Not enough experience with the document tracker to dissuade that feeling;

- A procedure that the IESG is still using that encourages that feeling

The first point I think I don't need to explain. That's the 
perception, whether true or not.

The second point cannot be addressed by saying "let's see if the 
document tracker solves the problem." The distrust of the IESG 
already exists. The document tracker will, at times, indicate a 
discuss by one AD, yes or no objection by everyone else, and an 
explanation of the discuss that will not be satisfactory to a reader.

The third point is the key one: The current procedure of the IESG 
*reinforces the perception* that one AD can block a document without 
the buy-in of the rest of the IESG, because on paper the rest of the 
IESG never buys in. And with the current perception that an AD might 
(however rarely) vote discuss for spurious reasons, the current 
policy makes for a bad feeling. For example, below you say:

>One of the common "votes" that happens during the telechats is "no 
>further objection" which formally means "no objection" but in 
>practice means "I agree with others, but don't have more to add and 
>don't need to be in the process loop to see that the document gets 
>fixed".
>
>Forcing the IESG to have "consensus" or "unanimity" (those words 
>have been used on this thread) on all discusses procedurally seems 
>like a high overhead approach for dealing with a particular problem.

So maybe the solution here is to formalize "no further objection". 
That is, if there is a discuss that you agree with, you can vote 
"concur with discuss". That's the equivalent of voting "no objection" 
but noting that you actually are on board with the discuss vote. If 
the IESG comes out with one discuss, one yes, and the rest "concur 
with discuss", I'd consider that consensus to discuss. However, if 
you get one discuss, one yes, and the rest "no objection", that's not 
consensus to discuss. That seems to me no more overhead, but now 
you've got the ability to make an IESG rule that says, "If there's 
only one discuss vote and no concur votes, the document passes." And 
from the outside, you'd be able to see what has happened. With the 
current process, there's no way to tell whether there's real 
consensus or it's one of those one-in-a-million "one AD is 
unreasonably holding things up" instances.

>the time"

I have heard no comments to the effect that "it happens all the 
time". Again, I think this is a caricature on your part.

>and that "everyone has examples".

I can think of a few, though only one on which I was smack in the 
middle of the fray.

>But I wonder sometimes if we are all thinking of the same document 
>from 3 years ago. We can't
>fix what happened 3 years ago, but we can fix things that are broken _today_.

Even assuming it is extremely rare, leaving a procedure in place that 
allows it to happen in the future is a problem that needs fixing. 
Perhaps the current IESG is a wonderful set of folks who would never 
let such a thing happen. That doesn't mean we should leave the 
procedure as-is.

>This in effect is happening AFAIK. The IESG does support the 
>security ADs when this happens.

It needs to be done publicly.

>>The problem with the current process (as I understand it) is that 
>>it allows documents to be blocked by one or two IESG members 
>>without the consensus of the group.
>
>In theory, yes. But in practice? It would be instructive for the 
>IESG to ask itself where this has happened, and I will bring up the 

Even "very rarely" is enough to change the procedure.

>Note: This note might come across as sounding like I don't think 
>there are any problems that need fixing. There are. But I am 
>unconvinced that the "one AD veto" is one of the real problems. 
>Given that at least some in the community appear to think it is a 
>problem, I'd really appreciate some concrete examples. My suspicion 
>is that if we look at specifics, the reality may be quite a bit 
>different than the appearance.

I've got to tell you that I'm not terribly sanguine about the results 
of you asking for "concrete examples" or your "bringing up explicitly 
within the IESG" the topic of whether other members of the IESG think 
there are examples of discuss votes that are not supported by the 
rest of the ADs. We've already been told that past ADs have held 
their tongues so that there wouldn't be retaliation within the IESG, 
and I for one don't feel like pointing fingers in public about the 
situations I've encountered, if only for lack of good taste and for 
the hurt feelings I suspect it might cause. I can't imagine that 
you're going to get a bunch of very open responses to your query.

Look, we've got a procedure currently that can't publicly distinguish 
between single discuss votes which are supported by the rest of the 
IESG and those that aren't. I think the perceptual and trust problems 
it causes are obvious. I think I have outlined a very low-overhead 
solution to the problem (whether or not we choose that particular 
solution). What's the issue here?

pr

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 May 2003 14:52:56 -0700

Thomas,

>>"single AD veto". There are many comments that imply it happens "all 

PR> I have heard no comments to the effect that "it happens all the 
PR> time". Again, I think this is a caricature on your part.

You have done us the service of offering your candid views about the
current discussion. He has shared his sense of the realities inside the
IESG and his reactions to the public discussion. For these, I am
appreciative.

The problem with being candid is that it invites others to be candid. So
I hope you won't mind, Thomas, if I return the favor.

My perception of the Yokohama plenary was of two, very pronounced
phenomena.

One was of considerable community discontent about the current operation
of the IETF and notably of the IESG.

(I'm *always* disgruntled, my own criticisms don't matter much. But when
I see quite a few other IETF folks disgruntled, it's another matter.)

The other phenomenon of note was a frankly defensive reaction from most
of the IESG.

Please forgive me noting that Pete's assessment of your note matches
mine: You seem to be reacting to things that have neither been said nor
implied, and I am pretty sure they are not felt.

Folks are generally trying to be very careful in what *is* said.

Folks are generally trying very hard to avoid making personal
criticisms.

Folks are generally trying very hard to make constructive suggestions,
including suggesting compromise paths.

(A reminder: Most of the current problems have a long history, beyond
any particular individuals. Individuals do the actions, but the problems
appear to be structural. However, individuals who have been
participating in the problem have an inherent conflict of interest, if
they are in charge of the change process.)

When someone is part of group that is the focus of community
disgruntlement, it is easy to get defensive, to misinterpret what is
said, and generally to entrench into a siege mentality.

Please don't.

The most notable thing about the Kobe "revolution" is how little was
actually changed.

We need to make changes now, but we need to make as few as possible.
This is only possible if the effort to make change is pursued honestly,
as well as constructively.

Caricaturizing core concerns, ignoring core concerns, or trivializing
the difficulties of the change effort will not achieve the results the
community wants.

The effort is not about nit-picking adherence to process details. It is
about problems with productivity and utility.

d/

---

From: Thomas Narten <[email-masked]>
Date: Fri, 23 May 2003 09:45:13 -0400

Going back through this thread to understand better...

> I don't see this as a problem at all.

I see a problem with Keith's statement here. It can be read to imply
that Keith thinks it's fine for an AD to block a document without
there being any other support for the action by the rest of the
IESG. I disagree with this view, and I doubt anyone else on the IESG
would agree with this view. I hope that I'm misreading Keith's intent
here.

What is the case is that there is an assumption that when an AD raises
a discuss, there is validity behind it. Whenever there is a discuss on
a document, the issue needs to be articulated so that the rest of the
IESG and the IETF community as a whole can be made to understand what
the issue is. If that can't be done, we have a fairly basic
problem. Our internal processes call for all discuss's to be written
up. Once one has words, one can discuss them and agree/disagree, claim
lack of understanding, etc. But the notion that an AD can (or does)
just put in a vague/bogus discuss and no one ever objects to it is
broken shouldn't be happenning. If it is happening, that's broken, and
needs to be fixed. Again, here, having specific examples to point to
would help. (I'll grant some people are saying there is an appearance
of this happening, and our process rules don't prevent it from being
possible, and therefore this aspect of our processes needs to be
changed.)

Now, you can read my words above differently depending on whether you
think the cup is half empty or half full. I.e., maybe the IESG just
defers to others and doesn't even check whether a particular discuss
has any validity. Or, that all IESG members review *every* discuss in
detail and agree with it. The reality is somewhere in between. For
example, when the security ADs raise an issue, I do review them, and I
have found that in most cases I agree with them. So I don't feel like
I need to explicitely check every thing they say -- they have a track
record and I have found them to be reasonable.

> Many of the issues that hold up document publication are not easily
> understood without expertise in that particular area.

But it is also an absolute requirement that a real issue must be
explainable to the community. So suggesting that "the issue is too
hard to understand by mere mortals and therefore an AD must have
blocking power" is unnacceptable.  IMO, the "one discuss blocks" rule
isn't designed to allow the above, but is intended to allow any AD to
raise an issue that can't simply be dismissed, say, because only one
AD voted that way. 

> Also, IESG does not "block" documents, it explains what is wrong
> with them and sends them back to the working group.  It's simply
> infeasible to expect all of IESG to reach consensus on every issue
> that requires a change to a document. For a deep technical issue,
> there *might* be four people on IESG who really have enough
> appreciation for that issue to express an informed opinion - and two
> of those might have to stretch to understand it.

I would couch this differently. Every AD must be capable of being able
to understand an issue being raised. This is part of our need for
breadth. But it may take time -- or even a significant amount of time
-- to do that in cases where the issue is subtle, etc. Requiring that
all ADs understand everything to this level is simply not
scalable. But the other extreme of one AD "understanding" an issue,
but no one else (either in the WG or on the IESG) is also broken.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 May 2003 10:29:33 -0400

> there being any other support for the action by the rest of the

Not quite - but I should clarify that part of the reason I don't see this as a
problem is that I don't view a Discuss as "blocking a document".

IMHO IESG does not have enough power to block documents that are truly 
bad - the presumption is that IESG must tell the WG how to fix the document,
and sometimes that is simply infeasible.  And IESG wastes a lot of its energy
trying to reconcile problems with documents that should simply be discarded.
But if IESG were given the power to actually block documents, I agree it
should take a significant plurality of IESG to do so.

Note that even under our current processes and procedures if an AD were to
repeatedly vote Discuss for no good reason in order to block a document, there
are several avenues available to fix the problem.  The IESG has a procedure
that would require at least one other AD's support in order to continue
blocking - which seems unlikely if there's no good reason.  Failing that,
there is always the ability to appeal to IAB and/or recall the AD.  

But I don't really think this is a problem in reality, as opposed to
perception.  Generally, as Thomas says, when an AD votes Discuss there is
enough understanding of the issue among IESG for other ADs to support and/or
clarify the objection that is being raised.   But even if only one AD supports
the Discuss, I think it's reasonable to allow a single AD to raise the issue,
and send the document back to the WG, with the WG expected to respond in good
faith - either to fix the problem or refute the problem.  

And if they can't resolve their differences, I'd probably suggest that the AD
write up a "dissenting opinion" RFC - doing his best job to explain the
problem - and publish that simultaneously with the WG's RFC.  I've seen more
recalcitrant WGs than stubbornly incorrect ADs, so I don't presume that the WG
is more right than the AD - actually I think the AD is more likely to be
correct about the objections he/she is raising even when he/she has a hard
time explaining them to others.  But perhaps more importantly, I've seen each
of ADs and WG charirs and document authors refuse to cooperate or compromise
or even try to understand each other when they thought they could get their
way by exploiting the rules.  So I think we should try to avoid rules that
automatically permit either an AD or a WG to force his/her/its preferred
outcome.