Hi, I appreciate the effort to make incremental changes to process. That is the right way to do things. However, I'm not convinced about the need for this draft, and I have a few comments. Cheers, Adrian === Section 1 Since the publication of BCP 9, such external references have become more common. I don't doubt you, but since this statement is unsubstantiated, it made me wonder, whether it matters. I think it doesn't and could be omitted. --- Section 1 Some of these external references, however, present a challenge, as they may not be freely available. Why "however"? --- Section 1 BCP 9 also discusses references from standards track specifications to 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 also defines the terms "source" and "target" documents. This document presents a procedure to be used when evaluating standards track IETF documents that make normative references to external specifications. Given the second paragraph, what is the purpose of the first paragraph? It's true and interesting, but not relevant to this document. Although the definitions of "source document" and "target document" are used in this document. --- Section 2 Authors/editors of source documents may be required by the IESG 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. The mechanism for acquiring access to those documents is to be specified in the shepherd writeup. Note that there is no requirement for a freely available copy of the reference after the publication of the draft as an RFC, nor is there any requirement that the copies be provided to the general public. As others have noted, this gives the IESG power to require action. I have issues: 1. Authors/editors only serve the working group. Don't require them to do stuff. 2. The IESG serves the community and steers. If the community has consensus to do otherwise, why is the IESG making this requirement? Maybe request or suggest? (Note that even a Discuss is not a requirement.) 3. Following on from the previous, if you want to set a rule, set a rule. Don't leave it to the variations in IESG membership to determine what has to be done, but give a clear set of instructions to the producers of all documents. If your problem is that sometimes it's OK to have a reference and sometimes it isn't, can you give any guidance on when to do what? 4. Why do you limit access to reviewers of the document. Surely all implementers 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 the working group has written the document, after "early" Directorate reviews, and working group last call. So, doesn't the mechanism need to be documented somewhere else? Probably in the reference in the document. --- Section 2 Another path forward may be to generate an RFC of appropriate status that 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 the target document -----Original Message----- From: iesg-secretary@xxxxxxxx <iesg-secretary@xxxxxxxx> Sent: 10 May 2024 16:51 To: IETF-Announce <ietf-announce@xxxxxxxx> Cc: draft-kucherawy-bcp97bis@xxxxxxxx Subject: Last Call: <draft-kucherawy-bcp97bis-05.txt> (Procedure for Standards Track Documents to Refer Normatively to External Documents) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'Procedure for Standards Track Documents to Refer Normatively to External Documents' <draft-kucherawy-bcp97bis-05.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@xxxxxxxx mailing lists by 2024-06-07. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a procedure for referencing external standards and specifications from IETF-produced documents on the Standards Track. In doing so, it updates BCP 9 (RFC 2026). The file can be obtained via https://datatracker.ietf.org/doc/draft-kucherawy-bcp97bis/ No 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
