Subject: [Rfced-future] Issue 134: Re: How can this process be changed?

From: Eliot Lear <[email-masked]>
Date: Sat, 4 Dec 2021 12:39:22 +0100

Returning to this:

On 12.11.21 03:39, Mark Nottingham wrote:
> I think explicitly saying that such changes are in scope for discussion in the RSWG is worthwhile, given the uncertainty that we've seen so far.

The proposed text:

> Updates, amendments and refinements of this document can be produced 
> using the process documented here, but are only operative upon 
> agreement of the IAB, the IESG, and the IETF LLC. Note that this does 
> not preclude such changes from being defined outside this process, so 
> long as the same agreement is found.

Based on your elaboration and the text, I understand the intent to be:

  * The IAB, IESG, and LLC must approve changes to the process defined
    in this document.
  * Proposals for change may come from outside the RSWG and RSAB in case
    there is some process failure within the RSWG and RSAB.
  * It is within scope for the RSWG and RSAB to discuss proposed changes.

And so my question is this:

  * Why would anyone use the process defined in this document when they
    can bypass it?  That just adds additional approvals.

Do you mean, rather:

> Updates, amendments and refinements of this document require agreement 
> of the IAB, the IESG, and the IETF LLC.  The RSWG and RSAB may discuss 
> proposed changes.

?

Also, I recall that there was a question as to whether the LLC should be 
in the approval chain.  What do people think?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Dec 2021 09:09:40 +1300

On 05-Dec-21 00:39, Eliot Lear wrote:
>> Updates, amendments and refinements of this document can be produced using the process documented here, but are only operative upon agreement of the IAB, the IESG, and the IETF LLC. Note that this does not preclude such changes from being defined outside this process, so long as the same agreement is found.
> 
>   * The IAB, IESG, and LLC must approve changes to the process defined in this document.
>   * Proposals for change may come from outside the RSWG and RSAB in case there is some process failure within the RSWG and RSAB.
>> Updates, amendments and refinements of this document require agreement 
of the IAB, the IESG, and the IETF LLC.  The RSWG and RSAB may discuss proposed changes.

That seems sufficient to me, but...
  
> Also, I recall that there was a question as to whether the LLC should be in the approval chain.  What do people think?

The LLC exists to serve the community, so the LLC cannot have a veto, but 
their opinion about feasibility must be heard. I'm not quite sure how best to word that.

    Brian C

---

From: Michael StJohns <[email-masked]>
Date: Sat, 4 Dec 2021 18:32:50 -0500

On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
>> Also, I recall that there was a question as to whether the LLC should 
>> be in the approval chain.  What do people think?
>
> The LLC exists to serve the community, so the LLC cannot have a veto, 
> but their opinion about feasibility must be heard. I'm not quite sure 
> how best to word that.

I've been off doing other things for a bit but..

This is a nonsense statement.  It is semantically equivalent to "The IAB 
exists to serve the community, so the IAB cannot have a veto."  
Substitute in IESG and you get similar nonsense.  I apologize in advance 
if I offend with calling this nonsense, but it truly does not make any 
sense nor can it be made to make sense.

The IAB, IESG and LLC board are selected by the community through the 
Nomcom process to represent the community and by doing so, to serve the 
community.  The LLC does get a veto for good and sufficient reasons - 
e.g. it's a brilliant idea that every one loves, but it will start 
breaking the bank in just about 2 years.   Or we've decided to stand up 
a second LLC to deal with the specifics of the RFC process as a 
subsidiary of the IETF LLC and the money and lawyers and external 
support must be gained. Or we want to move a task that's been contracted 
for and for which a contract modification may or may not be possible.  
Or any of a number of other items that fall specifically in the LLC's 
purview of keeping things legal and affordable and sustainable.

Neither the RSWG nor the RSAB are selected by the community, and so they 
can't be said to either represent the community or for that matter serve 
anything except a specific set of interests which may not necessarily 
align with the IAB/IESG/LLCs own view of the good of the community or 
for that matter the communities own view (for some definition of 
community).    So why are they veto-proof?

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Dec 2021 13:25:22 +1300

>>
>> The LLC exists to serve the community, so the LLC cannot have a veto, but their opinion about feasibility must be heard. I'm not quite sure how 
best to word that.
> This is a nonsense statement.  It is semantically equivalent to "The IAB exists to serve the community, so the IAB cannot have a veto."  
Substitute in IESG and you get similar nonsense.  I apologize in advance if I offend with calling this nonsense, but it truly does not make any sense nor can it be made to make sense.

No offence, but clearly I expressed it poorly.  What I'm getting at is that the LLC exists to provide support for the community (as specified in section 4.3 of RFC8711), so it is out of order for the LLC to object to community decisions *except as they affect administrative and technical support*. The proposed text doesn't capture that limitation. (And no, I don't see that the IAB and IESG are limited in a similar way.)

Regards,
   Brian

> The IAB, IESG and LLC board are selected by the community through the Nomcom process to represent the community and by doing so, to serve the community.  The LLC does get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.   Or we've decided to stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modification may or may not be possible.  Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable.
> 
> Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily align with the IAB/IESG/LLCs own view of the good of the community or for that matter the communities own view (for some definition of community).    So why are they veto-proof?
> 
> Later, Mike
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Dec 2021 16:56:27 -0800

I agree with Brian here. One of the major themes when the LLC was
formed was how people wanted it to be subordinate to the community,
and so any say it has should be strictly limited.

I can see a case to be made for the LLC having a say in whether some
substantive change proposed by the RSWG (e.g., RFCs must be printed on
gold plates) was practical. However, even then I think it would be
better if the LLC gave advice and the RSWG and RSAB set policy.

I don't see any reason why the LLC should be allowed to veto process
changes instituted by the RSWG/RSAB.

-Ekr

On Sat, Dec 4, 2021 at 4:25 PM Brian E Carpenter <
[email-masked]> wrote:

> but their opinion about feasibility must be heard. I'm not quite sure how
> best to word that.
> >
> No offence, but clearly I expressed it poorly.  What I'm getting at is
> that the LLC exists to provide support for the community (as specified in
> section 4.3 of RFC8711), so it is out of order for the LLC to object to
> community decisions *except as they affect administrative and technical
> support*. The proposed text doesn't capture that limitation. (And no, I
> don't see that the IAB and IESG are limited in a similar way.)
>
> Regards,
>    Brian
>
>
> community.  The LLC does get a veto for good and sufficient reasons - e.g.
> it's a brilliant idea that every one loves, but it will start breaking the
> bank in just about 2 years.   Or we've decided to stand up a second LLC to
> deal with the specifics of the RFC process as a subsidiary of the IETF LLC
> and the money and lawyers and external support must be gained. Or we want
> to move a task that's been contracted for and for which a contract
> modification may or may not be possible.  Or any of a number of other items
> that fall specifically in the LLC's purview of keeping things legal and
> affordable and sustainable.
> >
> anything except a specific set of interests which may not necessarily align
> with the IAB/IESG/LLCs own view of the good of the community or for that
> matter the communities own view (for some definition of community).    So
> why are they veto-proof?
> >
> > Later, Mike
> >
> >
> >
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Michael StJohns <[email-masked]>
Date: Sat, 4 Dec 2021 20:01:14 -0500

On 12/4/2021 7:25 PM, Brian E Carpenter wrote:
>>> The LLC exists to serve the community, so the LLC cannot have a 
>>> veto, but their opinion about feasibility must be heard. I'm not 
>>> quite sure how 
> best to word that.
>>
>> This is a nonsense statement.  It is semantically equivalent to "The 
>> IAB exists to serve the community, so the IAB cannot have a veto." 
> Substitute in IESG and you get similar nonsense.  I apologize in 
> advance if I offend with calling this nonsense, but it truly does not 
> make any sense nor can it be made to make sense.
>
>
> that the LLC exists to provide support for the community (as specified 
> in section 4.3 of RFC8711), so it is out of order for the LLC to 
> object to community decisions *except as they affect administrative 
> and technical support*. The proposed text doesn't capture that 
> limitation. (And no, I don't see that the IAB and IESG are limited in 
> a similar way.)
>
RFC8711 is interesting but not controlling.  What is controlling are the 
articles of incorporation, specifically 4(b):

> Specific purpose. The purpose of the Company is to provide a corporate 
> legal framework
> for facilitating current and futureactivities related to the Internet 
> Engineering Task
> Force, the Internet Architecture Board (IAB), and the Internet 
> Research Task Force
> (IRTF). The intent is that legal responsibility for all IETF-related 
> activities under the
> corporate umbrella of the Member as of the Effective Date will 
> transfer to the Company.
> Except as minimally necessary to provide appropriate administrative 
> and legal support
> (consistent with that historically provided by the Member and the IETF 
> Administrative
> Support Activity (IASA)), formation of the Company is not intended to 
> change anything
> related to the oversight or steering of the standards process as 
> currently conducted by
> the Internet Engineering Steering Group (IESG) and the IAB, the 
> appeals chain, the
> process for making and organizations involved in confirming IETF and 
> IAB appointments,
> the IETF Nominations Committee (NomCom), the IRTF, or Member's 
> memberships in or
> support of other organizations

The RFC process is not "oversight or steering of the standards process" 
by any measure.   "...corporate legal framework for facilitating current 
and future activities.." covers what we're intending for the RFC 
process.  The LLC is not and was not intended to be a rubber stamp for 
things that need to get paid for or managed.  E.g. the RFC process.

And then there's section 4.4 of the RFC8711 -

>     *  Diligence.  The IETF LLC is expected to act responsibly so as to
>        minimize risks to IETF participants and to the future of the IETF
>        as a whole, such as financial risks.
(And yes, there is also the Responsiveness to the Community item in the 
same section - both apply or neither).

So, yes, the LLC gets a veto.

Later, Mike

>> Nomcom process to represent the community and by doing so, to serve 
>> the community.  The LLC does get a veto for good and sufficient 
>> reasons - e.g. it's a brilliant idea that every one loves, but it 
>> will start breaking the bank in just about 2 years.   Or we've 
>> decided to stand up a second LLC to deal with the specifics of the 
>> RFC process as a subsidiary of the IETF LLC and the money and lawyers 
>> and external support must be gained. Or we want to move a task that's 
>> been contracted for and for which a contract modification may or may 
>> not be possible.  Or any of a number of other items that fall 
>> specifically in the LLC's purview of keeping things legal and 
>> Neither the RSWG nor the RSAB are selected by the community, and so 
>> they can't be said to either represent the community or for that 
>> matter serve anything except a specific set of interests which may 
>> not necessarily align with the IAB/IESG/LLCs own view of the good of 
>> the community or for that matter the communities own view (for some 
>> definition of community).    So why are they veto-proof?
>>
>> Later, Mike
>>
>>
>>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 4 Dec 2021 20:05:35 -0500

I certainly wouldn't expect us to give the LLC an unlimited veto.
But they clearly have the right to say "no, that would be illegal", or 
"no, that would break the bank".
So they have a limited veto.  I look forward to Brian's rephrasing.

Yours,
Joel

On 12/4/2021 7:56 PM, Eric Rescorla wrote:
> On Sat, Dec 4, 2021 at 4:25 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > This is a nonsense statement.  It is semantically equivalent to
>     "The IAB exists to serve the community, so the IAB cannot have a veto."
>     advance if I offend with calling this nonsense, but it truly does
>     not make any sense nor can it be made to make sense.
> 
> 
>     No offence, but clearly I expressed it poorly.  What I'm getting at
>     is that the LLC exists to provide support for the community (as
>     specified in section 4.3 of RFC8711), so it is out of order for the
>     LLC to object to community decisions *except as they affect
>     administrative and technical support*. The proposed text doesn't
>     capture that limitation. (And no, I don't see that the IAB and IESG
>     are limited in a similar way.)
> 
>     Regards,
>         Brian
> 
> 
>      > The IAB, IESG and LLC board are selected by the community through
>     the Nomcom process to represent the community and by doing so, to
>     serve the community.  The LLC does get a veto for good and
>     sufficient reasons - e.g. it's a brilliant idea that every one
>     loves, but it will start breaking the bank in just about 2 years.  
>     Or we've decided to stand up a second LLC to deal with the specifics
>     of the RFC process as a subsidiary of the IETF LLC and the money and
>     lawyers and external support must be gained. Or we want to move a
>     task that's been contracted for and for which a contract
>     modification may or may not be possible.  Or any of a number of
>     other items that fall specifically in the LLC's purview of keeping
>     things legal and affordable and sustainable.
>      >
>      > Neither the RSWG nor the RSAB are selected by the community, and
>     so they can't be said to either represent the community or for that
>     [email-masked] <mailto:[email-masked]>
>     <https://www.iab.org/mailman/listinfo/rfced-future>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Dec 2021 17:06:15 -0800

On Sat, Dec 4, 2021 at 5:01 PM Michael StJohns <[email-masked]>
wrote:

> their opinion about feasibility must be heard. I'm not quite sure how
>
> best to word that.
>
>
> for facilitating current and future activities related to the Internet
> Engineering Task
> Force, the Internet Architecture Board (IAB), and the Internet Research
> Task Force
> corporate umbrella of the Member as of the Effective Date will transfer to
> the Company.
> Except as minimally necessary to provide appropriate administrative and
> legal support
> the Internet Engineering Steering Group (IESG) and the IAB, the appeals chain,
> the
> process for making and organizations involved in confirming IETF and IAB
> appointments,
> the IETF Nominations Committee (NomCom), the IRTF, or Member's memberships
> in or
> The RFC process is not "oversight or steering of the standards process" by
> any measure.   "...corporate legal framework for facilitating current and
> future activities.." covers what we're intending for the RFC process.  The
> LLC is not and was not intended to be a rubber stamp for things that need
> to get paid for or managed.  E.g. the RFC process.
>

I don't see how the articles of incorporation for the LLC are controlling
on us.

I could create EKR RFC Inc. whose articles said it was responsible for the
health of the
RFC series but that wouldn't compel anyone to listen to me. More
concretely, it's within
the remit of the community to take the RFC Series away from the LLC,
whatever the
articles say.

> So, yes, the LLC gets a veto.
I don't see that this follows, either. The LLC can act responsibly within
its limits. This doesn't
give it extra powers.

-Ekr

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Dec 2021 15:21:23 +1300

Mike,

Maybe my keyboard wasn't working. I thought I typed "it is out of order for the LLC to object to community decisions *except as they affect administrative and technical support*." That seems entirely consistent with what you are saying.

My proposed rewrite of the sentence in question after seeing other comments is:

OLD:
Updates, amendments and refinements of this document can be produced using the process documented here, but are only operative upon agreement of the IAB, the IESG, and the IETF LLC.

NEW:
Updates, amendments and refinements of this document can be produced using the process documented here, but are only operative upon agreement of the IAB, the IESG, and the IETF LLC
with regard to matters falling under their respective remits.

Thus, if the RSWG and RSAB deem that RFCs shall be published in Esperanto 
instead of English, the LLC could object on grounds of the expense and difficulty in hiring translators and copy-editors, but not on the grounds that it's a stupid idea.

    Brian

On 05-Dec-21 14:01, Michael StJohns wrote:
> RFC8711 is interesting but not controlling.  What is controlling are the articles of incorporation, specifically 4(b):
> 
legal framework
>> for facilitating current and futureactivities related to the Internet Engineering Task
>> Force, the Internet Architecture Board (IAB), and the Internet Research Task Force
>> (IRTF). The intent is that legal responsibility for all IETF-related activities under the
>> corporate umbrella of the Member as of the Effective Date will transfer to the Company.
>> Except as minimally necessary to provide appropriate administrative and legal support
Administrative
>> Support Activity (IASA)), formation of the Company is not intended to change anything
>> related to the oversight or steering of the standards process as currently conducted by
>> the Internet Engineering Steering Group (IESG) and the IAB, the appeals chain, the
>> process for making and organizations involved in confirming IETF and IAB appointments,
>> the IETF Nominations Committee (NomCom), the IRTF, or Member's memberships in or
by any measure.   "...corporate legal framework for facilitating current and future activities.." covers what we're intending for the RFC process.  The LLC is not and was not intended to be a rubber stamp 
for things that need to get paid for or managed.  E.g. the RFC process.
>>> The IAB, IESG and LLC board are selected by the community through the 
Nomcom process to represent the community and by doing so, to serve the community.  The LLC does get a veto for good and sufficient reasons - 
e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.   Or we've decided to stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modification may or may not be possible.  Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable.
>>>
>>> Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily 
align with the IAB/IESG/LLCs own view of the good of the community or for 
that matter the communities own view (for some definition of community).    So why are they veto-proof?

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Dec 2021 18:35:57 -0800

On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter <
[email-masked]> wrote:

> Mike,
>
> Maybe my keyboard wasn't working. I thought I typed "it is out of order
> for the LLC to object to community decisions *except as they affect
> administrative and technical support*." That seems entirely consistent with
> what you are saying.
>
> Updates, amendments and refinements of this document can be produced using
> the process documented here, but are only operative upon agreement of the
> IAB, the IESG, and the IETF LLC.
>
> NEW:
> Updates, amendments and refinements of this document can be produced using
> the process documented here, but are only operative upon agreement of the
> IAB, the IESG, and the IETF LLC
> instead of English, the LLC could object on grounds of the expense and
> difficulty in hiring translators and copy-editors, but not on the grounds
> that it's a stupid idea.
>

Brian, I agree with your sentiments, but I don't think that this text does
it, because this document is about the process *not* about the RFC Series
proper.

So, it seems to me that under this text, the RSWG could mandate translation
into Klingon without changing the process and only the RSAB could object.

Can you give me an example of a change to this document that the LLC could
have standing to object to?

-Ekr

> advance if I offend with calling this nonsense, but it truly does not make
> any sense nor can it be made to make sense.
> >>
> >>
> and future activities.." covers what we're intending for the RFC process.
> The LLC is not and was not intended to be a rubber stamp
> breaking the bank in just about 2 years.   Or we've decided to stand up a
> second LLC to deal with the specifics of the RFC process as a subsidiary of
> the IETF LLC and the money and lawyers and external support must be gained.
> Or we want to move a task that's been contracted for and for which a
> contract modification may or may not be possible.  Or any of a number of
> other items that fall specifically in the LLC's purview of keeping things
> legal and affordable and sustainable.
> >>>
> they can't be said to either represent the community or for that matter
> serve anything except a specific set of interests which may not necessarily

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 4 Dec 2021 21:52:43 -0500

It is a bit of a strecth of course, but, as an example of change that 
the LLC would probably be obliged to object to, imagine a change to the 
procedure that declared that the LLC had to fund, without question, 
whatever the RSWG / RSAB approved.  That would be a change to this 
document.  And, as I understand it, the LLC Board would be violating 
their legal obligations if they accepted it.

Yours,
Joel

On 12/4/2021 9:35 PM, Eric Rescorla wrote:
> 
> 
> On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter 
>     Maybe my keyboard wasn't working. I thought I typed "it is out of
>     order for the LLC to object to community decisions *except as they
>     affect administrative and technical support*." That seems entirely
>     consistent with what you are saying.
> 
>     agreement of the IAB, the IESG, and the IETF LLC.
> 
>     NEW:
>     agreement of the IAB, the IESG, and the IETF LLC
>     instead of English, the LLC could object on grounds of the expense
>     and difficulty in hiring translators and copy-editors, but not on
>     the grounds that it's a stupid idea.
> 
> 
> Brian, I agree with your sentiments, but I don't think that this text 
> does it, because this document is about the process *not* about the RFC 
> Series proper.
> 
> So, it seems to me that under this text, the RSWG could mandate 
> translation into Klingon without changing the process and only the RSAB 
> could object.
> 
> Can you give me an example of a change to this document that the LLC 
> could have standing to object to?
> 
> -Ekr
> 
> 
>          Brian
> 
>      >>>> The LLC exists to serve the community, so the LLC cannot have
>     a veto, but their opinion about feasibility must be heard. I'm not
>     quite sure how
>      >> best to word that.
>      >>>
>      >> No offence, but clearly I expressed it poorly.  What I'm getting
>     at is that the LLC exists to provide support for the community (as
>      > RFC8711 is interesting but not controlling.  What is controlling
>     are the articles of incorporation, specifically 4(b):
>      >
>     by any measure.   "...corporate legal framework for facilitating
>     current and future activities.." covers what we're intending for the
>     RFC process.  The LLC is not and was not intended to be a rubber stamp
>     reasons -
>     breaking the bank in just about 2 years.   Or we've decided to stand
>     up a second LLC to deal with the specifics of the RFC process as a
>     support must be gained. Or we want to move a task that's been
>     contracted for and for which a contract modification may or may not
>     be possible.  Or any of a number of other items that fall
>      >>> Neither the RSWG nor the RSAB are selected by the community,
>     and so they can't be said to either represent the community or for
>     that matter serve anything except a specific set of interests which
>     may not necessarily

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Dec 2021 19:25:57 -0800

That's a good point. I guess the text should stay. Perhaps we also need to
add some kind of similar text to the approval phase for ordinary documents?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Dec 2021 16:27:31 +1300

Yes, or any change that the LLC's lawyers advised would expose the
LLC to serious legal risk. I'm not a lawyer so I won't invent
an example. Really, my phrase "with regard to matters falling under
their respective remits" was intended to be non-specific, so maybe
it was a mistake to invent an example.

Regards
    Brian

---

From: Eliot Lear <[email-masked]>
Date: Sun, 5 Dec 2021 09:04:47 +0100

Yes, I think we mixed two things up:

  * The process for changing the governing document we are developing, and
  * The general approval process for documents from the RSWG

We are talking about the former.  For the latter, we discussed this and 
there is text in the draft that states that:

>    the RSAB shall
>    include the IETF Executive Director or their delegate as a non-voting
>    member since the IETF LLC is responsible for implementation of
>    policies governing the RFC Series.

That's because one could envision a good many changes that would require 
quite a number of adjustments, including contractual ones.

Eliot

---

From: Brian Carpenter <[email-masked]>
Date: Sun, 5 Dec 2021 22:01:41 +1300

Exactly, and there is no problem with the second point. For the first
point, my concern is that the LLC should stay in its lane when changes to
the model are in discussion.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Sun, 5 Dec 2021, 21:04 Eliot Lear, <[email-masked]> wrote:

>    - The process for changing the governing document we are developing,
>    and
>    - The general approval process for documents from the RSWG
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Dec 2021 05:25:28 -0800

I agree with this. My thesis is just that the LLC should have no more
authority in changes to the model than for changes to its implementation,
and requiring them to sign off on the model -- even with restrictions --
seems to do that. Do I have the wrong end of things?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 6 Dec 2021 09:41:22 +1300

To be clear, I think that Jay (and others under the LLC umbrella) have stayed entirely within their remit in the discussions on this list. But that isn't the same thing as giving the LLC an *unconditional* veto over future changes to the model.

Regards
    Brian

On 06-Dec-21 02:25, Eric Rescorla wrote:
> I agree with this. My thesis is just that the LLC should have no more authority in changes to the model than for changes to its implementation, and requiring them to sign off on the model -- even with restrictions -- seems to do that. Do I have the wrong end of things?
> 
> -Ekr
> 
> 
> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Exactly, and there is no problem with the second point. For the first point, my concern is that the LLC should stay in its lane when changes 
to the model are in discussion.
>     On Sun, 5 Dec 2021, 21:04 Eliot Lear, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         We are talking about the former.  For the latter, we discussed this and there is text in the draft that states that:
> 
>>            the RSAB shall
>         That's because one could envision a good many changes that would require quite a number of adjustments, including contractual ones.
> 
>         Eliot
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Dec 2021 12:59:15 -0800

No disagreement there.

On Sun, Dec 5, 2021 at 12:41 PM Brian E Carpenter <
[email-masked]> wrote:

> To be clear, I think that Jay (and others under the LLC umbrella) have
> stayed entirely within their remit in the discussions on this list. But
> that isn't the same thing as giving the LLC an *unconditional* veto over
> future changes to the model.
>
> Regards
>     Brian
>
> > On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Exactly, and there is no problem with the second point. For the
> first point, my concern is that the LLC should stay in its lane when
> changes
> >         We are talking about the former.  For the latter, we discussed
> this and there is text in the draft that states that:
> >
> >>            the RSAB shall
> >         That's because one could envision a good many changes that would
> require quite a number of adjustments, including contractual ones.
> >
> >         Eliot
> >
>
>

---

From: Michael StJohns <[email-masked]>
Date: Sun, 5 Dec 2021 16:45:28 -0500

On 12/5/2021 3:41 PM, Brian E Carpenter wrote:
> stayed entirely within their remit in the discussions on this list. 
> But that isn't the same thing as giving the LLC an *unconditional* 
> veto over future changes to the model.
>
To be clear, I'm not talking about giving the LLC a veto, I'm explaining 
that they have one regardless of what we believe or specify.   If the 
LLC board collectively decides not to approve the *implementation* of a 
set of changes, those changes will not happen as the contract is held by 
the LLC.  That is effectively a veto which cannot be overridden unless 
and until the LLC board composition changes and they take up the 
question again.  (Or in EKRs dream vision - where some other 
organization takes over the contracting and management of the RFC Series 
and is controlled by the RSWG).

I'm happy with Mirja's original text and I think it is both appropriate 
and correct and not overspecified.  To wit:

> "Updates, amendments and refinements of this document require 
> agreement of the IAB, the IESG, and the IETF LLC."

Again, you, EKR and others have been arguing with me about my pushback 
on trusting the RSAB and RSWG (neither of which is a community/Nomcom 
selected body) to "do the right thing".  Why are you so dead set on 
trying to legislate and constrain the behavior of a set of a community 
selected members in a manner that may ultimately conflict with their 
fiduciary duties? You appear to be unwilling to trust them to "do the 
right thing" without over specific text and I'm beginning to get hints 
of a "you're not the boss of me" argument here rather than something 
based in ensuring the system continues to work.

Later, Mike

>> authority in changes to the model than for changes to its 
>> implementation, and requiring them to sign off on the model -- even 
>> with restrictions -- seems to do that. Do I have the wrong end of 
>> things?
>>
>> -Ekr
>>
>>
>> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter 
>>         We are talking about the former.  For the latter, we 
>> discussed this and there is text in the draft that states that:
>>
>>>            the RSAB shall
>>         That's because one could envision a good many changes that 
>> would require quite a number of adjustments, including contractual ones.
>>
>>         Eliot
>>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Dec 2021 14:19:13 -0800

> and is controlled by the RSWG).

Two points:

1. They have an effective veto over some points and not others. For
instance, the LLC could not plausibly just refuse to implement a change
in which the ISE member of the RSAB got 25 votes.

2. Yes, it's certainly true that the LLC can just refuse to do certain
things, but there is a difference between "The LLC is just refusing
to execute the will of the community" and "The LLC is part of the
process of deciding what is supposed to happen." For example,
the LLC could refuse to seat a new AD by not giving them a datatracker
login, refusing to process their actions, etc., but I think we would
all agree that this is acting outside the rules. The text you propose
below is different: it gives the LLC a say in what the rules are
and so if they apply their veto they would be acting inside the ruls.

> > agreement of the IAB, the IESG, and the IETF LLC."

I can live with this with the text proposed by Brian limiting the
requirement
by the LLC to agreement within their area. Otherwise, this seems overbroad.

> based in ensuring the system continues to work.

It will probably make this conversation a lot smoother if you avoid
attributing motivations to others. In any case, I would appreciate it
if you did so.

-Ekr