Hi Marco, Thank you!
Sincerely, Sarah Tarrant RFC Production Center > On Mar 26, 2026, at 2:59 PM, Marco Tiloca <[email protected]> wrote: > > 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, > /MarcoFrom: 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 > > > > 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 > > > > 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>."). > > * 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>. > > 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> > > 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.) > > > > ==>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 > > 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 > > > > 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 > > 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 > > > > * 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 > > * 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 > > > > ==>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 > > > > [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 > > > > [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 > > > > [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 > > > > <== > > > > > > 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>. > > > > > > 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>, > > > 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>. > > > 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>). > > > > > > 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>. > > > > > > 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>). > > > 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]
