--On Wednesday, October 14, 2020 09:48 +1300 Jay Daley <jay@xxxxxxxx> wrote: > 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 <ben@xxxxxxxxxxx> >> 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. >>> 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. > > 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 rfc-editor@xxxxxxxxxxxxxx) 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. > > I agree, my question was about RPC staff offering non-RPC > related opinions. 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 <resnick@xxxxxxxxxxxx> 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
