Subject: BCP 10 Update, adding an IAOC Advisor to the Nominating Committee

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 8 Aug 2017 21:44:53 -0500

Dear all,

At Alissa Cooper's request, I put together a short draft that updates BCP
10, the Nomcom process, adding a reminder that Nomcoms can ask the IAOC to
provide an advisor, and the IAOC can provide one.

Yeah, I thought that was already in BCP 10, but it's not :-) ...

For your reading pleasure, the draft is available at

URL:            https://www.ietf.org/internet-drafts/draft-dawkins-iesg-
nomcom-advisor-iaoc-01.txt
Status:         https://datatracker.ietf.org/doc/draft-dawkins-iesg-nomcom-
advisor-iaoc/
Htmlized:       https://tools.ietf.org/html/draft-dawkins-iesg-nomcom-
advisor-iaoc-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-iesg-
nomcom-advisor-iaoc-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dawkins-iesg-
nomcom-advisor-iaoc-01

BUT please send questions and comments to the (public) IETF-Nomcom mailing
list, which is intended for conversations about BCP 10 updates.

If you're not already subscribed to that mailing list, the URL for it is
https://www.ietf.org/mailman/listinfo/ietf-nomcom.

Alexey Melnikov has graciously agreed to AD-sponsor the draft.

Thanks,

Spencer, as an individual

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Aug 2017 11:27:05 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
    > At Alissa Cooper's request, I put together a short draft that updates BCP 10,
    > the Nomcom process, adding a reminder that Nomcoms can ask the IAOC to

The other entities provide liasons, and I see that your document explains why
an advisor is listed.    I understand that the word "advisor" is from BCP10,
and allows the nomcom to add advisors to the nomcom. I'd call this an
"import", because the nomcom pulls someone in.

The other liason are not nomcom decisions, and so there is some subtle distinction.

It's also not clear to be that we want the NOMCOM to ask for an IAOC advisor,
or if we the IAOC appoints someone.  The previous tradition was the IAOC
appointed someone, and they gave us Ole even after he was no longer a seated
IAOC member.

As a voting member and chair, I found the IAOC (liason) very useful in
explaining not only what the IAOC does, but also what the IAB and IESG do not
do, even when sometimes IAOC activities get relayed via IETF Chair or IAB
chair.  Many voting members are ignorant of the IAOC and sometimes look for
characteristics in an IESG or IAB member that would be more appropriate for IAOC.
So I strongly agree with always having an IAOC liason/advisor, even when not
appointing someone directly to the IAOC.

{nomcom: 2002,2012,2013. chair: 2014}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 Aug 2017 12:05:44 -0500

Hi, Michael,

> "import", because the nomcom pulls someone in.

Yeah. I'm kind of dancing here, because I'm trying to reuse terminology in
a new and exciting(?) way.

This document could

   - Remind the Nomcom that they will probably need help understanding what
   the IAOC does, so they should ask, OR
   - Tell the IAOC to appoint (let's call it) an Advisor, at the same time
   the IAB and IESG are appointing liaisons.

The first option is where I headed, because I tend to write permissive BCP
text ("BCP text is hard to get right").

The second option would probably appear in a new section that looks a lot
like https://tools.ietf.org/html/rfc7437#section-4.8, except that the
eligibility would be different. I'd be OK doing that, if it makes sense to
others.

For extra credit, https://tools.ietf.org/html/rfc7437#section-4.3 could
actually require that an IAOC advisor be named, at the same level of
"required" that the IAB and IESG liaisons are required. There would be more
text changes going this way (but, see below).

> appointing someone directly to the IAOC.

I'm willing to make this position a requirement, if that's the right
answer. It's optional in the current draft.

> {nomcom: 2002,2012,2013. chair: 2014}

Thanks for your continued review and advice. I'm {nomcom: 2011 liaison}, so
appreciate people with more, and especially more recent, experience telling
me what they're thinking.

Spencer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Aug 2017 13:48:37 -0500

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?

RjS

On 8/9/17 12:05 PM, Spencer Dawkins at IETF wrote:
> Hi, Michael,
>
> On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Spencer Dawkins at IETF <[email-masked]
>     <mailto:[email-masked]>> wrote:
> Yeah. I'm kind of dancing here, because I'm trying to reuse 
> terminology in a new and exciting(?) way.
>
> This document could
>
>   * Remind the Nomcom that they will probably need help understanding
>     what the IAOC does, so they should ask, OR
>   * Tell the IAOC to appoint (let's call it) an Advisor, at the same
>     time the IAB and IESG are appointing liaisons.
>
> The first option is where I headed, because I tend to write permissive 
> BCP text ("BCP text is hard to get right").
>
> The second option would probably appear in a new section that looks a 
> lot like https://tools.ietf.org/html/rfc7437#section-4.8, except that 
> the eligibility would be different. I'd be OK doing that, if it makes 
> sense to others.
>
> For extra credit, https://tools.ietf.org/html/rfc7437#section-4.3 
> could actually require that an IAOC advisor be named, at the same 
> level of "required" that the IAB and IESG liaisons are required. There 
> would be more text changes going this way (but, see below).
>
>
> Thanks for your continued review and advice. I'm {nomcom: 2011 
> liaison}, so appreciate people with more, and especially more recent, 
> experience telling me what they're thinking.
>
> Spencer

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 Aug 2017 11:59:49 -0700

On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks <[email-masked]> wrote:

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

Ted

> On Wed, Aug 9, 2017 at 10:27 AM, Michael Richardson <[email-masked]
> > wrote:
>
>>
>    - Remind the Nomcom that they will probably need help understanding
>    - Tell the IAOC to appoint (let's call it) an Advisor, at the same
> Thanks for your continued review and advice. I'm {nomcom: 2011 liaison},
> so appreciate people with more, and especially more recent, experience
> telling me what they're thinking.
>
> Spencer
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Aug 2017 15:02:13 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
    > Yeah. I'm kind of dancing here, because I'm trying to reuse terminology in a
    > new and exciting(?) way.

understood.

    > * Remind the Nomcom that they will probably need help understanding what the
    > IAOC does, so they should ask, OR
    > * Tell the IAOC to appoint (let's call it) an Advisor, at the same time the
    > IAB and IESG are appointing liaisons.

    > text ("BCP text is hard to get right").

I think that I'd prefer the IAOC be told to pick someone, but I'm listening
to other opinions.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Aug 2017 14:17:56 -0500

On 8/9/17 1:59 PM, Ted Hardie wrote:
> On Wed, Aug 9, 2017 at 11:48 AM, Robert Sparks <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Spencer -
>
>     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.
>
> 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.

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?

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

>>       * Remind the Nomcom that they will probably need help
>>         understanding what the IAOC does, so they should ask, OR
>>       * Tell the IAOC to appoint (let's call it) an Advisor, at the
>>         same time the IAB and IESG are appointing liaisons.
>>
>>     The first option is where I headed, because I tend to write
>>     permissive BCP text ("BCP text is hard to get right").
>>
>>     The second option would probably appear in a new section that
>>     looks a lot like https://tools.ietf.org/html/rfc7437#section-4.8
>>     <https://tools.ietf.org/html/rfc7437#section-4.8>, except that
>>     the eligibility would be different. I'd be OK doing that, if it
>>     makes sense to others.
>>
>>     <https://tools.ietf.org/html/rfc7437#section-4.3> could actually
>>     require that an IAOC advisor be named, at the same level of
>>     "required" that the IAB and IESG liaisons are required. There
>>     I'm willing to make this position a requirement, if that's the
>>     right answer. It's optional in the current draft.
>>
>>     liaison}, so appreciate people with more, and especially more
>>     recent, experience telling me what they're thinking.
>>
>>     Spencer
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 Aug 2017 14:56:19 -0500

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

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

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

> 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