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 |