[top post]
I think, Brian, we agree that there is a line to be drawn.
We are debating where to draw that line.
At one end of the scale we have only "open standards may be referrnced," and at the other end is "any reference can be made."
In between, we are debating who needs what access and when. (Also with a dimension added by whether the reference is normative or not -- assuming the proper use of "normative".)
I can see the view that "key reviewers" can be claimed to need access. But who is a key reviewer? We have a consensus process: How can someone in a working group support a draft unless they can review it? How can an IETF last call be considered to form consensus if a normative reference is "hidden"?
Taking that a step further, what is the purpose of IETF standards work? If it is to make open standards that are free access and open to implement, then what does it mean if you have to pay to access a normative reference?
So, I think I am saying that you need to move the line a whole lot further over. And I am saying that it is not the IESG's job to tweak this per document: we should set IETF-wide "rules".
Note that I observe two behaviours in working groups to get around all of this.
1. Inclusion of an (often very detailed) Appendix "explaining for the convenience of the reader" the referenced material. My principal concerns of this well-meaning approach are that it is not the IETF's job to re-interpret the work of other standards bodies, and that this interpretation may be (accidentally) inconsistent with the referenced external standard because it is not reviewed and cross-checked by the source standards body.
2. Transfer of references to external/paywalled documents to be Informative references even when they are used in a Normative way. This is, of course, plain wrong.
Cheers,
Adrian
On 11/05/2024 21:48 BST Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:Hi Adrian,Without disparaging your other comments, I think this is the one that needsdiscussion:4. Why do you limit access to reviewers of the document. Surely allimplementers and operators will need access for all time. Otherwise,what is the value of the document? Thus, you can say "All readers,"or "All users," and lose the second paragraph.Consider that we have an irresistible force (the IETF) meeting immovableobjects (the IEEE and the IEC, to continue with Carsten's example).If we want to write an IETF standard that explicitly depends on anIEEE/IEC standard, we basically have no realistic alternative to citinga paywalled document. Requiring that the IETF protagonists ensure thatreviewers have access to the paywalled document seems to be a reasonablecompromise between the dream world where all standards are freely availableand the world we actually live in.Whether implementers or operators are willing to pay for access, or riskgoing to court, really isn't the IETF's call. As already mentioned, there'san analogy with other IPR issues. We *prefer* unencumbered technology andunencumbered citations, but this can never be 100% achievable.RegardsBrianOn 12-May-24 01:37, Adrian Farrel wrote:Hi,I appreciate the effort to make incremental changes to process. That isthe right way to do things.However, I'm not convinced about the need for this draft, and I have afew comments.Cheers,Adrian===Section 1Since the publication of BCP 9, such external references have becomemore common.I don't doubt you, but since this statement is unsubstantiated, it mademe wonder, whether it matters. I think it doesn't and could be omitted.---Section 1Some of these external references, however, present achallenge, as they may not be freely available.Why "however"?---Section 1BCP 9 also discusses references from standards track specificationsto those of lower maturity levels. Updated guidance on this matter,and the first definition of the notion of "normative" versus"informative" references, can be found in BCP 97. BCP 97 alsodefines the terms "source" and "target" documents.This document presents a procedure to be used when evaluatingstandards track IETF documents that make normative references toexternal specifications.Given the second paragraph, what is the purpose of the first paragraph?It's true and interesting, but not relevant to this document. Althoughthe definitions of "source document" and "target document" are used inthis document.---Section 2Authors/editors of source documents may be required by the IESG tosecure freely available copies of the target documents for use by allanticipated reviewers during the source document's life cycle, whichincludes working group participants, any member of the community thatchooses to participate in Last Call discussions, area review teams,IANA expert reviewers, and members of the IESG. The mechanism foracquiring access to those documents is to be specified in theshepherd writeup.Note that there is no requirement for a freely available copy of thereference after the publication of the draft as an RFC, nor is thereany requirement that the copies be provided to the general public.As others have noted, this gives the IESG power to require action. Ihave issues:1. Authors/editors only serve the working group. Don't require them todo stuff.2. The IESG serves the community and steers. If the community hasconsensus to do otherwise, why is the IESG making this requirement?Maybe request or suggest? (Note that even a Discuss is not arequirement.)3. Following on from the previous, if you want to set a rule, set arule. Don't leave it to the variations in IESG membership todetermine what has to be done, but give a clear set of instructionsto the producers of all documents. If your problem is that sometimesit's OK to have a reference and sometimes it isn't, can you give anyguidance on when to do what?4. Why do you limit access to reviewers of the document. Surely allimplementers and operators will need access for all time. Otherwise,what is the value of the document? Thus, you can say "All readers,"or "All users," and lose the second paragraph.5. The shepherd write-up comes late in the process: certainly after theworking group has written the document, after "early" Directoratereviews, and working group last call. So, doesn't the mechanism needto be documented somewhere else? Probably in the reference in thedocument.---Section 2Another path forward may be to generate an RFC of appropriate statusthat captures the important parts of the intended target document.Sure, but...- Copyright of the source material (in the target document)- Inherited IPR- Accidental divergence from the target document- Determination of accuracy through review by the originators of thetarget document-----Original Message-----Sent: 10 May 2024 16:51To: IETF-Announce <ietf-announce@xxxxxxxx>Subject: Last Call: <draft-kucherawy-bcp97bis-05.txt> (Procedure for Standards Track Documents to Refer Normatively to External Documents) to Best Current PracticeThe IESG has received a request from an individual submitter to consider thefollowing document: - 'Procedure for Standards Track Documents to ReferNormatively to External Documents'<draft-kucherawy-bcp97bis-05.txt> as Best Current PracticeThe IESG plans to make a decision in the next few weeks, and solicits finalcomments on this action. Please send substantive comments to thelast-call@xxxxxxxx mailing lists by 2024-06-07. Exceptionally, comments maybe sent to iesg@xxxxxxxx instead. In either case, please retain the beginningof the Subject line to allow automated sorting.AbstractThis document specifies a procedure for referencing externalstandards and specifications from IETF-produced documents on theStandards Track. In doing so, it updates BCP 9 (RFC 2026).The file can be obtained viaNo IPR declarations have been submitted directly on this I-D.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
