Hello Sarah, That's correct. In other words:
* The whole Appendix B and its content are to be removed. * Section 1.2 is ultimately intended to keep only its first paragraph. Thanks, /Marco ________________________________ From: Sarah Tarrant <[email protected]> Sent: Thursday, March 26, 2026 8:45 PM To: Marco Tiloca <[email protected]> Cc: Rikard Höglund <[email protected]>; [email protected] <[email protected]>; Francesca Palombini <[email protected]>; [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: Re: Document intake questions about <draft-ietf-ace-oscore-gm-admin-16> has been added to the RFC Editor queue Hi Marco, Thank you for the detailed reply. We are currently awaiting AD approval of version -17. In the meantime, we've logged your intake form answers and have one additional question: Q: In Appendix B, there is a note to the RFC Editor about removing the section. This section includes an artwork element that is referenced in Section 1.2, which also includes a note about removing a paragraph. Just to be clear, the following are to be removed: Appendix B, the artwork element in Appendix B, and the following paragraph in Section 1.2: In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 3 of Appendix B. For example, {e'group_name': "gp1", e'gp_enc_alg': 10} stands for {-13: "gp1", -4: 10}. Please let me know. Thank you, Sarah Tarrant RFC Production Center > On Mar 26, 2026, at 1:54 PM, Marco Tiloca <[email protected]> wrote: > > Hello Sarah, > > Please find our answers inline below. > > > In addition to those, please note that we have just submitted a new version > -17 of the present document, with one clarifying update in Section 1.1 > "Terminology" and two clarifying updates in Section 3 "Format of Scope". > > The three updates are related to changes made in the approved version -21 of > [ACE-KGO], based on the corresponding IESG evaluation review from Mike Bishop > and addressed in Sections 3 and 8 of that document, see > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2FZuhDaBhAeZjwCdEsgsIbe7wfdYw%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331212819%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0%2BdY8VP0JfbQikQiKb%2FdBx8WmR7eu2m7xbLQsd82Nw%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/ace/ZuhDaBhAeZjwCdEsgsIbe7wfdYw/> > > Two of those comments about [ACE-KGO] are also relevant and applicable to > version -16 of the present document, which was already approved for > publication when we received those comments. > > [ACE-KGO] > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm-oscore%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331238525%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Bh1DkKaKMYt9X2oTecSpFHEXas%2FjlTmRzQCdu38FXsM%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/> > > Please see below the three updates in question, now incorporated in the > latest version -17 of the present document. > > **Update #1 (Section 1.1)** > > OLD > > The url-path to a group-configuration resource has GROUPNAME as last > > segment, with GROUPNAME the invariant group name assigned upon its > > creation. Building on the considered url-path of the group-collection > > resource, this document uses /manage/GROUPNAME as the url-path of a > > group-configuration resource; implementations are not required to use this > > same construct and can define their own instead. > > NEW (emphasis mine) > > The url-path to a group-configuration resource has GROUPNAME as last > > segment, with GROUPNAME the invariant group name assigned upon its > > creation. **Aligned with that, a group name has to be consistent with the > > semantics of URI path segments (see Section 3.3 of [RFC3986]).** Building > > on the considered url-path of the group-collection resource, this document > > uses /manage/GROUPNAME as the url-path of a group-configuration resource; > > implementations are not required to use this same construct and can define > > their own instead. > > Rationale: Explicitly state that a group name (referred to as GROUPNAME in > the document) is restricted to URI-safe characters. This is just a > clarification of something that is effectively already required in the > document. > > **Update #2 (Section 3)** > > OLD > > - Literal pattern: "Toid" is specialized as a CBOR text string, whose value > > specifies an exact group name as a literal string. That is, only one > > specific group name expressed as a literal text string matches with this > > group name pattern. > > NEW > > - Literal pattern: "Toid" is specialized as a CBOR text string, whose value > > specifies an exact group name as a literal string. That is, only one > > specific group name expressed as a literal text string matches with this > > group name pattern. > > > > Consistent with the definition of group-configuration resource (see > > Section 1.1), the specified group name has to be consistent with the > > semantics of URI path segments (see Section 3.3 of [RFC3986]). > > Rationale: Explicitly state that a group name (referred to as GROUPNAME in > the document) is restricted to URI-safe characters. This is just a > clarification of something that is effectively already required in the > document. > > **Update #3 (Section 3)** > > OLD > > Future specifications that define new permissions on the admin resources at > > the Group Manager MUST register a corresponding numeric identifier in the > > "Group OSCORE Admin Permissions" registry defined in Section 11.4 of this > > document. > > NEW > > Future specifications that define new permissions on the admin resources at > > the Group Manager must register a corresponding numeric identifier in the > > "Group OSCORE Admin Permissions" registry defined in Section 11.4 of this > > document. > > Rationale: It does not make sense to apply normative requirements to future > specifications. Hence, we changed the text to use "must" instead of "MUST". > > > Finally, we have also: > > * Ensured that CDDL sourcecode snippets are marked as such in the XML file. > > * Fixed the "Note to RFC Editor" final paragraph in Section 1.2, to be > formatted as plain text instead of as a quote. > > > Best, > /Marco > > From: Sarah Tarrant <[email protected]> > Sent: Wednesday, March 25, 2026 3:45 PM > To: Marco Tiloca <[email protected]>; Rikard Höglund <[email protected]>; > [email protected]<[email protected]>; Francesca Palombini > <[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-ace-oscore-gm-admin-16> > has been added to the RFC Editor queue > 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 text in the Abstract is accurate. > > The content of the sections "Acknowledgments" and "Authors' Addresses" is > accurate. > > <== > > > 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fadmin%2Feditors%2Fstyle-guide&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331255679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xfj%2FhOqqMqXGj%2FU58z9cT3rdS26rRxZY8l2h2l3tQC4%3D&reserved=0>.<https://httpwg.org/admin/editors/style-guide>"). > * 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.)? > > ==>MT > > We can think of the following points. > > - Format: there is a conceptual and structural correspondence between some > sections of the present document and some sections of > draft-ietf-ace-key-groupcomm-oscore. This especially holds for: > > - Section 3 "Format of Scope" of the present document and Section 3 "Format > of Scope" of the other document (the former builds on and extend the data > model defined in the latter). > > - Section 7 "ACE Groupcomm Parameters" of the present document and Section > 12 "ACE Groupcomm Parameters" of the other document. > > - Section 8 "ACE Groupcomm Error Identifiers" of the present document and > Section 13 "ACE Groupcomm Error Identifiers" of the other document. > > - Terminology: see Section 1.1. This document largely uses the terminology > from RFC 9200, RFC 7252, and RFC 8613, as well as from > draft-ietf-core-groupcomm-bis, draft-ietf-core-oscore-groupcomm, > draft-ietf-ace-key-groupcomm-oscore (also in the same cluster C564). > > - Capitalization generally follows the document from which it is imported (if > imported). See, for example, terms imported from RFC 8613, > draft-ietf-core-oscore-groupcomm, and draft-ietf-ace-key-groupcomm-oscore. > Some terms defined in RFC 9200 use a different capitalization, e.g., "Client" > and "Resource Server" are used in their uppercase version. This is consistent > with how those terms are used in draft-ietf-ace-key-groupcomm-oscore, which > in turn aligns with RFC 9594 that it builds on. In such cases, we think that > it is more appropriate for this document to use the same capitalization > (uppercase version). Finally, the word "Administrator" is also used in its > uppercase version, consistent with the same choice for "Group Manager". > > - Some words are surrounded by single quotes (i.e., 'foo'), when referring to > a parameter within group configurations or within a message. E.g., see > 'group_mode', 'group_name', etc. when referring to such parameters within > exchanged messages. This is consistent with > draft-ietf-ace-key-groupcomm-oscore, which in turn builds on RFC 9594. > > - Letters in hexadecimal notation are lowercase. > > <== > > > 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 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331271745%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HVxz6YNdmh1kq0LCw6asjw7xNVhly%2BXAkdkox3K7o1k%3D&reserved=0<https://author-tools.ietf.org/idnits>>. > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331287635%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xcs5asjFt2hK6zGPv02SOXnpBHNah%2B9Tx7pllukBxQM%3D&reserved=0<https://author-tools.ietf.org/idnits3/>> > with your document and reporting any issues to them. > > ==>MT > > There is one reference to an obsoleted RFC, i.e., RFC 6347. This is > intentional: Section 1.1 of this document mentions both DTLS 1.2 (RFC 6347) > and DTLS 1.3 (RFC 9147) as possible versions of DTLS that can be used in the > DTLS transport profile of ACE (RFC 9202). Therefore, please keep both the > reference to RFC 6347 and the reference to RFC 9147 obsoleting the former. > > <== > > > 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 B "CDDL Model" and Appendix C "Document Updates" have to be removed, > as noted in their first line. Before Appendix B can be removed, the actions > described in the last paragraph of Section 1.2 "Notations" need to be > performed. > > The following sections intentionally share similarities in structure and > style, which is good to preserve: > > * Sections 5.1.1 and 5.1.2. > * Sections 5.2.1 and 5.2.2. > * Sections 6.1-6.8. > * Sections 7 and 8. > * Sections 11.1-11.3. > > <== > > > 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/>, e.g.: when indicating the > CBOR simple value null, true, or false; or when denoting endpoints > (resources) such as /token at the AS or /authz-info at the RS. > > <== > > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331303659%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PRp9b3fJXspFQjyJrfVHMgvsxaZ7vj%2B7fu9OBDS3V0g%3D&reserved=0.)<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types> > > ==>MT > > The document contains snippets of sourcecode in CDDL and CBOR diagnostic > notation. In the XML, they are all correctly indicated as such, see the > "sourcecode" element, with type="cddl" or type="cbor-diag". The snippets have > been successfully validated using the online tools at > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcddl.anweiss.tech%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331320531%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ghqcNd38Lp8VDzY3Nh12MshLJVRmLLD1h4TWco78Gqc%3D&reserved=0<https://cddl.anweiss.tech/> > and > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcbor.me%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331338197%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VitA7n144EY7WpkrP6wIWbIM7nCZQ46rz4yVgHd5AlA%3D&reserved=0<https://cbor.me/> > > 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 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%2Fthat&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331354473%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d9x9%2FTNoNXKb3VPrqE%2FJ1n2DMKWIBeyj%2FZ%2FLyYtzrqM%3D&reserved=0<https://github.com/martinthomson/i-d-template/that> > we have regularly used. > > The only SVG figure (Figure 1 in Section 2.1) matches the ASCII art used in > the text output, and it fits into a single page of the PDF output. > > <== > > > 8) 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331370632%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z1UNM0MJoC8%2FgzBN6h6ygqpXQgRepITZaoqXeWshekY%3D&reserved=0<https://www.rfc-editor.org/cluster_info.php?cid=C564> > > * 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331386462%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Qzz36GtiGIRQ1EKtk4yOyF8DOrFU%2BJgpTAqVFwsnQ9c%3D&reserved=0<https://www.rfc-editor.org/about/clusters/> > * 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331402236%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1n1H4iDJuLDrfE%2FqWxMfMBKWP%2Bi%2F65ncjR5tC8arH7U%3D&reserved=0<http://www.rfc-editor.org/all_clusters.php> > > ==>MT > > It is way more natural that one first reads the other three documents > [1][2][3] in the cluster, and then the present document [4]. > > If we define N_x as the RFC number for the document [x] in the cluster, we > believe that the following is preferable: N_1 < N_2 < N_3 < N_4. > > Ideally, the following is additionally preferable: > > * N_2 = N_1 + 1 > * N_4 = N_3 + 1 > > Similar considerations were provided when replying to the intake questions > about [1], [2], and [3]. > > We do not think that there is repeated text across the two documents in the > cluster. > > > [1] > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-groupcomm-bis%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331417658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hJb%2FgBFFkdT8LjGycTrVgRUcoEiQVmV7CDmwzVHugoo%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/> > > [2] > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-groupcomm%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331433686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FCaHVAKcdha6S5ZOq%2FA8VrfWv2r%2FPsiEEgxsMgNTwBo%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/> > > [3] > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm-oscore%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331450706%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BJ%2BUO7rqHnRjlzk%2BzYO7peR8O%2BA2qQHx8mCPclCPmwg%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/> > > [4] > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-oscore-gm-admin%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331467191%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TwJ4YoJ%2FFoY1F1%2F%2B2XnRxk61sGggc0DMl70YjPYuKAs%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/> > > <== > > > 9) Is there anything else that the RPC should be aware of while editing this > document? > > ==>MT > > Not really. Thanks! > > <== > > > > On Mar 13, 2026, at 3:52 PM, [email protected] wrote: > > > > Author(s), > > > > Your document draft-ietf-ace-oscore-gm-admin-16, 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331486073%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LAvmtlmowCssVrF5ycQvESibkL76vyZbK44oT4j2C%2FE%3D&reserved=0<https://www.rfc-editor.org/current_queue.php>>. > > > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331505621%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7KMLytm5L3PIwlUx3H1uCIUMdXu3DmlO9fbH3D%2Bo09Q%3D&reserved=0<https://datatracker.ietf.org/submit/>>, > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331521698%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Fk1j3ObXy5yFfxnngaQ8ShjEWPLK7AAhw8tvVzPSLgI%3D&reserved=0<https://www.rfc-editor.org/pubprocess/how-we-update/>>. > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331537937%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0ff62hjmpvfQH0K9BK4g%2FUKwkwjNbDkFW3AxVD2ujpM%3D&reserved=0<https://www.rfc-editor.org/styleguide/>>). > > > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331554143%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jLgjU3XH8b7OpxPFhfvWXXwkExSzjJhYW9Vi%2FXKYl6Q%3D&reserved=0<https://www.rfc-editor.org/current_queue.php>>. > > > > 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%7Cc86e7f80213f4c5e930c08de8b7039fb%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639101511331570516%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8ovJcXPlZgTf%2F56TW5U6%2B1JyDjvv%2F1EDUiQzA9m705E%3D&reserved=0<https://www.rfc-editor.org/about/queue/>>). > > 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 > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
