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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On Behalf Of > Leslie Daigle > Sent: Wednesday, January 26, 2005 03:16 > To: ietf@xxxxxxxx > 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@xxxxxxxx > >>>> https://www1.ietf.org/mailman/listinfo/ietf > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ietf mailing list > >>> Ietf@xxxxxxxx > >>> https://www1.ietf.org/mailman/listinfo/ietf > >> > >> > >> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@xxxxxxxx > >> https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf