Procedure for Standards Track Documents to Refer Normatively to External Documents
draft-kucherawy-bcp97bis-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-10-10
|
05 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead |
2024-06-07
|
05 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-06-06
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2024-06-06
|
05 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-kucherawy-bcp97bis-05, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-kucherawy-bcp97bis-05, which is currently in Last Call, and has the following comments: We note that this document does not contain a standard IANA Considerations section. After examining the draft, we understand that, upon approval of this document, there are no IANA Actions that need completion. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-06-05
|
05 | Paul Wouters | [Ballot comment] The text surrounding my DISCUSS item has vanished from the document, which was a clever way to resolve my issue :) |
2024-06-05
|
05 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss |
2024-05-10
|
05 | Jenny Bui | The following Last Call announcement was sent out (ends 2024-06-07): From: The IESG To: IETF-Announce CC: draft-kucherawy-bcp97bis@ietf.org, ek.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: … The following Last Call announcement was sent out (ends 2024-06-07): From: The IESG To: IETF-Announce CC: draft-kucherawy-bcp97bis@ietf.org, ek.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (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' 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@ietf.org mailing lists by 2024-06-07. Exceptionally, comments may be sent to iesg@ietf.org 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. |
2024-05-10
|
05 | Jenny Bui | IESG state changed to In Last Call from Last Call Requested |
2024-05-10
|
05 | Jenny Bui | Last call announcement was generated |
2024-05-09
|
05 | Erik Kline | Last call was requested |
2024-05-09
|
05 | Erik Kline | IESG state changed to Last Call Requested from IESG Evaluation::AD Followup |
2024-05-09
|
05 | Erik Kline | Last call announcement was generated |
2024-05-08
|
05 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2024-05-08
|
05 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-05-08
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2024-05-08
|
05 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-05.txt |
2024-05-08
|
05 | Murray Kucherawy | New version accepted (logged-in submitter: Murray Kucherawy) |
2024-05-08
|
05 | Murray Kucherawy | Uploaded new revision |
2024-04-03
|
04 | Gunter Van de Velde | [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-kucherawy-bcp97bis-04 Thank you for the work put into this document. Please find below some … [Ballot comment] # Gunter Van de Velde, RTG AD, comments for draft-kucherawy-bcp97bis-04 Thank you for the work put into this document. Please find below some non-blocking COMMENT points. 132 other implementations of that standard. For documents that are 133 referenced, any document that includes key information an implementer 134 needs would be normative. For example, if one needs to understand a What about following rewrite proposal to make the text read easier: "For referenced documents, any document containing essential information required by an implementer would be considered normative." 164 There are a number of circumstances in which an IETF document may 165 need to make a normative reference to a document at a lower maturity 166 level, but such a reference conflicts with Section 4.2.4 of 167 [RFC2026]. For example: I find that in RFC2026 the section "4.2.4 Historic". Not sure how the pieces fit together. mostlikely due to being too much rookie AD to understand the conflict reference 162 2. The Need for Downward References 164 There are a number of circumstances in which an IETF document may 165 need to make a normative reference to a document at a lower maturity 166 level, but such a reference conflicts with Section 4.2.4 of 167 [RFC2026]. For example: Should it be spelled out more explicit that this list is not a limited list? 200 The term "Standards-Track document", as used in this specification, 201 is assumed to include only Standards-Track documents at any maturity 202 level, plus BCPs, but not documents with any other status. Would this include the historical documents that were valid when RFC was written, but became historical after few years due to technology evolution. (i guess i may be thrown of the rails by the reference to RFC2026 section 4.2.4 from earlier in the document) 238 At the option of the author/editor, similar notes may be attached to 239 non-normative references. is this text necessary? this seems irrelevant for normative down-refs 241 The exception to this process is the unusual case where the source 242 document is less stable than the target document, even if the target 243 document is at a lower maturity level. In such cases, the above 244 notation is omitted. 3 lines up it was already mentioned that the annotation can be omitted. not sure if these lines can be combined instead? 246 When the document is prepared to submit to the IESG for approval, a 247 document shepherd writeup [RFC4858] is normally prepared. This What about following readability rewrite: "Upon preparing a document for submission to the IESG for approval, it is customary to create a document shepherd write-up, as outlined in [RFC4858]". 271 identified. If it elects not to do so, then any future downref to 272 the same target document is subject again to the procedures described 273 in this document. In making this decision, the IESG should take into I am not sure what "any future downref to the same target document" exactly means. Does this mean that once a target document is used once as normative reference, that in futire instances for other source documents it can be used without special annotation notes? 311 * the actual reference to it (e.g., a web link) may have dubious 312 location stability; I am not a big fan of the word 'dubious'. It implies it it obscure or malicious or something else negative. Using the wording 'questionable' has less negative connotation. a possible rewrite option: 'The stability of the actual reference's location, such as a web link, may be questionable.' 348 6. Downref Registry 350 The IETF has previously established a registry of downrefs to RFCs 351 that have been previously waived by the IESG in the manner described 352 in Section 4.2. The registry includes the name of the referenced RFC How to access this registry? (i as rookie AD has no idea how to access this or how it is instantiated Be well, G/ |
2024-04-03
|
04 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-03-29
|
04 | Orie Steele | [Ballot comment] I support the other discusses, in particular the comments from John Scudder |
2024-03-29
|
04 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-01-26
|
04 | Gunter Van de Velde | Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review |
2024-01-26
|
04 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version': Cleaning up stale OPSDIR queue |
2022-10-27
|
04 | (System) | Changed action holders to Murray Kucherawy, Erik Kline (IESG state changed) |
2022-10-27
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-10-27
|
04 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this. However I am not sure what it the final outcome of this work other than adding some notes … [Ballot comment] Thanks for working on this. However I am not sure what it the final outcome of this work other than adding some notes in the references. Hence, I am supporting Warren's discuss. |
2022-10-27
|
04 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2022-10-27
|
04 | Lars Eggert | [Ballot comment] # GEN AD review of draft-kucherawy-bcp97bis-04 CC @larseggert Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/5ZJZXPwzpBcB3uuIPCiJMLQ6gKU). … [Ballot comment] # GEN AD review of draft-kucherawy-bcp97bis-04 CC @larseggert Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/5ZJZXPwzpBcB3uuIPCiJMLQ6gKU). ## Comments I agree with most of the other Discusses, which is why I decided to just comment on this document rather than duplicating them. Generally, I feel we need a much more lightweight process than we currently have and that we would have if we adopted this revision. ### Section 2, paragraph 0 ``` 2. The Need for Downward References ``` Might want to add the very common example of needing to normatively cite a cryptographic algorithm described in a CFRG document. ### Section 3, paragraph 2 ``` A reference involves two documents, the one in which the reference is embedded and the document referenced. Where needed for clarity, these documents are referred to as the "source document" and "target document", respectively. ``` But which is which? I assume the "source" is the one containing the reference, and the "target" is being references? ### Section 4.1, paragraph 4 ``` * A note is included in the reference text that indicates that the reference is to a target document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, and, optionally, explaining why the downref is appropriate. ``` Is there an xml2rfc and ideally kramdown-rfc way of doing that easily? ### Section 4.1, paragraph 5 ``` There is no separate review of these references. For example, when the downref is to a document of a lower maturity level that is understood to be stable, the annotation can be omitted. ``` Understood by whom? And what does stable mean? I think this concept needs to be removed from the process. ### Section 4.1, paragraph 5 ``` At the option of the author/editor, similar notes may be attached to non-normative references. ``` That seems redundant and would make it more difficult to spot the downrefs. ### Section 4.1, paragraph 5 ``` The exception to this process is the unusual case where the source document is less stable than the target document, even if the target document is at a lower maturity level. In such cases, the above notation is omitted. ``` We don't have a defined notion of document stability. (See above, I think this concept needs to go, or it needs to be clarified.) ### Section 4.2, paragraph 1 ``` With appropriate community review, the IESG may establish procedures for when normative downref should delay a document and when downrefs should simply be noted. Absent specific guidance, authors and reviewers should use their best judgment. It is assumed that, in a significant majority of cases, noting a downref is preferable to delaying publication. ``` I think our procedure is the DOWNREF registry. Would suggest to remove this and just merge Section 6 here. ### Section 4.2, paragraph 4 ``` understanding of the relevant technical area. For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well known among cryptographers. Such documents are added to the "Downref Registry" defined in Section 6. ``` Would suggest to replace MD5 with another example. ### Section 6, paragraph 3 ``` Note that there is currently no registry of downrefs to non-IETF documents. ``` Should there be? I think yes. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 4.1, paragraph 8 ``` - When the document is prepared to submit to the IESG for approval, a - --------- + When the document is to be submitted to the IESG for approval, a + +++ +++ ``` #### Section 4.1, paragraph 8 ``` - writeup should contain a description of any downrefs that appear in - ^^^^^^ - the document, and should make particular note of any downref that is - ^^^^^^ + writeup SHOULD contain a description of any downrefs that appear in + ^^^^^^ + the document, and SHOULD make particular note of any downref that is + ^^^^^^ ``` #### Section 5, paragraph 11 ``` - that captures the important parts of the intended target docuemnt. - - + that captures the important parts of the intended target document. + + ``` ### Grammar/style #### Section 1, paragraph 5 ``` ly understand or implement the subject matter in the RFC, or whose contents ^^^^^^^^^^^^^^ ``` This phrase is redundant. Consider using "subject" to avoid wordiness. #### Section 5, paragraph 7 ``` ing access to those documents is to be be specified in the shepherd writeup. ^^^^^ ``` Possible typo: you repeated a word. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2022-10-27
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2022-10-27
|
04 | Robert Wilton | [Ballot comment] I support Alvaro's discuss. Hi Murray, Thanks for this document, I'm always up for a single new RFC that replaces 3 others. However, … [Ballot comment] I support Alvaro's discuss. Hi Murray, Thanks for this document, I'm always up for a single new RFC that replaces 3 others. However, I also support Alvaro's discuss. I'm not sure that the new process, or reaffirming an existing process that nobody follows, is necessary. Specifically, I'm not quite sure what problem we are aiming at solving? (1) p 3, sec 2. The Need for Downward References * There are exceptional procedural or legal reasons that force the target of the normative reference to be an informational or historical RFC or to be at a lower standards level than the referring document. Would it be worth including the example of "Architecture" or "Framework" documents that are quite plausibly defined as being informational, but are still reasonably likely to be normatively referenced? (2) p 4, sec 4.1. Authors and Editors When a Standards-Track or BCP document requires a normative reference to a document of lower maturity, the authors/editors should apply the following very simple procedure: Is there any downref from a Full Internet Standard to a Draft Standard? Is there any downref from Informational to Experimental? (3) p 5, sec 4.2. The IESG With appropriate community review, the IESG may establish procedures for when normative downref should delay a document and when downrefs should simply be noted. Absent specific guidance, authors and reviewers should use their best judgment. It is assumed that, in a significant majority of cases, noting a downref is preferable to delaying publication. I don't understand this, why would a downref delay publication of a document? What would it be waiting for? Do you mean delay by reissuing the IETF last call? (4) p 5, sec 4.2. The IESG When a document is presented to the IESG for publication that contains a downref not called out by the author/editor(s) as described in the previous section, it is strongly recommended that the normal IETF Last Call procedure will be issued, with the need for the downref explicitly documented in the Last Call itself. Any community comments on the appropriateness of downrefs will be considered by the IESG as part of its deliberations. I think that it is probably simpler for downrefs (not in the registry) to always be called out in the last call. Don't we have tooling that is meant to already spot this? (5) p 6, sec 5. Non-IETF Target Documents Authors and editors should try to avoid such references due to the challenges they present, as they affect the IETF's ability to ensure the quality of its output. However, such references are not always avoidable. Should "references" be replaced with "normative references"? Nit level comments: (6) p 3, sec 2. The Need for Downward References * A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. Did you mean "standards track document" for "standards document" here? (7) p 4, sec 3. Definitions The term "Standards-Track document", as used in this specification, is assumed to include only Standards-Track documents at any maturity level, plus BCPs, but not documents with any other status. Here you refer to "standards-track document", in other places it has been referred to without the hyphen and capitalization. Regards, Rob |
2022-10-27
|
04 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-10-26
|
04 | Warren Kumari | [Ballot discuss] I'm still very unclear *exactly* what problem this is intended to address; we can already normatively refer to lower level documents. This document … [Ballot discuss] I'm still very unclear *exactly* what problem this is intended to address; we can already normatively refer to lower level documents. This document seems to add a *large* amount of process for the authors, the IESG, the community/WGs, and possibly the RFC Editor as well, and I'm not sure what the gain is here. As Alvaro pointed out, we already have the "annotation" procedure in RFC4897 (published more than 15 years ago), and we don't actually use it, and nothing seems to have broken. We also already have the "misref" bit solved - it's part of normal IETF processing. RFC3967, RFC4897, RFC8067 are important documents, and I don't think that we should be obsoleting them without a really good reason - and I don't see that here. |
2022-10-26
|
04 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2022-10-25
|
04 | Alvaro Retana | [Ballot discuss] (1) The annotation procedure in §4.1 was originally defined in rfc4897 more than 15 years ago. I have seen plenty of downrefs, but … [Ballot discuss] (1) The annotation procedure in §4.1 was originally defined in rfc4897 more than 15 years ago. I have seen plenty of downrefs, but I have yet to see this process used. This DISCUSS point challenges the continued inclusion of this procedure as a best current practice as it seems to have never been adopted. (2) §4.2: With appropriate community review, the IESG may establish procedures for when normative downref should delay a document and when downrefs should simply be noted. Absent specific guidance, authors and reviewers should use their best judgment. It is assumed that, in a significant majority of cases, noting a downref is preferable to delaying publication. The IESG has already documented this guidance in the 2006 "IESG Statement: Normative and Informative References", where it says: The distinction between normative and informative references is often important. The IETF standards process according to RFC 2026 and RFC 3967, and the RFC Editor publication process, both need to know whether a reference to a work in progress is normative. An RFC cannot be published until all of the documents that it lists as normative references have been published. In practice, this often results in the simultaneous publication of a group of interrelated RFCs. It is clear that the IESG Statement expects publication to be delayed (vs. just noting the downref). |
2022-10-25
|
04 | Alvaro Retana | [Ballot comment] §6: Going forward, new registry entries should also record the reason the registry addition was made, the name of the external … [Ballot comment] §6: Going forward, new registry entries should also record the reason the registry addition was made, the name of the external body owning the target reference, and the name of the Area Director making the new entry. Note that there is currently no registry of downrefs to non-IETF documents. Unfortunately, this text (or the rest of the document) doesn't include rfc2119 keywords. What kind of entries are expected to "record the reason the registry addition was made"? Without additional guidance, entries such as "approved by the IESG" could be used. Also, for the existing downref registry, there is no "external body owning the target reference". Was this entry meant for a registry of non-IETF documents? |
2022-10-25
|
04 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2022-10-24
|
04 | Roman Danyliw | [Ballot discuss] ** Section 4.2 When a document is presented to the IESG for publication that contains a downref not called out by … [Ballot discuss] ** Section 4.2 When a document is presented to the IESG for publication that contains a downref not called out by the author/editor(s) as described in the previous section, it is strongly recommended that the normal IETF Last Call procedure will be issued, with the need for the downref explicitly documented in the Last Call itself. In the first paragraph, what’s the more precise definition of the state in which a “document is presented to the IESG” that doesn’t call out the downref? Is that the WG submitting it as a PubReq to the AD? Or the full IESG for telechat review? If it’s the former (AD Review) then why can’t the document just be updated with the new style of reference with any other AD Review feedback? If it is the latter (telechat), is this text suggesting _another_ IETF LC since the document won’t reach the full IESG without going through an initial IETF LC? A duplicate IETF LC seems to be covered in the next paragraph. |
2022-10-24
|
04 | Roman Danyliw | [Ballot comment] ** Section 4.1 * A note is included in the reference text that indicates that the reference is to … [Ballot comment] ** Section 4.1 * A note is included in the reference text that indicates that the reference is to a target document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, and, optionally, explaining why the downref is appropriate. A process aside: are we going to hold publication until we have coordinated with the RFC Editor on how such a note would look, and “establish[ed] procedures regarding the text to use, or give guidance on this text.” ** Section 4.2 This should only occur when the same document (and version) ... Such documents are added to the "Downref Registry" defined in Section 6. The first phrase comes from RFC3967. I’m wondering about the intent of the parenthetical. The DOWNREF registry only has RFCs. What is the versioning envisioned here? See related comments in Section 6. ** Section 6. Going forward, new registry entries should also record the reason the registry addition was made, the name of the external body owning the target reference, and the name of the Area Director making the new entry. Note that there is currently no registry of downrefs to non-IETF documents. I’m not sure how to take the observation in the last paragraph. Are we expanding the aperture of the downref registry? POSSIBLE NEW TEXT (to replace the current last sentence): Going forward, the applicability of this downref registry is expanded to include non-IETF documents. |
2022-10-24
|
04 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2022-10-24
|
04 | Paul Wouters | [Ballot discuss] Can we have a (normative) reference to the downref registry at https://datatracker.ietf.org/doc/downref ? After reading the document I had to google "ietf downref … [Ballot discuss] Can we have a (normative) reference to the downref registry at https://datatracker.ietf.org/doc/downref ? After reading the document I had to google "ietf downref registry" to find it :P |
2022-10-24
|
04 | Paul Wouters | [Ballot comment] The IESG may, at its discretion, establish policies regarding external documents referenced normatively by Standards-Track RFCs in light of these … [Ballot comment] The IESG may, at its discretion, establish policies regarding external documents referenced normatively by Standards-Track RFCs in light of these challenges. Such policies are to be developed with solicitation of community input. It is as if the document is conveying a new power to the IESG here, but doesn't the IESG already have this power? Eg this sentence isn't adding anything new? In fact, this document's author is an IESG member acting on making a policy developed with solicitation of community input itself already ! Q.E.D ? |
2022-10-24
|
04 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2022-10-24
|
04 | John Scudder | [Ballot discuss] I acknowledge that Section 4.1 is largely inherited from RFC 4897, but I'm scratching my head over the importance of a document … [Ballot discuss] I acknowledge that Section 4.1 is largely inherited from RFC 4897, but I'm scratching my head over the importance of a document being "stable"... without ever defining what "stability" means, for example, The exception to this process is the unusual case where the source document is less stable than the target document, even if the target document is at a lower maturity level. In such cases, the above notation is omitted. If you pressed me to define document "stability" I'd first reach for whether it's a good-quality archival reference. But that can't be it, because all RFCs are good archival references, no matter their maturity level. Because of this, I don't know how to apply the standard set out by Section 4.1. A possible fix would be to remove all the sentences and clauses that mention "stable", a different one would be to define what it means. |
2022-10-24
|
04 | John Scudder | [Ballot comment] ## COMMENT ### Section 4.1: I've read this a few times and I don't understand what it's telling me, sorry: There is … [Ballot comment] ## COMMENT ### Section 4.1: I've read this a few times and I don't understand what it's telling me, sorry: There is no separate review of these references. For example, when the downref is to a document of a lower maturity level that is understood to be stable, the annotation can be omitted. It looks like the "for example" grafts the final sentence on to what was in RFC 4897, but I don't get how that sentence is an example of "there is no separate review", it just seems like an additional piece of specification. (But see also my discuss about "stable".) ### Section 4.2: This section says that: In the case of a downref approved in this manner, the annotations described above should be added to the reference unless the IESG, after consideration of Last Call input, concludes it is inappropriate. I've never seen one of these annotations in the wild. I went and checked the last eight references in the Downref registry (https://datatracker.ietf.org/doc/downref/) so I could see what one looked like. There aren't any. Unless I'm confused, it appears this rule is honored mainly in the breach. As such, perhaps it doesn't make sense to propagate it forward into bcp97bis. Alternately, if we are going to keep it as a requirement, then I guess we should start doing it. I am not advocating the latter approach, but it does seem like we gotta do one or the other. ### Section 5: I agree with Éric's comment that some more precise term than "freely available" is desirable. ### Section 6: The IETF has previously established a registry of downrefs to RFCs that have been previously waived by the IESG in the manner described Is there a reason there isn't a reference to the Downref registry's location? (That being, https://datatracker.ietf.org/doc/downref/). Would the reference be... normative? (Also, how about dropping one of the "previously"s? Probably the first one.) ### Section 6: The first paragraph and the second are in almost-conflict: Going forward, new registry entries should also record the reason the registry addition was made, the name of the external body owning the target reference, and the name of the Area Director making the new entry. Note that there is currently no registry of downrefs to non-IETF documents. That is to say, the first paragraph tells us that we have to include "the name of the external body" (by the way, shouldn't there be "(if any)" appended to that?). But the second tells us there's no such animal. I guess the first paragraph implies we're going to start tracking non-IETF downrefs, and the second paragraph should be deleted? ## NITS - s/very simple procedure/procedure/ - s/docuemnt/document/ - Why is RFC 3339 a "possible" example? Isn't it just... an example? |
2022-10-24
|
04 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2022-10-24
|
04 | Martin Duke | [Ballot comment] - I don't understand this paragraph: "The exception to this process is the unusual case where the source document is less stable than … [Ballot comment] - I don't understand this paragraph: "The exception to this process is the unusual case where the source document is less stable than the target document, even if the target document is at a lower maturity level. In such cases, the above notation is omitted." So if there's a Experimental document that normatively references an Informational reference, but the Info document is though to be "more stable", we just don't annotate anything in the references section at all? To me, that seems more confusing than just explicitly stating something in the text. - s/docuemnt/document |
2022-10-24
|
04 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2022-10-24
|
04 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-kucherawy-bcp97bis-04 CC @evyncke Thank you for the work put into this document. Please find below some … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-kucherawy-bcp97bis-04 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Please note that Patrick Mevzek is the DNS directorate reviewer (at chairs' request) and you may want to consider his dns-dir reviews as well (mainly nits): https://datatracker.ietf.org/doc/review-kucherawy-bcp97bis-03-dnsdir-lc-mevzek-2022-10-16/ Special thanks to Erik Kline for the shepherd's detailed write-up. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Section 2 Suggest not to use the (too) old MD5 as an example... ### Section 4.1 s/A note is included in the reference text/An optional note is included in the reference text/ ? ### Section 5 In `it may not be freely available` should 'freely' be more descriptive ? I.e., behind a paywall ? or restricted publication to members only ? Suggest to use 'cost free' (or any more English wording) ``` Note that there is no requirement for a freely available copy of the reference beyond the publication of the draft as an RFC. ``` To be honest, I am a little puzzled with the above text: if a required/normative reference is no more available after publication, then how can the specification be implemented ? But, this depends what is meant by 'freely', if it means 'without any cost' then this is fine, if it means 'availably only to members of a 3rd party', then this is annoying to say the least. ### Section 6 How can authors find this 'downref registry'? Should it be documented/specified ? (to be honest, I have no clue as I rely on idnits...) ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2022-10-24
|
04 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2022-10-20
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2022-10-20
|
04 | Murray Kucherawy | [Ballot Position Update] New position, Recuse, has been recorded for Murray Kucherawy |
2022-10-20
|
04 | Erik Kline | Ballot has been issued |
2022-10-20
|
04 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2022-10-20
|
04 | Erik Kline | Created "Approve" ballot |
2022-10-20
|
04 | Erik Kline | IESG state changed to IESG Evaluation from Waiting for Writeup |
2022-10-20
|
04 | Erik Kline | Ballot writeup was changed |
2022-10-20
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2022-10-20
|
04 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-04.txt |
2022-10-20
|
04 | Murray Kucherawy | New version accepted (logged-in submitter: Murray Kucherawy) |
2022-10-20
|
04 | Murray Kucherawy | Uploaded new revision |
2022-10-18
|
03 | Cindy Morgan | Placed on agenda for telechat - 2022-10-27 |
2022-10-17
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-10-16
|
03 | Patrick Mevzek | Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Patrick Mevzek. Sent review to list. |
2022-10-10
|
03 | Jim Reid | Request for Last Call review by DNSDIR is assigned to Patrick Mevzek |
2022-10-10
|
03 | Jim Reid | Request for Last Call review by DNSDIR is assigned to Patrick Mevzek |
2022-10-05
|
03 | Pete Resnick | Request for Last Call review by ARTART Completed: Almost Ready. Reviewer: Pete Resnick. Sent review to list. |
2022-10-05
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2022-10-05
|
03 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-kucherawy-bcp97bis-03, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-kucherawy-bcp97bis-03, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2022-09-28
|
03 | Watson Ladd | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Watson Ladd. Sent review to list. |
2022-09-23
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2022-09-23
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2022-09-22
|
03 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Vijay Gurbani. Sent review to list. |
2022-09-21
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2022-09-21
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2022-09-21
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2022-09-21
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2022-09-20
|
03 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-03.txt |
2022-09-20
|
03 | Murray Kucherawy | New version accepted (logged-in submitter: Murray Kucherawy) |
2022-09-20
|
03 | Murray Kucherawy | Uploaded new revision |
2022-09-20
|
02 | Barry Leiba | Request for Last Call review by ARTART is assigned to Pete Resnick |
2022-09-20
|
02 | Barry Leiba | Request for Last Call review by ARTART is assigned to Pete Resnick |
2022-09-19
|
02 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-09-19
|
02 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-10-17): From: The IESG To: IETF-Announce CC: draft-kucherawy-bcp97bis@ietf.org, ek.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: … The following Last Call announcement was sent out (ends 2022-10-17): From: The IESG To: IETF-Announce CC: draft-kucherawy-bcp97bis@ietf.org, ek.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level' 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@ietf.org mailing lists by 2022-10-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document defines the procedure used in these circumstances. This document merges and updates, and thus obsoletes, RFC 3967, RFC 4897, and RFC 8067. 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. |
2022-09-19
|
02 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-09-19
|
02 | Cindy Morgan | Last call announcement was generated |
2022-09-18
|
02 | Erik Kline | Last call was requested |
2022-09-18
|
02 | Erik Kline | Last call announcement was generated |
2022-09-18
|
02 | Erik Kline | Ballot approval text was generated |
2022-09-18
|
02 | Erik Kline | Ballot writeup was generated |
2022-09-18
|
02 | Erik Kline | IESG state changed to Last Call Requested from AD Evaluation |
2022-09-18
|
02 | Erik Kline | # Document Shepherd Write-Up for draft-kucherawy-bcp97bis *This shepherd writeup version is dated 4 July 2022.* ## Document History 1. Was the document considered in any … # Document Shepherd Write-Up for draft-kucherawy-bcp97bis *This shepherd writeup version is dated 4 July 2022.* ## Document History 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there? It was discussed on ietf@ first: https://mailarchive.ietf.org/arch/browse/ietf/?q=draft-kucherawy-bcp97bis where is was suggested to go to gendispatch. The discussion there: https://mailarchive.ietf.org/arch/browse/gendispatch/?q=draft-kucherawy-bcp97bis yielded "AD sponsorship is fine". 2. Was there controversy about particular points that caused the WG to not adopt the document? No. This being a process document the impetus was largely that it should go through a dispatch process. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Not applicable. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. Not applicable. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. Not applicable. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? Not applicable. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. Not applicable. The id-nits tool reports no real issues (see also #14 below). ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? - None. - None. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? - BCP. - Because it is a bis and merge of 3 other documents that form BCP 97. - Yes. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. No known IPR claims. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) No nits of note. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? None. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. None. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? None. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. - It will obsolete RFCs 3967, 4897, and 8067. - Noted on the title page, mentioned in the abstract and in the introduction. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). Not applicable. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. Not applicable. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-09-17
|
02 | Erik Kline | IESG state changed to AD Evaluation from Publication Requested |
2022-09-08
|
02 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-02.txt |
2022-09-08
|
02 | Murray Kucherawy | New version accepted (logged-in submitter: Murray Kucherawy) |
2022-09-08
|
02 | Murray Kucherawy | Uploaded new revision |
2022-01-20
|
01 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2022-01-20
|
01 | Erik Kline | Note added 'AD-sponsored update to BCP97 documents.' |
2022-01-20
|
01 | Erik Kline | IESG process started in state Publication Requested |
2022-01-08
|
01 | Erik Kline | [S4.2; comment] * The "Downref Registry" mention here could have a forward reference to S7. [S9; question] * Is the downref registry URL worth including? … [S4.2; comment] * The "Downref Registry" mention here could have a forward reference to S7. [S9; question] * Is the downref registry URL worth including? I would assume that https://datatracker.ietf.org/doc/downref/ is stable enough to be referenced but perhaps it's not important. |
2021-12-05
|
01 | Erik Kline | Notification list changed to ek.ietf@gmail.com because the document shepherd was set |
2021-12-05
|
01 | Erik Kline | Document shepherd changed to Erik Kline |
2021-10-17
|
01 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-01.txt |
2021-10-17
|
01 | (System) | New version approved |
2021-10-17
|
01 | (System) | Request for posting confirmation emailed to previous authors: Murray Kucherawy |
2021-10-17
|
01 | Murray Kucherawy | Uploaded new revision |
2021-10-07
|
00 | Murray Kucherawy | Shepherding AD changed to Erik Kline |
2021-10-07
|
00 | Murray Kucherawy | Changed consensus to Yes from Unknown |
2021-10-07
|
00 | Murray Kucherawy | Intended Status changed to Best Current Practice from None |
2021-10-07
|
00 | Murray Kucherawy | Stream changed to IETF from None |
2021-10-04
|
00 | Murray Kucherawy | New version available: draft-kucherawy-bcp97bis-00.txt |
2021-10-04
|
00 | (System) | New version accepted (logged-in submitter: Murray Kucherawy) |
2021-10-04
|
00 | Murray Kucherawy | Uploaded new revision |