Subject: Re: [Iasa20] Last Call: <draft-ietf-iasa2-trust-update-00.txt> (Update to the Selection of Trustees for the IETF Trust) to Best Current Practice

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Oct 2018 16:38:57 -0400

I’ve heard this there is a little confusion about the timeline for appointments if this document is approved soon and the current NomCom is asked to seat trustees, so I’d like to suggest the following clarification:

OLD 
The terms of the appointed trustees from IETF NomCom shall be three years.  The initial selection shall be one, two, and three year terms in order to initially stagger the terms and thus miminize potential annual Trustee turnover.  The other appointments by the IESG and the ISOC Board of Trustees shall be two year terms, with the initial terms being one and two years, respectively.

NEW 
The terms of the appointed trustees from IETF NomCom shall be three years.  The initial selection shall be one, two, and three year terms in order to initially stagger the terms and thus miminize potential annual Trustee turnover.  The other appointments by the IESG and the ISOC Board of Trustees shall be two year terms, with the initial terms being one and two years, respectively. The term lengths of initial appointees should be measured from the First IETF of the year in which they are seated even if they are appointed after the First IETF of the year.

Alissa

> On Sep 21, 2018, at 5:18 PM, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from the IETF Administrative Support Activity
> 2 WG (iasa2) to consider the following document: - 'Update to the Selection
> of Trustees for the IETF Trust'
>  <draft-ietf-iasa2-trust-update-00.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-10-05. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This memo updates the selection of trustees for the IETF Trust.
>   Previously, the Internet Administrative Oversight Committee (IAOC)
>   members also acted as trustees but the IAOC has been eliminated as
>   part of an update of the structure of the Internet Administrative
>   Support Activity (IASA).  This memo specifies that the trustees shall
>   be selected separately.
> 
>   This memo updates RFCs 4071 and 4371 with regards to the selection of
>   trustees.  All other aspects of the IETF Trust remain as they are
>   today.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
>

---

From: Scott Mansfield <[email-masked]>
Date: Tue, 2 Oct 2018 20:48:08 +0000

So I interpret this to say...

The NomCom will put forward three candidates.  For this year, the NomCom will put forward one candidate for a one year term, one candidate for a two year team, and one candidate for a three year term.  

 Next year’s NomCom will have one slot to fill.

Is that right?

Thanks.

Sent from my iPhone

> On Oct 2, 2018, at 16:38, Alissa Cooper <[email-masked]> wrote:
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Jari Arkko <[email-masked]>
Date: Tue, 2 Oct 2018 23:30:10 +0200

> The terms of the appointed trustees from IETF NomCom shall be three years.  The initial selection shall be one, two, and three year terms in order to initially stagger the terms and thus miminize p…

Sounds reasonable, and definitely clearer. Thanks.

Jari

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 2 Oct 2018 19:39:17 -0400

> On Oct 2, 2018, at 4:48 PM, Scott Mansfield <[email-masked]> wrote:
> 

That is my reading of the draft. And my suggested clarification further explains that the three appointments by this year’s nomcom need not be completed by IETF 104, and if they are not then the appointees will serve a little less than 3, 2, and 1 years, respectively. That also would apply to the the other two initial appointments.

Alissa

---

From: Scott Mansfield <[email-masked]>
Date: Wed, 3 Oct 2018 00:06:25 +0000

Thanks for the affirmation of the staggering point and clarification that the new paragraph allows a schedule that completes after IETF 104.  

Depending on the timing, it may be possible to align with the LLC timing, but I will wait for the official guidance.

Thanks,
-scott.
Sent from my iPhone

> On Oct 2, 2018, at 19:39, Alissa Cooper <[email-masked]> wrote:
> 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 5 Oct 2018 19:36:41 +0300

Adrian,

Many thanks for your perceptive review.

I have adopted your suggestions in my copy of the draft.

One follow-up below:

> Section 2
> 
>   IETF rules regarding recalls and other NomCom-related processes
>   continue to apply [RFC7437].
> 
> Pedantic, but you can't quite get away with this because the NomCom
> processes in 7437 did not apply to pure IETF Trust appointments.
> 
> How about...
> 
>   The processes regarding NomCom appointments and recalls of Trustees
>   for the IETF Trust follow those described in [RFC7437].

That’s much better, and this was an important catch.

> Does this mean this document updates 7437?

I think not, because this document uses 7437… would be happy to hear if people think otherwise.

Jari

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Oct 2018 17:59:18 +0100

Hi Jari,

> I think not, because this document uses 7437… would be happy to hear if people

Happy to go with that.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Oct 2018 11:11:37 +0100

Jari,
Thanks for the new version.
I checked, and you seem to have captured all my points.

Best,
Adrian

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: 05 October 2018 17:37
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-iasa2-trust-
> [email-masked]
> Subject: Re: Last Call: <draft-ietf-iasa2-trust-update-00.txt> (Update to the
> Selection of Trustees for the IETF Trust) to Best Current Practice
> 
> Adrian,
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 10 Oct 2018 15:04:40 +0000

Sounds good. And FWIW, we are soon working on an update/replacement of RFC 7437.

On 10/7/18, 6:11 AM, "Adrian Farrel" <[email-masked]> wrote:

    Jari,
    
    Best,
    Adrian

---

From: "John R. Levine" <[email-masked]>
Date: 15 Oct 2018 22:01:29 -0400

> Sounds good. And FWIW, we are soon working on an update/replacement of RFC 7437.

Found another nit in trust-update.  It currently sort of says that all 
trustees can be recalled by the BCP 10 process.  Assuming this is not 
hugely contentious, I think it'd be better to say that nomcom appointed 
trustees can be recalled by the BCP 10 process, IESG and ISOC trustees can 
be recalled by the appointing bodies.  It seems kind of odd to have the 
appointment and recall processes not match.

R's,
John

>    > I think not, because this document uses 7437… would be happy to hear if people

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Oct 2018 09:49:20 +0300

Thanks. That certainly makes sense to me.

Jari

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 16 Oct 2018 10:14:04 +0200

> On Oct 16, 2018, at 4:01 AM, John R. Levine <[email-masked]> wrote:
> 
> Found another nit in trust-update.  It currently sort of says that all trustees can be recalled by the BCP 10 process.  

I thought this was purposefully mirroring the recall process for the LLC Board, which allows ISOC- and IESG-appointed directors to be recalled using the BCP 10 process.

Alissa

> Assuming this is not hugely contentious, I think it'd be better to say that nomcom appointed trustees can be recalled by the BCP 10 process, IESG and ISOC trustees can be recalled by the appointing bodies.  It seems kind of odd to have the appointment and recall processes not match.
> 
> R's,
> John
> 
> Please consider the environment before reading this e-mail. https://jl.ly_______________________________________________
> iasa20 mailing list
> [email-masked]

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 16 Oct 2018 07:53:28 -0400

On Tue, Oct 16, 2018 at 04:14 Alissa Cooper <[email-masked]> wrote:

> trustees can be recalled by the BCP 10 process.
>
> I thought this was purposefully mirroring the recall process for the LLC
> Board, which allows ISOC- and IESG-appointed directors to be recalled using
> the BCP 10 process.
>

I thought that too; I know it seems weird (ISOC might just reappoint the
same person).

>
> > Assuming this is not hugely contentious, I think it'd be better to say
> that nomcom appointed trustees can be recalled by the BCP 10 process, IESG
> and ISOC trustees can be recalled by the appointing bodies.  It seems kind
> of odd to have the appointment and recall processes not match.
> >
> > R's,
> > John
> >
> >>   > I think not, because this document uses 7437… would be happy to
> hear if people
> >>   > think otherwise.
> >>   >
> >>   > Jari
> >>
> >>
> >>
> >
> > Regards,
> > Please consider the environment before reading this e-mail.
> https://jl.ly_______________________________________________
> > iasa20 mailing list
> > [email-masked]
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 16 Oct 2018 14:23:47 +0000

+1 (and I thought this was a specific prior discussion on the list a few weeks ago)

From: Joe Lorenzo Hall <[email-masked]>
Date: Tuesday, October 16, 2018 at 7:53 AM
To: Alissa Cooper <[email-masked]>
Cc: Jari Arkko <[email-masked]>, "John R. Levine" <[email-masked]>, "Livingood, Jason" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Iasa20] Last Call: <draft-ietf-iasa2-trust-update-00.txt> (Update to the Selection of Trustees for the IETF Trust) to Best Current Practice

On Tue, Oct 16, 2018 at 04:14 Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:

> On Oct 16, 2018, at 4:01 AM, John R. Levine <[email-masked]<mailto:[email-masked]>> wrote:
>

I thought that too; I know it seems weird (ISOC might just reappoint the same person).

>> On 10/7/18, 6:11 AM, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>   Jari,
>>   > From: Jari Arkko [mailto:[email-masked]<mailto:[email-masked]>]
>>   > To: [email-masked]<mailto:[email-masked]>
>>   > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-iasa2-trust-
>>   > [email-masked]<mailto:[email-masked]>
> John Levine, [email-masked]<mailto:[email-masked]>, Primary Perpetrator of "The Internet for Dummies",
> [email-masked]<mailto:[email-masked]>

_______________________________________________
iasa20 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iasa20
--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked]<mailto:[email-masked]>, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2018 10:33:13 -0400

> I thought this was purposefully mirroring the recall process for the LLC Board, which allows ISOC- and IESG-appointed directors to be recalled using the BCP 10 process.

I don't feel terribly strongly about it but if the Trust is supposed to be 
independent of the IETF, it seems wrong to let the IETF unilaterally fire 
everyone.

R's,
John

Regards,

---

From: Mike Bishop <[email-masked]>
Date: Tue, 16 Oct 2018 17:44:52 +0000

They might, but a recall and having to reappoint effectively forces ISOC to take a stand on whatever issue the IETF chose to recall over.  I don’t feel strongly in either direction, but it’s not a nonsensical construction.

From: iasa20 <[email-masked]> On Behalf Of Joseph Lorenzo Hall
Sent: Tuesday, October 16, 2018 4:53 AM
To: Alissa Cooper <[email-masked]>
Cc: [email-masked]; [email-masked]; Livingood, Jason <[email-masked]>; Jari Arkko <[email-masked]>; John R. Levine <[email-masked]>; [email-masked]
Subject: Re: [Iasa20] Last Call: <draft-ietf-iasa2-trust-update-00.txt> (Update to the Selection of Trustees for the IETF Trust) to Best Current Practice

>>   I checked, and you seem to have captured all my points..
>>
>>   Best,
>>   Adrian
>>

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Oct 2018 17:48:32 -0400

> On Oct 16, 2018, at 10:33 AM, John R. Levine <[email-masked]> wrote:
> 
> I don't feel terribly strongly about it but if the Trust is supposed to be independent of the IETF, it seems wrong to let the IETF unilaterally fire everyone.

The Beneficiary of the Trust shall be the IETF as a whole and not any individuals who may participate in IETF activities.   So, the trustees being accountable to the IETF as a whole seems just right to me, regardless of the body that appointed them.

Also, recall is not an easy process.  Recall that we learned that when an IAOC member stopped participating altogether.  This means that recall will not be used for minor things.

Russ

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2018 17:54:04 -0400

> Also, recall is not an easy process.  Recall that we learned that when an IAOC member stopped participating altogether.  This means that recall will not be used for minor things.

Well, yes, that told us that the recall process is not, as they say in the 
UK, fit for purpose, but that's a separate can of worms.

The chances of a trustee being recalled is remote so I don't think it's 
worth further ratholing.  Leave it alone and I'll adjust the draft 
trust admin procedures to match.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 16 Oct 2018 20:33:21 -0400

>>  Board, which allows ISOC- and IESG-appointed directors to be recalled
>>  using the BCP 10 process.

I took another look at the LLC agreement.  The IETF cannot recall the ISOC 
appointed member.  See Appendix A, section 9.

>>>  that nomcom appointed trustees can be recalled by the BCP 10 process,
>>>  IESG and ISOC trustees can be recalled by the appointing bodies.  It
>>>  seems kind of odd to have the appointment and recall processes not match.

Regards,

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Oct 2018 09:28:43 +0200

> On Oct 17, 2018, at 2:33 AM, John R. Levine <[email-masked]> wrote:
> 
> I took another look at the LLC agreement.  The IETF cannot recall the ISOC appointed member.  See Appendix A, section 9.

Ah sorry, I misread that.
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Oct 2018 06:50:24 -0400

Ok, here is my suggestion:

OLD 
The processes regarding NomCom appointments and recalls of Trustees for the IETF Trust follow those described in [RFC7437].  For the appointments by the IESG, the IESG is expected to run an open selection process and to consider the necessary skill set and conflicts of interest as part of that process.

NEW 
Trustees appointed by the IETF NomCom may be recalled according to the recall process described in [BCP 10]. Trustees appointed by the IESG or by the ISOC Board of Directors may be recalled by the appointing body.  For the appointments by the IESG, the IESG is expected to run an open selection process and to consider the necessary skill set and conflicts of interest as part of that process.

This mirrors the language John is working on for the Trust admin procedures (although I dropped the notion that the IESG and ISOC Board must vote to recall someone, because the IESG does not always vote). I cite BCP 10 instead of RFC 7437 since the BCP number is stable.

If this works for people I’ll put it in an RFC Editor note and approve the document.

Alissa

> On Oct 17, 2018, at 3:28 AM, Alissa Cooper <[email-masked]> wrote:
> 
> 
>

---

From: "John R. Levine" <[email-masked]>
Date: 22 Oct 2018 12:59:43 +0200

> Trustees appointed by the IETF NomCom may be recalled according to the 
> recall process described in [BCP 10]. Trustees appointed by the IESG or 
> by the ISOC Board of Directors may be recalled by the appointing body. 
> For the appointments by the IESG, the IESG is expected to run an open 
> selection process and to consider the necessary skill set and conflicts 
> of interest as part of that process.

OK with me.

R's de Barcelona,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2018 09:32:45 +1300

OK for me

   Brian

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 25 Oct 2018 13:15:11 -0500

Section 2 says that NomCom-appointed Trustees can be recalled according 
to 7437 (presumably bis). Can the IESG-appointed and ISOC-BoT-appointed 
Trustees be recalled or otherwise removed as Trustees? If so, by what 
mechanism? I don't have any opinion on what the mechanism should be 
(e.g., the appointing body can simply say, "You're fired", or the 7437 
process could be used, or ...), but I do think there needs to be some 
mechanism specified for removing them if necessary.

pr

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 25 Oct 2018 13:18:42 -0500

On 25 Oct 2018, at 13:15, Pete Resnick wrote:

> Section 2 says that NomCom-appointed Trustees can be recalled 
> according to 7437 (presumably bis). Can the IESG-appointed and 
> ISOC-BoT-appointed Trustees be recalled or otherwise removed as 
> Trustees? If so, by what mechanism? I don't have any opinion on what 
> the mechanism should be (e.g., the appointing body can simply say, 
> "You're fired", or the 7437 process could be used, or ...), but I do 
> think there needs to be some mechanism specified for removing them if 
> necessary.

My apologies; I see this has already been resolved.

pr