RE: Follow-up from NomCom advisor discussion

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

 



+1 to Brian's comment to apply common sense and do the right thing in the short term and fix this properly for next year (if necessary).

I'm not particularly familiar with RFC 8713, but I note that section 5.7 allows the Nomcom committee to recall any members (except the chair) for any reason.

Hence, perhaps the Nomcom could appoint the advisor(s) that it needs, possibly ask them not to vote (or abstain) and rely on section 5.7 in the hypothetical, but realistically unlikely, case that the advisors try and abuse the Nomcom process.

Regards,
Rob


> -----Original Message-----
> From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Brian E Carpenter
> Sent: 24 July 2020 21:29
> To: STARK, BARBARA H <bs7652@xxxxxxx>; 'Samuel Weiler'
> <weiler@xxxxxxxxxxxxx>
> Cc: 'ietf@xxxxxxxx' <ietf@xxxxxxxx>
> Subject: Re: Follow-up from NomCom advisor discussion
> 
> It's always been my understanding of the IETF process that if a process
> rule defies common sense, we should ignore the rule and carry on.
> 
> So I believe that the NomCom should simply inform its advisors that
> they don't get to vote on procedural issues this year. Or simply decide
> not to hold any votes on procedural issues. Or whatever common sense
> method allows them to have the advisors that they need.
> 
> And before next year, just remove that clause from the BCP.
> 
> Regards
>    Brian Carpenter
> 
> On 25-Jul-20 04:28, STARK, BARBARA H wrote:
> >
> >
> >> From: Samuel Weiler <weiler@xxxxxxxxxxxxx>
> >>
> >> Thank you for following the RFC8713 process and seeking the NomCom's
> >> approval of the proposed advisors.
> >>
> >> I trust that you and the Nomcom will still get useful help and advice
> >> from Henrik and Suresh, even with them outside the official NomCom
> >> circle, and I am confident that this NomCom will succeed.
> >
> > While I do think we will succeed, early indications are the NomCom will
> be somewhat hamstrung by the inability to bring in advisors. I strongly
> suspect the language in RFC8713 that grants voting privilege to all people
> brought in as advisors (to provide expert knowledge, skills, and guidance
> in any area where the NomCom may not natively have these ) will
> effectively prevent anyone from ever being brought in as an advisor.
> >
> > I'm wondering if it might be possible to file an erratum to get this
> immediate problem fixed in RFC8713?
> > Something like:
> > s/The Chair, liaisons, and advisors do not vote on the selection of
> >    candidates.  They do vote on all other issues before the committee
> >    unless otherwise specified in this document./
> >    The Chair, liaisons, and advisors do not vote on the selection of
> >    candidates.  The Chair, liaisons and prior year's Chair do vote on
> all other issues before the committee
> >    unless otherwise specified in this document. No other advisor votes./
> >
> > Just a thought. I really dislike operating in a kludgy and inefficient
> way. It's obvious we need Henrik's help. This voting clause is really
> standing in the way of efficient operation, and potential advisors aren't
> saying "I refuse to advise unless I get to vote on procedural issues".
> > Barbara
> >
> >
> >>
> >> On Thu, 23 Jul 2020, STARK, BARBARA H wrote:
> >>
> >>> With the addition of liaisons from every I*, adding Henrik and
> >>> Suresh would have caused there to be 9 people on NomCom who could
> >>> influence procedures -- potentially in ways that were undesirable to
> >>> a majority of the 10 Voting Members. This idea made some people
> >>> uncomfortable.
> >
> > .
> >





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

  Powered by Linux