Subject: Re: [Iasa20] Issues with draft-ietf-iasa2-rfc5377bis-01

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 5 Nov 2018 15:44:30 +0000

After quite a bit of discussion, the WG chairs have asked Joel to add the text suggested by WG members (see below) to 5377bis. This should free us up to proceed on the trust drafts and then on 5377. If anyone has concerns with that, please speak up now. Thanks!
JL

Proposed text:
Any member of the IETF community may appeal a decision of the trust by transmitting the appeal to the Chair. The Chair shall present the appeal to the Trustees for consideration and possible action, and shall inform the appellant of the Trustees’ decision. Trustees appointed by the IETF NomCom may be recalled by the member recall process described in section 7 of BCP 10. Trustees appointed by the IESG or by the ISOC Board of Directors may be recalled by vote of the appointing body.

On 10/24/18, 11:35 AM, "iasa20 on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    In article <[email-masked]> you write:
    >Joel helpfully clarified this for me off-list. I read this to mean “other than BCP 101” but it is intended to
    >mean “other than this document.”
    >
    >I wonder if it would be possible to describe two buckets of trust decisions and apply the appeals process to one
    >of them, sort of how 4071 does for IAOC decisions. For example, if the trust were to make a bunch of updates to
    >the trust agreement without consulting with the community, that seems like something that could be appealable. No
    >appeal could really be binding — that is, even if such a decision were appealed the trust couldn’t be forced
    >to retract the changes — but if the community wants to make provision for process appeals of that sort that
    >could probably be written down.
    
    If the trustees did something as egregious as unilaterally amending
    the trust, and their response to an informal appeal was anything other
    than holy smokes, we screwed up, we'll redo it right, the appropriate
    response would be to fire them and replace them with people who
    understand what their job is.  This seems to me like process for the
    sake of process to deal with vanishingly unlikely situations.
    
    R's,
    John
    
    _______________________________________________
    iasa20 mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iasa20

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Nov 2018 11:34:31 -0500

Jason,

I don't believe that 5377bis is the optimal place to put that
text, but can live with it if that is what the WG wants to do.

John Levine's comment notwithstanding, or perhaps because of it,
I'm a bit concerned about having a group that can make important
policies that is not accountable to the community.   His comment
"fire them and replace them with people who understand what
their job is" seems exactly right, but we don't seem to have a
"fire them" mechanism available: the recall mechanism couldn't
be more difficult to use if we had designed it to be; in the
context of the sort of situation John hypothesizes, the
community's having to beg, e.g., the IESG and IAB to remove
members rather than being able to do it directly (even if those
bodies appoint replacements) seems broken; etc.   But it is
probably late to be asking for reconsideration of those issues
and I join with John in hoping that situations that would
require firing all or most of the Trustees will never occur.

thanks
   john

--On Monday, November 5, 2018 15:44 +0000 "Livingood, Jason"
<[email-masked]> wrote:

> After quite a bit of discussion, the WG chairs have asked Joel
> to add the text suggested by WG members (see below) to
> 5377bis. This should free us up to proceed on the trust drafts
> and then on 5377. If anyone has concerns with that, please
> speak up now. Thanks! JL
> 
> Proposed text:
> Any member of the IETF community may appeal a decision of the
> trust by transmitting the appeal to the Chair. The Chair shall
> present the appeal to the Trustees for consideration and
> possible action, and shall inform the appellant of the
> Trustees' decision. Trustees appointed by the IETF NomCom
> may be recalled by the member recall process described in
> section 7 of BCP 10. Trustees appointed by the IESG or by the
> ISOC Board of Directors may be recalled by vote of the
> appointing body.
> 
> On 10/24/18, 11:35 AM, "iasa20 on behalf of John Levine"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     In article
> <[email-masked]> you write:
> >Joel helpfully clarified this for me off-list. I read this to
> mean "other than BCP 101" but it is intended to     >mean
> "other than this document."
>     >
>     >I wonder if it would be possible to describe two buckets
> of trust decisions and apply the appeals process to one
> >of them, sort of how 4071 does for IAOC decisions. For
> example, if the trust were to make a bunch of updates to
> >the trust agreement without consulting with the community,
> that seems like something that could be appealable. No
> >appeal could really be binding — that is, even if such a
> decision were appealed the trust couldn't be forced     >to
> retract the changes — but if the community wants to make
> provision for process appeals of that sort that     >could
> probably be written down.
>     
>     If the trustees did something as egregious as unilaterally
> amending     the trust, and their response to an informal
> appeal was anything other     than holy smokes, we screwed up,
> we'll redo it right, the appropriate     response would be to
> fire them and replace them with people who     understand what
> their job is.  This seems to me like process for the     sake
> of process to deal with vanishingly unlikely situations.     
>     R's,
>     John
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 5 Nov 2018 17:12:49 +0000

I sympathize with your concern over the replacement mechanism for the Trust. If the community and Trust think deeper changes are needed, then the community may want to consider taking that work up in a new WG I suppose. 

In terms of putting this into 5377bis, I am glad to hear you could live with it. But where else do you feel that should go if not 5377bis?

Jason

On 11/5/18, 11:34 AM, "iasa20 on behalf of John C Klensin" <[email-masked] on behalf of [email-masked]> wrote:

    Jason,

    
    thanks
       john

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Nov 2018 13:46:24 -0500

--On Monday, November 5, 2018 17:12 +0000 "Livingood, Jason"
<[email-masked]> wrote:

> I sympathize with your concern over the replacement mechanism
> for the Trust. If the community and Trust think deeper changes
> are needed, then the community may want to consider taking
> that work up in a new WG I suppose. 

Probably the right answer, especially since changes there might
imply an overhaul of some other procedures.

> In terms of putting this into 5377bis, I am glad to hear you
> could live with it. But where else do you feel that should go
> if not 5377bis?

To me, 5377 and 5377bis are IPR documents, not Trust management
documents.  Stuffing procedures for oversight of the Trustees in
there seems a little strange (I think that is consistent with
some comments Joel made a while ago) and was weird in 5377
itself.  

Consistent with the model of discussing selection and recall in
the same place (cf draft-ietf-iasa2-rfc7437bis and its many
predecessors going back to RFC 2027) and viewing this as
something about the Trust that is necessitated by the split from
the IAOC, I think it belongs, along with Trustee selection, in
draft-ietf-iasa2-trust-update, with rationale, if needed, in
draft-ietf-iasa2-trust-rationale.   That would have another
advantage: putting the suggested text into 5377bis really
requires a normative reference there to
draft-ietf-iasa2-trust-update to answer the quite reasonable
question "ok, and how are Trustees appointed and by whom"?

Again, I'm not going to try to hold things up over this but I
would not be at all disappointed it the WG decided to revisit
the questions.

FWIW, I feel _much_ more strongly about replacing, rather than
narrowly updating, fundamental procedural, charter, RFC Editor
documents, etc.

    best,
     john

> Jason
伀渀 ㄀㄀⼀㔀⼀㄀㠀Ⰰ ㄀㄀㨀㌀㐀 䄀䴀Ⰰ ∀椀愀猀愀㈀　 漀渀 戀攀栀愀氀昀 漀昀 䨀漀栀渀 䌀 䬀氀攀渀猀椀渀∀ഀ਀㸀 㰀椀愀猀愀㈀　ⴀ戀漀甀渀挀攀猀䀀椀攀琀昀⸀漀爀最 漀渀 戀攀栀愀氀昀 漀昀 樀漀栀渀ⴀ椀攀琀昀䀀樀挀欀⸀挀漀洀㸀 眀爀漀琀攀㨀ഀ਀㸀 ഀ਀㸀     䨀愀猀漀渀Ⰰഀ਀㸀     ഀ਀㸀     䤀 搀漀渀✀�
� 戀攀氀椀攀瘀攀 琀栀愀琀 㔀㌀㜀㜀戀椀猀 椀猀 琀栀攀 漀瀀琀椀洀愀氀 瀀氀愀挀攀 琀漀 瀀甀琀ഀ਀㸀 琀栀愀琀     琀攀砀琀Ⰰ 戀甀琀 挀愀渀 氀椀瘀攀 眀椀琀栀 椀琀 椀昀 琀栀愀琀 椀猀 眀栀愀琀 琀栀攀 圀䜀ഀ਀㸀 眀愀渀琀猀 琀漀 搀漀⸀     ഀ਀㸀     䨀漀栀渀 䰀攀瘀椀渀攀✀猀 挀漀洀洀攀渀琀 渀漀琀眀�
��琀栀猀琀愀渀搀椀渀最Ⰰ 漀爀 瀀攀爀栀愀瀀猀 戀攀挀愀甀猀攀ഀ਀㸀 漀昀 椀琀Ⰰ     䤀✀洀 愀 戀椀琀 挀漀渀挀攀爀渀攀搀 愀戀漀甀琀 栀愀瘀椀渀最 愀 最爀漀甀瀀 琀栀愀琀 挀愀渀ഀ਀㸀 洀愀欀攀 椀洀瀀漀爀琀愀渀琀     瀀漀氀椀挀椀攀猀 琀栀愀琀 椀猀 渀漀琀 愀挀挀漀甀渀琀愀戀氀攀 琀漀 琀栀攀ഀ਀㸀 挀漀洀洀甀渀
椀琀礀⸀   䠀椀猀 挀漀洀洀攀渀琀     ∀昀椀爀攀 琀栀攀洀 愀渀搀 爀攀瀀氀愀挀攀 琀栀攀洀 眀椀琀栀ഀ਀㸀 瀀攀漀瀀氀攀 眀栀漀 甀渀搀攀爀猀琀愀渀搀 眀栀愀琀     琀栀攀椀爀 樀漀戀 椀猀∀ 猀攀攀洀猀 攀砀愀挀琀氀礀ഀ਀㸀 爀椀最栀琀Ⰰ 戀甀琀 眀攀 搀漀渀✀琀 猀攀攀洀 琀漀 栀愀瘀攀 愀     ∀昀椀爀攀 �
�栀攀洀∀ 洀攀挀栀愀渀椀猀洀ഀ਀㸀 愀瘀愀椀氀愀戀氀攀㨀 琀栀攀 爀攀挀愀氀氀 洀攀挀栀愀渀椀猀洀 挀漀甀氀搀渀✀琀     戀攀 洀漀爀攀 搀椀昀昀椀挀甀氀琀ഀ਀㸀 琀漀 甀猀攀 椀昀 眀攀 栀愀搀 搀攀猀椀最渀攀搀 椀琀 琀漀 戀攀㬀 椀渀 琀栀攀     挀漀渀琀攀砀琀 漀昀 琀栀攀ഀ਀㸀 猀漀爀琀 漀昀 猀椀琀甀愀琀椀漀渀�
��䨀漀栀渀 栀礀瀀漀琀栀攀猀椀稀攀猀Ⰰ 琀栀攀     挀漀洀洀甀渀椀琀礀✀猀ഀ਀㸀 栀愀瘀椀渀最 琀漀 戀攀最Ⰰ 攀⸀最⸀Ⰰ 琀栀攀 䤀䔀匀䜀 愀渀搀 䤀䄀䈀 琀漀 爀攀洀漀瘀攀     洀攀洀戀攀爀猀ഀ਀㸀 爀愀琀栀攀爀 琀栀愀渀 戀攀椀渀最 愀戀氀攀 琀漀 搀漀 椀琀 搀椀爀攀挀琀氀礀 ⠀攀瘀攀渀 椀昀 琀栀漀猀攀ഀ਀㸀 戀漀
搀椀攀猀 愀瀀瀀漀椀渀琀 爀攀瀀氀愀挀攀洀攀渀琀猀⤀ 猀攀攀洀猀 戀爀漀欀攀渀㬀 攀琀挀⸀   䈀甀琀 椀琀 椀猀ഀ਀㸀 瀀爀漀戀愀戀氀礀 氀愀琀攀 琀漀 戀攀 愀猀欀椀渀最 昀漀爀 爀攀挀漀渀猀椀搀攀爀愀琀椀漀渀 漀昀 琀栀漀猀攀 椀猀猀甀攀猀ഀ਀㸀     愀渀搀 䤀 樀漀椀渀 眀椀琀栀 䨀漀栀渀 椀渀 栀漀瀀椀渀最 琀栀愀琀�
�猀椀琀甀愀琀椀漀渀猀 琀栀愀琀 眀漀甀氀搀ഀ਀㸀     爀攀焀甀椀爀攀 昀椀爀椀渀最 愀氀氀 漀爀 洀漀猀琀 漀昀 琀栀攀 吀爀甀猀琀攀攀猀 眀椀氀氀 渀攀瘀攀爀ഀ਀㸀 漀挀挀甀爀⸀     ഀ਀㸀     琀栀愀渀欀猀ഀ਀㸀        樀漀栀渀ഀ਀㸀     ഀ਀㸀     ⴀⴀ伀渀 䴀漀渀搀愀礀Ⰰ 一漀瘀攀洀戀攀爀 㔀Ⰰ�
��㈀　㄀㠀 ㄀㔀㨀㐀㐀 ⬀　　　　 ∀䰀椀瘀椀渀最漀漀搀Ⰰഀ਀㸀 䨀愀猀漀渀∀     㰀䨀愀猀漀渀开䰀椀瘀椀渀最漀漀搀䀀挀漀洀挀愀猀琀⸀挀漀洀㸀 眀爀漀琀攀㨀ഀ਀㸀     ഀ਀㸀     㸀 䄀昀琀攀爀 焀甀椀琀攀 愀 戀椀琀 漀昀 搀椀猀挀甀猀猀椀漀渀Ⰰ 琀栀攀 圀䜀 挀栀愀椀爀猀 栀愀瘀攀ഀ਀㸀 愀猀欀攀搀 䨀漀攀氀    
 㸀 琀漀 愀搀搀 琀栀攀 琀攀砀琀 猀甀最最攀猀琀攀搀 戀礀 圀䜀 洀攀洀戀攀爀猀 ⠀猀攀攀ഀ਀㸀 戀攀氀漀眀⤀ 琀漀     㸀 㔀㌀㜀㜀戀椀猀⸀ 吀栀椀猀 猀栀漀甀氀搀 昀爀攀攀 甀猀 甀瀀 琀漀 瀀爀漀挀攀攀搀 漀渀ഀ਀㸀 琀栀攀 琀爀甀猀琀 搀爀愀昀琀猀     㸀 愀渀搀 琀栀攀渀 漀渀 㔀㌀㜀㜀⸀ 䤀昀 愀渀礀漀渀攀�
�栀愀猀ഀ਀㸀 挀漀渀挀攀爀渀猀 眀椀琀栀 琀栀愀琀Ⰰ 瀀氀攀愀猀攀     㸀 猀瀀攀愀欀 甀瀀 渀漀眀⸀ 吀栀愀渀欀猀℀ 䨀䰀ഀ਀㸀     㸀 ഀ਀㸀     㸀 倀爀漀瀀漀猀攀搀 琀攀砀琀㨀ഀ਀㸀     㸀 䄀渀礀 洀攀洀戀攀爀 漀昀 琀栀攀 䤀䔀吀䘀 挀漀洀洀甀渀椀琀礀 洀愀礀 愀瀀瀀攀愀氀 愀 搀攀挀椀猀椀漀渀ഀ਀㸀 �
��昀 琀栀攀     㸀 琀爀甀猀琀 戀礀 琀爀愀渀猀洀椀琀琀椀渀最 琀栀攀 愀瀀瀀攀愀氀 琀漀 琀栀攀 䌀栀愀椀爀⸀ഀ਀㸀 吀栀攀 䌀栀愀椀爀 猀栀愀氀氀     㸀 瀀爀攀猀攀渀琀 琀栀攀 愀瀀瀀攀愀氀 琀漀 琀栀攀 吀爀甀猀琀攀攀猀 昀漀爀ഀ਀㸀 挀漀渀猀椀搀攀爀愀琀椀漀渀 愀渀搀     㸀 瀀漀猀猀椀戀氀攀 愀挀琀椀漀渀Ⰰ
 愀渀搀 猀栀愀氀氀 椀渀昀漀爀洀 琀栀攀ഀ਀㸀 愀瀀瀀攀氀氀愀渀琀 漀昀 琀栀攀     㸀 吀爀甀猀琀攀攀猀✀ 搀攀挀椀猀椀漀渀⸀ 吀爀甀猀琀攀攀猀 愀瀀瀀漀椀渀琀攀搀ഀ਀㸀 戀礀 琀栀攀 䤀䔀吀䘀 一漀洀䌀漀洀     㸀 洀愀礀 戀攀 爀攀挀愀氀氀攀搀 戀礀 琀栀攀 洀攀洀戀攀爀 爀攀挀愀氀氀ഀ਀㸀 瀀爀漀挀攀猀猀 搀攀猀�
�爀椀戀攀搀 椀渀     㸀 猀攀挀琀椀漀渀 㜀 漀昀 䈀䌀倀 ㄀　⸀ 吀爀甀猀琀攀攀猀ഀ਀㸀 愀瀀瀀漀椀渀琀攀搀 戀礀 琀栀攀 䤀䔀匀䜀 漀爀 戀礀 琀栀攀     㸀 䤀匀伀䌀 䈀漀愀爀搀 漀昀 䐀椀爀攀挀琀漀爀猀ഀ਀㸀 洀愀礀 戀攀 爀攀挀愀氀氀攀搀 戀礀 瘀漀琀攀 漀昀 琀栀攀     㸀 愀瀀瀀漀椀渀琀椀渀最 戀漀搀礀⸀�
��਀㸀     㸀 ഀ਀㸀     㸀 伀渀 ㄀　⼀㈀㐀⼀㄀㠀Ⰰ ㄀㄀㨀㌀㔀 䄀䴀Ⰰ ∀椀愀猀愀㈀　 漀渀 戀攀栀愀氀昀 漀昀 䨀漀栀渀 䰀攀瘀椀渀攀∀ഀ਀㸀     㸀 㰀椀愀猀愀㈀　ⴀ戀漀甀渀挀攀猀䀀椀攀琀昀⸀漀爀最 漀渀 戀攀栀愀氀昀 漀昀 樀漀栀渀氀䀀琀愀甀最栀⸀挀漀洀㸀ഀ਀㸀 眀爀漀琀攀㨀     㸀 ഀ਀㸀     㸀 
    䤀渀 愀爀琀椀挀氀攀ഀ਀㸀     㸀 㰀㄀㜀䔀䄀䈀㔀䌀㌀ⴀ㔀㤀䄀㔀ⴀ㐀　㐀䘀ⴀ㠀㜀䔀㐀ⴀ㌀㤀䈀㠀㤀䘀㄀䐀㠀㐀䈀㐀䀀挀漀漀瀀攀爀眀⸀椀渀㸀 礀漀甀ഀ਀㸀 眀爀椀琀攀㨀     㸀 㸀䨀漀攀氀 栀攀氀瀀昀甀氀氀礀 挀氀愀爀椀昀椀攀搀 琀栀椀猀 昀漀爀 洀攀 漀昀昀ⴀ氀椀猀琀⸀ 䤀ഀ਀㸀 爀攀愀搀 琀栀椀猀 琀漀     㸀 �
�攀愀渀 ∀漀琀栀攀爀 琀栀愀渀 䈀䌀倀 ㄀　㄀∀ 戀甀琀 椀琀 椀猀ഀ਀㸀 椀渀琀攀渀搀攀搀 琀漀     㸀洀攀愀渀     㸀 ∀漀琀栀攀爀 琀栀愀渀 琀栀椀猀 搀漀挀甀洀攀渀琀⸀∀ഀ਀㸀     㸀     㸀ഀ਀㸀     㸀     㸀䤀 眀漀渀搀攀爀 椀昀 椀琀 眀漀甀氀搀 戀攀 瀀漀猀猀椀戀氀攀 琀漀 搀攀猀挀爀椀戀�
�� 琀眀漀ഀ਀㸀 戀甀挀欀攀琀猀     㸀 漀昀 琀爀甀猀琀 搀攀挀椀猀椀漀渀猀 愀渀搀 愀瀀瀀氀礀 琀栀攀 愀瀀瀀攀愀氀猀 瀀爀漀挀攀猀猀ഀ਀㸀 琀漀 漀渀攀     㸀 㸀漀昀 琀栀攀洀Ⰰ 猀漀爀琀 漀昀 栀漀眀 㐀　㜀㄀ 搀漀攀猀 昀漀爀 䤀䄀伀䌀ഀ਀㸀 搀攀挀椀猀椀漀渀猀⸀ 䘀漀爀     㸀 攀砀愀洀瀀氀攀Ⰰ 椀昀 琀栀
攀 琀爀甀猀琀 眀攀爀攀 琀漀 洀愀欀攀 愀ഀ਀㸀 戀甀渀挀栀 漀昀 甀瀀搀愀琀攀猀 琀漀     㸀 㸀琀栀攀 琀爀甀猀琀 愀最爀攀攀洀攀渀琀 眀椀琀栀漀甀琀ഀ਀㸀 挀漀渀猀甀氀琀椀渀最 眀椀琀栀 琀栀攀 挀漀洀洀甀渀椀琀礀Ⰰ     㸀 琀栀愀琀 猀攀攀洀猀 氀椀欀攀 猀漀洀攀琀栀椀渀最ഀ਀㸀 琀栀愀琀 挀漀甀氀搀 戀攀 愀瀀�
�攀愀氀愀戀氀攀⸀ 一漀     㸀 㸀愀瀀瀀攀愀氀 挀漀甀氀搀 爀攀愀氀氀礀 戀攀ഀ਀㸀 戀椀渀搀椀渀最 ᐠ 琀栀愀琀 椀猀Ⰰ 攀瘀攀渀 椀昀 猀甀挀栀 愀     㸀 搀攀挀椀猀椀漀渀 眀攀爀攀ഀ਀㸀 愀瀀瀀攀愀氀攀搀 琀栀攀 琀爀甀猀琀 挀漀甀氀搀渀✀琀 戀攀 昀漀爀挀攀搀     㸀琀漀     㸀 爀攀琀爀愀挀琀ഀ਀㸀 琀�
��攀 挀栀愀渀最攀猀 ᐠ 戀甀琀 椀昀 琀栀攀 挀漀洀洀甀渀椀琀礀 眀愀渀琀猀 琀漀 洀愀欀攀     㸀ഀ਀㸀 瀀爀漀瘀椀猀椀漀渀 昀漀爀 瀀爀漀挀攀猀猀 愀瀀瀀攀愀氀猀 漀昀 琀栀愀琀 猀漀爀琀 琀栀愀琀     㸀挀漀甀氀搀ഀ਀㸀 㸀 瀀爀漀戀愀戀氀礀 戀攀 眀爀椀琀琀攀渀 搀漀眀渀⸀ഀ਀㸀     㸀     ഀ਀㸀    
 㸀     䤀昀 琀栀攀 琀爀甀猀琀攀攀猀 搀椀搀 猀漀洀攀琀栀椀渀最 愀猀 攀最爀攀最椀漀甀猀 愀猀ഀ਀㸀 甀渀椀氀愀琀攀爀愀氀氀礀     㸀 愀洀攀渀搀椀渀最     琀栀攀 琀爀甀猀琀Ⰰ 愀渀搀 琀栀攀椀爀 爀攀猀瀀漀渀猀攀ഀ਀㸀 琀漀 愀渀 椀渀昀漀爀洀愀氀     㸀 愀瀀瀀攀愀氀 眀愀猀 愀渀礀琀栀椀渀最 漀琀栀攀�
�     琀栀愀渀 栀漀氀礀ഀ਀㸀 猀洀漀欀攀猀Ⰰ 眀攀 猀挀爀攀眀攀搀 甀瀀Ⰰ     㸀 眀攀✀氀氀 爀攀搀漀 椀琀 爀椀最栀琀Ⰰ 琀栀攀ഀ਀㸀 愀瀀瀀爀漀瀀爀椀愀琀攀     爀攀猀瀀漀渀猀攀 眀漀甀氀搀 戀攀 琀漀     㸀 昀椀爀攀 琀栀攀洀 愀渀搀ഀ਀㸀 爀攀瀀氀愀挀攀 琀栀攀洀 眀椀琀栀 瀀攀漀瀀氀攀 眀栀漀   �
�� 甀渀搀攀爀猀琀愀渀搀 眀栀愀琀     㸀 琀栀攀椀爀ഀ਀㸀 樀漀戀 椀猀⸀  吀栀椀猀 猀攀攀洀猀 琀漀 洀攀 氀椀欀攀 瀀爀漀挀攀猀猀 昀漀爀 琀栀攀     猀愀欀攀     㸀ഀ਀㸀 漀昀 瀀爀漀挀攀猀猀 琀漀 搀攀愀氀 眀椀琀栀 瘀愀渀椀猀栀椀渀最氀礀 甀渀氀椀欀攀氀礀 猀椀琀甀愀琀椀漀渀猀⸀     ഀ਀㸀     
㸀     刀✀猀Ⰰഀ਀㸀     㸀     䨀漀栀渀ഀ਀㸀     㸀     ഀ਀㸀     㸀     开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开ഀ਀㸀     㸀     椀愀猀愀㈀　 洀愀椀氀椀渀最 氀椀猀琀ഀ਀㸀     㸀     椀愀猀愀㈀　䀀椀攀琀昀⸀漀爀最ഀ�
�㸀     㸀     栀琀琀瀀猀㨀⼀⼀眀眀眀⸀椀攀琀昀⸀漀爀最⼀洀愀椀氀洀愀渀⼀氀椀猀琀椀渀昀漀⼀椀愀猀愀㈀　ഀ਀㸀     㸀     ഀ਀㸀     㸀 ഀ਀㸀     ഀ਀㸀     ഀ਀㸀     ഀ਀㸀     ഀ਀㸀     开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开开�
��ഀ਀㸀     椀愀猀愀㈀　 洀愀椀氀椀渀最 氀椀猀琀ഀ਀㸀     椀愀猀愀㈀　䀀椀攀琀昀⸀漀爀最ഀ਀㸀     栀琀琀瀀猀㨀⼀⼀眀眀眀⸀椀攀琀昀⸀漀爀最⼀洀愀椀氀洀愀渀⼀氀椀猀琀椀渀昀漀⼀椀愀猀愀㈀　ഀ਀㸀     ഀ਀㸀 ഀ਀ഀ਀ഀ਀ഀ਀

---

From: "John R Levine" <[email-masked]>
Date: 6 Nov 2018 07:06:16 +0700

On Mon, 5 Nov 2018, John C Klensin wrote:
> bodies appoint replacements) seems broken; etc.

The nomcom appoints a majority of the trustees.  Even if the IESG and ISOC 
chose not to recall their members, the nomcom ultimately controls the 
trust's descisions.

>  But it is probably late to be asking for reconsideration of those 
> issues and I join with John in hoping that situations that would require 
> firing all or most of the Trustees will never occur.

Has there ever been an appeal in the decade the trust has existed?   This 
seems awfully hypothetical.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Nov 2018 19:47:52 -0500

--On Tuesday, November 6, 2018 07:06 +0700 John R Levine
<[email-masked]> wrote:

>> members rather than being able to do it directly (even if
>> those bodies appoint replacements) seems broken; etc.
> 
> The nomcom appoints a majority of the trustees.  Even if the
> IESG and ISOC chose not to recall their members, the nomcom
> ultimately controls the trust's descisions.
> 
>>  But it is probably late to be asking for reconsideration of
>>  those  issues and I join with John in hoping that situations
>> that would require  firing all or most of the Trustees will
>> never occur.
> 
> Has there ever been an appeal in the decade the trust has
> existed?   This seems awfully hypothetical.

Provisions to remove people, especially if one has asked them to
reconsider an issue and they behave inappropriately, are, almost
by definition, hypothetical.  If the selection process does its
job well, those situations are also very unlikely.   However,
one ultimately makes one of two assumptions.   One is that the
selection process is infallible and the odds are about zero of,
e.g., a few strong personalities convincing the other Trustees
to do something that the IETF community wouldn't like but they
believe the community would want if only its members were not so
ignorant and knew what was good for them.   The other is that no
process is infallible and, more important, that having
mechanisms for community oversight, especially including ways
for the community to insist on explanations of decisions, are
useful in their own right.

>From the latter perspective, having an appeal mechanism reminds
people that they are accountable to the community and cannot
behave arbitrarily, out of self-interest, etc.  Its not being
used may demonstrate that it was unnecessary, but could equally
demonstrate that it is doing its job.  And, again, I don't need
to anticipate that the mechanism will be used regularly to
believe that having a mechanism in place that could be used, and
used effectively, is a good idea.

    best,
   john

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 6 Nov 2018 17:08:46 +0700

Given this discussion and some timing constraints around the new trustee selection processes, I went ahead and approved draft-iasa2-trust-update and draft-iasa2-trust-rationale for publication. I appreciate people’s flexibility here. Although it would be unusual, I suspect that if people do not want to put the appeals text in 5377bis that a bis to draft-iasa2-trust-update containing the appeals text could get done before the new trustees are seated in March.

Alissa

> On Nov 6, 2018, at 1:46 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> itself.  Consistent with the model of discussing selection and recall in
> �琀栀猀琀愀渀搀椀渀最Ⰰ 漀爀 瀀攀爀栀愀瀀猀 戀攀挀愀甀猀攀ഀ਀㸀 漀昀 椀琀Ⰰ     䤀✀洀 愀 戀椀琀 挀漀渀挀攀爀渀攀搀 愀戀漀甀琀 栀愀瘀椀渀最 愀 最爀漀甀瀀 琀栀愀琀 挀愀渀ഀ਀㸀 洀愀欀攀 椀洀瀀漀爀琀愀渀琀     瀀漀氀椀挀椀攀猀 琀栀愀琀 椀猀 渀漀琀 愀挀挀漀甀渀琀愀戀氀攀 琀漀 琀栀攀ഀ਀㸀 挀漀洀洀甀渀
> �䨀漀栀渀 栀礀瀀漀琀栀攀猀椀稀攀猀Ⰰ 琀栀攀     挀漀洀洀甀渀椀琀礀✀猀ഀ਀㸀 栀愀瘀椀渀最 琀漀 戀攀最Ⰰ 攀⸀最⸀Ⰰ 琀栀攀 䤀䔀匀䜀 愀渀搀 䤀䄀䈀 琀漀 爀攀洀漀瘀攀     洀攀洀戀攀爀猀ഀ਀㸀 爀愀琀栀攀爀 琀栀愀渀 戀攀椀渀最 愀戀氀攀 琀漀 搀漀 椀琀 搀椀爀攀挀琀氀礀 ⠀攀瘀攀渀 椀昀 琀栀漀猀攀ഀ਀㸀 戀漀
> �㈀　㄀㠀 ㄀㔀㨀㐀㐀 ⬀　　　　 ∀䰀椀瘀椀渀最漀漀搀Ⰰഀ਀㸀 䨀愀猀漀渀∀     㰀䨀愀猀漀渀开䰀椀瘀椀渀最漀漀搀䀀挀漀洀挀愀猀琀⸀挀漀洀㸀 眀爀漀琀攀㨀ഀ਀㸀     ഀ਀㸀     㸀 䄀昀琀攀爀 焀甀椀琀攀 愀 戀椀琀 漀昀 搀椀猀挀甀猀猀椀漀渀Ⰰ 琀栀攀 圀䜀 挀栀愀椀爀猀 栀愀瘀攀ഀ਀㸀 愀猀欀攀搀 䨀漀攀氀    
> �昀 琀栀攀     㸀 琀爀甀猀琀 戀礀 琀爀愀渀猀洀椀琀琀椀渀最 琀栀攀 愀瀀瀀攀愀氀 琀漀 琀栀攀 䌀栀愀椀爀⸀ഀ਀㸀 吀栀攀 䌀栀愀椀爀 猀栀愀氀氀     㸀 瀀爀攀猀攀渀琀 琀栀攀 愀瀀瀀攀愀氀 琀漀 琀栀攀 吀爀甀猀琀攀攀猀 昀漀爀ഀ਀㸀 挀漀渀猀椀搀攀爀愀琀椀漀渀 愀渀搀     㸀 瀀漀猀猀椀戀氀攀 愀挀琀椀漀渀Ⰰ
> �਀㸀     㸀 ഀ਀㸀     㸀 伀渀 ㄀　⼀㈀㐀⼀㄀㠀Ⰰ ㄀㄀㨀㌀㔀 䄀䴀Ⰰ ∀椀愀猀愀㈀　 漀渀 戀攀栀愀氀昀 漀昀 䨀漀栀渀 䰀攀瘀椀渀攀∀ഀ਀㸀     㸀 㰀椀愀猀愀㈀　ⴀ戀漀甀渀挀攀猀䀀椀攀琀昀⸀漀爀最 漀渀 戀攀栀愀氀昀 漀昀 樀漀栀渀氀䀀琀愀甀最栀⸀挀漀洀㸀ഀ਀㸀 眀爀漀琀攀㨀     㸀 ഀ਀㸀     㸀 
> � 琀眀漀ഀ਀㸀 戀甀挀欀攀琀猀     㸀 漀昀 琀爀甀猀琀 搀攀挀椀猀椀漀渀猀 愀渀搀 愀瀀瀀氀礀 琀栀攀 愀瀀瀀攀愀氀猀 瀀爀漀挀攀猀猀ഀ਀㸀 琀漀 漀渀攀     㸀 㸀漀昀 琀栀攀洀Ⰰ 猀漀爀琀 漀昀 栀漀眀 㐀　㜀㄀ 搀漀攀猀 昀漀爀 䤀䄀伀䌀ഀ਀㸀 搀攀挀椀猀椀漀渀猀⸀ 䘀漀爀     㸀 攀砀愀洀瀀氀攀Ⰰ 椀昀 琀栀
> �攀 挀栀愀渀最攀猀 ᐠ 戀甀琀 椀昀 琀栀攀 挀漀洀洀甀渀椀琀礀 眀愀渀琀猀 琀漀 洀愀欀攀     㸀ഀ਀㸀 瀀爀漀瘀椀猀椀漀渀 昀漀爀 瀀爀漀挀攀猀猀 愀瀀瀀攀愀氀猀 漀昀 琀栀愀琀 猀漀爀琀 琀栀愀琀     㸀挀漀甀氀搀ഀ਀㸀 㸀 瀀爀漀戀愀戀氀礀 戀攀 眀爀椀琀琀攀渀 搀漀眀渀⸀ഀ਀㸀     㸀     ഀ਀㸀    
> � 甀渀搀攀爀猀琀愀渀搀 眀栀愀琀     㸀 琀栀攀椀爀ഀ਀㸀 樀漀戀 椀猀⸀  吀栀椀猀 猀攀攀洀猀 琀漀 洀攀 氀椀欀攀 瀀爀漀挀攀猀猀 昀漀爀 琀栀攀     猀愀欀攀     㸀ഀ਀㸀 漀昀 瀀爀漀挀攀猀猀 琀漀 搀攀愀氀 眀椀琀栀 瘀愀渀椀猀栀椀渀最氀礀 甀渀氀椀欀攀氀礀 猀椀琀甀愀琀椀漀渀猀⸀     ഀ਀㸀     
> #<^_NSEDR_^#<ഀ਀㸀     椀愀猀愀㈀　 洀愀椀氀椀渀最 氀椀猀琀ഀ਀㸀     椀愀猀愀㈀　䀀椀攀琀昀⸀漀爀最ഀ਀㸀     栀琀琀瀀猀㨀⼀⼀眀眀眀⸀椀攀琀昀⸀漀爀最⼀洀愀椀氀洀愀渀⼀氀椀猀琀椀渀昀漀⼀椀愀猀愀㈀　ഀ਀㸀     ഀ਀㸀 ഀ਀ഀ਀ഀ਀ഀ਀

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Nov 2018 20:55:53 +0700

Alissa,

> On Nov 6, 2018, at 5:08 PM, Alissa Cooper <[email-masked]> wrote:
> 

Somewhat relevant to this is that recall process in RFC7437 has been extended to also cover the IETF trustees appointed by the NomCom.  See:

https://tools.ietf.org/html/draft-ietf-iasa2-rfc7437bis-03

Not the same as an appeal, but we will have the ability to recall a sitting IETF Trust Trustee.

Thanks,
Bob

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Nov 2018 09:44:20 -0500

--On Tuesday, November 6, 2018 17:08 +0700 Alissa Cooper
<[email-masked]> wrote:

> Given this discussion and some timing constraints around the
> new trustee selection processes, I went ahead and approved
> draft-iasa2-trust-update and draft-iasa2-trust-rationale for
> publication. I appreciate people's flexibility here.
> Although it would be unusual, I suspect that if people do not
> want to put the appeals text in 5377bis that a bis to
> draft-iasa2-trust-update containing the appeals text could get
> done before the new trustees are seated in March.

Alissa,

While I continue to favor flexibility, I suggest that it is well
within the IESG's authority to tell the Nomcom and others that,
because the portions of draft-iasa2-trust-update and
draft-iasa2-trust-rationale that affect them and the trustee
selection process have been approved by the IESG, they should
just go ahead and do their thing.  Similarly, IIR, there are a
few precedents for the IESG approving a document for publication
and then asking the RFC Editor to go slow on it in case a
discussion that is still underway changes things.   In a way,
publication holds for normative references are, while initiated
by the RFC Editor, just an example of that more general "wait
until the ducks are lined up and we are sure what this spec will
actually mean" principle.

I also note that, if the updating I-D were posted and started
rapidly moving through the process before AUTH48 on
draft-iasa2-trust-update, it would be entirely appropriate and
normal for someone in the community to recommend that a sentence
and normative reference to the I-D be added to that document and
to appeal if the request for not granted.  Whether because of
the normative reference or because of the appeal, that would
have the same effect on the publication dates of
draft-iasa2-trust-update and presumably
draft-iasa2-trust-rationale as inserting a paragraph into each
document and doing a quick IETF LC on the change and would
require the IESG to interpret the rules as suggested above to
avoid interfering with the schedule.

There has always been a gray area as to whether a specification
is effective on the date the IESG signs off, the date the RFC is
published, or when the 60 day appeal window runs out on those
actions.  IIR, there have been occasional discussions on whether
to clarify that in some formal way and the conclusion has been
that any problems are hypothetical in the overwhelming number of
cases and that, for the edge cases, we might actually be better
off with the flexibility the ambiguity creates.  This might
reasonably be treated as one such case.

I am _not_ suggesting that your decision is necessarily
inappropriate, only that it is not the only plausible option if
the reason for it is to avoid upsetting the timing of the
trustee selection process.

    john

p.s. speaking from my perspective only, I prefer either a bis or
an update to draft-iasa2-trust-update to picking some document
about another topic (in this discussion, 5377bis, but one could
pick others) and just tacking appeals text onto it.  And I
prefer getting things right and the text into
draft-iasa2-trust-update because all of the other options make
the IETF look like things are being down without careful review
and consideration and hence a bit silly.

---

From: "John R Levine" <[email-masked]>
Date: 6 Nov 2018 23:26:41 +0700

> Not the same as an appeal, but we will have the ability to recall a sitting IETF Trust Trustee.

Right.  There is an informal appeal process, and a recall process.  I 
think that is plenty for the IETF trust.

In general, I would prefer to move away from the model of having detailed 
appeals processes that we never use, and toward a model where we appoint 
peopel who we expect will do their jobs, and in the unlikely event that 
they don't, we can replace them.

Specifically for the trust, since trust actions that one might appeal will 
generally involve contracts, I don't know what it means to have a signed 
contract that an appeal can unilaterally un-sign and I don't think anyone 
else does either.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly