Re: [auth48] AUTH48: RFC-to-be 9538 <draft-ietf-cdni-delegation-acme-04> for your review

[Alice Russo <[e-mail]>]

Authors,

This is a reminder that we await word from you regarding the questions below and this document's readiness for publication as an RFC. The files are here:

  https://www.rfc-editor.org/authors/rfc9538.html
  https://www.rfc-editor.org/authors/rfc9538.pdf
  https://www.rfc-editor.org/authors/rfc9538.txt
  https://www.rfc-editor.org/authors/rfc9538.xml (source)

Diff files of all changes from the approved Internet-Draft:
  https://www.rfc-editor.org/authors/rfc9538-diff.html 
  https://www.rfc-editor.org/authors/rfc9538-rfcdiff.html (side by side)

This page shows the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9538

Thank you.
RFC Editor/ar

> On Jan 22, 2024, at 10:57 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the
> following questions, which are also in the XML file.
> 
> 1) <!--[rfced] May this be rephrased as follows for readability?
> 
> Original:
>   RFC9115 allows delegating entities to remain in
>   full control of the delegation and be able to revoke it any time and
>   this avoids the need to share private cryptographic key material
>   between the involved entities.
> 
> Perhaps:
>   Per RFC 9115, delegating entities can remain in
>   full control of the delegation and can revoke it at any time.
>   This avoids the need to share private cryptographic key material
>   between the involved entities.
> -->
> 
> 
> 2) <!--[rfced] FYI, in Section 1.1, we added mention of "STAR" so that it
> is expanded upon first use. Please let us know if you prefer otherwise.
> (In the original, the first use was in Section 3 - "ACME STAR delegation"
> was followed by explanation but was without a direct expansion.)
> 
> Original:
>   It also uses
>   terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>   [RFC9115].
> 
> Current:
>   It also uses
>   terminology from Section 1.2 of [RFC8739] and Section 1.1 of
>   [RFC9115], including Short-Term, Automatically Renewed (STAR),
>   as applied to X.509 certificates.
> -->
> 
> 
> 3) <!--[rfced] How may this sentence be rephrased for clarity? In particular,
> "allows to specify" is not clear. Also, Section 2.3.1.3 of RFC 9115
> indicates that the CNAME mapping is optional; should this sentence be
> updated to reflect that?
> 
> Original:
>      |   Note: The delegation object defined in Section 2.3.1.3 of
>      |  [RFC9115] only allows to specify DNS mappings using CNAME RRs.
> 
> Perhaps:
>      |   Note: The delegation object defined in Section 2.3.1.3 of
>      |  [RFC9115] only allows DNS mappings to be specified using CNAME RRs.
> 
> Or:
>      |   Note: The delegation object defined in Section 2.3.1.3 of
>      |  [RFC9115] allows DNS mappings to be specified using only CNAME RRs.
> -->
> 
> 
> 4) <!--[rfced] FYI, for readability and precision, we have made the following
> updates: split this into two sentences, changed "criticality around"
> to "criticality of", and changed "which" to "this account".
> Please review and let us know if you prefer otherwise.
> 
> Original:
>   The reader is expected to understand the ACME delegation trust model
>   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>   [RFC9115]), in particular the criticality around the protection of
>   the user account associated with the delegation, which authorizes all
>   the security relevant operations between dCDN and uCDN over the ACME
>   channel.
> 
> Current:
>   The reader is expected to understand the ACME delegation trust model
>   (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of
>   [RFC9115]).  In particular, the reader is expected to understand the
>   criticality of the protection of the user account associated with the
>   delegation; this account authorizes all the security-relevant
>   operations between a dCDN and a uCDN over the ACME channel.
> -->
> 
> 
> Thank you.
> 
> RFC Editor/ar
> 
> 
> On Jan 22, 2024, [e-mail] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2024/01/22
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>  Please review and resolve any questions raised by the RFC Editor 
>  that have been included in the XML file as comments marked as 
>  follows:
> 
>  <!-- [rfced] ... -->
> 
>  These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>  Please ensure that you review any changes submitted by your 
>  coauthors.  We assume that if you do not speak up that you 
>  agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>  Please review the full content of the document, as this cannot 
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
> 
> *  Copyright notices and legends
> 
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions 
>  (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>  Please review the markup in the XML file to ensure that elements of  
>  content are correctly tagged.  For example, ensure that <sourcecode> 
>  and <artwork> are set correctly.  See details at 
>  <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>  Please review the PDF, HTML, and TXT files to ensure that the 
>  formatted output, as generated from the markup in the XML file, is 
>  reasonable.  Please note that the TXT will have formatting 
>  limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>  *  your coauthors
> 
>  *  [e-mail] (the RPC team)
> 
>  *  other document participants, depending on the stream (e.g., 
>     IETF Stream participants are your working group chairs, the 
>     responsible ADs, and the document shepherd).
> 
>  *  [e-mail], which is a new archival mailing list 
>     to preserve AUTH48 conversations; it is not an active discussion 
>     list:
> 
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>    *  Note: If only absolutely necessary, you may temporarily opt out 
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you 
>       have dropped the address. When the discussion is concluded, 
>       [e-mail] will be re-added to the CC list and 
>       its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc9538.xml
>  https://www.rfc-editor.org/authors/rfc9538.html
>  https://www.rfc-editor.org/authors/rfc9538.pdf
>  https://www.rfc-editor.org/authors/rfc9538.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9538-diff.html
>  https://www.rfc-editor.org/authors/rfc9538-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>  https://www.rfc-editor.org/authors/rfc9538-xmldiff1.html
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9538
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9538 (draft-ietf-cdni-delegation-acme-04)
> 
> Title            : Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment
> Author(s)        : F. Fieau, Ed., S. Emile, S. Mishra
> WG Chair(s)      : Kevin J. Ma, Sanjay Mishra
> Area Director(s) : Murray Kucherawy, Francesca Palombini
>