Hi all, I know this is a long threat but I would also like to add my objections to one point in the draft. I'm replying to Adrian's mail because he already raised this point below, however, I think this is an really important point and therefore would like to not my objection separately. It's about this sentence: 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. First, as Adrian says, the editors/authors do this job for the working group, so if at all it's on the working group. However, this is really requiring the wrong thing. What needs to be required before publication is that a document is has a certain technicially qulatity and respectively sufficiently reviewed; this includes a review by the IESG, however, it does not nessarily mean that every single point need to be reviewed in deepth by the IESG. E.g. if the referenced document is a well-established standard, I think I can assume it's okay without further reviewing it. If the reference document contains a detail that I need to understand in order to be able to review the draft at hand, that's something different. So the requirement is really not, from my point of view, that all reviewers have access to all normatively referenced dcouments but that reviewers are able to give the review needed. If that is not possible and therefore there is doubt that a document has not been reviewed sufficiently and might not have sufficient technical quality, the IESG should not approve its publication. Mirja On 11.05.24, 15:38, "Adrian Farrel" <adrian@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>> wrote: 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 <mailto:iesg-secretary@xxxxxxxx> <iesg-secretary@xxxxxxxx <mailto:iesg-secretary@xxxxxxxx>> Sent: 10 May 2024 16:51 To: IETF-Announce <ietf-announce@xxxxxxxx <mailto:ietf-announce@xxxxxxxx>> Cc: draft-kucherawy-bcp97bis@xxxxxxxx <mailto: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 <mailto:last-call@xxxxxxxx> mailing lists by 2024-06-07. Exceptionally, comments may be sent to iesg@xxxxxxxx <mailto: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/ <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 <mailto:last-call@xxxxxxxx> To unsubscribe send an email to last-call-leave@xxxxxxxx <mailto:last-call-leave@xxxxxxxx> -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
