Re: Mud. Clear as. Re: Rough consensus? #425 3.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sam Hartman <hartmans-ietf@xxxxxxx> writes:

> I don't think I can support your proposed text.  I still don't
> understand what your proposed section 3.5 does and don't think I could
> go along with the plausable readings I'm coming up with for that text.
>
> I don't think your text does a good job of meeting the principles
> Margaret tried to outline; in particular it seems to fail to meet the
> principle on escalation.  I'd be very interested in an explanation of
> how you think it compares to those principles.

I'm not sure I necessarily agree with Margaret's principles. Here's
a cut at a set of my own:

Any set of rules for how the IASA makes decisions and how the
IETF can influence them needs to satisfy two somewhat conflicting
constraints:

1. Preserve the openness of the process and allow the IETF to
   supervise IASA in order to ensure that it is serving the
   interests of the IETF.

2. Allow the IASA to make decisions without being second guessed
   at every turn by individual IETFers who happen not to like
   them.

This is always a tricky problem, but we have a model to fall
back on, which is RFC 2026 and 2727. We have three major
mechanisms for the community to provide oversight for the
IESG and IAB:

1. Appeals up the chain (S 6.5 of RFC 2026) for mistaken decisions
   by IESG.

2. The nomcom and recall process (RFC 2727) for misconduct by
   IESG/IAB members.

3. Creating new RFCs which constrain the behavior of IESG and IAB. 

It's important to note two things about these mechanism. First, each has
its own role. Individual appeals, even if successful, do not really
constrain the IESG's behavior in the future. Conversely, we generally
don't attempt to write new RFCs to reverse specific IESG decisions, nor
would we expect that they would succeed. 

Second, 2026 grants both the IESG and IAB a fair amount of latitude
about how to structure their internal procedures. In particular,
the IESG and IAB rules about how they reach decisions are largely
self-made, with only very modest amounts of guidance from the 
RFCs. I think it's generally considered that that's a good thing.

With that in mind, I would like to suggest the following principles:

1. The IETF community should have input on the internal rules
   set by the IASA and the IASA should be required to respond
   to comments by the community on said rules.

2. While the IASA's behavior should be constrained by BCPs (as it will
   be constrained by the first one) we should in general refrain from
   enacting specific internal IASA rules changes by BCP. If it is believed
   that the IAOC is making bad decisions we have a mechanism for unseating
   them.

3. Decisions of the IAOC should be appealable (following the
   usual 2026 appeal chain) on the sole grounds that the IASA's
   processes were not followed. Those decisions should NOT be
   appealable on the grounds that the decisions were simply bad ones.

I recognize that point (3) above is somewhat controversial, so 
I'll attempt to justify it a bit. The simple fact is that the 
IASA (both IAD and IAOC) will be constantly making business decisions
and if we are to keep the job manageable (and in the case of IAD
keep the costs down) they have to know that they will not be
constantly second-guessed by the community on what kind of cookies
they purchased. If the community feels very strongly that the 
wrong kind of cookies were purchased then they can ask for a
rule demanding chocolate chip, and in the worst case pass
a chocolate chip cookie RFC.

There's a parallel here in the RFC 2026 appeals process. While
the IAB and IESG can review a decision both for process violations
AND for technical merit, the ISOC BOT is extremely constrained in 
that it can only provide limited procedural review (S 6.5.3)

   Further recourse is available only in cases in which the procedures
   themselves (i.e., the procedures described in this document) are
   claimed to be inadequate or insufficient to the protection of the
   rights of all parties in a fair and open Internet Standards Process.
   Claims on this basis may be made to the Internet Society Board of
   Trustees.  The President of the Internet Society shall acknowledge
   such an appeal within two weeks, and shall at the time of
   acknowledgment advise the petitioner of the expected duration of the
   Trustees' review of the appeal.  The Trustees shall review the
   situation in a manner of its own choosing and report to the IETF on
   the outcome of its review.

   The Trustees' decision upon completion of their review shall be final
   with respect to all aspects of the dispute.

It seems to me that this is a good model to follow for IASA.

I've deliberately avoided trying to write text because I think
it's important to agree on principles first.

-Ekr



























_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]