Hi Carsten, Not sure I would link the tooling vs asking to have the exact section to look into.
The reference clause is meant to provide a normative/information source for a specific behavior modeled. Providing precisely where to look is superior compared to providing vague/generic reference entries. This helps navigate through the module and external documentation. Cheers, Med (no AD Fez) > -----Message d'origine----- > De : Carsten Bormann <[email protected]> > Envoyé : mercredi 18 février 2026 17:05 > À : Kent Watsen <[email protected]> > Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Objet : Re: [netmod] AUTH48: RFC-to-be 9907 <draft-ietf-netmod- > rfc8407bis-28>: RFCs without titles > > > On Feb 18, 2026, at 16:58, Kent Watsen <[email protected]> > wrote: > > > > 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"/>) > > The RFC ecosystem now has “relative references” (deep references > into a document referenced in the References), which can be used > for “Section references”. > > I generally recommend that these be used as much as possible to > make the RFCs that employ them more usable. > However, YANG models are included as code blocks (<sourcecode > element), which do not provide for any internal markup of the text > in the code block. > If they did, I would argue for using section references as much as > possible, but I can’t. > > Grüße, Carsten ____________________________________________________________________________________________________________ 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]
