Carsten: thank you for the review on this document. I added you to the CC of my ballot (No Objection).
Francesca
From: art <art-bounces@xxxxxxxx> on behalf of Carsten Bormann via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, 23 November 2021 at 11:59
To: art@xxxxxxxx <art@xxxxxxxx>
Cc: last-call@xxxxxxxx <last-call@xxxxxxxx>, draft-eggert-bcp45bis.all@xxxxxxxx <draft-eggert-bcp45bis.all@xxxxxxxx>
Subject: [art] Artart last call review of draft-eggert-bcp45bis-06
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)?
_______________________________________________
art mailing list
art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/art
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
