[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]
Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07
Brian - thanks for translating my wild ramblings.Margaret - I'm not suggesting that we bypass the IESG review process - its already happened and as you might guess I consider none of the objections showstoppers to publishing this document.
WRT ISOC - I admit I hadn't considered it, but Brian makes a good point that the ISOC process has been relatively benign in the past.
The current process has some broken pieces. The new document fixes some of those pieces without breaking others.
Speaking as a member of a confirming body I want to follow a process that is more correct than was evident last year.
Mike At 17:36 10/8/2003, Brian E Carpenter wrote:
Margaret, Yes, we need the ISOC to agree to the final document, to ensure that the liability insurance taken out by ISOC is solid. So this step can't be avoided, but it has always been a formality in the past, once the IESG has approved the document. As far as I can see, Mike is suggesting that the IESG approves the document for BCP and simultaneously recharters the WG to fix the issues raised. This does seem reasonable and pragmatic. Brian Margaret.Wasserman@nokia.com wrote: > > Hi Mike, > > Are you suggesting that we skip the ISOC BoT approval > that usually applies to process documents? > > Or, are you only suggesting that we should bypass the IESG > review/approval process? > > I've been told that the ISOC BoT approval was included for > some sort of legal/liability/insurance-related reasons, so it > probably wouldn't be wise to bypass it. > > Margaret > > > -----Original Message----- > > From: ext Michael StJohns [mailto:mstjohns@mindspring.com] > > Sent: Wednesday, October 08, 2003 3:33 PM > > To: Harald Tveit Alvestrand; ietf-nomcom@lists.elistx.com > > Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 > > > > > > I'm going to go out on a limb here and suggest the IESG approve this > > document as is with the understanding that the NomcomWG will > > continue to > > work on the issues identified. > > > > Here's why - the substantive issues are ALL present in the > > current (2727) > > process and approving this document creates no additional > > problems. Indeed > > - this document fixes a number of problems that MUST be fixed > > sooner rather > > than later. > > > > I'm going to go further out on a limb and suggest the IESG > > immediately > > refer the document to the RFC editor, and indicate to the > > Nomcom chair that > > this is the process to be followed for this cycle and that > > the ID will be > > considered authoritative for the process pending the > > publication of the RFC. > > > > I realize this is out of the ordinary, but this process has > > been going on > > for a year and I don't think we can wait another year to fix the 2727 > > brokeness. > > > > Mike > > > > > > > > > > > > > > At 11:13 10/7/2003, Harald Tveit Alvestrand wrote: > > >The IESG on October 2 evaluated the nomcom document. > > >It found a number of details that may need to be fixed, and three > > >substantive issue that it seems to the IESG that it is > > necessary to fix. > > > > > >The first 2 substantive issue was raised by Margaret Wasserman: > > > > > >------------------------------------------------------------- > > >>In section 2: > > >> The nominating committee will be given the title of > > the positions > > >> to be reviewed and a brief description of the desirable set of > > >> qualifications of the candidate that is nominated to fill each > > >> position. > > > > > >Is this information sent publicly or privately? There are two issues > > >here: > > > > > >1) I think that the "description of the desirable set of > > qualifications" > > > should be posted publicly, along with the list of open > > positions when > > > the call for nominations is sent. > > > > > >2) The IESG and IAB should know, unambiguously, whether or not the > > > information will be publicly disseminated before providing it. > > > > > >------------------------------------------------------------------ > > > From section 3, subsection 8: > > >> It is consistent with these rules for the announcements of a > > >> resignation, of the existence of a mid-term vacancy, > > and of the > > >> confirmed candidates to all occur at the same time as > > long as the > > >> actual sequence of events that occurred did so in the > > following > > >> order. > > >> > > >> * The nominating committee completes the advice and consent > > >> process for the candidate already sitting on another body. > > >> > > >> * The newly confirmed candidate resigns from their current > > >> position. > > >> > > >> * The body with the new mid-term vacancy requests that the > > >> nominating committee fill the position. > > >> > > >> * The Executive Director of the IETF informs the nominating > > >> committee of the mid-term vacancy. > > >> > > >> * The nominating committee acts on the request to fill the > > >> mid-term vacancy > > > > > >This section indicates that a position may be vacated and filled > > >without the community being notified that a position is > > open. IMO, no > > >position should be filled without public notice that the position is > > >open and a public call for nominations. > > > > > >I understand one shool of thought that says that this is okay for IAB > > >positions during the normal selection cycle. Because IAB members > > >don't have separate responsibilities, it _might_ be okay to > > pick 6 IAB > > >members from a candidate pool for 5 open positions, for example. > > >However, even in this case, the community might want to know if a > > >person with a particular specialty/area of expertise was moving, so > > >that folks with that type of expertise could be nominated. > > > > > >This section would also be problematic for IESG positions. > > This could > > >arise in any case where one IESG position is filled by a sitting IESG > > >member who is not up for renewal. For example, consider a situation > > >where the IESG chair does not volunteer for another term and is > > >replaced by a sitting IESG member who is not up for renewal. Even > > >though there are two ADs for most areas, the ADs often divide up the > > >area into logical sections, requiring different expertise for each > > >position. > > > > > >There are also issues with filling any postition according to this > > >section if it is applied to interim vacancies. For example, the > > >nomcom should not be empowered to move an IAB member to the IESG to > > >fill and interim vacancy and replace the IAB member without making a > > >public call for nominations for the open IAB position. > > >---------------------------------------------------------------- > > >The third substantive issue was raised by Thomas Narten: > > > > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > >> Trustees are expected to review the operation and executing > > >> process of the nominating committee and to report > > any concerns > > >> or issues to the Chair of the nominating committee > > immediately. > > >> If they can not resolve the issue between > > themselves liaisons > > >> must report the issue to their respective bodies. If their > > >> respective body agrees that there is an issue the > > liaison must > > >> report it according to the dispute resolution process stated > > >> elsewhere in this document. > > > > > >I worry that there will be problems with the above in practice. In > > >particular, the text requires that a liaison report problems back to > > >their respective group (i.e., IESG or IAB) before invoking the formal > > >dispute resolution mechanism. But confidentiality rules rather limit > > >what the liaison can say to their body, and in the case where dispute > > >resolution may need invoking, it seems like details will be > > >important. I worry that this will create problems in > > practice, with it > > >being unclear what can be said. And if that is the case, it > > is unclear > > >what value the discussion within the respective I* would actually > > >have. This is perhaps more a problem for the IESG, since it has no > > >confirming role, but it seems like a general issue. > > > > > >There are ways of dealing with this, but I'm not sure what is best or > > >what the WG might think. Some initial thoughts: > > > > > >- I note that the current wording doesn't mention the obvious, i.e., > > > have the liaisons and previous chair get together and discuss > > > before escalating. One could also have the liaison (independently) > > > decide whether to formally appeal after such a consultation. This > > > avoids the confidentiality issue and would seem like a necessary > > > check as part of escalating issues. > > > > > >- add some wording saying that confidentiality rules allow sharing of > > > info as needed to assess whether to file a formal complaint. > > >-------------------------------------------------------------------- > > > > > >I think these needs to be discussed in the WG, and that they need to > > >either have new text crafted or a justification for the > > current choices given. > > > > > >The more-or-less minor issues can be found in the ID tracker: > > >> > ><https://datatracker.ietf.org/public/pidtracker.cgi?command=v> > iew_id&dTag=90> > >01&rfc_flag=0> > > > > > >and are also given below in raw format. > > >These are, in the opinion of the IESG, "non-show-stopper" > > issues - not > > >things that are critical enough to block/delay publication > > of the document > > >on their own, but important enough to be worth mentioning, > > in case they > > >can be quickly fixed while the document is "open". It is up > > to the WG what > > >to do with these. > > >------------------------------------------------------------- > > ------------- > > >Steve Bellovin: > > >Comment: > > >The recall section makes no provision or even suggestion > > that the Recall > > >Chair verify the putative signers. > > > > > >Section 5, Point 12 suggests that the committee consult with > > the sitting > > >members of the IAB and IESG. I think that consultation with > > WG chairs > > >should be suggested. > > > > > >Ted Hardie: > > >Comment: > > >I note that the oral tradition section indicates that no > > person should > > >serve on both the IESG and IAB, except the IETF Chair who > > serves on both by > > >definition. I believe that there is some lack of clarity on > > whether the IAB > > >Chair's role ex officio in the IESG means she "serves on", > > and that this is > > >probably not the place to resolve that or go into the > > liaisons from one > > >body to the other. To capture the same thing, how about: > > > > > >"No person should serve both on the IAB and as an Area > > Director, except > > >the IETF Chair whose roles as an IAB member and Area > > Director of the > > >General Area is set out elsewhere". > > > > > >Thomas Narten: > > > > > >If a voting volunteer member is recalled the committee may > > >> choose to proceed with only 9 voting volunteers at its own > > >> discretion. In all other cases the Chair must > > repeat the random > > >> selection process including an announcement of the iteration > > > > > >> prior to the actual selection as stated elsewhere in this > > >> document. > > > > > >The above implies to me that the nomcome is required to find a > > >replacement for a resignation, but is not for a recall. Shouldn't the > > >nomcom be allowed to also not replace resignations? I.e, I > > assume that > > >the nomcom would have the option of filling or not filling > > any nomcom > > >opening, regardless of how it occurs. > > > > > >> It is consistent with this rule for the nominating > > committee to > > >> choose one or more of the currently open positions > > to which it > > >> may assign a term greater than 2 years in order to > > ensure the > > >> ideal application of this rule in the future. > > > > > >s/greater than 2 years/of up to 3 years/ > > > > > >(right now, in theory, nomcom could pick the length of time, though I > > >suspect a lot of folk would be surprised if this ever happend...) > > > > > >> committee. The addition must be approved by all > > members of the > > >> committee according to its established voting mechanism. > > >> Advisors participate as individuals. > > > > > >"all members" wording implies everyone must agree. What is the intent > > >here? Is it "must be approved by a quorum of the committee according > > >to its established voting mechanism"? Note: similar wording appears > > >elsewhere. > > > > > >> conducted. A member may recalled if at least a > > quorum of all > > >> committee members agree, including the vote of the > > member being > > >> recalled. > > > > > >What does this mean? simple majority if there is a quorum? (I ask > > >because in most cases this document doesn't proscribe rules, leaving > > >that to the nomcom to decide.) > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > >> term. > > > > > >not consistent with interim appointments > > > > > >> First, when there is only one official nominating > > committee the > > > > > >add comma after committee > > > > > >> As of the publication of this document the current > > mechanism is > > > ^ > > >> an email message to both the "ietf" and the "ietf-announce" > > >> mailing lists. > > > > > >comma above > > > > > > > > >> None of the Chair, liaisons, or advisors vote on > > the selection > > >> of candidates. They do vote on all other issues before the > > >> committee unless otherwise specified. > > > > > >s/specified/specified in this document/? (what is the intent?) > > > > > >> 6. A Chair, in consultation with the Internet Society > > President, > > >> may appoint a temporary substitute. > > > > > >Better to say "... for the Chair position". > > > > > >> If they can not resolve the issue between > > themselves liaisons > > > > > >comma after themselves. > > > > > >> The confirmation process must be completed at least > > one month > > >> prior to the First IETF. > > > > > >s/must/should/ other parts of the document imply should on > > this topic. > > > > > >> The term of a nominating committee begins when its > > members are > > >> officially announced. The term ends at the Third IETF (not > > >> three meetings) after the next nominating committee's term > > >> begins. > > > > > >ambigous wording. Reword: > > > > > > The term ends at the Third IETF (not three > > meetings), that is, > > > the IETF after the next nominating committee's term begins. > > > > > >Jon Peterson: > > >Comment: > > >The Introduction fastidiously notes that the organization of > > the IESG is > > >outside the scope of the document. However, in so far as > > Section 3 bullet > > >3 explains that half of the IESG positions are reviewed by > > the NomCom per > > >year, would it make sense to mention at a high level that > > IESG members > > >serve in specific Areas, and that the review process is staggered to > > >preserve continuity and institutional memory within Areas? > > This seems like > > >an important detail of the NomCom process to omit, even if > > it might change > > >as the IETF changes. I'd note that Section 3 bullet 3 > > already has a caveat > > >about future IESG reorganization, so I'm not sure how it > > would hurt to > > >talk about the current IESG structure, in the interests of > > fully depicting > > >the existing practice. > > > > > >Margaret Wasserman: > > > > > >Comment: > > >EDITORIAL: > > > > > >>Abstract > > >> > > >> The process by which the members of the IAB and IESG are selected, > > >> confirmed, and recalled is specified. This document is a > > >> self-consistent, organized compilation of the process as > > it was known > > >> at the time of publication. > > > > > >Very weak... I also don't think that the last sentence is true, > > >as this document changes some things. Suggestions: Add a bit > > >more information (i.e mention the Nominations Commitee?) and remove > > >"as it was known at the time of publication". > > > > > >The section numbering in this document doesn't match usual > > >conventions. This makes it harder to refer to sections in this > > >document unambiguously. > > > > > >> 3. One-half of each of the then current IESG and IAB positions is > > >> selected to be reviewed each year. > > > > > >s/One-half of each of/One-half of/ > > >s/positions is/positions are/ > > > > > >> The intent of this rule to ensure the review of approximately > > >> one-half of each of the IESG and IAB sitting members > > each year. > > > > > >s/one-half of each of/one-half of/ > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > >> term. > > > > > >This isn't always true. Replacement candidates may serve > > >terms of less than two years. > > > > > >> A term may begin or end no sooner than the > > >> first day of the meeting and no later than the last day of the > > >> meeting as determined by the mutual agreement of the currently > > >> sitting member and the confirmed candidate. The confirmed > > >> candidate's term may overlap the sitting member's > > term during the > > >> meeting as determined by their mutual agreement. > > > > > >How does this apply to IAB terms? In the case where there is > > >more than one new IAB member, I don't think that it is > > >defined which IAB member each new member is replacing. > > >>In section 4, subsection 7: > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > >> Trustees are expected to review the operation and executing > > >> process of the nominating committee and to report > > any concerns > > > > > >There is a mention here of a liaison from the ISOC board. > > >But, there in section 4.3 there is a list of nomcom members > > >that indicates how they are selected, and the ISOC liaison > > >is not listed. > > > > > >The organization of this document seems to result in repeating > > >a lot of information. There are also a lot of forward > > >references. This makes it difficult to find the part(s) of > > >the document that apply to a particular part of the process. > > > > > >---------------------------------------------------------------- > > >To subscribe or unsubscribe from this elist use the subscription > > >manager: <http://lists.elistx.com/subscribe> > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.elistx.com/subscribe> > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.elistx.com/subscribe> -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]
Powered by eList eXpress LLC