[procon] Re: Conclusion of the last call on draft-ietf-procon-2026bis-08
"D. J. Bernstein" <djb@cr.yp.to> Sun, 14 June 2026 08:03 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: procon@mail2.ietf.org
Delivered-To: procon@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 672AC100F5061 for <procon@mail2.ietf.org>; Sun, 14 Jun 2026 01:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781424224; bh=XugbBYVQ3bxIqxLYntJpbqjAbhSF2RiBPKKmKO4oDUs=; h=Date:From:To:Subject:In-Reply-To; b=YZUYseHIpHY1XezvRTKxjH/KoMFLHnFfSYj6/ztjsMX5hsHTGBLGNE8ADFqEcf9tY vzdeDkdapskGX55EgTRNJL2myftfM4SbZQbETEK9dMpSCbLr0bBaX3Zk8hIB5rN2+A LhvDHsVBs+IEM8ldJyAt7uOe4DfOjDKzJURDRQoo=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level:
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.999, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJUzbICpKSL3 for <procon@mail2.ietf.org>; Sun, 14 Jun 2026 01:03:43 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id CE6C7100F505C for <procon@ietf.org>; Sun, 14 Jun 2026 01:03:43 -0700 (PDT)
Received: (qmail 1383954 invoked by uid 1010); 14 Jun 2026 08:03:43 -0000
Received: from unknown (unknown) by unknown with QMTP; 14 Jun 2026 08:03:43 -0000
Received: (qmail 3110536 invoked by uid 1000); 14 Jun 2026 08:03:38 -0000
Date: Sun, 14 Jun 2026 08:03:38 -0000
Message-ID: <20260614080338.3110534.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: procon@ietf.org
Mail-Followup-To: procon@ietf.org
In-Reply-To: <4cd2333c-e5c5-415b-a4ff-e2c0288743c5@lear.ch>
Message-ID-Hash: XYZ4BENVYCINDIAPXSLRIMOS2DN7TL2Q
X-Message-ID-Hash: XYZ4BENVYCINDIAPXSLRIMOS2DN7TL2Q
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [procon] Re: Conclusion of the last call on draft-ietf-procon-2026bis-08
List-Id: "Discussion of consolidating process documents and changes to the standards process per IETF 121 ALLDISPATCH." <procon.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/procon/GqENbCe25RBki-CXF4WH24ZkkvM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/procon>
List-Help: <mailto:procon-request@ietf.org?subject=help>
List-Owner: <mailto:procon-owner@ietf.org>
List-Post: <mailto:procon@ietf.org>
List-Subscribe: <mailto:procon-join@ietf.org>
List-Unsubscribe: <mailto:procon-leave@ietf.org>
Once again: Where RFC 2418 says that WG disagreements "must be resolved by a process of open review and discussion", the new document says that disagreements "must be resolved by a process of open review and, where appropriate, open discussion". This change violates the PROCON charter. Eliot Lear writes: > D. J. Bernstein wrote: > > For example, inserting "where appropriate" into the requirement for > > "open review and discussion" is not a merge of the existing documents. > > It's not about milestones or adoption. So it violates the charter. Done. > No it's not. The document that permits "where > appropriate" is RFC 2026. Huh? You're quoting a provision that (1) is about a different situation and (2) doesn't say "where appropriate". ---D. J. Bernstein ===== NOTICES ===== IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5 (normative), "Rights in Contributions", provides a modification right "unless explicitly disallowed in the notices contained in a Contribution (in the form specified by the Legend Instructions)". The official language from IETF's "Legend Instructions" for the situation that "the Contributor does not wish to allow modifications nor to allow publication as an RFC" is as follows: "This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft." <https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf> The same language is used in, e.g., RFC 5831. The same language hereby applies to this document. This is not disclaiming or limiting the applicability of IETF policies; it is strictly following IETF policies. IESG claims that the "explicitly disallowed" provision in BCP 78 is limited to the examples in Section 3 in BCP 78. That is incorrect. BCP 78 states that Section 5, "Rights in Contributions", is normative, while Section 3, "Exposition of Why These Procedures Are the Way They Are", is informative. The opt-out provision in the normative text is clear, and cannot be limited by an informative section. BCP 78 does not give IESG any authority to issue changes or purported clarifications of the rules. Rationale for exercising the BCP 78 opt-out provision: I'm fine with redistribution of copies of this document. The issue is instead with modification, such as (1) IESG's May 2025 posting of an IESG-mangled version of an appeal that I had filed and (2) IETF management selling IETF mailing-list text to AI companies. This goes far beyond what copyright law allows as fair use (such as giving quotes for purposes of commentary). When I complained about the mangled document, the IETF Executive Director responded not by apologizing but instead by asserting that IETF management had the power to do whatever it wanted.
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] Re: Conclusion of the last call on draft… D. J. Bernstein
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Re: Conclusion of the last call on draft… D. J. Bernstein
- [procon] Re: Conclusion of the last call on draft… D. J. Bernstein
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Conclusion of the last call on draft-iet… Jari Arkko
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Leslie Daigle (ThinkingCat)
- [procon] Re: Conclusion of the last call on draft… Leslie Daigle (ThinkingCat)
- [procon] Re: Conclusion of the last call on draft… IETF Chair
- [procon] Re: Conclusion of the last call on draft… Jari Arkko
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] Re: Conclusion of the last call on draft… Simon Josefsson
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Simon Josefsson
- [procon] Re: Conclusion of the last call on draft… Joel Halpern
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Re: Conclusion of the last call on draft… D. J. Bernstein
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] Re: Conclusion of the last call on draft… Jari Arkko
- [procon] Re: Conclusion of the last call on draft… D. J. Bernstein
- [procon] Re: Conclusion of the last call on draft… Salz, Rich
- [procon] Re: Conclusion of the last call on draft… Eliot Lear
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] Re: Conclusion of the last call on draft… Brian E Carpenter
- [procon] What WGLC comments remain after draft -10 Salz, Rich
- [procon] Should we remove reference to RFC 1311? Salz, Rich
- [procon] Re: Should we remove reference to RFC 13… Brian E Carpenter
- [procon] Re: Should we call drafts "inactive" ins… Brian E Carpenter
- [procon] Re: Should we call drafts "inactive" ins… Salz, Rich
- [procon] Re: Should we remove reference to RFC 13… Salz, Rich
- [procon] Should we call drafts "inactive" instead… Salz, Rich
- [procon] Who determines consensus? Salz, Rich
- [procon] Who specifies "historic" status? Salz, Rich
- [procon] Re: Should we call drafts "inactive" ins… Jeffrey Haas
- [procon] Re: Who specifies "historic" status? Brian E Carpenter
- [procon] Re: Who specifies "historic" status? Scott O. Bradner
- [procon] Re: Who specifies "historic" status? Brian E Carpenter
- [procon] Re: Who specifies "historic" status? Scott O. Bradner
- [procon] Re: Who specifies "historic" status? Salz, Rich
- [procon] Details on what changed in draft -11 Salz, Rich