Hi Marco, Thank you for the detailed response! The markdown looks great. We'll contact you if we need any further clarification.
Sincerely, Sarah Tarrant RFC Production Center > On Feb 5, 2026, at 8:49 AM, Marco Tiloca <[email protected]> wrote: > > Hello Sarah, > > Thanks for your mail! > > Please find our replies inline below. > > Best, > /Marco (for the author team) > From: Sarah Tarrant <[email protected]> > Sent: Tuesday, February 3, 2026 10:55 PM > To: [email protected] <[email protected]>; Marco Tiloca > <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected]<[email protected]> > Subject: Document intake questions about <draft-ietf-core-groupcomm-bis-17> > 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. > > > Please note that the RPC team will not work on your document until we hear > from you > (that is, your document will remain in AUTH state until we receive a reply). > Even > if you don't have guidance or don't feel that you need to make any updates to > the > document, you need to let us know. After we hear from you, your document will > start > moving through the queue. You will be able to review and approve our updates > during AUTH48. > > Please feel free to contact us with any questions you may have at > [email protected]. > > Thank you! > The RPC Team > > -- > > 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? > * Are the Authors' Addresses, Contributors, and Acknowledgments > sections current? > > ==>MT > > The abstract and the "Acknowledgments" section look good. > > As to the "Authors' Addresses" section, please remove the following two lines > from the entry of Marco Tiloca: > > Isafjordsgatan 22 > SE-16440 Stockholm Kista > > <== > > > 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? > If so, please provide a pointer to that document (e.g., this document's > terminology should match DNS terminology in RFC 9499). > * Is there a pattern of capitalization or formatting of terms? (e.g., field > names > should have initial capitalization; parameter names should be in double > quotes; > <tt/> should be used for token names; etc.) > > ==>MT > > Please consider the input below. > > - Format: to the best of our knowledge, it is not based on an existing > document. However, we reuse elements from RFC 7390 that the present document > obsoletes. > - Terminology: See Section 1.2. The terminology of RFC 7252 is key here. > - Capitalization generally follows the document from which it is imported (if > imported). > - "Option" is capitalized when used together with the name of a CoAP option > and when referring to CoAP Options. (RFC 7252 does mostly the same) > - Terms that we introduce are not capitalized (usually) e.g., 'group URI', > 'security material', 'application group', 'security group', etc. > - Uppercase is used for constants. > - Uppercase is used for names that can be substituted with something, e.g., > 'APPNAME'. > - The hexadecimal notation for IPv6 address literals uses lowercase. > > <== > > > 3) Please review the entries in the References section carefully with > the following in mind. Note that we will update as follows unless we > hear otherwise at this time: > > * References to obsoleted RFCs will be updated to point to the current > RFC on the topic in accordance with Section 4.8.6 of RFC 7322 > (RFC Style Guide). > > * References to I-Ds that have been replaced by another I-D will be > updated to point to the replacement I-D. > > * References to documents from other organizations that have been > superseded will be updated to their superseding version. > > Note: To check for outdated RFC and I-D references, you can use > idnits > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fidnits&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702057962%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3zDkF%2BOKDtIx5Rvyb8RzaO%2B8a%2F6qXRgm%2BUIEJTAE%2F3k%3D&reserved=0>. > You can also help the > IETF Tools Team by testing idnits3 > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fidnits3%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702081574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wICac84sam%2BMX44G7VTh2oh9VBWTXf1OTpuGhm4Q8GM%3D&reserved=0> > with your document and reporting any issues to them. > > ==>MT > > Once published as an RFC, the present document will obsolete the referred RFC > 7390. However, the intention is clearly to keep that reference in the newly > published RFC. Besides that, the references do not include an obsoleted RFC. > > The references do not include a replaced Internet Draft. > > The references [IEEE802.15.4] and [UML] from other organizations should > already be up-to-date, and we do not foresee side-effects in the present > document if they were replaced with more recent, superseding ones. > > <== > > > 4) Is there any text that requires special handling? For example: > *Are there any sections that were contentious when the document was drafted? > *Are any sections that need to be removed before publication marked as such > (e.g., Implementation Status sections (per RFC 7942)). > *Are there any instances of repeated text/sections that should be edited > the same way? > > ==>MT > > We do not identify sections that have been contentious. > > Appendix G "Document Updates" has to be removed, as noted in its first line. > > Appendices B.1, B.2, and B.3 intentionally have a similar structure, which is > good to preserve. > > <== > > > 5) This document contains SVG. What tool did you use to make the svg? > > The RPC cannot update SVG diagrams, so please ensure that: > > * the SVG figures match the ASCII art used in the text output as closely as > possible, and > * the figures fit on the pages of the PDF output. > > ==>MT > > We used aasvg, as automatically invoked by the toolchain at > https://github.com/martinthomson/i-d-template/ that we have regularly used. > > The SVG figures match the ASCII art used in the text output. > > Figures 21 and 22 do not fit into a single page of the PDF format. Perhaps > recent updates in xml2rfc and the toolchain at large avoid an abrupt ending > of too long images? In the worst case, like done in RFC 9770, we can have > those two figures in pure ASCII instead of in SVG. They would still span > multiple pages, but the result should be acceptable and without an abrupt > ending. > > <== > > > 6) This document is part of Cluster 564: > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcluster_info.php%3Fcid%3DC564&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702098118%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UgQhKhYSH9%2FsAwqYH%2FVRciCbGTz6END%2BBztRK9Uq3NI%3D&reserved=0 > > * To help the reader understand the content of the cluster, is there a > document in the cluster that should be read first? Next? If so, please provide > the order and we will provide RFC numbers for the documents accordingly. > If order is not important, please let us know. > * Is there any text that has been repeated within the cluster document that > should be edited in the same way (for instance, parallel introductory text or > Security Considerations)? > * For more information about clusters, see > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fabout%2Fclusters%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702113772%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oVAK9fLx%2B5rWRonZxXGhNbwcHHFC8%2Fmjtf6%2FBAV%2F9BU%3D&reserved=0 > * For a list of all current clusters, see: > https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rfc-editor.org%2Fall_clusters.php&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702129467%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xqoJkEftZrn0xUFIXK2EmcjTpSSedrIZcpNu9D7Oyns%3D&reserved=0 > > ==>MT > > Although it is not crucial, it feels more natural that one first reads the > present document and then the companion "security document". So, if possible, > it is preferable that the present document gets an RFC number X lower than > the RFC number Y assigned to draft-ietf-core-oscore-groupcomm-RFC-to-be. > Ideally, Y = X + 1. > > We do not think that there is repeated text across the two documents in the > cluster. > > <== > > > 7) Because this document obsoletes RFC 7390 and updates RFCs 7252 and 7641, > please review > the reported errata and confirm whether they have been addressed in this > document or are not relevant: > > * RFC 7252 > (https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Frfc7252&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702145215%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a1trRKI0hUwOhPzFIR2f43olKEXGGZjjgpGyIPumd7c%3D&reserved=0) > > ==>MT > > The errata to RFC 7252 that are "Verified" or "Held for Document Update" are > not relevant for this document, which does not address those. Any other filed > errata is marked as "Rejected". > > <== > > > 8) Would you like to participate in the RPC Pilot Test for editing in > kramdown-rfc? > If so, please let us know and provide a self-contained kramdown-rfc file. For > more > information about this experiment, see: > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dpilot_test_kramdown_rfc&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702160763%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MdmqpUoeyh7W7ToIz5OCTf2zvDvZqZTlRHFThDR9W1k%3D&reserved=0. > > ==>MT > > Yes, we would like to participate. > > You can extract the markdown source (with the includes performed) from an > RFCXML directly submitted as such in the following way: > > kramdown-rfc-extract-markdown draft-ietf-core-groupcomm-bis-17.xml > > draft-ietf-core-groupcomm-bis-17.md > > Please find attached a markdown file extracted this way. > > <== > > > 9) Would you like to participate in the RPC Pilot Test for completing AUTH48 > in > GitHub? If so, please let us know. For more information about this experiment, > see: > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Drpc-github-phase-0-pilot-test&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702176256%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9IW4kEeMdFNE6LBTkC5Py%2BPhDO0R7gkOiJ%2BVLlGiy54%3D&reserved=0. > > ==>MT > > Yes. > > <== > > > 10) Is there anything else that the RPC should be aware of while editing this > document? > > ==>MT > > Not really. Thanks! > > <== > > > > On Feb 3, 2026, at 3:47 PM, [email protected] wrote: > > > > Author(s), > > > > Your document draft-ietf-core-groupcomm-bis-17, which has been approved for > > publication as > > an RFC, has been added to the RFC Editor queue > > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcurrent_queue.php&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702194884%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UI0wewwPs80jD0iF5o6udfN6%2FpQ9WmfswxmRyYz8zo4%3D&reserved=0>. > > > > If your XML file was submitted using the I-D submission tool > > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fsubmit%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702218181%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tpLfSRHbQqIElJ1EXPzdcR9h4RFA2abou0zVaEMrCPU%3D&reserved=0>, > > we have already retrieved it > > and have started working on it. > > > > If you did not submit the file via the I-D submission tool, or > > if you have an updated version (e.g., updated contact information), > > please send us the file at this time by attaching it > > in your reply to this message and specifying any differences > > between the approved I-D and the file that you are providing. > > > > You will receive a separate message from us asking for style input. > > Please respond to that message. When we have received your response, > > your document will then move through the queue. The first step that > > we take as your document moves through the queue is converting it to > > RFCXML (if it is not already in RFCXML) and applying the formatting > > steps listed at > > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fpubprocess%2Fhow-we-update%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702235313%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x5uCF6ZDL8XBeRDx9ZDKm2bTRDzWksZzsx6PnwLIrgA%3D&reserved=0>. > > Next, we will edit for clarity and apply the style guide > > (<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702250743%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5L%2FO7lGLOpkToeVM9gf%2BU8dRqoQT7vxypubotd1ouL8%3D&reserved=0>). > > > > You can check the status of your document at > > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcurrent_queue.php&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702265677%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iC%2FPzyaAAHHsPN0tvpPrniR4MCkj3lJ6vgegQBuE5xA%3D&reserved=0>. > > > > You will receive automatic notifications as your document changes > > queue state (for more information about these states, please see > > <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fabout%2Fqueue%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd0020c0bc3a04b6ad85608de636f0768%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057525702281025%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7COUGZtAcf3NptPZle%2FRzJlxEne%2BRSMKUXeWu39P0Qk%3D&reserved=0>). > > When we have completed > > our edits, we will move your document to AUTH48 state and ask you > > to perform a final review of the document. > > > > Please let us know if you have any questions. > > > > Thank you. > > > > The RFC Editor Team > > > > <draft-ietf-core-groupcomm-bis-17.md> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
