Re: BCP97bis
Michael Richardson <mcr+ietf@sandelman.ca> Sat, 16 October 2021 20:29 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB633A0C5E for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz-9heIprOXT for <ietf@ietfa.amsl.com>; Sat, 16 Oct 2021 13:29:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64ED3A0C5C for <ietf@ietf.org>; Sat, 16 Oct 2021 13:29:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0BBA518092; Sat, 16 Oct 2021 16:29:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cYycslpP_Y73; Sat, 16 Oct 2021 16:29:38 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E4041808D; Sat, 16 Oct 2021 16:29:38 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1A4F7236; Sat, 16 Oct 2021 16:29:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Murray S. Kucherawy" <superuser@gmail.com>, ietf <ietf@ietf.org>
Subject: Re: BCP97bis
In-Reply-To: <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <CAL0qLwavK5dYdmYPVxdMT5rA=jBZv1cEyAsVBEWOD7p9MoZR1g@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 16 Oct 2021 16:29:12 -0400
Message-ID: <15645.1634416152@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0GjIlx_USZaMsSUoD_oDg7QHkAE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Oct 2021 20:29:20 -0000
{reading the document before I read the thread of replies} Thank you for doing this revision: this kind of work is often thankless. A question as I read section 4.2 (The IESG). I think that idnits presently finds and notes downrefs. As a document shepherd, I've never had to research them. (Maybe that's a fault on my part, maybe I should have been) I'm mostly thinking that downrefs should ideally be noted and resolved during WGLC. I think that this happens, but maybe I have too small a sample. Are we having a problem getting downrefs identified early enough, or are things okay? I also wonder if we shouldn't have a process to attempt to clean the downref registry out, but reclassifying the documents. The repeated MD5 and HMAC document listed as examples seem like good datapoints. (MD5 might be Historic, but HMAC is still awesome) } At a minimum, authors/editors of source documents need to secure freely } available copies of the target documents for use by all anticipated reviewers } during the source document's life cycle, which includes working group } participants, any member of the community that chooses to participate in Last } Call discussions, area review teams, IANA expert reviewers, and members of } the IESG. It seems to me, if this requirement is to be taken seriously, that either the DT or some other resource needs to contain notes on how to obtain the references. My opinion is that the IETF has allowed the IEEE to embrace and suffocate the open-stand.org effort. During RFC8995 review, authors were told by many about about 802.1AR had a new revision and shoudln't we update to it. But, the new revision was unobtainable because the IEEE had 500 errors on their web site for more than a year, which is why we did not cite it. I feel that it shouldn't be just my problem to solve this problem on my own. I have very strong opinions about what happens when a standard becomes part of a lawful regulation. It then becomes part of a law, and the public should have full access to know the law. (Because, ignorance is not a defense) This is particularly important for regulations relating to safety. (I could insert "cyber" before safety, but the word cyber is almost always redundant). In particular, it shouldn't cost money to find out if a product one is being subjected to is safe. As background to a talk I was asked to do, I actually have been doing some reading on requirements to publish laws, and I thought it would be a no-brainer in the UN Charter, but I was surprised. Surely, Canada's 1982 Constitution and Charter of Rights would say something.... not obvious actually. Just that anything published federally has to be in both official languages, and a bunch of provincial statements. Some papers on how governments have used copyright to generate revenue from publishing the laws and legal decisions. Only the Yukon territorial constiution has an actual mandate. A reason I choose to do work at the IETF is because I could read the specifications (using RFC/FTP by email...) without hassle. So I am reacting the word "At a minium", and I don't think we are even getting to that minimum. There are a bunch of specifications that aren't just transitioning from some legacy specification to an RFC, but which we are allocating numbers/etc. for entities which make it very difficult to read their documents. I think that we should be doing more than the minimum here. } Appendix A. Changes Since RFC8067 } The following are the changes in this document relative to the prior state of BCP 97: } } o Apply erratum #2793. https://www.rfc-editor.org/info/rfc8067 doesn't mention any errata. https://www.rfc-editor.org/errata_search.php?eid=2793 indicates that it is errata against RFC4897. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- BCP97bis Murray S. Kucherawy
- Re: BCP97bis Russ Housley
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis David Farmer
- Re: BCP97bis Brian Carpenter
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Scott Bradner
- Re: BCP97bis Russ Housley
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and Informational-as-Standard Michael Richardson
- RE: BCP97bis Larry Masinter
- Re: BCP97bis Joel M. Halpern
- Re: BCP97bis Michael Richardson
- Re: BCP97bis Brian E Carpenter
- RE: BCP97bis Larry Masinter
- Re: BCP97bis John Levine
- Re: BCP97bis Scott Bradner
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Brian E Carpenter
- Re: BCP97bis Russ Housley
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis John C Klensin
- Re: BCP97bis Michael Richardson
- Re: BCP97bis John C Klensin
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis Carsten Bormann
- Re: BCP97bis tom petch
- RE: BCP97bis mohamed.boucadair
- RE: BCP97bis ned+ietf
- Re: BCP97bis John C Klensin
- BCP97bis and "freely available" John C Klensin
- RE: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- RE: BCP97bis mohamed.boucadair
- Re: BCP97bis a process problem tom petch
- Re: BCP97bis John C Klensin
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Lars Eggert
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Warren Kumari
- Re: BCP97bis Salz, Rich
- Re: BCP97bis and "freely available" Scott O. Bradner
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis John C Klensin
- Re: BCP97bis and "freely available" Michael Richardson
- Re: BCP97bis and "freely available" John C Klensin
- BCP written by another AD [was Re: BCP97bis] Brian E Carpenter
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis Michael Richardson
- Re: BCP97bis and "freely available" Sandy Wills
- Re: BCP97bis and "freely available" Michael StJohns
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Randy Presuhn
- Re: BCP97bis and "freely available" George Michaelson
- Re: BCP97bis and "freely available" Brian E Carpenter
- Re: BCP97bis and "freely available" Salz, Rich
- Re: BCP97bis a process problem Michael Richardson
- Re: BCP97bis and "freely available" Michael Richardson
- RE: BCP97bis ned+ietf
- Re: BCP97bis a process problem Brian E Carpenter
- Re: BCP97bis and "freely available" tom petch
- Re: BCP97bis a process problem tom petch
- Re: BCP written by another AD [was Re: BCP97bis] Erik Kline
- Re: BCP97bis Murray S. Kucherawy
- Re: BCP97bis Salz, Rich
- Re: BCP97bis Murray S. Kucherawy