Subject: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt

From: [email-masked]
Date: Tue, 07 Sep 2021 05:06:36 -0700

A new version (-04) has been submitted for draft-eggert-bcp45bis:
https://www.ietf.org/archive/id/draft-eggert-bcp45bis-04.txt
https://www.ietf.org/archive/id/draft-eggert-bcp45bis-04.html

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-eggert-bcp45bis-04

IETF Secretariat.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Sep 2021 16:41:13 -0400

*  Last Call discussions of proposed protocol actions now take place
      on the IETF Last Calls mailing list [LAST-CALLS].

Document actions also, not just protocol actions.

   Apart from appointing SAAs, the IETF Chair should divorce themselves
   from the day-to-day operation and management of the SAA team.

I find "divorce themselves" to be an odd phrase, and suggest instead,
"the IETF Chair should stay away from the".

   Because an SAA serves at the discretion of the IETF Chair - even if
   the IETF Chair is not otherwise involved in the operation of the SAA
   team - any SAA decision could be appealed to the IAB.  The IAB shall
   then review the situation and attempt to resolve it in a manner of
   its own choosing.

Why are we varying from the normal appeal process here?  One reason to
keep the IETF Chair out of the operation is exactly so the first
appeal *can* go to the IETF Chair, as it normally would.  Then to the
plenary IESG, and then to the IAB.  I don't see a good reason to
change that process.

-- 
Barry

On Tue, Sep 7, 2021 at 8:07 AM <[email-masked]> wrote:
> --
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Sep 2021 16:41:13 -0400

-- 
Barry

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 09:50:49 +0300

Hi,

thanks for the suggestions. Please see https://github.com/larseggert/bcp45bis/pull/6 for a PR that rolls those in.

> plenary IESG, and then to the IAB.  I don't see a good reason to

This was also brought up by Rob during his AD review. This text is based on the current text in BCP45, which says:

   The IETF Chair, the IETF Executive Director, or a sergeant-at-arms
   appointed by the Chair is empowered to restrict posting by a person,
   or of a thread, when the content is inappropriate and represents a
   pattern of abuse.  They are encouraged to take into account the
   overall nature of the postings by an individual and whether
   particular postings are an aberration or typical.  Complaints
                                                      ^^^^^^^^^^
   regarding their decisions should be referred to the IAB.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I assumed that "complaints" were supposed to be appeals, because otherwise it's undefined what the IAB was supposed to do with these complaints.

I'm fully OK with using the regular appeals process here, but since it would be a change from the original BCP45 and the intent was to do a minimal bis, I didn't make that change.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 09:50:49 +0300

Hi,

Thanks,
Lars

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Sep 2021 23:53:38 -0700

On Wed, Sep 8, 2021 at 11:51 PM Lars Eggert <[email-masked]> wrote:

> Hi,
>
> thanks for the suggestions. Please see
> https://github.com/larseggert/bcp45bis/pull/6 for a PR that rolls those
> in.
>
> This was also brought up by Rob during his AD review. This text is based
> on the current text in BCP45, which says:
>
> I assumed that "complaints" were supposed to be appeals, because otherwise
> it's undefined what the IAB was supposed to do with these complaints.
>
> I'm fully OK with using the regular appeals process here, but since it
> would be a change from the original BCP45 and the intent was to do a
> minimal bis, I didn't make that change.
>
> Thanks,
> Lars
>
> --
> Gendispatch mailing list
> [email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Sep 2021 23:53:38 -0700

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Sep 2021 23:56:57 -0700

I don't think it really matters.

I am not aware of any successful appeal ever, so write whatever seems
expedient,

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Sep 2021 23:56:57 -0700

thanks,
Rob

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Sep 2021 19:06:21 +1200

> On 9/09/2021, at 6:50 PM, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 

As an aside - In case anyone has forgotten, the IETF Executive Director (me) can no longer do this as per RFC 8717.

Jay 

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

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Sep 2021 19:06:21 +1200

Jay 

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 10:11:54 +0300

Hi,

> As an aside - In case anyone has forgotten, the IETF Executive Director (me) can no longer do this as per RFC 8717.

thanks for pointing that out - I had forgotten that! Will remove that now.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 10:11:54 +0300

Hi,

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 10:15:21 +0300

Hi,

> thanks for pointing that out - I had forgotten that! Will remove that now.

I might have forgotten, but the SAA text from Dhruv corrected this already, so the current version is fine: https://github.com/larseggert/bcp45bis/pull/1

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Sep 2021 10:15:21 +0300

Hi,

Thanks,
Lars

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Sep 2021 00:20:12 -0700

As has been pointed out before, this discussion seems better suited for the
general IETF list. Is there something that needs to be dispatched here?

Not to mince words: I hope they enjoy that discussion, on a list I will
never join.

thanks,
Rob

On Thu, Sep 9, 2021 at 12:15 AM Lars Eggert <[email-masked]> wrote:

> I might have forgotten, but the SAA text from Dhruv corrected this
> already, so the current version is fine:
> https://github.com/larseggert/bcp45bis/pull/1
>
> Thanks,
> Lars
>
> --
> Gendispatch mailing list
> [email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Sep 2021 00:20:12 -0700

thanks,
Rob

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Sep 2021 10:12:21 -0400

> I am not aware of any successful appeal ever, so write whatever seems expedient,

Then perhaps you should look at the data.  There have been many
appeals that have been upheld.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Sep 2021 10:12:21 -0400

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Sep 2021 10:18:18 -0400

> I assumed that "complaints" were supposed to be appeals, because
> otherwise it's undefined what the IAB was supposed to do with these
> complaints.
>

But you've already changed "complaints" to "could be appealed", which
moves from something generic and undefined to something formal and
documented.  And, in fact, this document is so markedly different to
RFC 3005 that I couldn't use a DIFF at all, so I see the changes as
not minimal.  Please re-consider this point, and make it clear that
the normal appeals process applies.  It absolutely makes the most
sense for people to start with the IETF Chair -- or at the least, the
IESG -- before going to the IAB.  Appeals work best when there's more
than one stage to them.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Sep 2021 10:18:18 -0400

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2021 09:54:04 +1200

Nit pick:

> It absolutely makes the most
> sense for people to start with the IETF Chair

Actually, appeals (from WGs) start with an AD, so maybe this one
should start with the General Area AD? (I know it's the same person,
but wearing a slightly different hat.)

Better, perhaps: start with an AD, normally the General Area AD.
If the nature of the appeal personally involves the IETF Chair, the
appeal should start with some other AD.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Sep 2021 09:54:04 +1200

Regards
   Brian

---

From: Lars Eggert <[email-masked]>
Date: Fri, 10 Sep 2021 10:10:29 +0300

Hi,

I have a proposed change to use the normal RFC2026 appeals process in https://github.com/larseggert/bcp45bis/pull/7/files. This is the current change:

--- a/draft-eggert-bcp45bis.md
+++ b/draft-eggert-bcp45bis.md
@@ -192,8 +192,8 @@ manner.

 Because an SAA serves at the discretion of the IETF Chair - even if the IETF
 Chair is not otherwise involved in the operation of the SAA team - any SAA
-decision could be appealed to the IAB. The IAB shall then review the situation
-and attempt to resolve it in a manner of its own choosing.
+decision can be appealed to the IETF Chair, per {{!RFC2026}}. Decisions by the
+IETF Chair can be appealed to the IESG as whole, again per {{!RFC2026}}.

 # Security Considerations

Please let me know if this expresses what is desired?

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 10 Sep 2021 10:10:29 +0300

Hi,

Thanks,
Lars

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Sep 2021 07:01:39 -0400

That works for me, Lars, and thanks.

I see Brian's point about Gen AD instead of IETF Chair, but I don't
agree with it here, because the SAAs are explicitly appointed by the
IETF Chair, not related to the Gen Area.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Sep 2021 07:01:39 -0400

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2021 08:19:46 +1200

> IETF Chair, not related to the Gen Area.

You're correct. There's still the corner case where the IETF Chair is
conflicted - for example, if the message(s) objected to by the SAAs
made allegations about the IETF Chair themself. Probably another AD
should be the first recourse in that case.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Sep 2021 08:19:46 +1200

Brian

---

From: Lars Eggert <[email-masked]>
Date: Sat, 11 Sep 2021 08:36:39 +0300

Hi Brian,

Is that an option in your reading of 2026? They way I understand it is that if the AD is conflicted, the entire IESG is the next step?

Thanks,
Lars

-- 
Sent from a mobile device; please excuse typos.

> On Sep 10, 2021, at 23:20, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Lars Eggert <[email-masked]>
Date: Sat, 11 Sep 2021 08:36:39 +0300

Hi Brian,

Thanks,
Lars

>>> +IETF Chair can be appealed to the IESG as whole, again per {{!RFC2026}}

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 11 Sep 2021 19:37:42 +1200

Hi Lars,
Since 2026 doesn't mention conflict of interest, that's probably the
procedure. Not entirely satisfactory, but we could live with it.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Sat, 11 Sep 2021, 17:37 Lars Eggert, <[email-masked]> wrote:

> Hi Brian,
>
> Is that an option in your reading of 2026? They way I understand it is
> that if the AD is conflicted, the entire IESG is the next step?
>
> Thanks,
> Lars
>
> --
> >>> I have a proposed change to use the normal RFC2026 appeals process in
> https://github.com/larseggert/bcp45bis/pull/7/files. This is the current
> change:
> >>>
> the IETF

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 11 Sep 2021 19:37:42 +1200

Hi Lars,

Regards,
    Brian Carpenter

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 15 Sep 2021 08:47:34 +0000

I’ve not seen any further comments on this thread since Saturday.

My interpretation is that Lars and Barry are supportive of this change.

Brian, my interpretation is that Lar’s proposed text is acceptable to you.  Please clarify if this is not the case.

I would like to wait until Friday to see if there are any further comments on Lar’s proposed text.  If there are no strong objections then on Friday I’ll ask Lars to post a -05 with the change and I’ll kick off IETF LC.

Regards,
Rob

From: Brian Carpenter <[email-masked]>
Sent: 11 September 2021 08:38
To: Lars Eggert <[email-masked]>
Cc: Barry Leiba <[email-masked]>; GENDISPATCH List <[email-masked]>; [email-masked]
Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt

Hi Lars,
Since 2026 doesn't mention conflict of interest, that's probably the procedure. Not entirely satisfactory, but we could live with it.
Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Sat, 11 Sep 2021, 17:37 Lars Eggert, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

Thanks,
Lars

> On Sep 10, 2021, at 23:20, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
>
>>> On Fri, Sep 10, 2021 at 3:11 AM Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hi,
>>>
> [email-masked]<mailto:[email-masked]>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 15 Sep 2021 08:47:34 +0000

Regards,
Rob

Hi Lars,

Thanks,
Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 2021 08:55:50 +1200

> Brian, my interpretation is that Lar’s proposed text is acceptable to you.  Please clarify if this is not the case.

It's acceptable. In my experience, IESG members have always known when to 
recuse themselves.

    Brian

> *From:*Brian Carpenter <[email-masked]>
> *Sent:* 11 September 2021 08:38
> *To:* Lars Eggert <[email-masked]>
> *Cc:* Barry Leiba <[email-masked]>; GENDISPATCH List <[email-masked]>; [email-masked]
> *Subject:* Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-04.txt
> 
>  
> 
> Hi Lars,
> 
> On Sat, 11 Sep 2021, 17:37 Lars Eggert, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian,
> 
>     Is that an option in your reading of 2026? They way I understand it 
is that if the AD is conflicted, the entire IESG is the next step?
>     > On Sep 10, 2021, at 23:20, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >>> On Fri, Sep 10, 2021 at 3:11 AM Lars Eggert <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>> Hi,
>     >>>
>     >>> I have a proposed change to use the normal RFC2026 appeals process in https://github.com/larseggert/bcp45bis/pull/7/files <https://github.com/larseggert/bcp45bis/pull/7/files>. This is the current change:
>     >>>
>     > [email-masked] <mailto:[email-masked]>
>     > https://www.ietf.org/mailman/listinfo/gendispatch <https://www.ietf.org/mailman/listinfo/gendispatch>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 2021 08:55:50 +1200

Brian

---

From: Lloyd W <[email-masked]>
Date: Fri, 17 Sep 2021 20:31:33 +1000

As a latecomer to this thread, and as someone with rather more recent
experience of the SAAs than most... section 4 says:

   A sergeant-at-arms (SAA) is an officer appointed by a deliberative
   body to keep order during its meetings [SAA-WIKIPEDIA].  SAAs for the
   IETF discussion list are appointed by the IETF Chair

The contradiction here is obvious. An SAA is appointed by a deliberative body,
during its meetings, and the IETF Chair is not a deliberative body. An SAA
should be appointed by the deliberative body itself, which is to say, the list
itself, by the list members.

Furthermore, this draft is written by the current IETF Chair. So, this can
be seen as shoring up and reaffirming the Chair's power. 

I strongly object to this. Documenting or redocumenting an existing process
doesn't make that process right, and this violates the basic concept of the
SAA as described.

Lloyd Wood
[email-masked]

> On 15 Sep 2021, at 18:48, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
>

---

From: Lloyd W <[email-masked]>
Date: Fri, 17 Sep 2021 20:31:33 +1000

Lloyd Wood
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Sat, 18 Sep 2021 10:24:59 +0300

Hi,

On 2021-9-17, at 13:31, Lloyd W <lloyd.wood=[email-masked]> wrote:
> during its meetings, and the IETF Chair is not a deliberative body.

I added this quote from Wikipedia, because SAA is a pretty US/UK-centric term, and I received feedback that it is confusing to participants from other regions when they first encounter it.

I'd be happy to point to a different explanatory definition. I'd also be happy to remove it again.

> An SAA

Maybe it should, but BCP45 didn't set it up this way and this draft is not intending to change that.

> be seen as shoring up and reaffirming the Chair's power.

If you compare this document to BCP45, you will find that it actually significantly reduces the power of the IETF Chair. First, BCP45 allows for the Chair to directly impose posting restrictions. This hasn't been the practice for quite a number of years, and this document hence removes that option, placing it entirely at the disposition of the SAAs. Second, it clarifies that the appeals process applies here, which BCP45 left somewhat unclear.

> doesn't make that process right, and this violates the basic concept of the

If you would like to propose changes to the BCP45 SAA process, please do so. Objecting to this document isn't going to result in such changes, because BCP45 would remain unchanged.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 18 Sep 2021 10:24:59 +0300

Hi,

Thanks,
Lars

---

From: Lloyd W <[email-masked]>
Date: Sat, 18 Sep 2021 18:54:26 +1000

> On 18 Sep 2021, at 17:25, Lars Eggert <[email-masked]> wrote:
> 

Sergeant At Arms  is a loaded term with multiple meanings. If you look at the origin of the term, it's a lackey appointed by the king... which is to say, here, the IETF chair. And yet the IETF has a mantra, increasingly hard to believe, about no kings or presidents.

If you look at the US house of representatives, the SAA is appointed by the house - the deliberative body. If you look at Robert's Rules of Order, beloved by a certain type of US military mind, it's slightly different again. The reference to Wikipedia does not clarify the sense of use or the scope of the role intended in your draft.

Now, the SAAs have indeed proved to be lackeys of the IETF Chair, doing the chair's bidding, and that has been well documented (the former chair restricted my and others' postings on a pet  terminology topic for five days a year ago. major embarrassing snit.) That hasn't changed. I do think it should be changed -- no kings, presidents, or IETF chairs driving pet hobbyhorses -- and that the chair's powers are not yet restricted enough.

But, more immediately, the text as written in your draft says 'appointed by' twice in succession - by different entities. One of those is clearly not true, or you're not at all clear on what being appointed means. This is more than just a typo nit, it goes to,the heart of who the SAA is responsible to.

Personally, I dislike the SAA term and its militaristic and hierarchical connotations - but, given what the SAAs currently are, it's actually fair warning. And, as you say, it's unclear to those outside imperial or westminster trappings. 'moderators' may be clearer. it is, after all, just a mailing list. But how they are appointed and who they are responsible to needs to be clearer.

best

Lloyd Wood
[email-masked]

---

From: Lloyd W <[email-masked]>
Date: Sat, 18 Sep 2021 18:54:26 +1000

best

Lloyd Wood
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Sep 2021 21:47:04 -0400

> doesn't make that process right, and this violates the basic concept 
1.  From experience with several "moderation" events over the past few 
years, I believe the power to appoint SAAs (and by inference, to direct 
the SAAs) has been misused by IETF Chairs in the past on multiple 
occasions, such as to suppress useful input that the Chair at the time 
did not like.  I therefore believe that the IETF Chair should no longer 
be appointing or directing the SAA of the IETF list.   I believe that 
the SAAs should act as independent, generally neutral moderators whose 
decisions can be overridden by IAB, and that the SAAs should instead be 
appointed by the nomcom or perhaps the IAB Chair.

Separating the SAA function from IESG entirely would leave IESG freer to 
concentrate on providing technical direction and evaluating technical work.

2. The use of the term "unprofessional" remains problematic, both 
because the term is poorly defined, and because there are a number of 
associations with the word "professional" in employment settings that 
should not apply to the IETF.   For example, "professional" often means 
that you should not disagree with the technical opinions of your 
"superiors", whereas in IETF we should behave as peers on technical 
matters in order to preserve consensus-based decision making that at 
least to some extent helps to minimize decisions being made by major 
industry players without regard to other input.

In practice, being "professional" often means "don't rock the boat", say 
by not contributing ideas that differ from what the corporate or 
community leaders seem to favor

Professional can also mean not calling out abusive practices or 
practices that harm employees or the public.

Professional" can also mean "be conventional" even when the notion of 
"conventional" is arbitrary and specific to or excludes a particular 
culture, region, gender and/or gender role, sexual preference, etc.   It 
can impose expectations on appearance and behavior in ways that do not 
affect the quality of work or job performance, such as by disallowing 
certain hairstyles, styles of dress, etc.

"Professional" can even mean "follow industry conventions" even when 
such conventions lack justification, or are harmful to the industry or 
to ordinary people.

In general what "professional" means is to conform to an unwritten set 
of arbitrary prejudices that "everybody is supposed to know" even though 
(or perhaps because) they're only vaguely defined and rarely, if ever, 
stated.   And for that reason, accusations of being "unprofessional" can 
be and sometimes are used to marginalize or punish anyone who is 
different in any way.

These concerns could be addressed by either (a) not using any derivative 
of the word "professional" as criteria for what's appropriate for the 
IETF list; or (b) specifically defining "professional" in an IETF context.

But I think it would better to not use the term at all, and instead of 
trying to exclude "negative" contributions, define positive criteria for 
what makes a constructive contribution to the discussion.

For the above reasons I strongly recommend against publication of the 
current draft as an RFC.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Sep 2021 19:18:32 -0700

I am in favor of publishing this document. Those who would prefer some more
global change to the SAA process should instead propose those changes in
the form of a draft.

-Ekr

On Sat, Sep 18, 2021 at 12:25 AM Lars Eggert <[email-masked]> wrote:

> I added this quote from Wikipedia, because SAA is a pretty US/UK-centric
> term, and I received feedback that it is confusing to participants from
> other regions when they first encounter it.
>
> If you compare this document to BCP45, you will find that it actually
> significantly reduces the power of the IETF Chair. First, BCP45 allows for
> the Chair to directly impose posting restrictions. This hasn't been the
> practice for quite a number of years, and this document hence removes that
> option, placing it entirely at the disposition of the SAAs. Second, it
> clarifies that the appeals process applies here, which BCP45 left somewhat
> unclear.
>
> If you would like to propose changes to the BCP45 SAA process, please do
> so. Objecting to this document isn't going to result in such changes,
> because BCP45 would remain unchanged.
>
> Thanks,
> Lars
>
>
> >
> > Lloyd Wood
> > [email-masked]
> >
> >> Brian, my interpretation is that Lar’s proposed text is acceptable to
> you.  Please clarify if this is not the case.
> >>
> >> I would like to wait until Friday to see if there are any further
> comments on Lar’s proposed text.  If there are no strong objections then on
> Friday I’ll ask Lars to post a -05 with the change and I’ll kick off IETF
> LC.
> >>
> >> Regards,
> >> Rob
> >>
> >>
> >> Cc: Barry Leiba <[email-masked]>; GENDISPATCH List <
> [email-masked]>; [email-masked]
> >> >>> I have a proposed change to use the normal RFC2026 appeals process
> in https://github.com/larseggert/bcp45bis/pull/7/files. This is the
> current change:
> >> >>>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Sep 2021 19:18:32 -0700

-Ekr

On Sat, Sep 18, 2021 at 12:25 AM Lars Eggert <[email-masked]> wrote:

> >> My interpretation is that Lars and Barry are supportive of this change

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Sep 2021 19:59:54 -0700

Also in favor of publishing, but do agree that SAA is a rather pompous term
for “moderator”. That wording doesn’t need to change now, though.

thanks,
Rob

On Fri, Sep 24, 2021 at 7:19 PM Eric Rescorla <[email-masked]> wrote:

> I am in favor of publishing this document. Those who would prefer some
> more global change to the SAA process should instead propose those changes
> in the form of a draft.
>
> -Ekr
>
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 24 Sep 2021 19:59:54 -0700

thanks,
Rob

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Sep 2021 14:29:51 -0400

On 9/24/21 10:18 PM, Eric Rescorla wrote:

> more global change to the SAA process should instead propose those 
> changes in the form of a draft.

Asking for a draft, or at least a concrete set of proposed changes to 
the current document, seems reasonable.  What does not seem reasonable 
is to publish the current draft before these identified problems are 
dealt with.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 26 Sep 2021 14:38:41 -0400

> If you compare this document to BCP45, you will find that it actually significantly reduces the power of the IETF Chair. First, BCP45 allows for the Chair to directly impose posting restrictions. T…
What I believe has happened in recent years, is that one or more IETF 
Chairs (perhaps in consultation with IESG) have provided explicit 
direction to the SAAs, and without IETF Consensus backing for such 
direction or actions.   Unless I very much misunderstand the situation, 
to me this looks like a considerable extension of IETF Chair power that 
was not intended by BCP45.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Sep 2021 11:42:35 -0700

> is to publish the current draft before these identified problems are

I believe we will simply have to disagree on this point

-Ekr

Keith

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 27 Sep 2021 10:04:53 +1000

> is to publish the current draft before these identified problems are 

This is a process document.  It describes how things work.  Whether you like current practices, there is still value in having processes documented.  I'm supportive of publishing this documentation of current practices.

As far as changes to the moderation of some of the more contentious IETF lists goes, it is very reasonable to start a discussion about how those processes might be improved.  It is perfectly normal for the update of process documentation to stimulate thinking and conversations about improvements to process.  However, any changes that result belong in the NEXT update.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 09:56:20 +0300

Hi,

On 2021-9-25, at 4:47, Keith Moore <[email-masked]> wrote:
> 1.  From experience with several "moderation" events over the past few years, I believe the power to appoint SAAs (and by inference, to direct the SAAs) has been misused by IETF Chairs in the past on multiple occasions, such as to suppress useful input that the Chair at the time did not like.

under BCP45, the IETF Chair can directly restrict posting privileges of individuals or on a thread, without involving the SAA team or relying on their ability to appoint SAAs. You will find that BCP45bis removes this ability, because practice for a number of yers has been to let the SAAs operate independently.

>  I therefore believe that the IETF Chair should no longer be appointing or directing the SAA of the IETF list.   I believe that the SAAs should act as independent, generally neutral moderators whose decisions can be overridden by IAB, and that the SAAs should instead be appointed by the nomcom or perhaps the IAB Chair.

As has been suggested on this thread, if there is a desire for a more fundamentally respecification of how list moderation on the discussion list operates, this would be better handled as a separate work item.

> Separating the SAA function from IESG entirely would leave IESG freer to concentrate on providing technical direction and evaluating technical work.

Under BCP45 and BCP45bis, the IESG is not involved in the appointment or operation of the SAAs. This is - and AFIK has been - always handled by the IETF Chair.

> 2. The use of the term "unprofessional" remains problematic,

The term "unprofessional" appears once in BCP45bis, in a bullet item that is directly taken from BCP45.

> But I think it would better to not use the term at all, and instead of trying to exclude "negative" contributions, define positive criteria for what makes a constructive contribution to the discussion.

BCP45 chose to do both, i.e., describe which topics are appropriate and give examples of which are considered inappropriate. BCP45 retains that structure.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 10:03:47 +0300

Hi,

On 2021-9-26, at 21:38, Keith Moore <[email-masked]> wrote:
> What I believe has happened in recent years, is that one or more IETF Chairs (perhaps in consultation with IESG) have provided explicit direction to the SAAs,

as I just said in another reply, the IETF Chair under BCP45 is permitted to directly restrict posting privileges, without the need to consult the IESG or the SAA team.

> and without IETF Consensus backing for such direction or actions.

BCP45 does not require IETF consensus when posting privileges are restricted.

> Unless I very much misunderstand the situation, to me this looks like a considerable extension of IETF Chair power that was not intended by BCP45.

I disagree. BCP45 is very clear on what powers it grants.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Sep 2021 10:04:49 +0300

> BCP45 chose to do both, i.e., describe which topics are appropriate and give examples of which are considered inappropriate. BCP45 retains that structure.
                     ^^^
                     bis

Thanks,
Lars

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Sep 2021 14:17:56 -0400

> This is a process document.  It describes how things work.  Whether you like current practices, there is still value in having processes documented.  I'm supportive of publishing this documentation…

But it's more than a document of current practices, it's being proposed 
as a statement of "best" current practice.   I don't think the current 
practice (over the past few years) is anything like "best", and I think 
it's done considerable harm to IETF's openness and ability to build 
consensus.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 27 Sep 2021 15:32:09 -0400

> under BCP45, the IETF Chair can directly restrict posting privileges of individuals or on a thread, without involving the SAA team or relying on their ability to appoint SAAs. You will find that BC…

I think I see your point, but I'm not entirely sure that the current 
draft is an improvement even in that aspect.   If the IETF Chair 
directly restricts someone's posting privileges, at least the Chair is 
visibly taking responsibility for that action.   If the Chair instead 
directs the SAAs to restrict someone else's posting privileges, it can 
hide the Chair's action.

I'm not aware of any case in the past in which this has actually 
occurred, but the lack of a requirement for transparency is somewhat 
troubling regardless of the mechanism.

> As has been suggested on this thread, if there is a desire for a more fundamentally respecification of how list moderation on the discussion list operates, this would be better handled as a separat…

I haven't seen a reason given for making it a separate work item, so I 
can only guess as to why you make that assertion.   I can guess, for 
example, that you'd rather not have IETF rathole on a discussion of 
exactly what "professional" means.   I could understand such a 
reluctance, but to me it seems clear that the ambiguity has caused 
problems in the past, and allowed people's input to be suppressed for 
dubious reasons.

The problem I have with making it a separate work item is that doing 
that can be an effective way of making sure that such a discussion never 
happens.

At any rate I don't think the current proposal qualifies as a "best 
current practice".

IETF was a very different organization when RFC3005 was written. My 
recollection is that dealing with input from disagreeing, sometimes 
strident, and/or eccentric individuals, though it was sometimes annoying 
to some, was accepted at that time as a necessary condition of the 
openness required for consensus building in IETF.    As such, RFC3005 
seems to have been written with the expectation of general comity among 
most IETF participants, as well as a common sense of purpose which sadly 
no longer seems to exist.

These days, it seems that suppression of inconvenient input is now much 
more in fashion, and is even justified as enforcing 
"professionalism".    So I think BCP45 needs to be updated to fit the 
current times.

Keith

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Sep 2021 09:54:08 +0300

Hi,

On 2021-9-27, at 22:32, Keith Moore <[email-masked]> wrote:
> I haven't seen a reason given for making it a separate work item, so I can only guess as to why you make that assertion.

let me try and explain.

The only reason I even started a BCP45bis (thinking it would be a quick, non-controversial update...) was that a previous IESG promised to the community this would be done in case the "last-call experiment" was declared a success, to "to formally move the location for last-call discussions". [1]

Besides minor corrections and wording suggestions from various IETF participants, the only other changes of note are:

* to remove the wording about IETF Exec Dir's ability to impose posting restrictions (which RFC8717 already made effective)

* to do the same for the IETF Chair (per current practice)

* to add some material from the SAA team on their self-organization principles

* to clarify that the normal appeals process applies to SAA decisions

None of these changes - in my opinion - go beyond what BCP45 already defined, and I'd therefore characterize them as minor updates.

However, more fundamental changes to this process, suggested by you and others, such as appointing SAAs through the NomCom, making the SAA team the IAB's responsibility, closing the discussion list entirely, etc. would go beyond the scope of BCP45 and the minor update that BCP45bis is intending to be. I would therefore prefer to see them made independently from this minor revision.

I also think someone other than the IETF Chair should be the editor for such a larger revision of the process.

> These days, it seems that suppression of inconvenient input is now much more in fashion, and is even justified as enforcing "professionalism".    So I think BCP45 needs to be updated to fit the current times.

I still disagree with your characterization that any "suppression of inconvenient input" is happening or has happened, and will point out again that BCP45 was already concerned with maintaining a level of professionalism on the discussion list; this is not terminology I added or even changed in BCP45bis.

Thanks,
Lars

---

From: Dan Harkins <[email-masked]>
Date: Mon, 27 Sep 2021 23:57:20 -0700

+1

On 9/27/21 11:17 AM, Keith Moore wrote:
>> This is a process document.  It describes how things work. Whether 
>> you like current practices, there is still value in having processes 
>> documented.  I'm supportive of publishing this documentation of 
>> current practices.
>
> But it's more than a document of current practices, it's being 
> proposed as a statement of "best" current practice.   I don't think 
> the current practice (over the past few years) is anything like 
> "best", and I think it's done considerable harm to IETF's openness and 
> ability to build consensus.
>
> Keith
>
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Sep 2021 11:06:34 -0400

Hi Lars,

First, thanks for the explanation, as it helps to make the differences 
in our positions clear.

Of course it's not unusual that (for better or worse) when revising a 
document we find a conflict between a desire to make only simple 
revisions, versus needing to update every part of the document, not only 
to fix bugs but to update references, use more modern notation (e.g. 
ABNF), impose new minimum requirements (e.g. TLS version), etc., because 
many things assumed by the previous version of the document have changed 
in the time since that version was published.

> However, more fundamental changes to this process, suggested by you and others, such as appointing SAAs through the NomCom, making the SAA team the IAB's responsibility, closing the discussion list…
I disagree that these would be expanding the scope of BCP45, as they 
deal with the same topics as BCP45 does.   (FWIW I'm not in favor of 
closing the ietf@ list, though I've seen that suggestion elsewhere.)
> I also think someone other than the IETF Chair should be the editor for such a larger revision of the process.
I concur.
> I still disagree with your characterization that any "suppression of inconvenient input" is happening or has happened, and will point out again that BCP45 was already concerned with maintaining a l…

We do indeed disagree on that, as I have personally experienced efforts 
to malign me and to discourage my input, and I've seen others treated 
similarly.   And those experiences have convinced me without a doubt 
that BCP45 has been used to justify efforts to control the IETF 
conversation that were inconsistent with its original intent, and that 
the language in BCP45 therefore needs to be updated.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 10:52:44 +1300

Hi,

A couple of points on the draft:

1) The current BCP45 states "It also hosts discussions of IETF direction, policy, meetings, and procedures." That has been deleted in the draft, which leaves a gap.

I think that the list of appropriate postings should include something like:

 * Discussions of IETF direction, policy, and the standards process in general.

(and perhaps mention that drafts in this area go to GENDISPATCH.)

2) I suggest an extra sentence just after this:

> These topics used to be in scope for the IETF discussion list, but have since moved to dedicated lists:
> 
> * Last Call discussions of proposed protocol actions now take place on the IETF Last Calls mailing list [LAST-CALLS].
> 
> * Discussion of IETF administrative policies now take place on the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS].

Add:

However, if the discussion is broader than the specific protocol concerned, or than administration as such, it may revert to the IETF discussion list, preferably with an appropriate change of the Subject header.

[For example, if the Last Call discussion identifies a completely separate technical requirement, or if the admin discussion identifies a problem with the standards process.]

Regards
   Brian Carpenter

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Sep 2021 14:59:17 -0700

On Wed, Sep 29, 2021 at 2:53 PM Brian E Carpenter <
[email-masked]> wrote:

> Add:
>
> However, if the discussion is broader than the specific protocol
> concerned, or than administration as such, it may revert to the IETF
> discussion list, preferably with an appropriate change of the Subject
> header.
>

fwiw, I don't agree with this idea at all, and in fact think it is a source
of pain on the IETF discussion list.

Either way, this would be a substantive change quite separate from the
documentation this draft aims to provide, and more appropriate for a draft
that aims to change BCP45 deliberately.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Sep 2021 11:12:05 +1300

On 30-Sep-21 10:59, Rob Sayre wrote:
> On Wed, Sep 29, 2021 at 2:53 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Add:
> 
> fwiw, I don't agree with this idea at all, and in fact think it is a source of pain on the IETF discussion list.
> 
> Either way, this would be a substantive change quite separate from the documentation this draft aims to provide, and more appropriate for a draft that aims to change BCP45 deliberately.

But the draft *does* change BCP45 deliberately - it explicitly says that some topics that used to be valid are no longer valid, and implicitly removes "direction, policy ... and [standards process] procedures". My first suggestion brings BCP45bis back closer to BCP45.

I have many times seen last call discussion veer off into extraneous technical topics and admin discussion veer off into standards process topics. Where are those topics to be raised, if not on ietf@ ?

   Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 29 Sep 2021 15:22:24 -0700

On Wed, Sep 29, 2021 at 3:12 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Add:
> >
> > fwiw, I don't agree with this idea at all, and in fact think it is a
> source of pain on the IETF discussion list.
> >
> But the draft *does* change BCP45 deliberately - it explicitly says that
> some topics that used to be valid are no longer valid, and implicitly
> removes "direction, policy ... and [standards process] procedures". My
> first suggestion brings BCP45bis back closer to BCP45.
>

OK, I see your point here, but I think the draft accurately documents the
places where contributions will be more effective. I think this is more a
reflection of current practice, rather than policy setting, but reasonable
people can disagree.

>
> I have many times seen last call discussion veer off into extraneous
> technical topics and admin discussion veer off into standards process
> topics. Where are those topics to be raised, if not on ietf@ ?
>

Currently, they can bubble up there, but I don't think it's productive at
all and don't think it should be explicit in this draft.

thanks,
Rob

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 20:19:55 -0400

> (and perhaps mention that drafts in this area go to GENDISPATCH.)

As currently constituted GENDISPATCH mostly serves to hide discussions 
that are of broad community interest, creating the risk that major 
process changes will be implemented without significant community review 
and feedback.  Also, in the past some GENDISPATCH chairs have made 
efforts to restrict such discussions along very narrow lines, e.g. 
insisting that all discussion on a topic be narrowly centered on a very 
biased draft document. Also, the constraints in GENDISPATCH's charter 
overly constrain the recommendations that GENDISPATCH can make.

I don't think that discussion of such matters should be tightly 
controlled, beyond normal guidelines for conduct; nor that such 
discussion should be forcibly split between GENDISPATCH and other 
lists.   I also think it's unhelpful to insist that there be a draft in 
place before any such discussion can take place (in GENDISPATCH even 
moreso than with most technical discussions). More recently GENDISPATCH 
chairs have allowed some wider ranging discussion, but this has been a 
problem in the past.

So I would not want to see GENDISPATCH enshrined in BCP45bis.

I actually believe that the GENDISPATCH group be shut down, or at least, 
that its charter be drastically altered.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Sep 2021 20:22:56 -0400

> I have many times seen last call discussion veer off into extraneous technical topics and admin discussion veer off into standards process topics. Where are those topics to be raised, if not on iet…

I believe IETF still needs a "general" list where topics that don't fit 
anywhere else, or really any topic of broad community interest or broad 
relevance to the Internet, can be discussed. Traditionally the ietf@ 
list has served that purpose.   I'm not saying that no other list could 
serve that purpose, but that we do need such a forum.

It wouldn't make sense to say "no, you can't discuss that topic 
anywhere, because we don't have a list for that".

Keith

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Sep 2021 11:52:40 +0300

Hi,

> 1) The current BCP45 states "It also hosts discussions of IETF direction, policy, meetings, and procedures." That has been deleted in the draft, which leaves a gap.

Most of those topics moved to admin-discuss and the meeting attendees lists. Others are in scope for gendispatch (although I am unsure whether a possibly ephemeral WG should be explicitly named in the BCP).

> (and perhaps mention that drafts in this area go to GENDISPATCH.)

I think this may be a little too broad. How about:

* Discussions of IETF direction, policy, and the standards process
  in general, when a more suitable list (such as admin-discuss,
  architecture-discuss, a meeting attendees list, or a
  process-oriented WG list) cannot be identified.

> [For example, if the Last Call discussion identifies a completely separate technical requirement, or if the admin discussion identifies a problem with the standards process.]

I agree that should be possible. Do you think that with the proposed change above, this would still need to be explicitly called out again?

Thanks,
Lars