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:59 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 11:12 PM > To: Marco Tiloca <[email protected]>; Göran Selander > <[email protected]>; Francesca Palombini > <[email protected]>; > [email protected]<[email protected]>; Rikard Höglund > <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected]<[email protected]>; [email protected] > <[email protected]>; [email protected] > <[email protected]> > Subject: Document intake questions about <draft-ietf-core-oscore-groupcomm-28> > 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 entries of Marco Tiloca and > Rikard Höglund: > > Isafjordsgatan 22 > SE-16440 Stockholm Kista > > * Please remove the following two lines from the entries of Göran Selander, > Francesca Palombini, and John Preuß Mattsson: > > Torshamnsgatan 23 > 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 > > We can think of the following points. > > - Format: to the best of our knowledge, it is not based on an existing > document. There is a conceptual correspondence between some sections of the > present document and some sections of RFC 8613. > - Terminology: see Section 1.1. The terminology of RFC 7252 and of RFC 8613 > is key here. > - Capitalization generally follows the document from which it is imported (if > imported). See, for examples, terms imported from RFC 8613. > - "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 capitalized when they identify parameters or > keying material (e.g., "Pairwise Sender Key", "parameter Authentication > Credential Format"). Notably, "Group Manager" is also capitalized. Other new > terms used in plain prose are usually not capitalized (e.g., "keying > material", "silent server", "group mode", "pairwise mode"). Hopefully, the > current text is consistently using capitalization as intended. > - Some words are surrounded by single quotes (i.e., 'foo'), when referring to > a parameter within a message. E.g., see 'kid context', 'kid', and 'Partial > IV' when referring to such parameters in CoAP request/response messages or in > a COSE message. > - Letters in hexadecimal notation are 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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872472099%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3N0Ds9%2Faf2jxaASgIPk7kiae%2FL%2BKPLdiGucsKXlCaG8%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872493909%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jM07fwPGUMkjP1nqGCF3ASqtUV2TPt5GqhbWvsZ8ZXk%3D&reserved=0> > with your document and reporting any issues to them. > > ==>MT > > The current references do not include an obsoleted RFC or a replaced Internet > Draft. > > The current reference [NIST-800-56A] from another organization should already > be up-to-date. As announced at [0], NIST has recently decided to produce a > new version of that specification, but the timeline for such an update is not > clear to us. > > [0] > https://www.nist.gov/news-events/news/2026/01/nist-update-special-publication-800-56a-and-revise-800-56c > > <== > > > 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. > > Section 13 "Implementation Status" and Appendix E "Document Updates" have to > be removed, as noted in their first line. > > As noted at the beginning of Section 13, removing that section should be > followed by removing RFC 7942 from the list of references. > > Sections 4.3.1 and 4.3.2 intentionally have a similar structure, which is > good to preserve. > > <== > > > 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 **) > > ==>MT > > We believe so. That should be limited to <tt/>, when indicating the CBOR > simple value null, true, or false. > > <== > > > 6) This document contains sourcecode: > > * Does the sourcecode validate? > * Some sourcecode types (e.g., YANG) require certain references and/or text > in the Security Considerations section. Is this information correct? > * Is the sourcecode type indicated in the XML? (See information about > types: > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types&data=05%7C02%7Cmarco.tiloca%40ri.se%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872509582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dWAWx7XdrAReL5dSQNXIwT6QA5roWZKpgfLnwRt%2BXRQ%3D&reserved=0.) > > ==>MT > > The document contains the following six snippets of sourcecode. > > * Section 3.4 (1 instance) > > Figure 2 consists of CDDL sourcecode, which has been validated using the > online tool at https://cddl.anweiss.tech/ > > In the XML, the sourcecode is correctly indicated as such, see the > "artwork" element including type="CDDL". Not sure whether "CDDL" is > equivalent to "cddl" in the official list of sourcecode types. (Also not sure > if and how the "sourcecode" element should also be used) > > * Section 4.2 (1 instance) > > Within the third bullet point, there is CDDL sourcecode for the array info. > This sourcecode has been validated using the online tool at > https://cddl.anweiss.tech/ > > In the XML, the sourcecode is correctly indicated as such, see the > "sourcecode" element, with type="CDDL". Not sure whether "CDDL" is equivalent > to "cddl" in the official list of sourcecode types. > > * Section 4.3.1 (2 instances) > > Within the first and third bullet point, CBOR diagnostic notation is used. > This has been validated using the online tool at https://cbor.me/ > > In the XML, this is currently not indicated. In both instances, the > "artwork" element should include type="cbor-diag". (Not sure if and how the > "sourcecode" element should also be used) > > * Section 4.3.2 (2 instances) > > Within the first and third bullet point, CBOR diagnostic notation is used. > This has been validated using the online tool at https://cbor.me/ > > In the XML, this is currently not indicated. In both instances, the > "artwork" element should include type="cbor-diag". (Not sure if and how the > "sourcecode" element should also be used) > > > To the best of our knowledge, we do not have sourcecode types that require > certain references and/or text in the "Security Considerations" section. > > <== > > > 7) 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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872524802%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FCrxwULTg2xaVu4%2FOtydvaKS88KucdPjlbGiFlMs0vI%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872540044%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=51JtFTPKPECORDhSxE%2FeDqB7XlWpQZk0sl2WdJ%2FdhPE%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872558814%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XQ%2BiIDR%2Fyyypnpss6SOdJQIFcd0m1kLpuFSGO2L0hUg%3D&reserved=0 > > ==>MT > > Although it is not crucial, it feels more natural that one first reads the > other document in the cluster (i.e., draft-ietf-core-groupcomm-bis) as the > "message transfer document", and then the present document as the associated > "security document". > > So, if possible, it is preferable that the present document gets an RFC > number Y greater than the RFC number X assigned to > draft-ietf-core-groupcomm-bis-RFC-to-be. Ideally, Y = X + 1. > > We do not think that there is repeated text across the two documents in the > cluster. > > <== > > > 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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872574969%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bz%2BhJjXBgIJzuzWhj2uNgnA4Q2TEcnaC2jEbUt3jD%2Bg%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-oscore-groupcomm-28.xml > > draft-ietf-core-oscore-groupcomm-28.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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872590741%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FwYuSVa5w2KtP1dmTCkbYY%2BL1vElvMq6Y0I2v7lctj0%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 4:07 PM, [email protected] wrote: > > > > Author(s), > > > > Your document draft-ietf-core-oscore-groupcomm-28, 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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872606119%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sNEmsGwZr5yn9GgrGOMcCk7vAPYVz3nllDyUUX5CsYA%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872621337%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=asfMuPRfMPszkeYgkH2yL0uckS%2BfAUbK8SBdXZxM%2FBA%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872636778%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jrqHf6EGAsuliat9FLBOryktAreji9xe5RBSIaGVjXI%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535872652221%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i10o2P7urzDcab4mLBr1ZGh5Tv9lUJlHnnJXHBUyvwc%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535873020691%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BPSOTFm8jaGPkWPI%2BwTS7RX5KrQAHAyt9HFYnMv%2BWXs%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%7Ce4b4fbd73e404b14065a08de637165d2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057535873051329%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rFEBj%2FDa5Q83MSxhnHRE6PQjLoFsvXBy8UmJSwW4hZk%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-oscore-groupcomm-28.md> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
