Re: #720 and #725 - Appeals and IAD autonomy

Hi John -

Your note seems like an outlier.  In particular, it takes a really
*strong* stance on protecting people from each other because
people *will* act badly.  For example, the way I read your
note, the IESG will micromanage and the IASA/IAD will order
bagels flown in daily from New York.  Appeals will be a daily
happening and people will hire lawyers instead of working it out.

I think you're trying to solve many corner cases.  I don't
think we need to solve them right now.  As Dave Farber would
say, maybe we should burn those bagels when we get to them?

Seriously: this BCP seems, imo, pretty much cooked.  There may
be flaws and holes that people forgot, but this would be alot
easier to nail down if we had some operational experience in
the new framework and then solve problems that are real.
There are lots of checks in balances in place, there are going
to be lots of new people who have to get up to speed, and
the community is watching.  

I know you don't want to revise the BCP every 10 minutes for the
next 10 years, but if we had to ammend it once or even twice,
this would not be a big tragedy.

My personal advice: let's stop negotiating, call this BCP cooked, 
and move on to other fires.

Carl
(speaking as a "private citizen" again ... my contract with
ISOC has run it's course)


> --On Thursday, 23 December, 2004 10:22 +0100 Harald Tveit
> Alvestrand <harald(_at_)alvestrand(_dot_)no> wrote:
>  
> > > > John,
> > > >
> > > > ...
> > > > I like all of those properties, and it should be a small
> > > > twist of language (starting from the text in the draft, not
> > > > the most recent suggestion) to make it come out that way.
> > > > But I'm not sure I'm reading your words correctly, so better
> > > > double-check....
> > > A fascinating question, actually.   I think you are reading my
> > > words correctly and that, by happy coincidence, the words that
> > > are now in the draft are fairly easily adapted.
> > >
> > > But the principles are more important than the words, and I
> > > think this is a profound change in principles.  It is, I
> > > think, a significant change to say "if you expect the IAOC
> > > model to succeed,
> > >
> > >    * the IETF has got to keep its hands off the day-to-day
> > >    decisions, even when they seem wrong
> > >    
> > >    * the IESG and IAB need to be prohibited structurally
> > >    from micromanaging, or managing at all, beyond the
> > >    degree that the IAOC wants to permit.  They supply
> > >    input, they make requests, but decisions rest on the
> > >    IAOC side of the wall and stay there, with the only
> > >    _real_ recourse being to fire the IAOC
> > >
> > > and then to figure out a way to implement those principles.
> > Actually, I think we have agreement on those principles, and
> > have mostly been struggling with how to express them.
> >
> > Appeals procedures (under whatever name) are procedures that
> > should exist so that if someone thinks something's gone really
> > wrong, it's possible to get it noticed and talked about - and,
> > if it's necessary, corrected.
> >
> > Trying to manage anything by routine appeals is totally broken.
> Well, perhaps we are close enough that it doesn't make sense to
> have further discussion without text, and text in context, but...
>
> I think the "something's gone really wrong" and "...corrected"
> part of the above _might_ miss the point I'm trying to make.  
>
>       (1) If you have an appeal procedure, any appeal
>       procedure at all, then it is up to the judgment of the
>       individual members of the community whether a decision
>       is "really wrong".   I don't need to worry about denial
>       of service attacks here, just about people acting in
>       good faith and with the best of intentions.  Remember we
>       have had debates on the IETF list about the variety of
>       pastries to be available during meeting coffee breaks as
>       well as the theory for selecting meeting sites.   I may
>       be too concerned about this, but I think those debates
>       could easily have led to appeals about meeting locations
>       when people concluded that the decisions being made were
>       against the expressed consensus  desires of the
>       community (or against plain good sense).   Such appeals
>       have been prevented by the assumption that the IETF
>       membership has no ultimate control over _individual_
>       secretariat or Chair meeting siting decisions and that
>       contracts are already signed by the time meeting sites
>       are announced.   That has protected us from procedural
>       entanglements that could easily make meeting scheduling
>       impossible.  But, with the presumed requirements on the
>       admin structure for openness, that particular protection
>       disappears.
>       
>       (2) If there is an mechanism, any mechanism at all, for
>       the IESG and IAB to second-guess administrative entity
>       decisions, I think it can be guaranteed, given the sorts
>       of personalities we put on those bodies, that the
>       mechanism will sooner or later be used and that, once
>       used, there will be a tendency for its use to become
>       routine.  We appoint people with strong opinions and
>       with a tendency to want to manage, sometimes
>       micromanage, anything for which they feel responsible
>       and to do so aggressively.  If kept under control and in
>       perspective, those tendencies can be very useful.  But I
>       think any person who has listened to a few IESG
>       telechats, any WG Chair or Editor who has tried to get a
>       document through the system in recent years, anyone who
>       has worked for the Secretariat, and many others can
>       easily identify incidents that they would consider out
>       of control or without adequate perspective.
>
>       (3) Part of the problem here is that, on the technical
>       standards side, part of the job of the IESG is to ensure
>       that the collection of standards the IETF emits are
>       essentially consistent, that we don't have a standard in
>       one area that makes a standard in another area
>       impossible to implement.  Sometimes we don't get that
>       quite right and it requires some sorting-out.  But it
>       works most of the time, and works precisely because that
>       is a real IESG responsibility which the IESG and the
>       community take seriously.   On the admin side, the IAOC
>       has to be able to work out a plan and strategy that
>       works in works in a consistent way.  I want to see that
>       plan and strategy be public, and be exposed to comments
>       from the community, and so on, but they have to
>       represent a framework that the IAOC believes is
>       workable.   The possibility for "despite your framework,
>       we really need bagels flown in daily from Manhattan"
>       decisions, or even decisions about contracting
>       organizations or contract terms, overriding the
>       framework is a recipe for a fast trip down a slippery
>       slope toward complete disfunction.
>
> We need to prevent that, and we need to prevent that with real
> firewalls, not just "it should be appealed only if it is bad
> enough; the real risk is 'routine' appeals" language and
> intentions.    For the IAB or IESG to tell the IAOC "we know
> something about this, or have a perspective on this, that we
> don't think you considered adequately; here is the information,
> please reconsider" is fine.   It provides a means of input and
> it contains its own safeguard mechanism: were those requests to
> appear once a week, the IAOC would presumably start blowing them
> off.  And then the community would need to decide whether the
> issues were actually important enough to replace the IAOC
> membership and, if not, whether it was time to aim the
> clue-by-four in the direction of the IETF Leadership.
>
> The need for those firewalls is also the reason I've been
> reluctant to see the IAB and IETF Chairs even as members of the
> IAOC (not even getting to a debate about voting rights),
> weighting the IAOC more toward folks with administrative
> management/ finance experience than people selected primarily
> for their technical skills and, perhaps, technical project
> management experience.  I think we need to appoint the IAOC,
> make sure it has access to adequate information about what is
> going on in the IETF and what the IETF needs, and the let it
> function.   The community has apparently concluded that the best
> way to get that information to the IAOC is to put the IAB and
> IETF Chairs on it.  I disagree, but that is fine.   There are
> other areas, perhaps including Exec Dir appointments, where it
> is completely rational to require IESG and/or IAB advice and
> consent before a decision is actually made, but that is
> pre-decision, not reversing decisions. 
>
> For decisions once made, those options for strong communications
> makes other sorts of firewalls even more important.   And the
> key ones of those are "no appeals procedure" and "no ability of
> the IAB or IESG to reverse an IAOC decision".  None.  No
> judgments about what is sufficiently important or sufficiently
> wrong.  None.    If the IAOC doesn't like the behavior of the
> IAD, and tries to correct it by advice and negotiation, and
> fails, their only recourse is to fire the IAD.   And if the IETF
> Community (the IAB and IESG included) doesn't like the behavior,
> or decision-quality, of the IAOC, and can't fix that through
> advice and negotiation, then it needs to have a mechanism for
> firing and replacing the IAOC and should use it.   But no
> second-guessing or reversal of individual decisions.  Ever.
>
>     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