Re: [ietf-nomcom] BCP 10 Update, adding an IAOC Advisor to the Nominating Committee

[Spencer Dawkins at IETF <[e-mail]>]

Revectoring to the ietf-nomcom list, which is intended for conversations
like this ...

On Wed, Aug 9, 2017 at 2:17 PM, Robert Sparks <[e-mail]> wrote:

>
>
> On 8/9/17 1:59 PM, Ted Hardie wrote:
>
> On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks <[e-mail]>
> wrote:
>
>> Spencer -
>>
>> The attempt to avoid the term liaison is not working well for me.
>>
>> I think the biggest thing making you want to avoid that term are the
>> requirements on liaisons to oversee process as you call out in the
>> document. Instead of trying to to refashion terms, why don't you just
>> change things so that it is explicit that only the IAB, IESG, and ISOC
>> liaisons have that duty. Then you won't run into trouble with the "other
>> unrepresented organizations" text you quote.
>>
>> You can make it clear that for the IESG and IAB, seated members are
>> required. Any other body can delegate outside its membership.
>>
>> That _seems_ to me to be a more straightforward adjustment. What am I
>> missing?
>>
> There's at least one other potential shift: removing the IAOC liaison from
> the list of liaisons who might serve as replacement Nomcom chair.  If you
> remove that and the other process duties, it's not clear why it is useful
> to call two different sets of responsibilities by the same name.  You can
> do it, of course, as long as you've specified it.  But I don't personally
> see much of an advantage.
>
> My take is that we want the IAOC job or its successor to eventually by
> folks with specific skills in financial oversight, program management, and
> community relations.  Having the IAOC rep be able to explain those tasks to
> a Nomcom is very valuable, and I support getting this formalized.  I care
> about that much more than what we call it.
>
> I think the thing that's bothering me is that the current proposal still
> leaves the unintended trouble if the "Any committee member may propose the
> addition of a liaison" is exercised.
>

Yes, and that's borked.

I'm a tiny bit loath to turn this draft into a "liaison responsibilities
cleanup" draft, although Robert correctly points out that if we wanted to
clean up the liaison responsibilities, we would have changes to make.

If this draft continues to be about an advisor, I'd be happy to address the
liaison responsibilities in another draft. of course.

<rant>

When we have text in BCPs that is rarely/never executed, we don't look at
it very often. You'd be impressed at the list of people who told me they
didn't realize what all the liaison responsibilities are. I won't embarrass
the ones who told me that, and who have previously served as liaison (so,
subject to those responsibilities) without noticing that, but I can confirm
that *I* didn't notice them, in 2011 as the IAB liaison to the Nomcom :-)

That text doesn't age any better than error-path code that doesn't get
triggered for a very long time, of course.

But I digress.

</rant>


> If you strip away all the rationalization text, the change in Spencer's
> current document reduces to "Hey future nomcoms - it would be a good idea
> if you found an advisor that can talk to you about the IAOC, and the
> current IAOC might be a good body to ask to help you find one". I don't
> object to that. Perhaps the rationalization is a distraction?
>

It's only there to explain why this role isn't a liaison. If the role
becomes a liaison, the rationalization text would, of course, go away.


> But the rationalization part also argues that we want to say "If you think
> you want a liaison from some other body, you might want to look closely at
> asking for an advisor instead."
>

One could make the case that "Any committee member may propose the addition
of a non-voting liaison" is also borked.

Of course, I don't know why that  text is there in the first place. It's
also in RFC 3777, and in RFC 2727, which means it was added after RFC 2282
was published in 1998.  So I wonder if this was intended to prevent a
problem I don't know about?

Thanks again for the feedback. It's helpful.

Spencer