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] 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]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
