Subject: [Rfced-future] Issue 34: Do we need to update Anti-Harrassment policy and WG procedures to make them applicable to WG?

From: Eliot Lear <[email-masked]>
Date: Tue, 18 May 2021 11:14:38 +0200

Where last we left this discussion, John Klensin noted that there were IETF-specific dependencies.  In response, Lars recently wrote:

> Do we really need to do all this work on BCP25? I'll note that for example the IRTF has no issue to simply say "these IETF rules also apply to us" without the respective IETF rules needing an update to (also) say that.

Does anyone object to this approach, such that we apply RFC 7776 as updated by RFC 8716?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 May 2021 09:17:10 -0400

It depends how we write everything else.  For the IRTF, I think eveyrone 
understands the substitution of IRSG for IESG and IRTF chair for IETF 
Chair.  And the IAB is still the parent body.
If the replacements in the case of the RSWG turn out to be simple and 
clear, then keeping it simple is great.  But it is not even obvious that 
the correct path for escalating harrasment issues from the RSG chairs 
would go to the RSAB.  It may?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 May 2021 09:59:48 +1200

> would go to the RSAB.  It may?

I think we should try to avoid duplication of mechanisms, so the more
that we can re-use the IETF mechanism, the better. But we (the RFC community)
would have to ask the IETF if they agree to that; for example can we
add this to the IETF Ombudsteam's remit?

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 May 2021 08:53:07 +0200

One could envision several approaches:

Swap roles inside of the policy, or
Contract the service to the IETF

In answering this, it may be helpful to ask the questions-
How core is this to the function of the RFCWG/RSAB?  Could the IETF have an outsized role in RFC policy because of this?  (I’m really hoping not ;-)
If we go for the easiest path (reusing the IETF process in its entirety) and get it wrong, what’s the consequence?  Could we just fix it later?

Eliot

> On 18 May 2021, at 23:59, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 19 May 2021 17:11:35 +1000

On Wed, May 19, 2021, at 16:53, Eliot Lear wrote:
>  * Swap roles inside of the policy, or
>  * Contract the service to the IETF
> 
>  * How core is this to the function of the RFCWG/RSAB?  Could the IETF 
> have an outsized role in RFC policy because of this?  (I’m really 
> hoping not ;-)

Firstly, I think having an anti-harrassment policy or code of conduct is important enough that not having one is a non-starter.  I do think that the IETF will have an influence here, but I don't think that it is a direct functional influence, but a cultural one and that's entirely OK.  I don't think that it will lead to disproportionate power for the IETF stream at all.  Not unless the whole process (ombudsteam and whatnot) ends up so badly broken that can be used as a weapon.  At that point, the IETF is probably also irredeemably busted, so it's probably not necessary to consider that outcome; and if it does happen, we have the below.

>  * If we go for the easiest path (reusing the IETF process in its 
> entirety) and get it wrong, what’s the consequence?  Could we just fix 
> it later?

The main consequence is likely to be a good one: we get a well-tested policy and processes.  And if issues are found, the IETF is more likely to be the ones to find them and fix them.  But I guess if we find some way in which the process fails, that is just a tiny facet of the existing problem we have all acknowledged as being hard: that is, what do we do if we find this RSWG business isn't working out?

>From my perspective, a broken RSWG process might lead to two entirely different resolution paths:

1. if the problem is small, we should empower the RSWG and RSAB to change the process

2. if the problem is so big and structural that it can't be resolved that way, I don't have a good answer, though this program is an existence proof of the community inventing a process to extricate itself from the same class of problem; so I'm almost inclined to say that we leave this one unsolved.  In the same way logicians acknowledge that Gödel was right but nonetheless persist, so can we.

For the purposes of the question of anti-harrassment and code of conduct, I believe that the first path is likely to be where we would end up.  The groups can fix the problem within their own processes.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 May 2021 08:05:14 -0400

I expect that the answer to the second question (how can we fix it if we 
get it wrong?) depends heavily on the earlier discussion about how can 
these procedures be updated?

If the answer, for minor updates, is not too much effort, then taking a 
reasonable first cut and moving on seems a very effective approach.

Yours,
Joel

On 5/19/2021 2:53 AM, Eliot Lear wrote:
>     entirety) and get it wrong, what’s the consequence?  Could we just
>     fix it later?
> 
> 
> Eliot
> 
>> On 18 May 2021, at 23:59, Brian E Carpenter 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>> Where last we left this discussion, John Klensin noted that there 
>>>> were IETF-specific dependencies.  In response, Lars recently wrote:
>>>>
>>>>> Do we really need to do all this work on BCP25? I'll note that for 
>>>>> example the IRTF has no issue to simply say "these IETF rules also 
>>>>> apply to us" without the respective IETF rules needing an update to 
>>>>> (also) say that.
>>>>