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://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://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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416485170%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I6auUL7M9DDDZp14LcBDnWVBlGPPD4FG4WlWMIqZvkc%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416512768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tjJgql59KHPZSRuYWIV1tdmpuRVGsDodJNJNhRcGT1U%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416530816%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UowMFCSPyFYlrC87kQGmOlbCHPOd9KoX3NyMycM1%2B6k%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416548144%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9NDQjzxadrLWAslVBfTM2u8EImxyXmbecFw8iUf4ub4%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://cddl.anweiss.tech/ and 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://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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416565053%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EsVGCbBNmsdH5Dv6Bjj5YotfFGZa2XA4Nc0I1EL1v0A%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416581085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VEn8%2B02%2ByoJ2dMuOyWcURVLxH9iB9UwHHdJz0zwN2%2BI%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416597444%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BQVrRa9PZ%2F6KrYjeFiWv4NHUA2%2Fhy%2B10OZ0af8uAFGU%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://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/
>
> [3] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/
>
> [4] 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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416613602%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p%2BVCeYVy9WqUjpiIiddLswCvpSljoaFWScSXpbP3kCE%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416629769%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=btPUg%2BU0FQjcvHX9IVqmXCH3cCgqKw07f%2BOR6Ry3%2FjY%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416645770%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VKFqc%2BOqHD0ShdyTKYZ7FWyLxxcNLZvlDuQ5cwB2d2w%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416663753%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OHCn3uwBaoNLiQg5troezoJwOa38oFbb2Kk%2BfZt9OlM%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416680824%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=POpqbVn0BY6%2BkUHDx8LMsUeRZPuHNcqOH4pBlFdwvnU%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%7C9fddd8210bec4fc3541508de8a7d2d39%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639100467416695987%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r5sv4wCR8yWXcDbYjeOfHdZ7idd3niCCW8NtO0q2EkM%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]
