Subject: Re: Consultation on proposed IETF LLC Community Engagement Policy

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2020 19:40:55 -0400

The policy cited seems strange in multiple regards.

In regard to the LLC Board, the policy states that it applies to the 
board, and then does not seem to say anything clear about what the 
policy is for board members.  Maybe I missed it?  More likely, given 
that most board members are also community participants (the extreme 
case being the IETF Chair) I suspect that there is not much to say.  So 
don't claim the policy applies to them.  Or put it more explicitly that 
there is nothing to say about the board.

The restrictions on the RPC seem to go too far.  While it is true that 
most of the people who work for the RPC are not IETF participants, some 
of them are.  And they should be permitted to do so.  And the current 
person filling the role of RSE is also an active IETF participant and I 
would not expect the LLC to prohibit him from participating in IETF 
activities.

The only one that seems to be captured properly is the Contractors other 
than Secretariat / RPC.

There is also the interesting complication that the RPC staffers have a 
business relationship with the secretariat.  We normally veyr much want 
the Secretariat to stay out of IETF business.  Is the distinction 
between the RPC and AMS really that clear?  My understanding is that at 
least some of the RPC are employed by AMS?

Yours,
Joel

On 10/11/2020 7:23 PM, IETF Executive Director wrote:
> The IETF Administration LLC (IETF LLC) has drafted a proposed IETF LLC Community Engagement Policy [1] that sets out how IETF LLC board, staff and contractors will engage with the IETF community, including
> 
> * what involvement board, staff and contractors may have in the the development of RFCs;
> * what engagement they may have with the NomCom;
> * How the IETF LLC seeks community feedback;
> * What mechanisms the IETF LLC uses for community engagement.
> 
> The policy proposes a new mailing list [email-masked] for the discussion of IETF LLC related matters.
> 
> The IETF LLC now seeks community feedback on this proposed policy.  Please provide feedback by 26 October 2020 00:00 UTC using any of the following methods:
> 
> * Raising an issue on the Github repository [2]
> * Direct to the IETF Executive Director at [email-masked]
> * Direct to the IETF LLC Board (not including the IETF Executive Director) at [email-masked]
> * To the [email-masked] list
> 
> [1] https://github.com/ietf-llc/community-engagement-policy-consultation/blob/master/DRAFT%20Community%20Engagement%20Policy.md
> [2] https://github.com/ietf-llc/community-engagement-policy-consultation/issues
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2020 19:49:23 -0400

I keep re-reading the discussion of interaction with the nomcom.  On one 
level, avoidance of "backstabbing" makes sense.

And then I think about interesting cases that the nomcom needs to know 
about.  Creating an example that is to the best of my knowledge 
completely fictitious, if a candidate for IETF Chair had a history of 
difficult interactions with either the RPC or the IETF Executive 
Director, it would seem that the nomcom should know about that.  And be 
able to get the information from the direct participants.  This policy 
would prohibit such direct communication.
(Yes, the nomcom might pick that person anyway.  The reasons for choices 
are manifold and complex.  I am concerned merely that the nomcom be able 
to get relevant information.)

Yours,
Joel

---

From: Jay Daley <[email-masked]>
Date: Mon, 12 Oct 2020 12:56:53 +1300

Hi Joel

Thanks!

> On 12/10/2020, at 12:40 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> In regard to the LLC Board, the policy states that it applies to the board, and then does not seem to say anything clear about what the policy is for board members.  Maybe I missed it?  More likely, given that most board members are also community participants (the extreme case being the IETF Chair) I suspect that there is not much to say.  So don't claim the policy applies to them.  Or put it more explicitly that there is nothing to say about the board.

While that’s true for two of the sections, 'Development of RFCs' and 'NomCom',  the other two sections, 'Community Feedback' and 'Mechanisms' apply equally to board and staff.  Does that need to be made clearer?

> 
> The restrictions on the RPC seem to go too far.  While it is true that most of the people who work for the RPC are not IETF participants, some of them are.  And they should be permitted to do so.  

My understanding is that this is not the case, but it is possible that some of the temporary RPC staff are and so I will check and add as an issue if that is the case.

> And the current person filling the role of RSE is also an active IETF participant and I would not expect the LLC to prohibit him from participating in IETF activities.

The RSE is not part of the RPC (as per RFC 8728) and so not subject to those provisions.  (BTW the current Temporary RFC Series Project Manager is not regarded as filling the RSE role).

> 
> The only one that seems to be captured properly is the Contractors other than Secretariat / RPC.
> 
> There is also the interesting complication that the RPC staffers have a business relationship with the secretariat.  We normally veyr much want the Secretariat to stay out of IETF business.  Is the distinction between the RPC and AMS really that clear?  My understanding is that at least some of the RPC are employed by AMS?

They are all employed/contracted by AMS.  AMS provides us with 

- RPC
- Secretariat
	-- Clerical
	-- Meetings 
	-- IT

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Mon, 12 Oct 2020 12:58:04 +1300

> On 12/10/2020, at 12:49 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I keep re-reading the discussion of interaction with the nomcom.  On one level, avoidance of "backstabbing" makes sense.
> 
> And then I think about interesting cases that the nomcom needs to know about.  Creating an example that is to the best of my knowledge completely fictitious, if a candidate for IETF Chair had a history of difficult interactions with either the RPC or the IETF Executive Director, it would seem that the nomcom should know about that.  And be able to get the information from the direct participants.  This policy would prohibit such direct communication.
> (Yes, the nomcom might pick that person anyway.  The reasons for choices are manifold and complex.  I am concerned merely that the nomcom be able to get relevant information.)

The NomCom has a formal liaison from the LLC Board, which I think would be the appropriate mechanism for this.  Do you agree and if so do I need to make the clear?

thanks again
Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2020 20:07:43 -0400

First, thanks Jay for engaging so promptly.

No, I do not think the liaison from the LLC Board is the right way for 
the kind of feedback I am concerned about to be delivered to the nomcom. 
  Two reasons for this.

1) If the interaction is with the RPC, it is unlikley that the LLC Board 
liaison will even know about the issues.  Even if the interaction is 
with you, I would be unsurprised if you had been discreet enough not to 
raise the issues with the LLC board unless the problem was actually 
interfering with your work.  But that does not mean that it is not 
useful information for the nomcom.
1') Even worse would be the case where the person with interaction 
difficulties was a sitting LLC Board member.  The liaison would find it 
almost impossible to relay the issues.  (Yes, there is a problem that 
the issue will come to the attention of the LLC Board Liaison.  That is 
a different topic.  I believe folks are aware that that can serve as a 
damper on feedback about sitting IAB or IESG members.  That is a topic 
for a different list.  And a very messy topic for which I do not know 
any remedies.)

2) One of the complications I have observed for the nomcom in various 
circumstances is that it is very hard to act on or even evaluate second 
hand information.  Too much gets lost, and there is too much inherent 
uncertainty about the underlying details.

Yours,
Joel

On 10/11/2020 7:58 PM, Jay Daley wrote:
> 
> 
>> On 12/10/2020, at 12:49 PM, Joel M. Halpern <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> I keep re-reading the discussion of interaction with the nomcom.  On 
>> one level, avoidance of "backstabbing" makes sense.
>>
>> Director, it would seem that the nomcom should know about that.  And 
>> be able to get the information from the direct participants.  This 
>> policy would prohibit such direct communication.
>> (Yes, the nomcom might pick that person anyway.  The reasons for 
>> choices are manifold and complex.  I am concerned merely that the 
>> nomcom be able to get relevant information.)
> 
> The NomCom has a formal liaison from the LLC Board, which I think would 
> be the appropriate mechanism for this.  Do you agree and if so do I need 
> to make the clear?
> 
> thanks again
> Jay
> 
>>
>> Yours,
>> Joel
>>
>>> The IETF Administration LLC (IETF LLC) has drafted a proposed IETF 
>>> LLC Community Engagement Policy [1] that sets out how IETF LLC board, 
>>> staff and contractors will engage with the IETF community, including
>>> The policy proposes a new mailing list [email-masked] 
>>> <mailto:[email-masked]> for the discussion of IETF LLC related 
>>> matters.
>>> The IETF LLC now seeks community feedback on this proposed policy. 
>>>  Please provide feedback by 26 October 2020 00:00 UTC using any of 
>>> the following methods:
>>> <mailto:[email-masked]>
>>> * Direct to the IETF LLC Board (not including the IETF Executive 
>>> Director) at [email-masked] <mailto:[email-masked]>
>>> * To the [email-masked] <mailto:[email-masked]> list
>>> [1] 
>>> https://github.com/ietf-llc/community-engagement-policy-consultation/blob/master/DRAFT%20Community%20Engagement%20Policy.md
>>> [2] 
>>> https://github.com/ietf-llc/community-engagement-policy-consultation/issues
>>
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked] <mailto:[email-masked]>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Oct 2020 20:11:38 -0400

In line for context, and I hope this does not get too deep.
Yours,
Joel

On 10/11/2020 7:56 PM, Jay Daley wrote:
> Hi Joel
> 
> Thanks!
> 
>> On 12/10/2020, at 12:40 PM, Joel M. Halpern <[email-masked] 
>> case being the IETF Chair) I suspect that there is not much to say. 
>>  So don't claim the policy applies to them.  Or put it more explicitly 
>> that there is nothing to say about the board.
> 
> While that’s true for two of the sections, 'Development of RFCs' and 
> 'NomCom',  the other two sections, 'Community Feedback' and 'Mechanisms' 
> apply equally to board and staff.  Does that need to be made clearer?
> 

Looking at those sections, I am not seeing how they would affect board 
members actions or discussions.

>> most of the people who work for the RPC are not IETF participants, 
>> some of them are.  And they should be permitted to do so. 
> 
> My understanding is that this is not the case, but it is possible that 
> some of the temporary RPC staff are and so I will check and add as an 
> issue if that is the case.

Please check more carefully.

> 
>> And the current person filling the role of RSE is also an active IETF 
>> participant and I would not expect the LLC to prohibit him from 
>> participating in IETF activities.
> 
> The RSE is not part of the RPC (as per RFC 8728) and so not subject to 
> those provisions.  (BTW the current Temporary RFC Series Project Manager 
> is not regarded as filling the RSE role).

Okay.  I was not sure which way you intended that.  I and I did not want 
to assume any particular outcome from the ongoing discussions on 
rfced-future.

>> There is also the interesting complication that the RPC staffers have 
>> a business relationship with the secretariat.  We normally veyr much 
>> want the Secretariat to stay out of IETF business.  Is the distinction 
>> between the RPC and AMS really that clear?  My understanding is that 
>> at least some of the RPC are employed by AMS?
> 

So Secretariat in this policy means those people employed by AMS under 
funding from the Secretariat contract?  And if they have a person who is 
split?
I think this needs clarification?

Again, Thank you,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Oct 2020 14:01:44 +1300

Hi,

> Staff, Secretariat and RPC are not expected to have any engagement regarding the content of technical standards except as required in their defined administrative roles. For Secretariat and RPC this may occasionally include contributing to or authoring RFCs related to their area of work.

I don't see how this will work if a staff member happens to be a subject matter expert and the IETF needs that expertise. I don't see the conflict of interest that we might be trying to avoid in that case. Suppose that an employee happens to be an expert in congestion control. Who is harmed, or who is in conflict, if they contribute to a discussion of congestion control in the QUIC WG? On the contrary, if they *don't* contribute, the IETF is harmed because it doesn't get the benefit of their expertise.

I can certainly see that they shouldn't do this during working hours, because they are paid to do something else then, but there are another 128 hours a week available for them to contribute to the IETF as private individuals.

It seems to me that the policy should be different. Something like:

"Staff, Secretariat and RPC are not expected to have any engagement regarding the content of technical standards as part of their job, except as required in their defined administrative roles.  For Secretariat and RPC this may occasionally include contributing to or authoring RFCs related to their area of work. However, in accordance with IETF principles, they may contribute freely to IETF technical discussions as private individuals in their own time."

There might well be conflict of interest if a staff member contributes to the discussion of a process RFC that concerns their own work, so there naturally need to be some rules about that, as set out in the draft policy.

Regards
   Brian Carpenter

---

From: Jay Daley <[email-masked]>
Date: Mon, 12 Oct 2020 14:21:25 +1300

Added as Issue #1 "Policy on feedback to the NomCom is too restrictive" at https://github.com/ietf-llc/community-engagement-policy-consultation/issues/1

> On 12/10/2020, at 1:07 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> No, I do not think the liaison from the LLC Board is the right way for the kind of feedback I am concerned about to be delivered to the nomcom.  Two reasons for this.
> 
> 1) If the interaction is with the RPC, it is unlikley that the LLC Board liaison will even know about the issues.  Even if the interaction is with you, I would be unsurprised if you had been discreet enough not to raise the issues with the LLC board unless the problem was actually interfering with your work.  But that does not mean that it is not useful information for the nomcom.
> 1') Even worse would be the case where the person with interaction difficulties was a sitting LLC Board member.  The liaison would find it almost impossible to relay the issues.  (Yes, there is a problem that the issue will come to the attention of the LLC Board Liaison.  That is a different topic.  I believe folks are aware that that can serve as a damper on feedback about sitting IAB or IESG members.  That is a topic for a different list.  And a very messy topic for which I do not know any remedies.)
> 
> 2) One of the complications I have observed for the nomcom in various circumstances is that it is very hard to act on or even evaluate second hand information.  Too much gets lost, and there is too much inherent uncertainty about the underlying details.
> 
> Yours,
> Joel
> 
> 
>>> On 12/10/2020, at 12:49 PM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> The policy proposes a new mailing list [email-masked] <mailto:[email-masked]> for the discussion of IETF LLC related matters.
>>>> * Direct to the IETF Executive Director at [email-masked] <mailto:[email-masked]>
>>>> * Direct to the IETF LLC Board (not including the IETF Executive Director) at [email-masked] <mailto:[email-masked]>

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Mon, 12 Oct 2020 14:32:42 +1300

> On 12/10/2020, at 1:11 PM, Joel M. Halpern <[email-masked]> wrote:
> 
>>> On 12/10/2020, at 12:40 PM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Looking at those sections, I am not seeing how they would affect board members actions or discussions.

Sometimes the board consults directly and they also have to follow these rules.

> Please check more carefully.

Added as issue #2 "Policy on RPC engagement in development of RFCs is too restrictive" at https://github.com/ietf-llc/community-engagement-policy-consultation/issues/2

> So Secretariat in this policy means those people employed by AMS under funding from the Secretariat contract?  And if they have a person who is split?

The two are currently quite separate and tendered as two separate contracts.  If someone did work for both then both sets of restrictions would apply.

Added as issue #3 "Policy needs to address people in multiple roles" at https://github.com/ietf-llc/community-engagement-policy-consultation/issues/3

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: IETF Executive Director <[email-masked]>
Date: Mon, 12 Oct 2020 14:35:06 +1300

> On 12/10/2020, at 2:01 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

This is broader than Joel’s point, which was restricted to the RPC and so I’ve added a separate issue for this #4 "Staff, secretariat and RPC who are subject matter experts should be allowed to contribute to RFC work" at https://github.com/ietf-llc/community-engagement-policy-consultation/issues/4

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Sun, 11 Oct 2020 23:33:26 -0700

How much of the whole discussion could be covered by a more general
requirement of "Avoid appearance of possible conflict of interest"?  I
think it is difficult to specify more exactly with the risk of lawyerly
mis-interpretation. You're left with the problem of deciding who
decides, but you have that problem anyway. Being more explicit about some
kinds of conflicts doesn't help and may even make things worse..

On Sun, Oct 11, 2020 at 4:41 PM Joel M. Halpern <[email-masked]> wrote:

> > The IETF Administration LLC (IETF LLC) has drafted a proposed IETF LLC
> Community Engagement Policy [1] that sets out how IETF LLC board, staff and
> contractors will engage with the IETF community, including
> >
> Please provide feedback by 26 October 2020 00:00 UTC using any of the
> following methods:
> >
> Director) at [email-masked]

-- 
--
https://LarryMasinter.net <http://larry.masinter.net>

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 12 Oct 2020 21:37:40 +0200

I think the section on Nomcom feedback is broken, in that it in many respects
makes the LLC board members immune from feedback to the NomCom from some of
the individuals (staff, contractors, RPC) that have closest contact with the
LLC board members, and can most directly be affected by LLC Board misbehaviour.

Having myself been affected in this way by bad behaviour from the board as
a contractor in the handling of the Tools Maintenance RFP a year ago, I find
it interesting that the LLC Board now proposes that I should be prevented from
giving feedback to the NomCom about board and member behaviour.

The proposal mentions possible retaliation from staff or contractors against
LLC Board members, but not possible retaliation against staff or contractors
from LLC Board members.  This is also seems skewed, and retaliation in the
other direction is unfortunately far more likely and easy to carry through if
there is no possibility of feedback to the NomCom.

In any case, feedback to the NomCom about performance is a necessary check on
bad behaviour and unfitness for any position.  I don't think any limitation
on feedback to the NomCom on the performance of NomCom-selected individuals is
appropriate.

	Henrik

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Oct 2020 16:05:06 -0400

> on feedback to the NomCom on the performance of NomCom-selected individuals is

I agree. The NomCom should be free to receive information wherever and
from whomever is willing to provide it; they should have whatever
information is available, and be able to judge for themselves whether
to give it credence or not.

 I also believe that "staff, Secretariat and RPC" and IANA and
contractors should be encouraged to provide feedback on IESG
candidates[0]. They have unique visibility into the character,
competence, and demeanor of serving IESG members. The IETF and IESG
wouldn't function without them, and we need a way to ensure that they
are treated with the respect that they deserve.

W

[0]: Yup, I know that this is not the focus of this thread, but it is related...

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Oct 2020 09:22:20 +1300

Hi Henrik,

It's the IETF that sets the rules about comments submitted to NomCom, and those submissions are of course completely confidential (and that extends to the LLC Board's liaison to NomCom, whose seat is not up for review). BCP10 says "The NomCom may disclose a list of names of nominees who are willing to be considered for positions under review to the community, in order to obtain feedback from the community on these nominees." I think any attempt to preempt the IETF rules on this by limiting who is part of that "community" is null and void.

Regards
   Brian Carpenter

---

From: Michael StJohns <[email-masked]>
Date: Mon, 12 Oct 2020 16:48:17 -0400

> [2] https://github.com/ietf-llc/community-engagement-policy-consultation/issues
I have so many problems with this - where to begin:

1) The Secretariat and RPC members are all employees of their respective 
organizations, and it's that organization, and only that organization 
that *might* have the right to impose behavioral controls on them.    I 
say "might" because what they can impose on their employees is usually 
fairly circumscribed by the law.

2) It's unclear what you're trying to accomplish here and why you're 
trying to mark these folk off as second-class citizens unable to 
participate in the IETF even to the extent of any random passersby.  If 
there's some actual form of conflict of interest you're trying to deal 
with here, it's not obvious from the text. This feels way too much like 
the "... is just a contractor" comment I got from one of the I* folk a 
while back without any real reason for it.  We've been hearing the 
mantra of inclusiveness for a while from the I*, I guess I never 
expected it to mean "except for our contractors".

3) With respect to any misbehavior/poor interactions with the I* on the 
part of the Secretariat, RPC, RSE or other contractors, I certainly want 
the Nomcom to hear about it.  That includes, but is not limited to, 
harassment, arrogance, brusqueness, and any other interaction that would 
tend to reduce the efficiency of the IETF community, or make any of the 
participants feel subordinate to any of the I*.  Any policy that 
restricts the ability to provide information to the Nomcom is a non-starter.

4) With respect to folding in the LLC Code of Conduct to the independent 
contractors, my guess is that none of this applies or can apply unless 
its actually incorporated into their contracts, and sections 8 and 9 
especially might be offensive to most contractors.  With respect to 
section 7 - that's usually already incorporated into the contract.  
Sections 10 and 11 are violations of the law, and are generally already 
incorporated.    In any event, assuming that US law applies to a lot of 
this, attempting to constrain "how" a contractor does their work might 
bring the tax people down on you.

Mike

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 11:23:40 +1300

> On 13/10/2020, at 9:48 AM, Michael StJohns <[email-masked]> wrote:
> 
> 1) The Secretariat and RPC members are all employees of their respective organizations, and it's that organization, and only that organization that *might* have the right to impose behavioral controls on them.    I say "might" because what they can impose on their employees is usually fairly circumscribed by the law.
> 
> 2) It's unclear what you're trying to accomplish here and why you're trying to mark these folk off as second-class citizens unable to participate in the IETF even to the extent of any random passersby.  If there's some actual form of conflict of interest you're trying to deal with here, it's not obvious from the text. This feels way too much like the "... is just a contractor" comment I got from one of the I* folk a while back without any real reason for it.  We've been hearing the mantra of inclusiveness for a while from the I*, I guess I never expected it to mean "except for our contractors".

As you’ve noted this is all about managing conflict of interest.  It is quite normal to include provisions to manage conflict of interest in policies and contracts that are then in turn applied to employees.

Those conflicts of interest could certainly be spelt out more clearly.  I’ve added issue #6 "Clearer explanation of potential conflicts of interest in development of RFCs" at https://github.com/ietf-llc/community-engagement-policy-consultation/issues/6 to capture this.

The complication around conflict of interest is that it often comes down to what people perceive and what people are willing to accept.  I will send a follow up email with some questions that aims to understand that better.

> 3) With respect to any misbehavior/poor interactions with the I* on the part of the Secretariat, RPC, RSE or other contractors, I certainly want the Nomcom to hear about it.  That includes, but is not limited to, harassment, arrogance, brusqueness, and any other interaction that would tend to reduce the efficiency of the IETF community, or make any of the participants feel subordinate to any of the I*.  Any policy that restricts the ability to provide information to the Nomcom is a non-starter.

You didn’t mention staff - was that deliberate because you think restrictions should apply to staff in what feedback they can provide to the NomCom, or is that not an intentional omission?

Also, you seem to be suggesting that the set of things that the NomCom should hear about should be scoped to "misbehaviour/poor interactions" rather than say "they wouldn’t agree to the contract term I wanted" - is that correct?

> 4) With respect to folding in the LLC Code of Conduct to the independent contractors, my guess is that none of this applies or can apply unless its actually incorporated into their contracts, and sections 8 and 9 especially might be offensive to most contractors.  With respect to section 7 - that's usually already incorporated into the contract.  Sections 10 and 11 are violations of the law, and are generally already incorporated.    In any event, assuming that US law applies to a lot of this, attempting to constrain "how" a contractor does their work might bring the tax people down on you.

The LLC Code of Conduct is incorporated into all service contracts.  Those contracts have been through multiple sets of lawyers without any concern about that policy.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Oct 2020 18:39:12 -0400

With regard to what the nomcom should hear about, I think the simplest 
answer is the one stated or implied in several other people's answers.
The nomcom should be able to hear from anyone about anything that person 
thinks is relevant to the nomcom's choices.  The nomcom can then weigh 
that input along with everything else, as they judge appropriate.

Trying to write rules to restrict that seems to be trying to solve the 
wrong problem in the wrong place.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 12 Oct 2020 23:45:13 +0100

Hi Jay,

Many thanks for bringing this proposed policy for consultation.

I think it might have helped if the section "Purpose of this Policy" had
included a little "why" as well as the "what". That is, reading that short
section it is clear to me what the policy does, but not what the purpose is.

Having read the proposal several times and finally caught up with the
mailing list, I am very much in support of many of the comments made about
NomCom feedback. NomCom is not a blind weighing machine balancing the number
and magnitude of comments. It is a group of careful and thoughtful
individuals who will look at all feed-back and, where necessary ask
questions and follow up with the people giving the feedback, with others who
might have a view, and with the nominees. And all this with the requirement
of confidentiality. NomCom is well able to detect potential conflict of
interest and see through slanted feedback.

It seems to me that the more information NomCom has, the better decisions it
will make.

In the light of this, I think you should remove all constraints on providing
feedback to NomCom by any person and about any person except that it should
be "an expectation that Covered Individuals clearly declare any relationship
that might be a cause of perceived conflict of interest on each piece of
NomCom feedback they give." Then NomCom has all the information.

Thanks,
Adrian

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of IETF
Executive Director
Sent: 12 October 2020 00:23
To: IETF Announcement List <[email-masked]>
Subject: Consultation on proposed IETF LLC Community Engagement Policy

* what involvement board, staff and contractors may have in the the
development of RFCs;
* what engagement they may have with the NomCom; 
* How the IETF LLC seeks community feedback;
* What mechanisms the IETF LLC uses for community engagement.

The policy proposes a new mailing list [email-masked] for the
discussion of IETF LLC related matters.

The IETF LLC now seeks community feedback on this proposed policy.  Please
provide feedback by 26 October 2020 00:00 UTC using any of the following
methods:

* Raising an issue on the Github repository [2]
* Direct to the IETF Executive Director at [email-masked]
* Direct to the IETF LLC Board (not including the IETF Executive Director)
at [email-masked]
* To the [email-masked] list

[1]
https://github.com/ietf-llc/community-engagement-policy-consultation/blob/ma
ster/DRAFT%20Community%20Engagement%20Policy.md
[2]
https://github.com/ietf-llc/community-engagement-policy-consultation/issues

-- 
Jay Daley
IETF Executive Director
[email-masked]

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: IETF Executive Director <[email-masked]>
Date: Tue, 13 Oct 2020 11:59:39 +1300

> On 13/10/2020, at 11:45 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Jay,
> 

This is one of the questions I was going to ask, whether or not the LLC should require contractors to declare themselves as contractors in their interactions with the NomCom as they are required to in other contexts (a clause nobody has disagreed with to date).  Email of questions to come.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Mon, 12 Oct 2020 19:18:11 -0400

Hi Jay -

All inline below.

> As you’ve noted this is all about managing conflict of interest.  It is quite normal to include provisions to manage conflict of interest in policies and contracts that are then in turn applied to…

Yes but - they need to be bona fide conflicts of interest, not just 
arbitrary restrictions on the employees public life. Especially with the 
IETF having no formal membership, and a having a long history of of 
taking all comers.

> The complication around conflict of interest is that it often comes down to what people perceive and what people are willing to accept.  I will send a follow up email with some questions that aims…

Fair - more constrained and specific language here will tend to 
mitigate.   I await an idea of what topics you will place on the table 
as being COIs between the contractors and the LLC that affect the 
relationships of the contractors and the IETF community at large.

> You didn’t mention staff - was that deliberate because you think restrictions should apply to staff in what feedback they can provide to the NomCom, or is that not an intentional omission?
If I say that AMS can impose requirements on its staff (commensurate 
with the law), surely you don't think I'm going to make a different rule 
for the LLC?   But again, you need to make sure those requirements are 
related to the job, serve a necessary purpose and are as minimal as 
possible.  In any event, in a normal company, the staff has recourse 
through the HR process, or at a higher level, through the board.  They 
also have a much closer relationship with the base policies of the LLC.
> Also, you seem to be suggesting that the set of things that the NomCom should hear about should be scoped to "misbehaviour/poor interactions" rather than say "they wouldn’t agree to the contract te…

We don't (and SHOULD NOT) control what people say, nor should we control 
what we allow the Nomcom to hear.    With respect to your example, I 
don't have any problem with a contractor coming in and indicating they 
perceive that the I* is negotiating in bad faith - that's as much of a 
problem as any other problem I can think of.    But the Nomcom gets to 
hear it and give it as much or as little weight as is appropriate.  
Ideally, they'll ask for the other side's view of the matter.

So, the answer is "no" to your question.   *I* want to make sure the 
Nomcom can hear about subjects on the list I provided, but that's not a 
comprehensive list and shouldn't be taken as constraining the subject 
matter of a Nomcom submission.

> The LLC Code of Conduct is incorporated into all service contracts.  Those contracts have been through multiple sets of lawyers without any concern about that policy.

I'm actually surprised at that.   How many times have you been asked to 
approve a section 8 or 9 action since the policy was finalized? (e.g. 
from the apparent date of 31 Oct 2019)

Hmm... taking a quick look at John Levine's contract at 
https://www.ietf.org/media/documents/CSA_-_Temporary_RFC_Series_Project_Manager_-_EXECUTED_REDACTED.pdf 
- which is actually dated before the 31 Oct 2019 date, the only phrase 
that seems to apply is "Contractor agrees to comply with all IETF LLC 
policies, as provided by IETFLLC to Contractor from time to time".    I 
wouldn't actually call that "incorporated" in the legal meaning.

https://www.ietf.org/media/documents/SOW_automatic_schedule_builder_EXECUTED_REDACTED.pdf 
doesn't appear to have that clause in it.

https://www.ietf.org/media/documents/Pantheon_IETF_SOW_2_Final_002_EXECUTED_REDACTED.pdf 
has "Developer agrees to comply with all applicable IETF LLC policies in 
performance of the Services."- note the difference between "all 
applicable" and "all".

I probably wouldn't have signed a contract with such an open ended 
ability for the LLC to impose requirements.  I'd instead require the 
terms be set at time of signing or amended later by mutual consent.   
 From a quick read, it looks like the LLC or its lawyers set the basic 
form of the letter contracts as the same language appears in the same 
place in many of these including the exact same typo of a missing close 
paren.

> Developer will comply with the policies that IETF LLC provides 
> toDeveloper (as may be updated from time to time upon written notice 
> to Developer.
Is there a record of those notices being sent to each of these developers?

Mike

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 12:29:37 +1300

> On 13/10/2020, at 12:18 PM, Michael StJohns <[email-masked]> wrote:
> If I say that AMS can impose requirements on its staff (commensurate with the law), surely you don't think I'm going to make a different rule for the LLC?   But again, you need to make sure those requirements are related to the job, serve a necessary purpose and are as minimal as possible.  In any event, in a normal company, the staff has recourse through the HR process, or at a higher level, through the board.  They also have a much closer relationship with the base policies of the LLC.

By staff I meant me and Greg.

> I'm actually surprised at that.   How many times have you been asked to approve a section 8 or 9 action since the policy was finalized? (e.g. from the apparent date of 31 Oct 2019)

Maybe 8 times?

> Hmm... taking a quick look at John Levine's contract at https://www.ietf.org/media/documents/CSA_-_Temporary_RFC_Series_Project_Manager_-_EXECUTED_REDACTED.pdf - which is actually dated before the 31 Oct 2019 date, the only phrase that seems to apply is "Contractor agrees to comply with all IETF LLC policies, as provided by IETF LLC to Contractor from time to time".    I wouldn't actually call that "incorporated" in the legal meaning.

Our lawyers have a different view and other lawyers have concurred with them, hence some of the slightly different language across contracts.

> https://www.ietf.org/media/documents/SOW_automatic_schedule_builder_EXECUTED_REDACTED.pdf doesn't appear to have that clause in it. 

That overlapped with this.

> https://www.ietf.org/media/documents/Pantheon_IETF_SOW_2_Final_002_EXECUTED_REDACTED.pdf has "Developer agrees to comply with all applicable IETF LLC policies in performance of the Services." - note the difference between "all applicable" and "all".
> 
> I probably wouldn't have signed a contract with such an open ended ability for the LLC to impose requirements.  I'd instead require the terms be set at time of signing or amended later by mutual consent.   From a quick read, it looks like the LLC or its lawyers set the basic form of the letter contracts as the same language appears in the same place in many of these including the exact same typo of a missing close paren.   

Yes we provide our standard contract as a negotiating draft.

>> Developer will comply with the policies that IETF LLC provides toDeveloper (as may be updated from time to time upon written notice to Developer.

There have not been any updates that require such a notice.  The only records I intend to keep are my email and an internal checklist, nothing public.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Oct 2020 19:47:01 -0400

Henrik, Jay,

I agree with Henrik, but let me go a step further and generalize
his comments to recognize a broader and more significant
problem.  It is an essential element of the Nomcom model that
the Nomcom should be able to receive input from anyone who
considers themselves a member of the community or affected by
its work.  Indeed, it is entirely appropriate for the Nomcom to
actively solicit that information even including asking specific
people who might have useful information.  We expect the Nomcom
to separate truth from innuendo, useful input from personal
vendettas, and, as the expression goes, the wheat from the chaff
in all of the input they receive.  We also assume that the input
they receive and the basis on which they make their choices in
specific cases will be held confidential and kept that way
permanently.   Without those assumptions and broad community
trust in them, the system simply does not work.

In that regard, I see little or nothing that distinguishes the
LLC Board and assorted staff or contractors from, e.g., ADs and
WG Chairs or, more generally, people who feel that they have
been treated especially well by either (or by appointees for
whom those bodies are (or should be) accountable.    I note
especially "advocate for a board candidate who is expected to
provide favourable treatment" and what seems to me the analogy
to community participants, or even Nomcom members, who might be
inclined to advocate for or against particular technical
positions or even to favor particular proposals of companies
over anything.  In all of those cases, the other side of the
coin that that people with inside views (or perceptions that an
individual or group has unfairly put their views at a
disadvantage) are precisely the ones with the information that
Nomcom needs to have.

All of that means we need to have very high expectations of the
abilities and fairness of the Nomcom as a group.  But we do.  No
one every claimed that they have an easy job.  And, again, if we
can't trust them to do that job, it seems to me only a matter of
time before the whole system falls apart.

best,
    john

g--On Monday, October 12, 2020 21:37 +0200 Henrik Levkowetz
<[email-masked]> wrote:

> 
> I think the section on Nomcom feedback is broken, in that it
> in many respects makes the LLC board members immune from
> feedback to the NomCom from some of the individuals (staff,
> contractors, RPC) that have closest contact with the LLC board
> members, and can most directly be affected by LLC Board
> misbehaviour.
> 
> Having myself been affected in this way by bad behaviour from
> the board as a contractor in the handling of the Tools
> Maintenance RFP a year ago, I find it interesting that the LLC
> Board now proposes that I should be prevented from giving
> feedback to the NomCom about board and member behaviour.
> 
> The proposal mentions possible retaliation from staff or
> contractors against LLC Board members, but not possible
> retaliation against staff or contractors from LLC Board
> members.  This is also seems skewed, and retaliation in the
> other direction is unfortunately far more likely and easy to
> carry through if there is no possibility of feedback to the
> NomCom.
> 
> In any case, feedback to the NomCom about performance is a
> necessary check on bad behaviour and unfitness for any
> position.  I don't think any limitation on feedback to the
> NomCom on the performance of NomCom-selected individuals is
> appropriate.
> 
> 
> 	Henrik
> 
> 
>> The IETF Administration LLC (IETF LLC) has drafted a proposed
>> IETF LLC Community Engagement Policy [1] that sets out how
>> IETF LLC board, staff and contractors will engage with the
>> IETF community, including
>> 
>> * what involvement board, staff and contractors may have in
>> the the development of RFCs; * what engagement they may have
>> with the NomCom; 
>> for the discussion of IETF LLC related matters.
>> 
>> The IETF LLC now seeks community feedback on this proposed
>> policy.  Please provide feedback by 26 October 2020 00:00 UTC
>> using any of the following methods:
>> 
>> * Direct to the IETF Executive Director at
>> [email-masked] * Direct to the IETF LLC Board (not
>> including the IETF Executive Director) at
>> [email-masked] * To the [email-masked] list
>> 
>> [1]
>> https://github.com/ietf-llc/community-engagement-policy-consu
>> ltation/blob/master/DRAFT%20Community%20Engagement%20Policy.md
>> [2]

should encourage receiving and even seek 

--On Monday, October 12, 2020 21:37 +0200 Henrik Levkowetz
<[email-masked]> wrote:

> 
> I think the section on Nomcom feedback is broken, in that it
> in many respects makes the LLC board members immune from
> feedback to the NomCom from some of the individuals (staff,
> contractors, RPC) that have closest contact with the LLC board
> members, and can most directly be affected by LLC Board
> misbehaviour.
> 
> Having myself been affected in this way by bad behaviour from
> the board as a contractor in the handling of the Tools
> Maintenance RFP a year ago, I find it interesting that the LLC
> Board now proposes that I should be prevented from giving
> feedback to the NomCom about board and member behaviour.
> 
> The proposal mentions possible retaliation from staff or
> contractors against LLC Board members, but not possible
> retaliation against staff or contractors from LLC Board
> members.  This is also seems skewed, and retaliation in the
> other direction is unfortunately far more likely and easy to
> carry through if there is no possibility of feedback to the
> NomCom.
> 
> In any case, feedback to the NomCom about performance is a
> necessary check on bad behaviour and unfitness for any
> position.  I don't think any limitation on feedback to the
> NomCom on the performance of NomCom-selected individuals is
> appropriate.
> 
> 
> 	Henrik
> 
> 
>> The IETF Administration LLC (IETF LLC) has drafted a proposed
>> IETF LLC Community Engagement Policy [1] that sets out how
>> IETF LLC board, staff and contractors will engage with the
>> IETF community, including
>> 
>> * what involvement board, staff and contractors may have in
>> the the development of RFCs; * what engagement they may have
>> with the NomCom; 
>> for the discussion of IETF LLC related matters.
>> 
>> The IETF LLC now seeks community feedback on this proposed
>> policy.  Please provide feedback by 26 October 2020 00:00 UTC
>> using any of the following methods:
>> 
>> * Direct to the IETF Executive Director at
>> [email-masked] * Direct to the IETF LLC Board (not
>> including the IETF Executive Director) at
>> [email-masked] * To the [email-masked] list
>> 
>> [1]
>> https://github.com/ietf-llc/community-engagement-policy-consu
>> ltation/blob/master/DRAFT%20Community%20Engagement%20Policy.md
>> [2]

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 13:00:05 +1300

Thank you all for the feedback so far.  In order to understand how to draft revisions to address the issues raised [1], I have some questions.  In asking these I want to reiterate that Conflict of Interest is, in my experience, often determined by individual perceptions rather than an entirely objective framework.

1.  The emerging view of the community is that an RPC employee *contributing* to a draft is sufficiently distant from the RPC process to avoid any conflict of interest.  It appears to me that *authoring* a draft however does introduce a conflict of interest (COI) as part of the RPC role is to enforce specific standards that authors must comply with, which is a standard COI that is controlled by separation of powers.  There is an existing situation where RPC staff author RFCs on behalf of the RPC but that is different from a personal role.

I would be interested therefore to hear which of the following ways forward you think is best (for now let’s leave aside whether policy or contract is the best way to capture this):

a.  Prohibit RPC staff from *authoring* non-RPC drafts (not contributing to, just authoring).
b.  Prohibit any RPC staff that author a non-RPC draft from any processing or discussion of that draft in their RPC role.
c.  No restrictions at all.

2.  RFC 8711 is clear about the role of the LLC that "It has no authority over the standards development activities of the IETF", which is taken to mean that there should be a bright line between the work of the LLC and the standards process.  The concern is that the LLC and the IETF Executive Director (and the Secretariat because they act on behalf of the LLC) have significant power in the the IETF, even if it is not directly about the standards process, and if allowed to participate in the standards process could utilise that power to "put their finger on the scales".

With that explanation would anyone object to maintaining the restriction on staff and Secretariat being involved in the standards process or do you think there is not a COI that needs to be guarded against?

3.  The proposed policy includes the following statement with regard to development of RFCs that nobody has yet suggested is inappropriate:
> Contractors are also expected to ensure that it is always clear to those being engaged with, if the contractor is engaging as a contractor or as a volunteer, as assumptions may vary between people and situations.

Does anyone object to that same clause applying to any interaction with the NomCom? 

Jay

[1]  https://github.com/ietf-llc/community-engagement-policy-consultation/issues

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Oct 2020 21:46:02 -0400

--On Tuesday, October 13, 2020 13:00 +1300 Jay Daley
<[email-masked]> wrote:

> Thank you all for the feedback so far.  In order to understand
> how to draft revisions to address the issues raised [1], I
> have some questions.  In asking these I want to reiterate that
> Conflict of Interest is, in my experience, often determined by
> individual perceptions rather than an entirely objective
> framework.
> 
> 1.  The emerging view of the community is that an RPC employee
> *contributing* to a draft is sufficiently distant from the RPC
> process to avoid any conflict of interest.  It appears to me
> that *authoring* a draft however does introduce a conflict of
> interest (COI) as part of the RPC role is to enforce specific
> standards that authors must comply with, which is a standard
> COI that is controlled by separation of powers.  There is an
> existing situation where RPC staff author RFCs on behalf of
> the RPC but that is different from a personal role.

Jay, this would be fine, except for two things.  The first is
that the distinction between "author" and "contributor" (whether
listed as such in the body of the I-D or RFC or not) has been
much less clear in the history of the RFC Series than your
description above seems to imply.  Putting the RPC aside for a
moment, I can't count the number of times (including when I was
an AD or WG chair) in which I've helped someone sketch out a
document and contributed strawman text and then dropped back to
Contributor or, more often, a simple acknowledgement.  Sometimes
those have even been documents whose positions I don't like but
felt it important that the community have a chance to consider
the ideas.  My participation in those ways has never been a
secret and I think there is an ethical (whether contractual or
not) obligation to disclose such involvement.

But I think the general principle is close to the one I
identified about the Nomcom restrictions: The IETF simply cannot
afford to discard (or be deprived of) knowledgeable and
competent input and opinions just because someone who has them
happens to have taken a job with a contractor organization (or
because they work for a company that has become unpopular).  We
(and especially WGs and the IESG) made evaluations of the
quality and content of work independent of its authorship and
their connections every day: even if we don't already get it
right, that is the business we are in, just as the Nomcom is in
the business of soliciting and evaluating comments about
candidates. It would be perfectly reasonable for AMS to say to
one of its staff "we have a contract here and you can't work on
that document to which you are contributing on company time".
It is not reasonable, or in the IETF's best interest, to prevent
input, contributions, or participation from anyone.  For many
I-Ds and RFCs, for the LLC to do that would constitute
interference in the standards process which I believe the LLC is
expressly forbidden to do (see Brian's note about the Nomcom
part of that).

> I would be interested therefore to hear which of the following
> ways forward you think is best (for now let's leave aside
> whether policy or contract is the best way to capture this):
> 
> a.  Prohibit RPC staff from *authoring* non-RPC drafts (not
> contributing to, just authoring). b.  Prohibit any RPC staff
> that author a non-RPC draft from any processing or discussion
> of that draft in their RPC role. c.  No restrictions at all.

Close to "c": this may be an AMS (or whomever the RPC contractor
is) issue, but it is not one in which the LLC should be meddling
wrt the RPC or any other AMS employee. 

> 2.  RFC 8711 is clear about the role of the LLC that "It has
> no authority over the standards development activities of the
> IETF", which is taken to mean that there should be a bright
> line between the work of the LLC and the standards process.
> The concern is that the LLC and the IETF Executive Director
> (and the Secretariat because they act on behalf of the LLC)
> have significant power in the the IETF, even if it is not
> directly about the standards process, and if allowed to
> participate in the standards process could utilise that power
> to "put their finger on the scales".

Again, if we eliminated participation from everyone whose
affiliations could create the appearance of putting fingers on
scales, we'd have very few people left, including members of the
LLC Board, even those who are not Nomcom appointees... whom I
note this policy does not prevent from contributing to the
standards process.

> With that explanation would anyone object to maintaining the
> restriction on staff and Secretariat being involved in the
> standards process or do you think there is not a COI that
> needs to be guarded against?

I think the only reasonable remedy to actual or perceived COIs
is full disclosure, not prohibitions.

> 3.  The proposed policy includes the following statement with
> regard to development of RFCs that nobody has yet suggested is
> inappropriate:
>> Contractors are also expected to ensure that it is always
>> clear to those being engaged with, if the contractor is
>> engaging as a contractor or as a volunteer, as assumptions
>> may vary between people and situations.
> 

I would be happier if such disclosure requirements applied to
everyone involved, including LLC staff and LLC Board members wrt
any decisions they make.

And that may expose a small pachyderm in this particular room:
In this situation and a number of others, the boundary seems a
little thin between your explaining a proposal from yourself
and/or the Board, asking questions to clarify community
perspectives (as above), and so on on one hand and either
advocating for particular approaches or offering perspective or
advice in your individual capacity.  Consistent with what I'd
said elsewhere, I think more transparency would be helpful while
more rules would probably not be.  Do you agree and, if so,
could you try to be a little bit more clear and when you are
speaking for the Board versus offering your own perspective and
when you are speaking as an individual rather than Exec Dir?

Finally, coming back to your response to one of Mike's
questions, is it reasonable to assume that, if the LLC makes new
polities that it intends to apply to future contracts and
retroactively to existing ones, those policies will at least be
clearly identified and shared with the community?  That would
seem to be consistent with general requirements about openness
and transparency without infringing or interacting with
confidential provisions of any particular contract?

   thanks,
    john

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 15:43:23 +1300

> when you are speaking as an individual rather than Exec Dir?

All interactions I have within the IETF are in my professional capacity as the IETF Executive Director.  "Advocating for particular approaches or offering perspective or advice" is part of what I am paid to do and the areas where I do that are all within the scope of the IETF LLC.  If I were to do that for something outside of the scope of my role, such as commenting on the technical details of a nascent standard, then that should be treated as me overstepping the boundary while wearing my Exec Dir hat, not me taking that hat off.  I entirely agree that this could do with greater clarity, which is what this policy aims to provide.

Your question about "speaking for the board versus offering your own perspective" is based on a misunderstanding of what the LLC is.  The LLC is not a board/group, such as the IAB/IESG/NomCom/RSOC etc, it is a company, which both the board of directors and I serve and which both of us can speak on behalf of.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Mon, 12 Oct 2020 19:51:25 -0700

At 04:23 PM 11-10-2020, IETF Executive Director wrote:
>LLC Community Engagement Policy [1] that sets out how IETF LLC 
>board, staff and contractors will engage with the IETF community, including
>

The purpose of this proposed policy is unclear as it covers conflict 
of interest and conduct.  It could be interpreted as a policy against 
a "speak up" culture.  Did the IETF LLC consider updating the 
existing conflict of interest and code of conduct policies instead of 
creating another policy?

Is there a list of individuals who are formally authorized to act on 
behalf of the IETF LLC?

Why is the IETF LLC specifying that the policy would be applicable 
for Association Management Solutions personnel when it is already 
covered under "Work Standards"?

Does the "occasionally include contributing to or authoring RFCs" 
statement conflict with the Intellectual Property clause in existing contracts?

Why is Association Management Solutions being asked to be supportive 
and helpful?

Why are there urgent consultations?

Why is the IETF LLC so concerned about staff or contractors 
retaliating against a LLC board member that it has to include that in 
the proposed policy?

The "clear potential for a conflict of interest" in the "NomCom" 
section does not make sense as it is not applicable to a process.

Why is an IETF LLC blog post an event for ietf-announce?

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Oct 2020 23:35:35 -0400

--On Tuesday, October 13, 2020 15:43 +1300 Jay Daley
<[email-masked]> wrote:

>> advocating for particular approaches or offering perspective
>> or advice in your individual capacity.  Consistent with what
>> I'd said elsewhere, I think more transparency would be
>> helpful while more rules would probably not be.  Do you agree
>> and, if so, could you try to be a little bit more clear and
>> when you are speaking for the Board versus offering your own
>> perspective and when you are speaking as an individual rather
>> than Exec Dir?
> 
> All interactions I have within the IETF are in my professional
> capacity as the IETF Executive Director.  "Advocating for
> particular approaches or offering perspective or advice" is
> part of what I am paid to do and the areas where I do that are
> all within the scope of the IETF LLC.  If I were to do that
> for something outside of the scope of my role, such as
> commenting on the technical details of a nascent standard,
> then that should be treated as me overstepping the boundary
> while wearing my Exec Dir hat, not me taking that hat off.  I
> entirely agree that this could do with greater clarity, which
> is what this policy aims to provide.
> 
> Your question about "speaking for the board versus offering
> your own perspective" is based on a misunderstanding of what
> the LLC is.  The LLC is not a board/group, such as the
> IAB/IESG/NomCom/RSOC etc, it is a company, which both the
> board of directors and I serve and which both of us can speak
> on behalf of.

Jay, unless I (and perhaps at least a few other members of the
community) are under the impression that company is managed by a
Board consisting of Directors [1].  That Board has "full and
complete discretion to manage and control the business and
affairs of the Company, to make all decisions affecting the
business and affairs of the Company and to take all such actions
as it deems necessary or appropriate to accomplish the purposes
of the Company. Neither the Member, any individual Director, any
officer, any staff member, nor any other person shall have any
authority or right to act on behalf of or bind the Company,
except as specifically authorized by the Board or as
otherwise provided herein."   Now, summarizing what I'm sure you
know but that others may not remember, the Board "will hire and
supervise" you.  You are an Officer of the Company but not a
Director.  And the Board may delegate authority to speak for the
Company to you.  So far, so good.

Things get more interesting when one looks at Section 5(d) of
that document, including the expectation that the Board will
"delegate management of day-to-day activities and related
decision-making to staff".  Nothing unusual there, but...

The members of the Board, with the exception of the one
appointed by ISOC, all all appointed by the Nomcom or confirmed
or appointed by the IESG.  If the Nomcom is going to do its job
of evaluating candidates (including especially incumbents) for
Board seats (including that of the IETF Chair), then it needs to
be able to evaluate the job that Board members are doing
deciding what authority to delegate to you (Section 5(b), in the
decisions it makes about what strategic responsibilities it
wants to retain versus delegating to you (or others, including
its Chair), and so on.  

If for no other reason than the mechanism of how Directors are
appointed and for things that are not day to day activities, the
distinction between positions you are taking under a delegation
of authority from the Board and positions taken by the Board on
which you are reporting is very important.  I suppose the Board
(or you if so delegated) could take the position that those
boundaries must remain confidential in the best interests of the
Company, but, I would then expect that information would be
disclosed to the Nomcom and that the community would be told why
it was inappropriate to share it.

Now, if some part of that is a continued misunderstanding, I'm
very interested in a better understanding.

thanks,
    john

[1] Limited Liability Company Agreement of IETF Administration
LLC

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 17:01:48 +1300

Hi Subramanian

There’s a lot here and it’s not clear to me if your questions are because you have specific concerns with the policy that I should be tracking as issues.

> On 13/10/2020, at 3:51 PM, S Moonesamy <[email-masked]> wrote:
> 
> The purpose of this proposed policy is unclear as it covers conflict of interest and conduct.  It could be interpreted as a policy against a "speak up" culture.  Did the IETF LLC consider updating the existing conflict of interest and code of conduct policies instead of creating another policy?

Because it goes broader than either of those.  e.g. the section on 'Mechanisms'.

> Is there a list of individuals who are formally authorized to act on behalf of the IETF LLC?

Yes.  Board and staff always, Secretariat generally, and our accountants, lawyers, Tools Team PM, NOC Lead and others on specific issues.

> Why is the IETF LLC specifying that the policy would be applicable for Association Management Solutions personnel when it is already covered under "Work Standards"?

It isn’t.

> Does the "occasionally include contributing to or authoring RFCs" statement conflict with the Intellectual Property clause in existing contracts?

No.

> Why is Association Management Solutions being asked to be supportive and helpful?

As a reminder, the policy is based on roles not who delivers them and covers multiple roles:

"When contributing to community discussions for any of these subjects, staff, Secretariat and RPC should aim to be supportive and helpful to the process and should not limit or otherwise interfere with the ability of the community to engage."

Do you think that there are times when we (all the roles above, including me) should engage in a way that is not supportive and helpful?

> Why are there urgent consultations?

Sometimes we need to act quickly.  For example, the last urgent consultation was about making fee waivers for IETF 108 unlimited and had to be conducted in 48 hours due to the fixed timing of the meeting.  It is conceivable there will be another and putting some structure in place before that happens again is a sensible plan.

> Why is the IETF LLC so concerned about staff or contractors retaliating against a LLC board member that it has to include that in the proposed policy?

This is a broad policy that covers a number of subjects of which NomCom interaction is just one.  BTW  ascribing/questioning motives, particularly with an emotive preface such as "so concerned", distracts from your underlying question. 

> 
> The "clear potential for a conflict of interest" in the "NomCom" section does not make sense as it is not applicable to a process.

I’m not sure I understand what you mean - the process is the NomCom appointment process.

> Why is an IETF LLC blog post an event for ietf-announce?

The IETF LLC has a strong commitment to transparency, which the community has repeatedly requested and/or supported.  Until recently we have not really had stats about blog readership and so we err on the side of caution by also using ietf-announce to make sure that transparency commitment is fulfilled.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Oct 2020 17:09:50 +1300

> On 13/10/2020, at 4:35 PM, John C Klensin <[email-masked]> wrote:
> 

Yes I think you’ve still misunderstood and I think we’re well into the weeds now so I will take this offlist.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 13 Oct 2020 08:31:53 +0100

You asked... 😊

> 1.  The emerging view of the community is that an RPC employee *contributing* to a
>  draft is sufficiently distant from the RPC process to avoid any conflict of interest.
> It appears to me that *authoring* a draft however does introduce a conflict of 
> interest (COI) as part of the RPC role is to enforce specific standards that authors
> must comply with, which is a standard COI that is controlled by separation of powers.
> There is an existing situation where RPC staff author RFCs on behalf of the RPC but
> that is different from a personal role.

There is no clear line between "authoring" and "contributing". This is, I think, a misunderstanding of how the IETF works.
An "author" may simply be an editor who compiles the consensus-view text.
A "contributor" may supply most of the text in a draft.

> I would be interested therefore to hear which of the following ways forward you
> think is best (for now let’s leave aside whether policy or contract is the best way
> to capture this):
>

If I am only allowed a choice of those three, then c.
But I prefer...
d. No restriction except that the staff shall at all times make clear their affiliation (both in emails and in the posted document).

> 2.  RFC 8711 is clear about the role of the LLC that "It has no authority over the standards
> development activities of the IETF", which is taken to mean that there should be a bright
> line between the work of the LLC and the standards process.  The concern is that the LLC 
> and the IETF Executive Director (and the Secretariat because they act on behalf of the LLC)
> have significant power in the the IETF, even if it is not directly about the standards process,
> and if allowed to participate in the standards process could utilise that power to "put their
> finger on the scales".

I see "no authority over" as very different from "participate in." In fact, I see the former as a statement of fact that contradicts the concern that the LLC and IED (and Secretariat) could influence the standards process and "put their finger on the scales."

> With that explanation would anyone object to maintaining the restriction on staff and 
> Secretariat being involved in the standards process or do you think there is not a COI
> that needs to be guarded against?

Since the standards process is entirely consensus based, attempts to interfere are visible to the community and are rectified. 

Again, you offer a choice of two things, and I refuse the choice 😊
Yes, there is a COI that needs to be guarded against. No, I object to your proposed way of guarding against it.
I believe that sufficient safeguard is achieved by full and frequent disclosure of affiliation.

> 3.  The proposed policy includes the following statement with regard to development
> of RFCs that nobody has yet suggested is inappropriate:
>
>> Contractors are also expected to ensure that it is always clear to those being engaged
>> with, if the contractor is engaging as a contractor or as a volunteer, as assumptions

Almost. 
When a person engages in their contracted role, that must be made clear.
When a person with a contracted role engages as an *individual* (please don't say "volunteer" as that has so many peculiarities) they should, nevertheless, disclose their contractual role.
(It is a rare thing that someone's opinions and desired outcomes are not in some way shaped by their employment experiences and prospects.)

Once again, Jay, very many thanks for holding this discussion with the community and in the open.

Best,
Adrian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Oct 2020 07:28:39 -0500

Hi, Jay,

On Sun, Oct 11, 2020 at 8:22 PM Jay Daley <[email-masked]> wrote:

> Added as Issue #1 "Policy on feedback to the NomCom is too restrictive" at
> https://github.com/ietf-llc/community-engagement-policy-consultation/issues/1
>
> liaison will even know about the issues.  Even if the interaction is with
> you, I would be unsurprised if you had been discreet enough not to raise
> the issues with the LLC board unless the problem was actually interfering
> with your work.  But that does not mean that it is not useful information
> for the nomcom.
> almost impossible to relay the issues.  (Yes, there is a problem that the
> issue will come to the attention of the LLC Board Liaison.  That is a
> different topic.  I believe folks are aware that that can serve as a damper
> on feedback about sitting IAB or IESG members.  That is a topic for a
> different list.  And a very messy topic for which I do not know any
> remedies.)
> >

Joel has been a Nomcom chair. I've never been a voting member, but I served
on the IAB from 2010-2013, on the IESG from 2013-2019, and as IAB liaison
to Nomcom in 2010-2011, so wanted to provide a slightly different
perspective (that ends up in the same place).

I understand that you're solving a slightly different problem for the LLC,
but hope this is helpful.

If I wanted to keep my feedback to Nomcom about a fellow IAB member or IESG
member confidential, routing it through a fellow IAB or IESG member is
involving someone who has to work with me, and with the person I'm
providing feedback on, is involving someone who doesn't have to be part of
the chain.

If I wanted to keep my feedback to the Nomcom anonymous, the current
process allows that (I send it to the Nomcom chair, who decides how to
anonymize it). I'm not sure how that would work if I had to route it
through a liaison. I've never provided anonymous feedback to the Nomcom,
but I've never needed to.

The IETF Nomcom is really strange, compared to the ways many other groups
choose their leadership, relying strongly on confidentiality, the desire of
Nomcom members to do the right thing, and the willingness of the community
to trust the Nomcom to do the right thing, whatever that turns out to be.
It's really jarring, what the Nomcom can do, if they think it's the right
thing to do ("change position descriptions if they think the ones they were
provided aren't workable", isn't what executive recruiters usually do).

It seems helpful to allow anyone who thinks their feedback is important to
the Nomcom to provide that feedback, confidentially in all cases and
anonymously if that's required, and trust the Nomcom to figure out what the
right thing to do is, based on the feedback that they're getting.

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Oct 2020 07:39:36 -0500

To follow up on this,

On Tue, Oct 13, 2020 at 2:32 AM Adrian Farrel <[email-masked]> wrote:

> *contributing* to a
> There is no clear line between "authoring" and "contributing". This is, I
> think, a misunderstanding of how the IETF works.

I agree with Adrian, here, with what I hope is the friendly amendment that
MOST of us are confused about that (it's not just you, Jay!)

We have had our shoelaces tied together between "names on the front of an
RFC" versus "editors" versus "authors" versus "additional authors" versus
"contributors" versus "people who provided helpful reviews and comments
which contributed text" versus other variants that I can't think of, right
now, and it's been that way since we started getting so many names on the
front of an RFC that everything else flowed off the first page and that
broke tools (so, at least a couple of decades).

But ""author" versus "contributor" definitely isn't a useful distinction.

Best,

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Oct 2020 10:11:29 -0500

I think the majority of the proposed policy is taking the wrong approach. Much of what I want to say has already said, but maybe there’s something left to add.

No organization that represents the IETF should have a policy that discourages people from fully participating in all aspects of the IETF standards process, except in very narrow situations. That is, any such policy should focus on real CoI, not imagined CoI.

I’m going to focus on the RPC, but I think the same logic applies to some degree for all LLC staff and contractors. The board might be different, but I have not thought that through.

In the case of the RPC, I have a great deal of difficulty imagining how an RPC member would have a vested interest on a technical matter due to fact of their presence on the RPC. It seems less likely than for employees of network equipment vendors. In fact, they might represent the idealized IETF participant, that is one who only represents their best technical judgement. If we were developing technical publication workflow standards, I could see CoI, but no more than for an employee of a router vendor contributing to routing protocol work.

It seems odd to me that the policy would allow more contribution to administrative work than technical work, since there is actually more likely to be CoI for administrative work.

IMO, any LLC participation policy should be primarily about transparency and declaration of CoI, not about limiting participation in general. Maybe people need to recuse from certain specific things due to certain specific conflicts, but that is very different than blanket participation rules. Any such policy should err on the side of encouraging participation, not discouraging it.

Thanks,

Ben.

> Begin forwarded message:
> 
> From: IETF Executive Director <[email-masked]>
> Date: October 11, 2020 at 6:23:28 PM CDT

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Oct 2020 10:14:49 -0500

> On Oct 11, 2020, at 7:11 PM, Joel M. Halpern <[email-masked]> wrote:
> 

+1. I am personally aware of such participation, and it would be a loss to the community if it were to stop.

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Oct 2020 10:26:03 -0500

> On Oct 12, 2020, at 7:00 PM, Jay Daley <[email-masked]> wrote:
> 

I concur with what others have said about the lack of a bright line between authoring and contributing. And for this specific purpose, there should be no difference.

> c.  No restrictions at all.

I prefer option c, with the caveat that perhaps the RPC member shouldn’t edit their own draft when it comes back to the RPC.

I have trouble imagining how an RPC staff member having offering RPC related opinions on a work-in-process draft would not, on the balance, do more good than harm.

> With that explanation would anyone object to maintaining the restriction on staff and Secretariat being involved in the standards process or do you think there is not a COI that needs to be guarded…

I have no objection to staff and Secretariat being involved in all aspects of  the standards process in general, as long as they are transparent about their affiliation and do not attempt to represent the opinions LLC, Secretariat, etc. If they have concrete, specific conflicts about a given subject, it might make sense for them to declare that or even recuse. But banning them from the standards process in general is the proverbial wrong tool.

> Does anyone object to that same clause applying to any interaction with the NomCom?

While it would be good for people to do this (even people not affiliated with the LLC), I agree with previous statements that this sort of thing should be up to the NomCom to decide.

Thanks,

Ben.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 13 Oct 2020 11:16:56 -0700

Hi Jay,
At 09:01 PM 12-10-2020, Jay Daley wrote:
>There's a lot here and it's not clear to me if your questions are 
>because you have specific concerns with the policy that I should be 
>tracking as issues.

I would like to understand what is being proposed before getting to concerns.

> > Why is the IETF LLC specifying that the policy would be 
> applicable for Association Management Solutions personnel when it 
> is already covered under "Work Standards"?
>
>It isn't.

Please see Section 1(b): 
https://www.ietf.org/media/documents/IETF_AMS_Secretariat_Agreement_FULL_-_2020_-_EXECUTED_REDACTED.pdf 
It states that "Contractor agrees to comply with all IETF LLC 
policies, as provided by IETF LLC to Contractor from time to time."

> statement conflict with the Intellectual Property clause in existing contracts?

That is not my reading of Section 8 of the "redacted contract" which 
states that the "Work Product" is owned by the IETF Trust.

>"When contributing to community discussions for any of these 
>subjects, staff, Secretariat and RPC should aim to be supportive and 
>helpful to the process and should not limit or otherwise interfere 
>with the ability of the community to engage."
>
>Do you think that there are times when we (all the roles above, 
>including me) should engage in a way that is not supportive and helpful?

Your question is about who delivers the service.  I would expect the 
entity managing the contract to determine what type of customer 
support is required.  It would be unexpected if customer support is 
not helpful.

>Sometimes we need to act quickly.  For example, the last urgent 
>consultation was about making fee waivers for IETF 108 unlimited and 
>had to be conducted in 48 hours due to the fixed timing of the 
>meeting.  It is conceivable there will be another and putting some 
>structure in place before that happens again is a sensible plan.

That was a one-off case.  If it recurs, it could be because of 
inadequate planning.  Such statements would make sense if the goal is 
to tick the compliance checkboxes.

> retaliating against a LLC board member that it has to include that 
> in the proposed policy?
>
>This is a broad policy that covers a number of subjects of which 
>NomCom interaction is just one.  BTW  ascribing/questioning motives, 
>particularly with an emotive preface such as "so concerned", 
>distracts from your underlying question.

I asked someone from the United States to review my question for 
appropriateness.  The person did not find anything emotive in the sentence.

Does the "use the NomCom process to retaliate against a LLC board 
member ..." ascribe motives?

>I'm not sure I understand what you mean - the process is the NomCom 
>appointment process.

The prohibited conflicts (please see conflict of interest policy) is 
about actions, relationships or transactions, instead of a process.

>The IETF LLC has a strong commitment to transparency, which the 
>community has repeatedly requested and/or supported.  Until recently 
>we have not really had stats about blog readership and so we err on 
>the side of caution by also using ietf-announce to make sure that 
>transparency commitment is fulfilled.

The IETF LLC is increasing the number of emails to subscribers by 
erring on the side of caution.  It is like using every possible 
mailing list because the IETF LLC can do it.

Were the conflict of interest disclosures sent to ietf-announce?

Regards,
S. Moonesamy

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 13 Oct 2020 15:42:13 -0500

On 12 Oct 2020, at 19:00, Jay Daley wrote:

> 2.  RFC 8711 is clear about the role of the LLC that "It has no 
> authority over the standards development activities of the IETF", 
> which is taken to mean that there should be a bright line between the 
> work of the LLC and the standards process.

Correct me if I'm wrong Jay, but this sounds to me like the LLC (board 
and ED) are trying to come up with a policy that instantiates the first 
paragraph of section 4.3 of RFC 8711:

4.3.  General IETF LLC Responsibilities

    The IETF LLC is established to provide administrative support to the
    IETF.  It has no authority over the standards development activities
    of the IETF.

and is trying to enumerate what it needs to do (or, more likely, needs 
not to do) to avoid running afoul of having "authority of the standards 
development activities".

I have always taken that admonition to mean that when the LLC engages in 
its enumerated responsibilities (Operations, Finances, Fundraising, and 
Compliance), none of those activities take precedence over the RFC 2026 
processes without amendment of those processes by the IETF community 
through normal rough consensus means. So, obviously the LLC may not say 
to the IESG, "Company X has been a generous sponsor, and therefore you 
should approve a document that Company X favors." That would be pretty 
egregious. But it's also not OK for the LLC to decide, "We think 
document review and determination of consensus would go much better with 
this cool new voting tool, which we've decided to deploy." The LLC must 
not (as the LLC) drive a change in the consensus determination process 
by introducing or requiring a new tool; the process change must be 
driven from the IETF community and a new tool or functionality requested 
from there through the IESG.[1]

Perhaps others have suggestions for how the LLC ought write down this 
limitation in the form of a policy, should the LLC feel that it needs 
one for itself. But overall, this seems based on a misunderstanding (or 
perhaps over-interpretation) of that line in 8711. I think it is 
important for the LLC to be clear about what that line means and to 
execute accordingly, but the policy as presented doesn't get it right.

pr

[1] As others have said, none of this requires that LLC board members or 
employees should not participate as individuals, just as employees of 
big donor Company X above do; they just all must go in with the 
understanding that they participate as individuals and make clear their 
potentials COIs if they choose to do so. As others have said, their 
input will be judged on the merits.

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Jay Daley <[email-masked]>
Date: Wed, 14 Oct 2020 09:48:15 +1300

Thanks Ben (and others)

Just a couple of follow-ups to clear up some possible crossed-wires:

> On 14/10/2020, at 4:26 AM, Ben Campbell <[email-masked]> wrote:
> 

The distinction I was trying to make here is between those who interact/negotiate with the RPC about drafts that are in the process of becoming RFCs and those who don’t.  I’ll assume that distinction is also mistaken unless I hear otherwise.

> I prefer option c, with the caveat that perhaps the RPC member shouldn’t edit their own draft when it comes back to the RPC.

That’s basically what I was getting at with b.  

> I have trouble imagining how an RPC staff member having offering RPC related opinions on a work-in-process draft would not, on the balance, do more good than harm.

I agree, my question was about RPC staff offering non-RPC related opinions.

thanks again
Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Oct 2020 15:51:43 -0500

> On Oct 13, 2020, at 3:48 PM, Jay Daley <[email-masked]> wrote:
> 
> Thanks Ben (and others)
> 
>> On 14/10/2020, at 4:26 AM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Apologies, I misread the intent of B to mean that they could not offer opinions related to the RPC role while contributing to the work prior to it going into the RFC editor state(s). I think that is distinctly different than acting as the assigned editor on such a draft when it reaches that state.

Ben.

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Oct 2020 17:12:34 -0400

--On Wednesday, October 14, 2020 09:48 +1300 Jay Daley
<[email-masked]> wrote:

>> I concur with what others have said about the lack of a
>> bright line between authoring and contributing. And for this
>> specific purpose, there should be no difference.
> 
> The distinction I was trying to make here is between those who
> interact/negotiate with the RPC about drafts that are in the
> process of becoming RFCs and those who don't.  I'll assume
> that distinction is also mistaken unless I hear otherwise.

Yes, that distinction does not work either.

>>> that author a non-RPC draft from any processing or
>>> discussion of that draft in their RPC role. c.  No
>>> restrictions at all.
 
>> I prefer option c, with the caveat that perhaps the RPC
>> member shouldn't edit their own draft when it comes back to
>> the RPC.
> 
> That's basically what I was getting at with b.  

But, in our context, that is elementary good sense.  Just as I
don't believe that we've ever written down the rule that an AD
is not supposed to AD-sponsor and shepherd an I-D that he or she
has written, if nothing else the "make sure there is an extra
set of eyes on this" principle suggests that someone should not
be the lead editor (for the RPC) on a draft they have written
all, or significant parts of.  I worry about over-specifying
that because it is not uncommon for an author to ask the RFC
Editor Function (via mail to [email-masked]) to
handle a specific editorial issue and get back an answer (often
a consensus one within the RFC Editor Function team) with
suggested text.  While it is an RPC/AMS issue rather than
something I think  the LLC should get into the middle of, I also
don't think we should do anything that discourages the RPC from
collaborating on a document, passing it back and forth and
getting multiple opinions on the handling of questions whose
answers are not obvious.   If we start trying to construct
rigid-sounding rules, we could easily end up in a situation in
which most of the RPC team was prohibited from editing a
document in which there has been some RFC Editor Function
involvement before it comes over the wall from the Stream.  

So, I think the preference should be that the RPC should
exercise good sense and professional judgment in working on any
document with which any of them have been involved.  No specific
rules needed beyond "act professionally".  If, for any reason,
they cease to do that, I think we have bigger problems than who
is editing a document, especially given the final checks at
AUTH48 by  the relevant streams.

>> I have trouble imagining how an RPC staff member having
>> offering RPC related opinions on a work-in-process draft
>> would not, on the balance, do more good than harm.
> 

And, again, if they are offering opinions that are non-RPC
related, they should be doing so as individuals with disclaimers
about employment and interests as appropriate.  There are
probably non-RPC related opinions that do not interact with the
standards process (or the Nomcom) in any way but I have trouble
coming up with examples.

And, as --On Tuesday, October 13, 2020 15:42 -0500 Pete Resnick
<[email-masked]> wrote in this footnote:

> [1] As others have said, none of this requires that LLC board
> members or employees should not participate as individuals,
> just as employees of big donor Company X above do; they just
> all must go in with the understanding that they participate as
> individuals and make clear their potentials COIs if they
> choose to do so. As others have said, their input will be
> judged on the merits.

Now, if the LLC wants to impose a disclosure requirement on
Directors, Officers, staff, contractors, and/or employees of
contractors that goes beyond the normal IETF requirements that
people act professionally and disclose COIs or other connections
that might bias their opinions or preferences, I think that
would be permissible (although, I hope, unnecessary).  But let's
not discourage or prohibit participation or other expressions of
opinion based on whatever expertise someone might have.

   john