Skip to main content

IETF Discussion List Charter
draft-eggert-bcp45bis-08

Revision differences

Document history

Date Rev. By Action
2022-04-11
08 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9245">AUTH48</a>
2022-03-29
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-02-24
08 (System) RFC Editor state changed to EDIT
2022-02-24
08 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-02-24
08 (System) Announcement was received by RFC Editor
2022-02-24
08 (System) IANA Action state changed to No IANA Actions from In Progress
2022-02-24
08 (System) IANA Action state changed to In Progress
2022-02-24
08 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-02-24
08 Cindy Morgan IESG has approved the document
2022-02-24
08 Cindy Morgan Closed "Approve" ballot
2022-02-24
08 Cindy Morgan Ballot approval text was generated
2022-02-24
08 Robert Wilton IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-02-24
08 Lars Eggert New version available: draft-eggert-bcp45bis-08.txt
2022-02-24
08 (System) New version approved
2022-02-24
08 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2022-02-24
08 Lars Eggert Uploaded new revision
2022-02-20
07 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2022-02-20
07 Barry Leiba Assignment of request for Last Call review by ARTART to Carsten Bormann was marked no-response
2022-02-17
07 (System) Removed all action holders (IESG state changed)
2022-02-17
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2022-02-17
07 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2022-02-16
07 Benjamin Kaduk
[Ballot comment]
Section 2

  When no dedicated mailing list exists, it may be preferable to
  request the creation of one [NON-WG-LISTS] and announce …
[Ballot comment]
Section 2

  When no dedicated mailing list exists, it may be preferable to
  request the creation of one [NON-WG-LISTS] and announce the
  availability of the new list on the IETF discussion list and on other
  related lists, such as area lists.

It seems that the other side of the comparison (rather than having the
discussion of that topic on the IETF discussion list) is implicit here.
There may be some benefit from making it explicit, perhaps as:

% When no dedicated mailing list exists for a topic, it may be preferable to
% request the creation of one [NON-WG-LISTS] and announce the
% availability of the new list on the IETF discussion list and on other
% related lists, such as area lists, rather than discussing that topic on
% the IETF discussion list.

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

I assume this has already been extensively discussed and that I have nothing
further to add, but just in case: "document action" is a term of art used in
IESG telechat agendas, referring to documents that are not on the standards
track ("protocol actions", the term that RFC 3005 used, is the term used on
IESG telechat agendas for the standards-track documents).  I believe that we
also use this list for last calls on WG charters, which may or may not
qualify as "document"s; I didn't check if there was previous discussion of
changing this to just "proposed actions".

Section 3

              Because the IESG and IAB are in the appeals chain for
  moderator decisions (see below), the IETF Chair therefore should not
  appoint a moderator who is serving in such a role.  If a moderator is
  selected for the IESG or IAB, they will step down from the moderator
  team.

I note that this gives no guidance on whether the stepping down should occur
"immediately" or not until a replacement has been designated.  Perhaps that
lack of guidance is intentional, but I note that the gap has been quite long
in practice (i.e., more than a year).
2022-02-16
07 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2022-02-16
07 John Scudder
[Ballot comment]
Two nits --

1. "Discussion of IETF administrative policies now take place"

Should be “Discussion… takes place” or “discussions… take place”.

2. I …
[Ballot comment]
Two nits --

1. "Discussion of IETF administrative policies now take place"

Should be “Discussion… takes place” or “discussions… take place”.

2. I thought you had taken care of this already, but just in case you still need a suggestion:

OLD:
  restrict posting by a person, or of a thread

NEW:
  restrict posting by a person, or to a thread

Presumably we aren’t getting into the prior approval of new threads business, therefore we can’t restrict “posting… of a thread” which implies creation of a new thread. By the way, I am assuming “thread” is well enough understood to not need definition, but that’s open to discussion I guess.
2022-02-16
07 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-02-16
07 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2022-02-16
07 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Many thanks to Carsten Bormann for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/ZnkYEl-9mRWfKXtzHVUu7u92QB0/. Carsten asks for …
[Ballot comment]
Thank you for the work on this document.

Many thanks to Carsten Bormann for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/ZnkYEl-9mRWfKXtzHVUu7u92QB0/. Carsten asks for more clarity about text being normative or descriptive. I also share his concern with using references to web pages (and mailing list) which might change in the future, and require a further update of the document, but not sure anything can be done about that.

I'll report Carsten's review below for visibility (note that the last comment has been addressed by v-07).

Francesca

----

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)?
2022-02-16
07 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-02-16
07 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2022-02-16
07 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this update.

I have two comments/observations-

  * I think it would good if the bullet 2 and bullet …
[Ballot comment]
Thanks for working on this update.

I have two comments/observations-

  * I think it would good if the bullet 2 and bullet 3 of the "Appropriate postings to the IETF discussion list include" list to be rewritten with the tone of bullet 4. With the current write up it feels like bullet 2 and bullet 3 says "something is allowed but there are other preferred venues". I think it would good if it says "think about other venues first then post here". This will be more consistent with a allowed "appropriate posting" tone.

  * Can we define "a self-moderation function" better? People might have different perspective of "a self-moderation function" in the IETF context.
2022-02-16
07 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-02-16
07 Roman Danyliw
[Ballot comment]
Thank you to Stefan Santesson for the SECDIR review.

** Section 1

  The IETF Note Well [NOTE-WELL] applies to discussions on the …
[Ballot comment]
Thank you to Stefan Santesson for the SECDIR review.

** Section 1

  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 [RFC7776], among others.

  This document obsoletes [RFC3005], documenting the use of other
  mailing lists for discussions that used to be in scope for the IETF
  discussion list, referring to applicable policies such as the
  Guidelines for Conduct [RFC7154] and the Anti-Harassment Policy
  [RFC7776], and clarifying moderation procedures.

Why are two references to RFC7154 and RFC7776 needed in back-to-back paragraphs?

** Section 2. Per “… they should be continued at that other venue as soon as this is pointed out”, pointed out by who?  A moderator? Community member?

** Section 3. 
  The moderators are intended to
  establish a self-moderation function on the community, by the
  community.

I don’t follow the intent of this text.

** Section 3.  Editorial.  Less colloquial.  s/should stay away from/should refrain from/

** Section 3.
  This has been in practice for a while, and the moderator team has
  independently maintained definitions of abuse patterns [MOD-UPC] and
  operating procedures [MOD-SOP] for them.

I’m not sure if “this has been in practice for a while” will age well.  Also, who is the “them”?  Likewise, do we want to assert that the moderator teams operate transparently with a set of operating procedures?  Perhaps:

NEW
The moderator team will independently define, publish, and execute their roles according to a set of documented operating procedures.  See abuse patterns [MOD-UPC] and operating procedures [MOD-SOP].
2022-02-16
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-02-15
07 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-02-14
07 Warren Kumari
[Ballot comment]
I have only a small editorial comment. Obviously it is non-blocking...

"Moderators (previously known as the "sergeant-at-arms") for the IETF discussion list are …
[Ballot comment]
I have only a small editorial comment. Obviously it is non-blocking...

"Moderators (previously known as the "sergeant-at-arms") for the IETF discussion list are appointed by the IETF Chair and are empowered to restrict posting by a person, or of a thread, ..."
The "restrict posting by a person, or of a thread, ..." reads a little strangely, but I don't have a good suggestion to fix it. My think at my issue is that if you are not in a situation where you are not restricting a person, then it collapses to "restrict posting of a thread, ..." and I don't thing that one restricts posting *of* a thread, rather one restricts posting *to* a  thread, or *continuing* a thread, or something.
Perhaps "restrict posting by a person, or continuing a thread, ..." or "restrict posting by a person, or to a thread, ..." or something. Again, this is just an editorial nit.
2022-02-14
07 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-02-09
07 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2022-02-07
07 Cindy Morgan Placed on agenda for telechat - 2022-02-17
2022-02-07
07 Éric Vyncke
[Ballot comment]
Thank you Lars for refreshing BCP45. I second the shepherd's text: "the document is short and well written". Thank you as well …
[Ballot comment]
Thank you Lars for refreshing BCP45. I second the shepherd's text: "the document is short and well written". Thank you as well for replacing "sergeant-at-arm" by "moderator", this is more civil ;-)

Minor comments (as usual they can be ignored):

- should the actual email "ietf@ietf.org" be mentioned ?

- section 2, 1st §, "as soon as this is pointed out" should "by whom" be clarified ?

- section 2, in "Announcements of conferences" should IRTF be mentioned ?

Regards

-éric
2022-02-07
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-02-07
07 Robert Wilton Ballot has been issued
2022-02-07
07 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2022-02-07
07 Robert Wilton Created "Approve" ballot
2022-02-07
07 Robert Wilton IESG state changed to IESG Evaluation from Waiting for Writeup
2022-02-07
07 Robert Wilton Ballot writeup was changed
2022-02-07
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-02-04
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-02-04
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-eggert-bcp45bis-07, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-eggert-bcp45bis-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2022-01-10
07 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2022-01-10
07 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2022-01-10
07 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-02-07):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-eggert-bcp45bis@ietf.org, rwilton@cisco.com, …
The following Last Call announcement was sent out (ends 2022-02-07):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-eggert-bcp45bis@ietf.org, rwilton@cisco.com, ietf@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-eggert-bcp45bis-07.txt> (IETF Discussion List Charter) to Best Current Practice

Responsible AD note:  I have asked for a second 4 week last call on this AD sponsored document for two reasons:
(1) I should have included ietf@ietf.org in the original last call notice because this mailing list is directly affected by this proposed BCP.  Please note, as per the Reply-To, any last-call discussion should happen on last-call@ietf.org and not be automatically copied on ietf@ietf.org.
(2) Based on the last call feedback received, there have been some moderate changes to the draft during the last call process (between -06 and -07) and a second last call gives the community an opportunity to review and comment on those changes, and to ensure that there is community consensus to publish.

The IESG has received a request from an individual submitter to consider the
following document: - 'IETF Discussion List Charter'
  <draft-eggert-bcp45bis-07.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-02-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Internet Engineering Task Force (IETF) discussion mailing list
  furthers the development and specification of Internet technology
  through the general discussion of topics for which no dedicated
  mailing lists exists.  As this is the most general IETF mailing list,
  considerable latitude is allowed, but there are posts and topics that
  are unsuitable for this mailing list.

  This document obsoletes RFC3005.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/



No IPR declarations have been submitted directly on this I-D.




2022-01-10
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-01-10
07 Robert Wilton Last call was requested
2022-01-10
07 Robert Wilton IESG state changed to Last Call Requested from Waiting for Writeup
2022-01-10
07 Robert Wilton Last call announcement was changed
2022-01-10
07 Robert Wilton Last call announcement was generated
2021-12-13
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-12-13
07 Lars Eggert New version available: draft-eggert-bcp45bis-07.txt
2021-12-13
07 (System) New version approved
2021-12-13
07 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-12-13
07 Lars Eggert Uploaded new revision
2021-12-13
07 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-12-13
07 Lars Eggert Uploaded new revision
2021-12-06
06 Robert Wilton Notification list changed to rwilton@cisco.com from gendispatch@ietf.org, rwilton@cisco.com
2021-11-23
06 Carsten Bormann Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Carsten Bormann. Sent review to list.
2021-11-23
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-11-21
06 Stefan Santesson Request for Last Call review by SECDIR Completed: Ready. Reviewer: Stefan Santesson. Sent review to list.
2021-11-11
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2021-11-11
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stefan Santesson
2021-11-11
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-11-11
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-eggert-bcp45bis-06, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-eggert-bcp45bis-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-11-06
06 Adam Montville Assignment of request for Last Call review by SECDIR to Adam Montville was rejected
2021-10-31
06 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list.
2021-10-23
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2021-10-23
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2021-10-21
06 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2021-10-21
06 Barry Leiba Request for Last Call review by ARTART is assigned to Carsten Bormann
2021-10-21
06 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-10-21
06 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-10-19
06 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-10-19
06 Amy Vezza
The following Last Call announcement was sent out (ends 2021-11-23):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-eggert-bcp45bis@ietf.org, gendispatch@ietf.org, …
The following Last Call announcement was sent out (ends 2021-11-23):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-eggert-bcp45bis@ietf.org, gendispatch@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-eggert-bcp45bis-06.txt> (IETF Discussion List Charter) to Best Current Practice


The IESG has received a request from an individual submitter to consider the
following document: - 'IETF Discussion List Charter'
  <draft-eggert-bcp45bis-06.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Internet Engineering Task Force (IETF) discussion mailing list
  furthers the development and specification of Internet technology
  through the general discussion of topics for which no dedicated
  mailing lists exists.  As this is the most general IETF mailing list,
  considerable latitude is allowed, but there are posts and topics that
  are unsuitable for this mailing list.

  This document obsoletes RFC3005.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-eggert-bcp45bis/



No IPR declarations have been submitted directly on this I-D.




2021-10-19
06 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-10-19
06 Robert Wilton Last call was requested
2021-10-19
06 Robert Wilton Ballot approval text was generated
2021-10-19
06 Robert Wilton Ballot writeup was generated
2021-10-19
06 Robert Wilton IESG state changed to Last Call Requested from Publication Requested
2021-10-19
06 Robert Wilton Last call announcement was changed
2021-10-19
06 Robert Wilton Last call announcement was generated
2021-10-19
06 Robert Wilton Last call announcement was generated
2021-10-19
06 Robert Wilton
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP.  This document updates and obsoletes RFC 3005 (BCP 45).  The correct status is reflected in the title page header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  The Internet Engineering Task Force (IETF) discussion mailing list
  furthers the development and specification of Internet technology
  through the general discussion of topics for which no dedicated
  mailing lists exists.  As this is the most general IETF mailing list,
  considerable latitude is allowed, but there are posts that are
  unsuitable for this mailing list.

  This document obsoletes RFC3005.


Working Group Summary

This document was considered and dispatched in the Gendispatch WG to AD Sponsored.  Rob Wilton agreed to AD sponsor this document since Lars Eggert (the responsible AD for Gendispatch) is the author of this document.  There was a short discussion about whether it was appropriate for an IESG member to be authoring this document, but after a brief discussion is was decided that it is appropriate for an AD to author a short process document to update BCP 45 to reflect how the list is currently being used.

Prior versions of this document have been discussed on the gendispatch mailing list, and received small updates.  There was some wider discussion concerning more significant updates to how the general IETF mailing list is managed, but it was agreed to decouple the small updates to describe how it is currently used/managed from any future evolution of the mailing list.


Document Quality

The document is short and well written.

Rob Wilton is the Sponsoring AD and Doc Shepherd.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Reviewed as part of the AD review.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, it is a small process update.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

N/A.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.


(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

There is, I believe, a reasonable consensus that this is how the ietf@ietf.org mailing list is currently being used.  My judgement is that there is rough consensus
to publish a small update now - some folks wanting this document to go further refining how the IETF mailing list works, but it does not look like such consensus would be quickly reached, if at all.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.


(13) Have all references within this document been identified as either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

Yes.  This document obsoletes RF3005 and replaces it as BCP45.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.
2021-10-11
06 Robert Wilton Last call announcement was generated
2021-10-11
06 Lars Eggert New version available: draft-eggert-bcp45bis-06.txt
2021-10-11
06 (System) New version approved
2021-10-11
06 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-10-11
06 Lars Eggert Uploaded new revision
2021-09-30
05 Lars Eggert New version available: draft-eggert-bcp45bis-05.txt
2021-09-30
05 (System) New version approved
2021-09-30
05 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-09-30
05 Lars Eggert Uploaded new revision
2021-09-07
04 Lars Eggert New version available: draft-eggert-bcp45bis-04.txt
2021-09-07
04 (System) New version approved
2021-09-07
04 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-09-07
04 Lars Eggert Uploaded new revision
2021-09-06
03 Robert Wilton
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP.  This document updates and obsoletes RFC 3005 (BCP 45).  The correct status is reflected in the title page header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

  The Internet Engineering Task Force (IETF) discussion mailing list
  furthers the development and specification of Internet technology
  through the general discussion of topics for which no dedicated
  mailing lists exists.  As this is the most general IETF mailing list,
  considerable latitude is allowed, but there are posts that are
  unsuitable for this mailing list.

  This document obsoletes RFC3005.


Working Group Summary

This document was considered and dispatched in the Gendispatch WG to AD Sponsored.  Rob Wilton agreed to AD sponsor this document since Lars Eggert (the responsible AD for Gendispatch) is the author of this document.  There was a short discussion about whether it was appropriate for an IESG member to be authoring this document, but after a brief discussion is was decided that it is appropriate for an AD to author a short process document to update BCP 45 to reflect how the list is currently being used.

Prior versions of this document have been discussed on the gendispatch mailing list, and received small updates.  There was some wider discussion concerning more significant updates to how the general IETF mailing list is managed, but it was agreed to decouple the small updates to describe how it is currently used/managed from any future evolution of the mailing list.


Document Quality

The document is short and well written.

Rob Wilton is the Sponsoring AD and Doc Shepherd.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Reviewed as part of the AD review.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, it is a small process update.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

N/A.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.


(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

There is, I believe, a reasonable consensus that this is how the ietf@ietf.org mailing list is currently being used.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None.


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.


(13) Have all references within this document been identified as either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

Yes.  This document obsoletes RF3005 and replaces it as BCP45.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.


(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.
2021-09-06
03 Robert Wilton Notification list changed to gendispatch@ietf.org, rwilton@cisco.com from gendispatch@ietf.org because the document shepherd was set
2021-09-06
03 Robert Wilton Document shepherd changed to Robert Wilton
2021-09-06
03 (System) Changed action holders to Robert Wilton (IESG state changed)
2021-09-06
03 Robert Wilton
Note added 'This document updates BCP45 to reflect how the ietf@ietf.org mailing list is currently being used/managed (e.g., covering that some discussions, like last-call, have …
Note added 'This document updates BCP45 to reflect how the ietf@ietf.org mailing list is currently being used/managed (e.g., covering that some discussions, like last-call, have moved to their own dedicated mailing lists).'
2021-09-06
03 Robert Wilton State Change Notice email list changed to gendispatch@ietf.org
2021-09-06
03 Robert Wilton IESG process started in state Publication Requested
2021-09-06
03 Robert Wilton Changed consensus to Yes from Unknown
2021-09-06
03 Robert Wilton Intended Status changed to Best Current Practice from None
2021-09-06
03 Robert Wilton Stream changed to IETF from None
2021-09-06
03 Robert Wilton Shepherding AD changed to Robert Wilton
2021-07-27
03 Pete Resnick Added to session: IETF-111: gendispatch  Wed-1200
2021-07-26
03 Lars Eggert New version available: draft-eggert-bcp45bis-03.txt
2021-07-26
03 (System) New version approved
2021-07-26
03 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-07-26
03 Lars Eggert Uploaded new revision
2021-06-23
02 Lars Eggert New version available: draft-eggert-bcp45bis-02.txt
2021-06-23
02 (System) New version approved
2021-06-23
02 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-06-23
02 Lars Eggert Uploaded new revision
2021-03-29
01 Lars Eggert New version available: draft-eggert-bcp45bis-01.txt
2021-03-29
01 (System) New version approved
2021-03-29
01 (System) Request for posting confirmation emailed to previous authors: Lars Eggert <lars@eggert.org>
2021-03-29
01 Lars Eggert Uploaded new revision
2021-03-29
00 Lars Eggert New version available: draft-eggert-bcp45bis-00.txt
2021-03-29
00 (System) New version approved
2021-03-29
00 Lars Eggert Request for posting confirmation emailed  to submitter and authors: Lars Eggert <lars@eggert.org>
2021-03-29
00 Lars Eggert Uploaded new revision