Hi Gavin, Thank you for your reply!
Regarding your question, I did have to add the following to the normative references section so that the XML could parse. So feel free to copy this and add it to your new version submission: <referencegroup anchor="STD95" target="https://www.rfc-editor.org/info/std95/";> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7480.xml"/ <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7481.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9082.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9224.xml"/> </referencegroup> You're right that you can't use "Section X of [STD95]", because that's not possible. But you can reference the entire STD or specific section numbers of the RFCs in the reference group. Thank you for asking and also for updating! Sarah Tarrant RFC Production Center > On May 22, 2026, at 4:32 AM, Gavin Brown <[email protected]> wrote: > > Greetings! > > Answers (and a question) below. > > On Thu, 21 May 2026, at 22:41, [email protected] wrote: >> Author(s), >> >> Congratulations, your document has been successfully added to the RFC >> Editor queue! >> The team at the RFC Production Center (RPC) is looking forward to >> working with you >> as your document moves forward toward publication. To help reduce >> processing time >> and improve editing accuracy, please respond to the questions below. >> Please confer >> with your coauthors (or authors of other documents if your document is >> in a >> cluster) as necessary prior to taking action in order to streamline >> communication. >> If your document has multiple authors, only one author needs to reply >> to this >> message. >> >> As you read through the rest of this email: >> >> * If you need/want to make updates to your document, we encourage you >> to make those >> changes and resubmit to the Datatracker. This allows for the easy >> creation of diffs, >> which facilitates review by interested parties (e.g., authors, ADs, doc >> shepherds). >> * If you feel no updates to the document are necessary, please reply >> with any >> applicable rationale/comments. > > One nit raised during IESG was about referencing RFCs that are part of a BCP. > I am unclear on how to do it in the xml2rfc syntax, and would appreciate your > advice, especially where I use the "section" and "sectionFormat" attributes > of <xref> elements. > > The feedback can be seen here (point 2 in Med’s email): > > https://mailarchive.ietf.org/arch/msg/regext/gAYbNWWFhnusWi1yTF67Xhx51gw/ > > Once I know how to mark this up I will submit a new version which addresses > both of Med’s nits. > >> [snip] >> >> 1) As there may have been multiple updates made to the document during >> Last Call, >> please review the current version of the document: >> >> * Is the text in the Abstract still accurate? > > Yes. > >> * Are the Authors' Addresses, Contributors, and Acknowledgments >> sections current? > > Yes. > >> 2) Please share any style information that could help us with editing your >> document. For example: >> >> * Is your document's format or its terminology based on another document, >> WG style guide, etc.? If so, please provide a pointer to that information >> (e.g., "This document's terminology should match DNS terminology in >> RFC 9499." or "This document uses the style info at >> <https://httpwg.org/admin/editors/style-guide>."). > > This document uses terminology from RFC 9803. > >> * Is there a general pattern of capitalization or formatting of terms that >> editors can follow (e.g., "Field names should have initial capitalization." >> or "Parameter names should be in double quotes." or "<tt/> should be used >> for token names." etc.)? > > I have used <tt> tags around tokens, property names etc inline in paragraph > text. > >> 3) Please carefully review the entries and their URLs in the >> References section with the following in mind. Note that we will >> update as follows unless we hear otherwise at this time: > > References all checked and LGTM. > >> 4) Is there any text that requires special handling? For example: >> * Are there any sections that were contentious when the document was drafted? > > None. > >> * Are any sections that need to be removed before publication marked as such > > Yes, there are a couple and these are marked. > >> (e.g., Implementation Status sections (per RFC 7942)). >> * Are there any instances of repeated text/sections that should be edited >> the same way? > > No. > >> 5) This document uses one or more of the following text styles. >> Are these elements used consistently? >> >> * fixed width font (<tt/> or `) >> * italics (<em/> or *) >> * bold (<strong/> or **) > > Yes, they should be. > >> 6) This document contains sourcecode: >> >> * Does the sourcecode validate? > > I noticed a minor issue which I will fix in the next version. The corrected > versions validate using the two publicly available RDAP validation tools. > >> * Some sourcecode types (e.g., YANG) require certain references and/or text >> in the Security Considerations section. Is this information correct? > > Not applicable. > >> * Is the sourcecode type indicated in the XML? (See information about >> types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) > > The two <sourcecode> elements both contain JSON, but they don’t currently > have the “type” attribute. I will add them in the next version. > >> 7) Is there anything else that the RPC should be aware of while editing this >> document? > > Nothing comes to mind. > > Thanks! > > G. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
