Hi Kent, Thanks for sharing your thoughts.
As modules are consumed out of the documents that define them, having the full title isn’t an issue if it is not present. The reasoning is that what I expect from an implementer/reader is to use the RFC label/section as search entry to retrieve that content as needed (check a normative behavior, better digest a statement, check a claim, etc.). There is also an extra “cost” for authors in checking all titles (especially, for drafts that changes over time :-(). I expect the same is happening during the edit by RFC editor. At least, I don’t see nothing in the current guidance to say “don’t do that” to authors who decide to do so. A recent example I have seen is: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/. None of the three YANG Doctors and two ballots from OPS ADs raised this specific point as a concern. Cheers, Med (as contributor) De : Kent Watsen <[email protected]> Envoyé : mercredi 18 février 2026 16:59 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : [email protected] Objet : Re: [netmod] AUTH48: RFC-to-be 9907 <draft-ietf-netmod-rfc8407bis-28>: RFCs without titles As Shepherd, I'm aware that this item has already been dropped, and so responses to your message are no longer needed. That said, I want to respond anyway, in case it's proposed again. As a contributor, I do not think it is a good idea. Generally, I want the body of the text to state where in the target document each reference occurs, in a context-specific manner. For instance, a YANG "description" may have text like: "Do Foo as described in Section A of RFC XXXX or, if Bar, then do Baz as described in Section B of RFC XXXX". The only thing missing is a mapping from "RFC XXXX" to its title, for those who haven't memorized every RFC number. FWIW, this is the same strategy used in RFCs, where the text in the body of the document uses relative references (e.g., <xref section="A" target="RFCXXXX"/>) and the Normative/Informative sections contain the mapping from the label (e.g., RFCXXXX) to something meaningful. Kent On Feb 18, 2026, at 2:38 AM, [email protected]<mailto:[email protected]> wrote: Hi all, The document currently under AUTH48 (https://www.rfc-editor.org/authors/rfc9907.txt) includes the following NEW text to address this point discussed with the RFC Editor: 20) <!--[rfced] Would you like to add examples of "reference" substatements? The RPC and OPS ADs discussed this topic during IETF 123. The examples would show that the RFC title does not need to be included. (The exception is in the "revision" statement, where the title is typically included.) For example: reference (with section) "RFC 8665, Section 5 RFC 8666, Section 6"; reference (just RFC number) "RFC 8665 RFC 8666"; --> NEW: 3.9. References Sections … Except the "import" and "revision" statements, note that it is acceptable to reference RFCs with their labels and without expanding their titles. An example of such use is as follows: leaf site-of-origin { type rt-types:route-origin; description "The Site of Origin attribute is encoded as a Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site via a particular AC and is used to prevent routing loops."; reference "RFC 4364, Section 7"; } leaf ipv6-site-of-origin { type rt-types:ipv6-route-origin; description "The IPv6 Site of Origin attribute is encoded as an IPv6 Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site."; reference "RFC 5701"; } Are there objections from the WG to include that new text? Cheers, Med (as editor) ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
