Hi Marco, Thanks for the heads up! We've updated to the new files and will continue processing version -18 as normal.
Sincerely, Sarah Tarrant RFC Production Center > On Feb 10, 2026, at 4:09 PM, Marco Tiloca <[email protected]> wrote: > > Hello Sarah, > > Following an exchange with IANA, we have just submitted version -18. > > The only change is the addition of one sentence at the beginning of Section 7 > "IANA Considerations", saying: > > "This document has no actions for IANA." > > Please find also attached to this mail the corresponding markdown source > (with the includes performed), directly extracted from the RFCXML. > > Best, > /Marco (for the author team) > > From: Sarah Tarrant <[email protected]> > Sent: Thursday, February 5, 2026 5:35 PM > To: Marco Tiloca <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]> > Subject: Re: Document intake questions about > <draft-ietf-core-groupcomm-bis-17> > 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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375773442%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I822pcphYvKkGFZMLOBA2W5adzcIBKo%2F17tLjzN8eDE%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375806075%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QWpMNo1qz9ChroAiASgMfIa0Tzez9PqBllziHaCFCP4%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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmartinthomson%2Fi-d-template%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375833021%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u9EuRwFEPFTRXm7B781YQI5hApDQ7xCLoLITZr4Y0oU%3D&reserved=0 > > 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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375856448%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9uvkFsG1HyZxbYuSpBcEHtfz5p6fngO9tVcFAGfe%2B4E%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375878291%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZBuggYdTEYIW4lHKzf9kGr03vzXLHorMEDDDHDyZZwc%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375896508%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ym%2B1GiqvteSp2WhIi2S8v6AhTzIho7QD9vW27YPMloc%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375914029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JijHTSbb7m7XqaxgR4pEU36HINoaZshsPy1JXekEpcM%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375931937%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lAKhL88KF1BYRY2X1c62d2U4iPH51WK2fe8JizJvy50%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375950250%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uNbjq92zmGDGt1oinx0Y0jVywef5NjVYWr3A05q7iPA%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375968450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HJt0WcofjmPGTcswCjzqH5%2B%2Bkghh26yv98huIbG%2F0u4%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061375991395%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Uqo9QhTDIFCMx%2FMFuWZZokyAcsNrkuKJgLAf7vpvrb4%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061376014553%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vfZScQnpWxU8793BS2s01CQi%2FoQjYmX05td%2BqJcOwsw%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061376037480%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GV14d3vkXuILNW26jq2ngIZkX4HffEEMuq9MK%2FLWcBk%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061376057255%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=15gATX2BnHorUXc1xassms7%2FS4dEx5Vkp6oP0btl6SU%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%7Ce03631b6552f4ddcc8ac08de64d49380%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639059061376074187%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QlxVlSAy4d%2B%2BmhJFsV5Z4EPPvoBNadI2BdmlDjg%2BZ8w%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> > > <draft-ietf-core-groupcomm-bis-18.md> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
