[art] Artart last call review of draft-eggert-bcp45bis-06

Carsten Bormann via Datatracker <noreply@ietf.org> Tue, 23 November 2021 10:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8033A0064; Tue, 23 Nov 2021 02:59:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carsten Bormann via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-eggert-bcp45bis.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.40.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163766515258.2889.17947564397204893159@ietfa.amsl.com>
Reply-To: Carsten Bormann <cabo@tzi.org>
Date: Tue, 23 Nov 2021 02:59:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/ZnkYEl-9mRWfKXtzHVUu7u92QB0>
Subject: [art] Artart last call review of draft-eggert-bcp45bis-06
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2021 10:59:13 -0000

Reviewer: Carsten Bormann
Review result: Ready with Issues

* Review for draft-eggert-bcp45bis-06
* Reviewer: Carsten Bormann
* Review result: Ready with Issues

I am the requested ARTART reviewer for this document.

The document adjusts RFC3005 for the present.

It needs to be, and succeeds in being, succinct, with a few places
where a little more clarity would still be desirable.

## Minor

* Introduction, second paragraph

           The IETF Note Well [NOTE-WELL] applies to discussions on the IETF
           discussion list and all other IETF mailing lists, and requires
           conformance with the IETF Guidelines for Conduct [RFC7154] and the
           Anti-Harassment Policy [IETF-AHP], among others.

This is a statement of fact, so it is not clear whether this is a
normative statement.  If it were normative, there would be a need to
point out normative references to web pages are problematic.

* 3.  Moderation, third paragraph

This section introduces the SAA, but doesn't quite make clear whether
it is the normative statement about SAAs, or is more on the
descriptive side (and maybe even should have a reference to a
normative statement published elsewhere).

           Apart from appointing SAAs, the IETF Chair should stay away from the
           day-to-day operation and management of the SAA team.  This has been
           in practice for a while, and the SAA team has independently
           maintained definitions of abuse patterns [SAA-UPC] and operating
           procedures [SAA-SOP] for them.  The SAA team should reach out to the
           IETF Chair for any conflict resolution in a timely manner.

In this paragraph it suddenly becomes clear that SAAs operate as a
team.  This has significant implications for their operation that need
to be expanded upon a little.  E.g., do members of the SAA team vote?
Do they otherwise establish consensus among them before acting?

## Editorial

* Abstract

The abstract probably needs an editorial round:

It might give the impression that ietf@ is a technology list
and does not mention that there is a lot of process discussion and
discussion about the evolution of IETF and its related organizations
on this list.

Specifically, "latitude" is meant with respect to the set of topics,
but that is not explicitly said.

Last sentence of first paragraph of intro needs to be copied to
abstract:

           This document defines the charter for the IETF
           discussion list and explains its scope.

* Introduction

See comments on abstract.

* 3.  Moderation

           [...] SAAs [...] are
           empowered to restrict posting by a person, or of a thread, when [...]

Can't quite parse "posting of a thread".  Is "posting to a thread"
meant?  Is it then OK to open a new thread on the same topic?

* 4.  Security Considerations

           This document does not raise any security issues.

(Any device that can be abused for censorship clearly does.)

* 6.2.  Informative References

There are a number of "n.d." in the references.  The RFC editor will
probably want to delete them.  Are any of these intended to point out
that the reference is to a *live* document (as opposed to a static,
undated document) and therefore should be kept (or expressed otherwise)?