> On Oct 12, 2020, at 7:00 PM, Jay Daley <jay@xxxxxxxx> 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. 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. > > 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. 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. > > > 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? 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. > > > 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? 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. > > > > Jay > > > > [1] https://github.com/ietf-llc/community-engagement-policy-consultation/issues > > -- > Jay Daley > IETF Executive Director > jay@xxxxxxxx >
