RE: IESG issues with draft-ietf-nomcom-rfc2727bis-07

[Margaret.Wasserman@nokia.com]

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>
>