Subject: Re: Re: Voting (again)

From: John Loughney <[email-masked]>
Date: Thu, 28 Apr 2005 9:24:02 +0300

Brian,

> > However, I'm not entirely convinced that the unrestricted veto really 
> > exists.  Before I can think about solutions to this problem, I need to 
> > reexamine the process and convince myself that it really is a problem.
> 
> A DISCUSS isn't a veto. I've seen numerous cases even in my short experience
> as an AD of DISCUSSes leading to, er, discussion and a new draft (or edits)
> that solves enough of the issues that the AD removes their DISCUSS. I don't
> think I've seen any new DISCUSSes that I would categorize as frivolous or
> individualistic.
> 
> What we do have is a long tail on the distribution of the dwell time of
> DISCUSSes. I haven't had a chance to analyze the root causes of the very
> old DISCUSSes.

Just a word from the peanut-gallery here.  As a recipient of DISCUSSes, I sometimes had trouble understanding what the DISCUSS was about.  Sometimes a DISCUSS is a request for a discussion on a point, because something was not clear.  Sometimes it is a warning, like "Are you really sure you mean this?  You should reconsider it or at least come up with some proof that it is a good idea." And sometimes, it is an outright veto, meaning "I will not let this document pass until this is fixed, even if the WG had fully examined this issue and purposefully chosen the solution."  Often, it is hard to understand what is meant by a DISCUSS, and due to IESG overload, it is not always possible to engage in a meaningful discussion of a DISCUSS.  I will note that recently things seem to be headed (slowly) in a more possitive direction, but ...

So, as a recipient of a DISCUSS, I've learned the hard way that the easiest way to resolve a DISCUSS is to ask the IESG member for the exact text they want added and be done with it.  I don't think this is the correct way to do things, but after working on a document for x number of years and trying to push it through the last mile, often document editors just want to get it done.

John

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 14:12:36 -0400

> So, as a recipient of a DISCUSS, I've learned the hard way that the
> easiest way to resolve a DISCUSS is to ask the IESG member for the
> exact text they want added and be done with it.  I don't think this is
> the correct way to do things, but after working on a document for x
> number of years and trying to push it through the last mile, often
> document editors just want to get it done.

When, as sometimes happens, everybody is happy with the suggested text,
that process works well.  We get closure on the issue in a short time.

The problem is when authors or WGs demand that the IESG provide
text that resolves a thorny technical problem.  Sometimes the IESG
needs to say "no, you can't do X, and it's your job - not ours - to 
find a different way to solve that problem".  IESG is in a much better
position to find technical flaws than to craft delicate compromises 
between competing interests.  And sometimes it is counterproductive
for the AD to suggest a compromise even when he has an idea for
something that might work -as WG participants will fight an idea from
an AD more than they would fight the same idea from one of their own.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Apr 2005 14:47:38 -0400

Keith,

There is another case, and I think it is the one to which John
was referring.

	1.  The WG comes up with some text, believing that text
	is accurate and appropriate.
	
	2.  An AD lodges a "discuss", demanding a change in the
	text and supplies the desired target text.
	
	3.  The author and/or WG conclude that the suggested
	change is unnecessary and actually makes the document
	worse, but does not change things sufficiently to be
	worth a long, protracted, and certainly unpleasant
	battle.   
	
	4.  Based on (3), the author and/or WG say "ok, whatever
	you like, make the change".

I think that, if we confuse this with "everybody is happy with
the
suggested text", or "the process working well", we are in bad
trouble.   

One of our more interesting difficulties is that it is really
hard to tell this case from "AD suggests a change, everyone
agrees that it is a clear improvement".   Document Editors and
WG Chairs usually know the difference, but even the AD may not
actually know, since the answer "ok,..., make the change" may be
the same in both this case and the "everyone is happy" one.
Where it does lead is to simmering resentments, and even doubts
about whether the IETF is the right place to get work done.  If
an AD regularly demands this type of change (remember, I'm not
talking about major technical omissions or disagreements here),
those resentments and doubts will tend to get cumulatively worse
the longer the AD remains on the IESG and the more that the IESG
members tolerate demands for that sort of change from their
colleagues.

And, if it isn't clear, I believe that an "I'm going to lodge
and hold a DISCUSS until you change that" position is a demand,
whether or not it is appropriate in a particular situation.

     john

--On Thursday, 28 April, 2005 14:12 -0400 Keith Moore
<[email-masked]> wrote:

>> So, as a recipient of a DISCUSS, I've learned the hard way
>> that the easiest way to resolve a DISCUSS is to ask the IESG
>> member for the exact text they want added and be done with
>> it.  I don't think this is the correct way to do things, but
>> after working on a document for x number of years and trying
>> to push it through the last mile, often document editors just
>> want to get it done.
> 
> When, as sometimes happens, everybody is happy with the
> suggested text, that process works well.  We get closure on
> the issue in a short time.
> 
> text that resolves a thorny technical problem.  Sometimes the
> IESG needs to say "no, you can't do X, and it's your job - not
> ours - to  find a different way to solve that problem".  IESG
> is in a much better position to find technical flaws than to
> craft delicate compromises  between competing interests.  And
> sometimes it is counterproductive for the AD to suggest a
> compromise even when he has an idea for something that might
> work -as WG participants will fight an idea from an AD more
> than they would fight the same idea from one of their own.
> 
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 15:00:45 -0400

John,

I agree - the situation you describe does occur.  However such cases
include "major technical omissions and disagreements" in addition
to minor technical differences.   Actually I suspect that this boils down
to a disagreement between the AD and the author/chair about whether
the technical omission or disagreement is a major one.  Sometimes 
the AD is right, sometimes the author or chair is.  

I think the ADs should continue to be able to raise such issues, but
I also think it might be helpful to have better way of resolving such
disputes than either "let the AD win" or "let's sit on this until the IESG
holds its nose and passes it".

Keith

> the suggested text", or "the process working well", we are in bad trouble.   
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2005 14:45:11 -0700

Keith,

The case John outlines is the one I am concerned about as well.

> the AD is right, sometimes the author or chair is.  

And, FWIW, when the AD suggests specific text changes, it's often enough
the desire of that AD rather than based on feedback from some other WG.
I.e., this is the point where the AD is asking for changes based on what
I consider individual input.

> holds its nose and passes it".

Sure - and sometimes other ADs get involved, and it boils down to "what
can you add/change to appease the other AD" rather than "what is
sensible to add".

Joe

> This message was passed through [email-masked], which is a sublist of [email-masked]. Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([email-masked]).

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 28 Apr 2005 15:12:10 -0700

Hi -

> From: "Joe Touch" <[email-masked]>
> To: "Keith Moore" <[email-masked]>
> Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 28, 2005 2:45 PM
> Subject: Re: text suggested by ADs
...
> can you add/change to appease the other AD" rather than "what is
...

Though this is an interesting discussion, it is so far removed from my own
experience as a document editor and WG chair that I have to wonder whether
we've been working with the same IESG.

Randy

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Apr 2005 18:19:47 -0400

And I've had much *worse* experiences with the IESG requiring changes to
documents ... including receiving suggested text (after many months of
the document disappearing into a black hole) that actually *reversed*
text inserted earlier at the request of an AD.

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 18:28:48 -0400

> [...]
> And, FWIW, when the AD suggests specific text changes, it's often 
> enough the desire of that AD rather than based on feedback from some 
> other WG.

I don't see anything wrong with that.  It's the ADs' job to push back 
on documents with technical flaws.  They're supposed to use their 
judgments as technical experts, not just be conduits of information 
supplied by others.

>> disputes than either "let the AD win" or "let's sit on this until the 
>> IESG holds its nose and passes it".
>
> Sure - and sometimes other ADs get involved, and it boils down to 
> "what can you add/change to appease the other AD" rather than "what is 
> sensible to add".

It's as likely to boil down to "how do we get this WG to realize that 
there really is a serious technical problem with what they've created?" 
  From a process viewpoint the two cases (one where a clueless AD is 
pushing back against a clueful WG, and another where a clueless WG is 
being pushed back on by a clueful AD) are equivalent, and it's 
difficult to change the process in a way that solves one of those 
problems without making the other one worse.

(and yes, both of these are extreme (though not rare) cases - it can 
also be a conflict between different kinds of cluefulness, where there 
are legitimate concerns on both sides and it's hard for any individual 
to see enough of the picture on short notice to understand what kind of 
compromise would be reasonable.)

Keith

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2005 15:39:36 -0700

Keith Moore wrote:
> I don't see anything wrong with that.  It's the ADs' job to push back on
> documents with technical flaws.  They're supposed to use their judgments
> as technical experts, not just be conduits of information supplied by
> others.

The process of AD review in 2026 specifies a few distinct things:
	- check for end-runs around WGs
	- check for inter-WG consistency
	- check for clarity commensurate with the doc level
	- check for tech quality commensurate with the doc level

The IAB is there to check for consistency with the the Internet, of course.

There's no point in the AD review at which their _input_ to the document
is solicited by the process in 2026; IMO, that's supposed to have
happened beforehand (though it often does not it is not a good excuse
for late input).

> there really is a serious technical problem with what they've created?"

That is a different issue when it occurs.

> being pushed back on by a clueful AD) are equivalent, and it's difficult
> to change the process in a way that solves one of those problems without
> making the other one worse.

They're only equivalent if another AD can't tell the difference between
the two. IMO, they could, were they involved in the process.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Apr 2005 18:55:05 -0400

Comments in line...

- Ralph

> judgments as technical experts, not just be conduits of information 

I disagree that the ADs are necessarily that much more technically
astute than the rest of us.  I would actually feel more comfortable with
ADs providing their technical judgment with the rest of us, through the
same mechanism: WG or IETF last call.  And that technical judgment
should be expressed openly, in an archived WG mailing list, where
everyone's technical input can be reviewed and everyone who provides
technical input can be held accountable.

If whoever wants to provide technical input to make a significant change
in a specification, be it an AD or a WG chair or ..., can't make a
sufficiently convincing case, in an open WG mailing list, that there at
least might not be "rough consensus" for a specification, then I would
say the specification doesn't need the change.

> problems without making the other one worse.

OK, so if the AD or the external reviewer or whoever needs to push back,
let's do it in the open, on a mailing list, during a last call...

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Apr 2005 16:56:46 -0700

> judgments as technical experts, not just be conduits of information 

That's fine when that is what they do. What you're hearing here is that 
it is not uniformly so.

Let me give you a specific case. I have a document which is at this 
instant in the RFC Editor's queue. It was supposed to describe the 
outlines of a procedure for renumbering a network without a flag day - 
starting with a network using prefix A and ending with a network using 
prefix B, what steps does one go through to transition prefixes while 
providing all services all the time? The key issue is that one working 
group had in essence said "there is a protocol designed; this is a done 
deal" while the operations community was shaking its head in wonder at 
the naivety of that position. I wanted to get the wisdom of both groups 
on paper in one place and make specific actionable recommendations to 
operational staff planning to do such a thing.

The IESG gave us a number of comments, some of which we dropped 
verbatim into the draft without much concern, and at least one of which 
sent the authors back into a fairly serious discussion amongst 
ourselves and resulted in a block of entirely new text. This is as you 
describe and how it should be.

But one comment from the IESG was that they wanted a specific paragraph 
added that said (in essence) "ULAs might be useful to help in 
renumbering", presumably by making one not need to renumber. As an 
aside, I don't see the real difference between a ULA and a site-local 
address - I think the RFC 3879 issues apply to both. But regardless, I 
don't see a procedural difference between changing from a ULA to some 
other kind of prefix or from some other kind of prefix to a ULA, and 
the statement that ULAs might be a third prefix that could be used by 
users of a site while other prefixes are being renumbered is at best 
conjectural and at worst a flat numbering system. The IESG statement 
did not address a technical flaw, was not specific, and was not 
actionable by a network manager who had decided to renumber his network 
and was looking for a procedure for doing so. And in my very private 
and most humble opinion, it was horse pucky. The AD simply wanted a 
reference to ULAs in the draft.

The good news is that I was able to argue him out of it. I asked him 
for something specific and actionable, in the form of a statement of 
exactly what way the renumbering procedure was different when 
renumbering from or to a ULA as against some other prefix, and told him 
that if he provided specific actionable text I would include it. He 
dropped the discussion.

The issue here is that ADs are human, with all the flaws the rest of us 
have. Yes, they try pretty hard to make the documents that come out of 
working groups "right", and they have to work pretty hard to make that 
happen. They also have their hobby-horses, and make comments during 
IESG review that should have been made "AD hat off" on the mailing 
list.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 20:27:57 -0400

> That's fine when that is what they do. What you're hearing here is 
> that it is not uniformly so.

Yes, I understand that, and many of us can cite specific cases where 
the power was inappropriately used.  But from a _process_ 
point-of-view, I don't see how to avoid the potential for misuse and 
still get the review that seems essential to keeping the quality level 
up.  We try to arrange that there are alternatives to having good 
proposals killed or stalled by capricious ADs - like appeals, the 
process that IESG now has to bypass a single member's DISCUSS, the 
independent submission process via the RFC Editor, etc.  And maybe we 
need more alternatives.  But I don't see how to get rid of the review.

> The issue here is that ADs are human, with all the flaws the rest of 
> us have. Yes, they try pretty hard to make the documents that come out 
> of working groups "right", and they have to work pretty hard to make 
> that happen. They also have their hobby-horses, and make comments 
> during IESG review that should have been made "AD hat off" on the 
> mailing list.

yes, yes, and yes.

Keith

p.s. FWIW & IMnsHO, ULAs, while useful, are at best only a small part 
of a satisfactory solution for keeping addresses stable across 
renumbering, even for applications that entirely run on local networks. 
  Even to explain why this is the case is not simple, but briefly: a) 
There are multiple reasons for a site to use ULAs (some more defensible 
than others) and it's not reasonable for an application to assume that 
a ULA is more appropriate for any particular purpose than any other 
prefix.  Different applications will have different requirements for 
addressing (some need stable addresses, others need privacy, others 
need maximum efficiency/throughput or minimum delay, others need 
addresses that are reachable by all participating hosts) and these 
requirements can even change depending on the set of hosts 
participating in an application. A default set of address selection 
rules (as we are already seeing) will not work well.  It appears 
possible to design a protocol that allows the network to tell hosts 
when ULA prefixes are equivalent to, but more stable than, other 
prefixes advertised on the network (and I wrote an I-D describing such 
a protocol), and it's possible to design an API extension which allows 
apps to say "please use stable addresses on this connection when 
available".  This would allow ULA-aware apps to make use of ULAs when 
they are available and when the network operator believes ULAs are more 
stable than PA or other prefixes.  But that requires a lot more than 
just the existence of ULAs to be workable, and even then, they only 
solve the stability problem for what is arguably a corner case.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Apr 2005 20:39:37 -0400

> as technical experts, not just be conduits of information supplied by

Exactly right.  We select AD's based on their technical expertise, and 
expect them to use that expertise in reviewing documents that come their 
way.  This is one of the reasons why it's hard to lighten AD load by 
getting other people to do reviews -- the expectation is that AD's will 
actually review the documents they approve, at least to some extent.

I think that talk about "expanding the IESG" is approaching the problem 
along the wrong tack.  Rather than making the management structure more 
top-heavy, why not introduce an additional layer?  Specifically, I'm 
thinking of a model in which AD's would appoint some number of "deputy 
AD's" who would review and comment on (assigned) documents in the AD's 
place.  This is somewhat more formal than the current directorate model, in 
which directorate members may assist with reviews but the AD still has to 
personally review every document (or perhaps, 50% of all documents, 
depending on how work is divided in areas with two AD's).

This is how large organizations scale management tasks -- they introduce 
layers of indirection and abstraction.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Apr 2005 20:53:24 -0400

> the two. IMO, they could, were they involved in the process.

If I may read between the lines here, it sounds like you're suggesting some 
sort of reality-check process that is more lightweight than a full appeal. 
Informally, we have that -- if one AD is giving me a hard time for a dumb 
reason, I can ask another AD to try to talk some sense into them.  But that 
only works if the participant has a good relationship with another AD, and 
while you hope that's true for WG chairs, that might not always be good 
enough.

So maybe your concern would be addressed by some sort of "discuss override" 
mechanism, by which the IESG could actively decide that a discuss is 
inappropriate and disregard it.  Such a mechanism would have to be invoked 
explicitly, and would perhaps involve a consensus call by the IESG chair...

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Apr 2005 20:56:30 -0400

> So maybe your concern would be addressed by some sort of "discuss 
> override" mechanism, by which the IESG could actively decide that a 
> discuss is inappropriate and disregard it.  Such a mechanism would 
> have to be invoked explicitly, and would perhaps involve a consensus 
> call by the IESG chair...

I believe such a mechanism already exists.  At least, we established 
such a mechanism while I was on IESG.

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Apr 2005 02:01:37 -0400

> astute than the rest of us.

1. ADs usually _are_ more technically astute than the average IETF 
participant (perhaps not you, but the average participant), because ADs 
are selected for their expertise while IETF participants are 
self-selecting.  (Maybe some are selected by their employers, but I 
don't think it's generally the practice of most employers to send their 
best technical people to standards committees. My impression is that 
many employers - not all by any means - would rather send people who 
are expendable, and/or who will represent the company's official 
position rather than their own best judgment.)

2. ADs also tend to have a broader perspective than the average IETF 
participant, because ADs are exposed to everything that IETF does while 
most participants' activity is confined to a narrow topic area.  That's 
not to say that a broad perspective is inherently less valuable than a 
narrow perspective - they're both valuable, but for different reasons.

But both of those are less relevant than the fact that it's IESG's 
_job_ to make judgments about the quality of specifications and 
protocols, and that this is a _necessary_ job.  WGs are too frequently 
insular and too frequently want to make unacceptable compromises - 
somebody has to serve as a check against that.  Somebody has to resolve 
conflicts between competing concerns.  Somebody has to make sure that 
the specifications are complete.  etc.

> I would actually feel more comfortable with ADs providing their 
> technical judgment with the rest of us, through the same mechanism: WG 
> or IETF last call.  And that technical judgment should be expressed 
> openly, in an archived WG mailing list, where everyone's technical 
> input can be reviewed and everyone who provides technical input can be 
> held accountable.

I have mixed feelings about this.  I believe that often it is the case 
that ADs providing technical input through the WG mailing list, and 
participating in discussions on that list, is the most effective way to 
resolve the differences.  On the other hand, mailing lists that are 
focused on a narrow topic are not good places for resolution of issues 
that involve concerns outside the WG's scope - the WG tends to dismiss 
those concerns out-of-hand even though they are valid.  Also it is 
impractical for every AD to participate in lengthy discussions with 
every WG whose work is commented on - where each message to a WG from 
an AD could elicit several responses, each expecting a response from 
the AD who is reviewing dozens of documents every week.

I can imagine a process that encourages the responsible AD and document 
author (and/or chair) to go over the DISCUSS comments together and to 
identify those which are noncontroversial and those which need further 
discussion.  The proposed resolution of the noncontroversial issues and 
the list of controversial issues should certainly be presented to the 
WG, and perhaps the WG should be encouraged to identify potential 
compromises on the controversial issues.  If the WG comes up with 
reasonable compromises, that's great.  But in general I don't think we 
can afford to insist that such issues be resolved on the WG mailing 
list in an discussion with the ADs.  Just like a design team within a 
WG might need to work out compromises within itself (to be ratified by 
the larger group), so  might the chair, authors, and ADs need to work 
out compromises at that level.

I don't think that it's feasible to insist that all issues raised by 
ADs be raised in Last Call, because ADs also have to make judgments 
about the importance and validity of Last Call comments, and they may 
even have to reconcile differences between conflicting Last Call 
comments.  What this means is that there are always going to be some 
issues raised after Last Call - and it's not clear that having two 
separate AD review phases in the process would an improvement  (in my 
experience, the more often I read a document, the harder it became to 
notice the effects of changes to that document).  But of course I do 
favor ADs (and others) bringing issues to a WG's attention as early as 
possible.  Ideally those issues should be raised long before Last Call 
time, and long before the WG thinks the design is frozen.

Keith

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Apr 2005 13:32:29 +0300

Hi Ralph,

>I would actually feel more comfortable with
FWIW, this seems fairly easy to implement even now, with
(1) The introduction of the tracker that records comments so
that they can be accessed in a public manner. (2) The
practise where DISCUSS comment resolution is brought back
to the WG list (unless the comments are obvious and non-
controversial enough to be simply put in by the editor).

Some WGs are doing this already. Just yesterday we had
a discussion on the IPv6 list about one DISCUSS and how
to resolve it.

--Jari

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Apr 2005 09:35:35 -0400

Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us.  That is, we need to be careful that
technical input from ADs isn't automatically assigned extra weight or
control (veto power).

Which is why I suggest ADs provide technical input in open mailing lists
during last calls, to make sure their technical input is on the same
footing as everyone else's technical input.  I agree that the IESG's job
is to ensure correctness, completeness, etc.  That feedback should be
provided earlier, in an open forum.

If a particular AD doesn't have cycles to monitor every last call - and,
as the AD has to review the doc and to a technical review, anyway, I'm
not sure monitoring last call discussions would consume many more cycles
than the current process - the AD could call on an expert or a
directorate to participate in the open process.

But, I'm indulging in generating solutions rather than identifying
problems.  I guess the problem I see is separating technical analysis
from process management...

- Ralph

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Apr 2005 12:19:33 -0400

> technical input from ADs isn't automatically assigned extra weight or

There's no way to avoid that happening and still have quality control. 

> provided earlier, in an open forum.

I agree that input should be provided as early as possible.  But some 
kinds of feedback inherently follow Last Call, and limiting IESG input
to before Last Call would just serve to make the process even slower
than it already is (by requiring multiple IESG reviews rather than just
one), while lowering publication quality (by preventing IESG from 
objecting to valid technical issues noticed after Last Call, and perhaps
discovered while considering Last Call input, but not directly related 
to issues raised in Last Call).
 
Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Apr 2005 17:20:36 -0400

Jeff,

To clarify, I was suggesting that we think about something a
little different.  Not an expanded IESG (which I agree would be
a poor idea), or "deputy ADs", but a separate body, such that we
had one body charged with management/coordination and another
one charged with "review/approval" and with neither superior to,
or reporting to, the other.

The problems I see with "deputy ADs", review committees,
strengthened directorates, etc., are all, ultimately, the same:
We select very responsible people to serve on the IESG.   As
long as they are, and feel, responsible, these additional bodies
or groups may help with the quality of review and may speed it
up, but most ADs, most of the time, will feel a need to still do
the reviews themselves, take responsibility for writeups issued
in their names, etc.  And they will have more people to manage.

The only way out of that trap is a separate review body.  Of
course, that has its own set of problems and issues, as others
have pointed out, but it would change the time equation and the
management/advocacy/decision conflicts and relationships.  I
don't see additional structures that report to the IESG changing
either of those significantly.

    john

--On Thursday, 28 April, 2005 20:39 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

> Exactly right.  We select AD's based on their technical
> expertise, and expect them to use that expertise in reviewing
> documents that come their way.  This is one of the reasons why
> it's hard to lighten AD load by getting other people to do
> reviews -- the expectation is that AD's will actually review
> the documents they approve, at least to some extent.
> 
> I think that talk about "expanding the IESG" is approaching
> the problem along the wrong tack.  Rather than making the
> management structure more top-heavy, why not introduce an
> additional layer?  Specifically, I'm thinking of a model in
> which AD's would appoint some number of "deputy AD's" who
> would review and comment on (assigned) documents in the AD's
> place.  This is somewhat more formal than the current
> directorate model, in which directorate members may assist
> with reviews but the AD still has to personally review every
> document (or perhaps, 50% of all documents, depending on how
> work is divided in areas with two AD's).
> 
> This is how large organizations scale management tasks -- they
> introduce layers of indirection and abstraction.

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 Apr 2005 15:38:08 -0700

Jeffrey Hutzelman wrote:
> If I may read between the lines here, it sounds like you're suggesting
> some sort of reality-check process that is more lightweight than a full
> appeal. Informally, we have that -- if one AD is giving me a hard time
> for a dumb reason, I can ask another AD to try to talk some sense into
> them.  But that only works if the participant has a good relationship
> with another AD, and while you hope that's true for WG chairs, that
> might not always be good enough.

Yup - it relies too much on goodwill and who-knows-whom, which is unfair
to those who are trying to get things through for the first time.
Working with the personalities can always avoid such issues; the rules
are there to provide guidance where that either isn't possible or breaks
down.

> discuss is inappropriate and disregard it.  Such a mechanism would have
> to be invoked explicitly, and would perhaps involve a consensus call by
> the IESG chair...

I'd rather force DISCUSS to be very explicit about the reason, and be
limited to the areas mentioned, but specifically prohibit last-pass
edits of the sort that ought to happen during last call or within the WG.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Apr 2005 15:53:17 -0700

>  limited to the areas mentioned, but specifically prohibit last-pass edits
>  of the sort that ought to happen during last call or within the WG.

Let me suggest that the rules be quite simple:

1. A Discuss may be asserted only when it pertains to a normative concern that 
involves the viability of the specification.

2. The AD raising the Discuss must post the details of their concern to the 
mailing list targeted to that specification and must provide clear direction 
as to how to cure the problem.  Failing the ability to provide the detail 
about how to fix the specification, the AD must engage in a dialogue that has 
the goal of specifying that detail.

In order to deal with the issue of a pocket veto, whereby the AD is 
intractable but maintains the veto, there needs to be a mechanism to force 
review of the Discuss, either to assert that, indeed, it involves a valid 
showstopper (failure) of the specification or that it can be ignored.  

 d/
 ---
 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Apr 2005 19:56:02 -0400

> involves the viability of the specification.

not reasonable.  even merely informative text can cause 
interoperability problems if it is wrong or misleading.

> the goal of specifying that detail.

not reasonable.  it's fine for an AD to provide suggestions as to how 
to resolve an issue, but it's not the AD's job to actually resolve 
issues that need to be sorted out at length either within the WG or 
between that WG and other parties.

> showstopper (failure) of the specification or that it can be ignored.

such a mechanism already exists.

Keith

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Apr 2005 23:06:01 -0400

> interoperability problems if it is wrong or misleading.

As a practical matter, the line between normative and informative is
likely grey enough to make this suggestion unworkable...

> between that WG and other parties.

I agree with the first clause; the concern must be explained and
motivated in detail.  The WG - not the AD or the doc authors in
isolation - should develop the solution.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 30 Apr 2005 11:12:44 -0700

> > >  1. A Discuss may be asserted only when it pertains to a normative
> > >  concern that involves the viability of the specification.
>

interesting point.  first question, then, is why has the ietf been finding it 
important to make the distinction between the two?

second question is how do we distinguish between Discuss items that really do 
pertain to "it won't work" and "it's unacceptably deficient" concerns, versus 
an AD's personal preferences and whims?

> > >  2. The AD raising the Discuss must post the details of their concern
> > >  to the mailing list targeted to that specification and must provide
> > >  clear direction as to how to cure the problem.  Failing the ability to
> > >  provide the detail about how to fix the specification, the AD must
> > >  engage in a dialogue that has the goal of specifying that detail.
>
>  I agree with the first clause; the concern must be explained and motivated
>  in detail.  The WG - not the AD or the doc authors in isolation - should
>  develop the solution.

This raises two issues.  One is that the focus of the suggestion is making 
sure that an AD who asserts a late-stage veto is meaningfully obligated to 
work constructively to remove it.  

The other is that working groups rarely develop solutions.  Participants or 
small sub-groups develop solutions; working groups review and approve.  

When a random participant raises a concern during specification development, 
the working group can readily acknowledge the issue and add it to the 
workload, or it can fail to gain traction.  In the former case, the working 
group takes responsibility for finding the solution.  In the latter, the issue 
is, effectively, turned back to the person with the concern.  It is up to them 
to find some way to get the working group to embrace the concern; the usual 
way to do this is to propose a solution, so that the working group has a more 
solid sense of the topic.

Now we move to a late-stage AD veto.  The working group has put years of 
effort in and lots of review.  Here comes an AD -- typically one who has not 
been involved until this point -- blocking progress by stating some concern.

If the concern is obviously valid to everyone, then there is no issue.  
Everyone goes wow, we sure are glad you caught that, and goes off to fix it.

The problem is when the AD's concern is not obviously valid, or at least not 
obviously valid as a valid reason for blocking progress.

Today, there is almost no cost to the AD in these situations and, therefore, 
no pressure on them to be reasonable and constructive to resolve it.

We need to change limits and incentives, to fix this.

> > >  intractable but maintains the veto, there needs to be a mechanism to
> > >  force review of the Discuss, either to assert that, indeed, it
> > >  involves a valid showstopper (failure) of the specification or that it
> > >  can be ignored.
> > >

If you are referring to a classic Appeal, then that is too heavyweight and 
onerous.  The cost to the participant, of making an appeal, is significant.

If you are referring to something else, what is is and where is it documented?

 d/
 ---
 Dave Crocker

---

From: Joe Touch <[email-masked]>
Date: Sat, 30 Apr 2005 21:54:32 -0700

Keith Moore wrote:
>> concern that
> not reasonable.  even merely informative text can cause interoperability
> problems if it is wrong or misleading.

Informative text that leads to such problems is incorrectly classified;
it must be normative if it causes interoperability problems.

>> to the
> not reasonable.  it's fine for an AD to provide suggestions as to how to
> resolve an issue, but it's not the AD's job to actually resolve issues
> that need to be sorted out at length either within the WG or between
> that WG and other parties.

An AD can't merely raise an issue without specifying the criteria by
which the issue can be resolved. Being able to cause a problem or
roadblock without being required to state the conditions to remove it is
a recipe for abuse.

>> force

Right now the onus is on the author to get around such a roadblock; the
onus ought to be on the AD to justify it first.

Joe