Re: BCP97bis
John C Klensin <john-ietf@jck.com> Mon, 18 October 2021 14:20 UTC
Return-Path: <john-ietf@jck.com>
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 EB2F73A140E for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 07:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 uqH5PAFbxegH for <ietf@ietfa.amsl.com>; Mon, 18 Oct 2021 07:20:33 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275623A1407 for <ietf@ietf.org>; Mon, 18 Oct 2021 07:20:31 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1mcTV6-000PDR-JT; Mon, 18 Oct 2021 10:20:28 -0400
Date: Mon, 18 Oct 2021 10:20:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
cc: Russ Housley <housley@vigilsec.com>, Carsten Bormann <cabo@tzi.org>, IETF <ietf@ietf.org>
Subject: Re: BCP97bis
Message-ID: <F0520C841C4B128BBC7DD2AF@PSB>
In-Reply-To: <CAL0qLwY=wdD2rCdG8BQGGG04Y4qFKAhS4v_8+YDeAcvQisGkpA@mail.gmail.com>
References: <CAL0qLwbwvs2Cp_urgJ=hzc6yEMGDaz3C0xf6RQXRrB89wAx=Rw@mail.gmail.com> <C657F78F-FF99-4898-8A08-844B32589DDE@vigilsec.com> <CAL0qLwbLqyWSqFGL2x-FpXXD19QG9-eZkrnTVm_fxt3tUfZSgg@mail.gmail.com> <C92D456E-63ED-453B-8F33-3AAECA40D1DA@vigilsec.com> <27721119-D39D-427D-8EEE-C5027DA15B06@akamai.com> <007c01d7c2dc$9090c780$b1b25680$@acm.org> <5385fd6f-b7a7-3baa-1374-f4d8d87216fd@joelhalpern.com> <6454.1634428177@localhost> <6702b78c-037f-f5fd-78a6-901a999dab54@gmail.com> <7E25FC36-0757-45EA-AB12-76F6818C797C@sobco.com> <B6BBF8C8788D1ECEACF549C0@PSB> <D290EE8C-6709-4A08-A827-41F7494D4E58@tzi.org> <A117413E-065D-478E-A1CA-3421D5FB0D12@vigilsec.com> <6803AC5BAEB3D637D13658B7@PSB> <CAL0qLwYY7mRwPz=bYnKN66tNmj4agaf5eEOd8-yMh3phEGmyGA@mail.gmail.com> <64733AD195E66632EA57F9E2@PSB> <CAL0qLwY=wdD2rCdG8BQGGG04Y4qFKAhS4v_8+YDeAcvQisGkpA@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/u746UJxERjenBaH1lMwmcidL2cU>
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: Mon, 18 Oct 2021 14:20:39 -0000
--On Sunday, October 17, 2021 21:28 -0700 "Murray S. Kucherawy" <superuser@gmail.com> wrote: > On Sun, Oct 17, 2021 at 7:42 PM John C Klensin > <john-ietf@jck.com> wrote: > >> > What did you mean by "in which document's categories the >> > reference falls"? >> >> In essence, the descriptions in your sections 4.2, 5, and 6 >> create categories of downrefs. I'd be inclined to divide 6 >> into two subcategories, one for what we have called >> "recognized standards bodies" in other contexts and one for >> other types of external references. Either way, I think that >> categorization could be very helpful going forward and I was >> suggesting that it should be included in the registry. > Do we have a good definition of "recognized standards bodies" > anywhere? This has come up recently in other contexts (e.g., > RFC 6838) recently and I'm wondering if there's an actual > definition somewhere that I don't know about. In particular, > what defines "recognized"? I think it went into the vocabulary with media type registrations (the predecessors of 6839) in which requests from such standards bodies, presumably for identifiers to support their work or defined by their standards, were (and are) given special treatment. Who qualified (or not) was left to the discretion of the IESG. The assumption was that the IESG would consider many of the issues we have been talking about in the context of BCP97bis: Is the body established, recognized, and credible? It is likely to be around for a while? Are their specifications "widely and freely available" (even if not free)? Should the criteria for "recognized" be the same for downrefs as for media types? I assume at least similar but don't know beyond that (and suspect we would get into trouble by trying to spell things out too much). As we try to make these things more precise and mechanical, there is another issue with "freely available" for which it might be useful to draw on the thinking in our patent policies. A WG is allowed to consider a possible standard built on patented and highly restricted technologies (e.g., you are going to need a license that may cost big bucks, and you have no guarantees that you will get one or that you will get the same terms as your competitor). They are expected to carefully consider less restricted technologies but, if they (and the community) conclude that the restricted technology is enough better than any of the alternatives, they are allowed to go ahead. Perhaps we need provision for exceptions, on a similar basis to the downref rules. Trying to lay out rigid rules that have no exceptions may be a bad idea. best, john > > Has there been a need previously to have a downref registry > for things external to the IETF? The current registry only > has RFCs in it. > > -MSK
- 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