Subject: Re: [Iasa20] Trust Drafts - WGLC

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 12 Sep 2018 15:30:19 +0000

Good suggestion. 

Jari -> What do you want to do here?

JL

On 9/12/18, 11:23 AM, "Bob Hinden" <[email-masked]> wrote:

    Jason,

    > On Sep 12, 2018, at 8:13 AM, Livingood, Jason <[email-masked]> wrote:
    > 
    > Unless Jari disagrees, I believe the plan was for this to just be a draft for discussion and it will expire.
    
    Thanks, that wasn’t clear to me in the last call.
    
    I wonder if it makes sense to move some of the Discussion draft, especially the Background Section, to the update draft.   It would provide more context to the published RFC.
    
    Thanks,
    Bob

    > 
    > On 9/7/18, 3:14 PM, "Bob Hinden" <[email-masked]> wrote:
    > 
    >    Jason,
    > 
    >> On Sep 7, 2018, at 11:09 AM, Livingood, Jason <[email-masked]> wrote:
    >> 
    >> BTW, in case you missed the emails to the list with the document links:
    >> https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale/
    >> https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/
    > 
    >    Clarification question.
    > 
    >    <draft-arkko-iasa2-trust-rationale> says in the Introduction:
    > 
    >       This memo is provided only for discussion.  There is no intention to
    >       publish this memo as an RFC.
    > 
    >    Is the purpose of the w.g. last call on this doc to only determine consensus, or to also publish as an RFC?
    > 
    > 
    >    Thanks,
    >    Bob
    > 
    > 
    >> 
    >> JL
    >> 
    >> From: "Livingood, Jason" <[email-masked]>
    >> Date: Friday, September 7, 2018 at 2:08 PM
    >> To: "[email-masked]" <[email-masked]>
    >> Subject: Trust Drafts - WGLC
    >> 
    >> Hi folks – Jari has updated his individual drafts to be WG drafts, following the call for adoption awhile back. He also made changes based on WG feedback. As a result it seems a good time to begin WGLC today, September 7th, and ending on September 21st.
    >> 
    >> Thanks
    >> Jason
    >> _______________________________________________
    >> iasa20 mailing list
    >> [email-masked]
    >> https://www.ietf.org/mailman/listinfo/iasa20
    > 
    > 
    >

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Sep 2018 19:10:18 +0300

The purpose of the rationale draft was to explain some of the aspects of the trust arrangement, as collected from other RFCs and agreements, and to explain the context why this particular change makes sense.

My idea was to let the -update become an RFC and let the rationale draft expire. That doesn’t preclude working group discussion (or even WGLC) to see if all relevant points were made, for instance.

I’ll do what the working group asks me to do with the drafts, of course. But, I have an opinion as a participant:

I’m quite hesitant in adding material from the rationale draft to the update draft/RFC, at least when it comes to the bulk of the material. The -update is supposed to describe how things will be, short and succinct. And it will be a BCP. I don’t want to explain in a new BCP, for instance, what the purpose of the Trust is because that is already given adequately in the original RFCs. And I don’t think we need to explain the transition situation because the draft will be in fresh memory when the transition happens.

Perhaps some other things could be more appropriate in the BCP, such as the explanation of what kind of work trustees are expected to do and why a particular number of years and trustees is appropriate. That kind of text could potentially move.

I’d suggest there’s couple of possible and reasonable paths forward:

1/ As is: let the rationale expire and the -update RFC has the actual rules that will apply from then on

2/ Selected move: carefully select some relevant parts of the rationale draft and move them to the -update draft; let the rationale draft again expire.

3/ Publish both: publish the -update as BCP, publish the -rationale as Info.

What would you like to do?

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Sep 2018 08:33:04 +1200

> 1/ As is: let the rationale expire and the -update RFC has the actual rules that will apply from then on

I think this is fine. We have enough RFCs that *must* be published for IASA 2.0 to happen, so let's not do extra stuff.

   Brian

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2018 16:44:31 -0400

In article <[email-masked]> you write:
>My idea was to let the -update become an RFC and let the rationale draft expire. That doesn’t preclude working
>group discussion (or even WGLC) to see if all relevant points were made, for instance.

>Perhaps some other things could be more appropriate in the BCP, such as the explanation of what kind of work
>trustees are expected to do and why a particular number of years and trustees is appropriate. That kind of text
>could potentially move.

I think shorter is better here.  The Trustees' work hasn't changed at
all, only the way they're appointed.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Sep 2018 13:56:41 -0700

Jari,

> On Sep 12, 2018, at 9:10 AM, Jari Arkko <[email-masked]> wrote:
> 

I prefer /2, could live with /1, and agree that we shouldn’t do 3/.

My thinking is that since the rational won’t be published, that the “Update” draft needs more background.  I assume all of these drafts need to go through an IETF last call where people not in the working group will be reviewing them.   Also, the Update draft currently points to the Rationale draft, this needs to change if the rational draft isn’t published.

I would be happy with adding text to the start of the Introduction section, something like (borrowing text from the rationale draft):

   The purpose of the Internet Engineering Task Force (IETF) Trust is to
   acquire, hold, maintain, and license certain existing and future
   intellectual property and other property used in connection with the
   administration of the IETF [RFC4371].  The intellectual property is,
   for instance, rights that the IETF contributors grant for text in
   RFCs and Internet Drafts.  The IETF Trust also manages trademarks
   such as "IETF" and domain names such as "ietf.org".  The IETF Trust
   is also serving the broader Internet community by holding domains and
   trademarks associated with Internet Assigned Numbers Authority (IANA)
   [RFC7979].

   The IETF Trust is a legal entity, registered in the Commonwealth of
   Virginia [Trust-FD].

Thanks,
Bob

---

From: "Leslie Daigle" <[email-masked]>
Date: Thu, 13 Sep 2018 09:51:43 -0400

> 3/ Publish both: publish the -update as BCP, publish the -rationale as 

I agree that there’s material in the -rationale document that is very 
specific to this moment in time in our collective thought process.  
However, there are also points that explain some of the historical 
background that we ought to have published somewhere (other than a 
random mail archive).

ISTM that if we don’t publish the -rationale document as an RFC, then 
we’ll be tempted to over-clutter the -update document, and/or future 
efforts of updating the Trust[*] won’t have the background, or will 
wonder what the status of this never-published draft really was[**].

Leslie.
[*] There won’t not be future efforts of updating the Trust
[**] It’s not like the bits will go away.  We’re only talking about 
whether the document is declared “completed”, really.

On 12 Sep 2018, at 12:10, Jari Arkko wrote:

> The purpose of the rationale draft was to explain some of the aspects 
> of the trust arrangement, as collected from other RFCs and agreements, 
> and to explain the context why this particular change makes sense.
>
> My idea was to let the -update become an RFC and let the rationale 
> draft expire. That doesn’t preclude working group discussion (or 
> even WGLC) to see if all relevant points were made, for instance.
>
> I’ll do what the working group asks me to do with the drafts, of 
> course. But, I have an opinion as a participant:
>
> I’m quite hesitant in adding material from the rationale draft to 
> the update draft/RFC, at least when it comes to the bulk of the 
> material. The -update is supposed to describe how things will be, 
> short and succinct. And it will be a BCP. I don’t want to explain in 
> a new BCP, for instance, what the purpose of the Trust is because that 
> is already given adequately in the original RFCs. And I don’t think 
> we need to explain the transition situation because the draft will be 
> in fresh memory when the transition happens.
>
> Perhaps some other things could be more appropriate in the BCP, such 
> as the explanation of what kind of work trustees are expected to do 
> and why a particular number of years and trustees is appropriate. That 
> kind of text could potentially move.
>
> 2/ Selected move: carefully select some relevant parts of the 
> rationale draft and move them to the -update draft; let the rationale 
> draft again expire.
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 13 Sep 2018 13:34:22 -0400

+1

On Wed, Sep 12, 2018 at 4:33 PM Brian E Carpenter <
[email-masked]> wrote:

> I think this is fine. We have enough RFCs that *must* be published for
> IASA 2.0 to happen, so let's not do extra stuff.
>
>    Brian
> > The purpose of the rationale draft was to explain some of the aspects of
> the trust arrangement, as collected from other RFCs and agreements, and to
> explain the context why this particular change makes sense.
> >
> > My idea was to let the -update become an RFC and let the rationale draft
> expire. That doesn’t preclude working group discussion (or even WGLC) to
> see if all relevant points were made, for instance.
> >
> > I’m quite hesitant in adding material from the rationale draft to the
> update draft/RFC, at least when it comes to the bulk of the material. The
> -update is supposed to describe how things will be, short and succinct. And
> it will be a BCP. I don’t want to explain in a new BCP, for instance, what
> the purpose of the Trust is because that is already given adequately in the
> original RFCs. And I don’t think we need to explain the transition
> situation because the draft will be in fresh memory when the transition
> happens.
> >
> > Perhaps some other things could be more appropriate in the BCP, such as
> the explanation of what kind of work trustees are expected to do and why a
> particular number of years and trustees is appropriate. That kind of text
> could potentially move.
> >
> > 2/ Selected move: carefully select some relevant parts of the rationale
> draft and move them to the -update draft; let the rationale draft again
> expire.
> >

-- 
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: "Leslie Daigle" <[email-masked]>
Date: Sat, 15 Sep 2018 15:46:24 -0400

Because Spencer asked me a question off list, let me clarify:  I am 
motivated by the fact that I have, in fact, had to dumpster-dive in my 
e-archives to find stuff from the the IASA 1.0 archive, for other people 
who happened to think to ask me.   You, Jari, may have even been the 
beneficiary of some of those dives.

I think that, if we have agreement on the content now, we should publish 
it where whoever-comes-next has a fighting chance to find it on their 
own.

Leslie.

On 13 Sep 2018, at 9:51, Leslie Daigle wrote:

> I agree that there’s material in the -rationale document that is 
> very specific to this moment in time in our collective thought 
> process.  However, there are also points that explain some of the 
> historical background that we ought to have published somewhere (other 
> than a random mail archive).
>
> ISTM that if we don’t publish the -rationale document as an RFC, 
> then we’ll be tempted to over-clutter the -update document, and/or 
> future efforts of updating the Trust[*] won’t have the background, 
> or will wonder what the status of this never-published draft really 
> was[**].
>
> Leslie.
> [**] It’s not like the bits will go away.  We’re only talking 
> about whether the document is declared “completed”, really.
>
>
>> of the trust arrangement, as collected from other RFCs and 
>> agreements, and to explain the context why this particular change 
>> makes sense.
>>
>> short and succinct. And it will be a BCP. I don’t want to explain 
>> in a new BCP, for instance, what the purpose of the Trust is because 
>> that is already given adequately in the original RFCs. And I don’t 
>> think we need to explain the transition situation because the draft 
>> will be in fresh memory when the transition happens.
>>
>> and why a particular number of years and trustees is appropriate. 
>> That kind of text could potentially move.
>>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Sep 2018 10:54:01 +0300

FWIW, I’d be OK with option 3, even if my perhaps main preference is option 1. It is only the option 2 that would cause more headache :-)

Jari

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Sep 2018 16:45:34 -0400

The -update document includes this text:

   For a discussion of why this change is needed and a rationale for
   these specific changes, see [I-D.ietf-iasa2-trust-rationale].

So, the most simple way forward is to publish -rationale as an Informational RFC.  Otherwise, an alternative paragraph is needed to provide some context.  Having to come up with an alternative paragraph seems like option 2...

Russ

> On Sep 16, 2018, at 3:54 AM, Jari Arkko <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 19 Sep 2018 20:05:04 -0400

In article <[email-masked]> you write:
>So, the most simple way forward is to publish -rationale as an Informational RFC.

I'm not overwhelmingly persuaded, but it's OK with me and better than
putting the history into the trust update.

One thing that that trust update doesn't specify is the sequencing of
updating the trust, selecting the new trustees, and seating the new
trustees.  I think that's fine, since that's a one-time issue that the
trust can handle itself, but I'd like to be sure that people won't
find it to be a problem.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Sep 2018 12:57:14 +1200

> putting the history into the trust update.

Agreed; if people think it's useful, it's "only" some extra work for
the RFC Editor.

> trust can handle itself, 

With help from the IESG, if interim Trustees need to be appointed.

> but I'd like to be sure that people won't
> find it to be a problem.

No, I think it's fine to leave the details out of the text.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2018 12:10:16 -0400

>With help from the IESG, if interim Trustees need to be appointed.

My assumption is that we will have the current trustees continue until
we have a set appointed under the new rules.  It's only a few months,
and we've all been appointed as IAOC members by the same groups that
will appoint the new ones.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Sep 2018 08:27:43 +1200

> will appoint the new ones.

Legally, if the IAOC ceases to exist, it is the IESG's job to appoint
Trustees. Certainly they could be the same people, but it's entirely
the IESG's choice, under 6.1(c) of the Trust Agreement, until the Trust
Agreement has been amended to change the definition of "Eligible Person".

    Brian

---

From: "John R Levine" <[email-masked]>
Date: 20 Sep 2018 16:29:32 -0400

On Fri, 21 Sep 2018, Brian E Carpenter wrote:
> Trustees. ...

Sorry, I thought it was obvious that this would be part of the text in the 
revised trust agreement.  We need to change it anyway, so the changes can 
include transitional rules.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Sep 2018 08:37:35 +1200

> include transitional rules.

Sure. I'll be interested to see the draft.

    Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 21 Sep 2018 17:54:53 +0000

So with the conclusion of WGLC here, the sense I've gotten from the discussion is that there is a slight preference for advancing -rationale to an Info RFC. Based on that, we'll request publication for both of the trust documents. There were a few minor comments on -rationale that we can fix in transit as we go through IETF LC and so on. 

Jon Peterson
Neustar, Inc.

On 9/19/18, 5:57 PM, "iasa20 on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
        Brian
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_iasa20&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=YAshr-SDidKmOEKhxqbBlrCIVyncpx8bnzXVFf4_rjs&s=TgoMKGiF-QUNyQG63BzGR9ZWTF4Mn_6yGjnr1zG8kwg&e=
    > 
    
    _______________________________________________
    iasa20 mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_iasa20&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=YAshr-SDidKmOEKhxqbBlrCIVyncpx8bnzXVFf4_rjs&s=TgoMKGiF-QUNyQG63BzGR9ZWTF4Mn_6yGjnr1zG8kwg&e=