|
RE: Mud. Clear as. Re: Rough consensus? #425 3.5
2005-01-26 09:23:11
I like this text. In any event, it seems much closer to what
the community seems to want than what we have in the revision 04
document. So I have included the text suggested by Leslie,
with the understanding that I have not yet seen Harald declare
consensus (seems early for that anyways).
In the rev 05 doc (that I just submitted to the repository) I
have marked the text as "strawman text"... so I hope that that
is acceptable for now.
Bert
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]On Behalf Of
Leslie Daigle
Sent: Wednesday, January 26, 2005 03:16
To: ietf(_at_)ietf(_dot_)org
Subject: Mud. Clear as. Re: Rough consensus? #425 3.5
With apologies for having posted & disappeared (ISP & other
unexpected connectivity challenges), I'd like to try another
cut at what I was getting at, based on the discussion since.
On Friday, I tried a minimal edit on words that had flown
around the list and seemed to have some consensus. Here's
more of an extensive rewrite.
Apart from the distinction I had tried to make about
. business decisions (implementation) versus
. performance
I heard these requirements expressed:
. DoS concerns -- don't create a system that begs for
denial of IASA service through the appeal/review process
. second-guessing -- don't create an environment where
some or all of the community is second-guessing IAD/IAOC
at every move
. community involvement -- adequate and appropriate
community involvement in the IASA decision making process
And I heard various theories about distinguishing between
. before decisions are made
. during the decision-making process
. after decisions have been made
particularly in terms of whether we are discussing
. appeal (review of executed action by an univolved
body)
. review (further discussion of an action or proposal)
. recall of IAOC members
Separately from those considerations, there is the question of
implementation -- what people/body(ies) invoke an action, and
so on.
So, generally speaking, I think the important things to capture
in the BCP are:
. business decisions remain within the IASA
in terms of review mechanisms (i.e., contracts, etc)
. the IASA should be explicitly pressed to publicize
and seek input on guidelines for making those decisions
. public information should include objective measurements
of system performance (e.g., document processing
times)
. there should be a crisp review process to address
the situation when (some subset of the IETF believes)
the IASA has not followed its guideliness in
carrying out an action -- and that includes the expectation
of having public guidelines.
To the meeting location example -- that would mean (IMO) that
the IASA should have some public guidelines for how it picks
meeting sites, and if a site is picked that appears to be at
odds with those guidelines, then there is a process for reviewing
the IASA's actions in selecting that site. NB - that is different
than appealing the site itself.
So, with all that in mind, I propose the following revised
text for the 2 sections I suggested on Friday:
--------
3.5 Business Decisions
Decisions made by the IAD in the course of carrying out IASA business
activities are subject to review by the IAOC.
The decisions of the IAOC must be publicly documented for each formal
action.
3.6 Responsiveness of IASA to the IETF
The IAOC is directly accountable to the IETF community for the
performance of the IASA. In order to achieve this, the
IAOC and IAD will ensure that guidelines are developed
for regular operation decision making. Where appropriate, these
guidelines should be developed with public input. In all
cases, they must be made public.
Additionally, the IASA should ensure there are reported objective
performance metrics for all IETF process supporting activities.
In the case where someone questions that an action of the IAD or the
IAOC has been undertaken in accordance with this document
or those operational guidelines (including the creation of an
appropriate set of such guidelines), he or she may ask for a formal
review of the action.
The request for review is addressed to the person or body that took
the action. It is up to that body to decide to make a response,
and on the form of a response.
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB or the IESG
to make the request on their behalf.
Answered requests for review and their responses are made public.
Reviews of the IAD's actions will be considered at his or her
following
performance review. Reviews of the IAOC's actions may be considered
when IAOC members are subsequently being seated.
-----------
Note that this deletes much of the text that is currently
the "Responsiveness of the IASA to the IETF Leadership"
section:
However, the nature of the IAOC's work
involves treating the IESG and IAB as major internal
customers of the
administrative support services. The IAOC and the IAD should not
consider their work successful unless the IESG and IAB are also
satisfied with the administrative support that the IETF is
receiving.
I wondered if this was still particularly relevant/appropriate or
needed...
Where it does leave the IAB and IESG in priviledged position is
that they act as channelers. I am not personally strongly wedded
to this -- it's a leftover from previous discussion.
Leslie.
Leslie Daigle wrote:
Following up the point I made in response to Mike St.Johns
a couple days ago, I went back through the document to see if/how
it distinguishes between being adequately responsive and
accountable to the community, from having appropriate
chains of accountability for contractual purposes (and
no micromanagement of the business affairs of the IASA).
It seems to me that we should:
1/ Change this section:
3.3 Relationship of the IAOC to Existing IETF Leadership
to "3.6 Responsiveness of IASA to the IETF"
and include the original text plus Harald's text adjusted to
be about the general processes. And a point about objective
process metrics.
2/ Add a section (3.5) specifically about business decisions --
which, as Mike St.Johns pointed out, should remain within
the IAD/IAOC.
That would make:
3.5 Business Decisions
Decisions made by the IAD in the course of carrying out
IASA business
activities are subject to review by the IAOC.
The decisions of the IAOC must be publicly documented to
include voting
records for each formal action.
3.6 Responsiveness of IASA to the IETF
The IAOC is directly accountable to the IETF community for the
performance of the IASA. However, the nature of the IAOC's work
involves treating the IESG and IAB as major internal
customers of the
administrative support services. The IAOC and the IAD should not
consider their work successful unless the IESG and IAB are also
satisfied with the administrative support that the IETF is
receiving.
In order to achieve this, the IASA should ensure there are
reported objective performance metrics for all IETF process
supporting activities.
In the case where someone questions an action of the IAD or the
IAOC in meeting the IETF requirements as outlined above, he or she
may ask for a formal review of the decision.
The request for review is addressed to the person or body that made
the decision. It is up to that body to decide to make a response,
and on the form of a response.
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB or the IESG
to make the request on their behalf.
Answered requests for review and their responses are made public.
Leslie.
Leslie Daigle wrote:
Interesting...
To the extent that the IAD and IAOC are dealing with
decisions about implementing requirements, I agree.
To the extent that the IAD and IAOC are applying judgement
to interpret the "best needs of the IETF" (i.e., determining
those requirements), I disagree. I think it's a little
heavy-handed to have to instigate a recall procedure if the
IAD (or IAOC) seem not to have heard the *community's* requirements
for meeting location.
So, (how) can we make the distinction without creating a
decision tree of epic proportions?
Leslie.
Michael StJohns wrote:
Hi Harald et al -
I apologize for chiming in on this so late, but I had
hopes it would
get worked out without me pushing over apple carts.
I can't support this and I recommend deleting this section in its
entirety.
My cut on this:
The decisions of the IAD should be subject to review (and in some
cases ratification) ONLY by the IAOC.
The decisions of the IAOC should not be subject to
further review by
the IETF at large. The proper venue for expressing tangible
displeasure with a decision is during the appointment and
reappointment process. (Note, I'm not precluding pre-decision
comment by the community at large, and I encourage the
IAOC to seek
such comment where appropriate but once the decision is
made its time
to stop whining and get on with things)
The decisions of the IAOC must be publicly documented to include
voting records for each formal action.
The IAOC and IAD must accept public or private comment
but there is
no requirement to either respond or comment on such missives.
The IAOC and IAD should not be subject to the IETF
appeals process.
The appropriate venue for egregious enough complaints on the
commercial side is the legal system or the recall process.
My reasoning:
The IAD and IAOC are making commercial (as opposed to standards)
decisions and the result of that may be contracts or
other commercial
relationships. Its inappropriate in the extreme to insert
a third (or
fourth or fifth) party into that relationship.
The IAD/IAOC relationship is going to be somewhat one of
employee/employer and its inappropriate to insert
external parties
into that relationship.
The documentation requirement is so that when the
appointment process
happens there will be some audit trail as to who did what to whom.
The IETF appeals process is not appropriate for a
commercial action.
A standards action may adversely affect competitors
across a broad
spectrum of companies. This commercial action only affects the
bidders or winners.
Please, let's get the IETF out of the metaphorical administrative
back seat and get them back to doing what they do well -
technology.
At 05:47 AM 1/19/2005, Harald Tveit Alvestrand wrote:
Trying to close this item, which is not resolved in the
-04 draft:
I believe that the list discussion has converged on very rough
consensus (Sam and Avri being the people who worry that we're
building a DoS attack defense that we don't need, but
Brian, Scott
and John Klensin, at least, strongly arguing that we need that
mechanism) on the following text, which I suggested on Jan 13,
replacing the last 3 paragraphs of section 3.4:
------------------------------------------------------
3.5 Decision review
In the case where someone questions a decision of the IAD or the
IAOC, he or she may ask for a formal review of the decision.
The request for review is addressed to the person or
body that made
the decision. It is up to that body to decide to make a response,
and on the form of a response.
The IAD is required to respond to requests for a review from the
IAOC, and the IAOC is required to respond to requests
for a review
of a decision from the IAB or from the IESG.
If members of the community feel that they are unjustly denied a
response to a request for review, they may ask the IAB
or the IESG
to make the request on their behalf.
Answered requests for review and their responses are made public.
-------------------------------------------------------
Can we live with this?
Harald
_______________________________________________
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
_______________________________________________
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|