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

[Alice Russo <[e-mail]>]

Frédéric,

Thank you for your prompt reply. The files have been updated accordingly.
Approvals are complete (as shown on the status page, https://www.rfc-editor.org/auth48/rfc9538); we will continue the publication process.

The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9538.html
  https://www.rfc-editor.org/authors/rfc9538.txt
  https://www.rfc-editor.org/authors/rfc9538.pdf
  https://www.rfc-editor.org/authors/rfc9538.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9538-diff.html
  https://www.rfc-editor.org/authors/rfc9538-rfcdiff.html (side by side)

Thank you.
RFC Editor/ar

> On Feb 8, 2024, at 10:11 AM, [e-mail] wrote:
> 
> Hi Alice,
> 
> I've checked the figure with scaling enabled. It looks good to me. I think we can safely enable scaling.
> 
> Thank you,
> 
> Regards,
> Frederic
> 
> 
> 
> Orange Restricted
> 
> -----Message d'origine-----
> De : Alice Russo <[e-mail]>
> Envoyé : jeudi 8 février 2024 19:06
> À : FIEAU Frédéric INNOV/NET <[e-mail]>; STEPHAN Emile INNOV/NET <[e-mail]>; Mishra, Sanjay <[e-mail]>
> Cc : Mishra, Sanjay <sanjay.mishra=[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; auth48archive <[e-mail]>
> Objet : question - Re: AUTH48: RFC-to-be 9538 <draft-ietf-cdni-delegation-acme-04> for your review
> 
> Authors,
> 
> Approvals are complete; however, we have a question regarding the SVG in Section 3:
> 
> The SVG has the width and height specified, which makes the artwork not scale. We suggest that scaling be enabled. Scaling will allow the figure to be resized when it is viewed on a mobile device; however, there may be aesthetic trade-offs (e.g., image may appear too large on a desktop screen).
> 
> Please review Figure 1 in the HTML and PDF files and let us know if they may be updated.
> 
> The current document (SVG does not scale):
>  https://www.rfc-editor.org/authors/rfc9538.html
>  https://www.rfc-editor.org/authors/rfc9538.pdf
>  https://www.rfc-editor.org/authors/rfc9538.xml (source)
> 
> vs. SVG without width and height:
>  https://www.rfc-editor.org/authors/test9538.html
>  https://www.rfc-editor.org/authors/test9538.pdf
>  https://www.rfc-editor.org/authors/test9538.xml (source)
> 
> Thank you.
> RFC Editor/ar
> 
>> On Feb 7, 2024, at 10:53 AM, [e-mail] wrote:
>> 
>> Hi Alice
>> 
>> I hope you are well.
>> 
>> I approve to the 4 new wording suggested below.
>> 
>> Tell me if you expect a more detailed answer.
>> 
>> Kind regards
>> Emile
>> 
>> 
>> 
>> From: Mishra, Sanjay <[e-mail]>
>> Sent: mercredi 7 février 2024 18:31
>> To: Alice Russo <[e-mail]>
>> Cc: FIEAU Frédéric INNOV/NET <[e-mail]>; STEPHAN
>> Emile INNOV/NET <[e-mail]>; Mishra, Sanjay
>> <sanjay.mishra=[e-mail]>; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> auth48archive <[e-mail]>
>> Subject: Re: [E] Re: AUTH48: RFC-to-be 9538
>> <draft-ietf-cdni-delegation-acme-04> for your review
>> 
>> Hi Alice - Thank you and please see response below for the 4 questions:
>> 
>> 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.
>> -->
>> Yes, I approve the new wording as suggested above
>> 
>> 
>> 
>> 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.
>> -->
>> 
>> Yes, I approve of the new wording as above.
>> 
>> 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.
>> 
>> Yes, I approve the above wording as suggested
>> 
>> 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.
>> 
>> Yes, I approve of the suggested text.
>> 
>> Thank you very much
>> Best
>> Sanjay
>> 
>> On Wed, Feb 7, 2024 at 12:17 PM Alice Russo <[e-mail]> wrote:
>> Authors,
>> 
>> Sanjay, thank you for your reply and for letting us know about Frederic's reply to the CDNI mailing list.
>> 
>> Please reply to the 4 questions below regarding changes to the text.
>> 
>> The edited document is 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%2Fauthors%2Frfc9538.xml&data=05%7C02%7Cfrederic.fieau%4
>> 0orange.com%7Cc88b1eb5d9144cae2a9d08dc28d0d95a%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C638430124676708826%7CUnknown%7CTWFpbGZsb3d8eyJWI
>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
>> C%7C&sdata=bDWXU7CzKJ0Dxaox5ktAbOIF07kEoJT96iiEXsm4gcs%3D&reserved=0
>> (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%2Fauthors%2Frfc9538-rfcdiff.html&data=05%7C02%7Cfrederi
>> c.fieau%40orange.com%7Cc88b1eb5d9144cae2a9d08dc28d0d95a%7C90c7a20af34b
>> 40bfbc48b9253b6f5d20%7C0%7C0%7C638430124676716807%7CUnknown%7CTWFpbGZs
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C0%7C%7C%7C&sdata=3Tog1N2ufOCwM4EzF9JqcE2xcqNrz3uSERbwEFnAY6E%3D&res
>> erved=0 (side by side)
>> 
>> This page shows the AUTH48 status of your document:
>> 
>> https://www/.
>> rfc-editor.org%2Fauth48%2Frfc9538&data=05%7C02%7Cfrederic.fieau%40oran
>> ge.com%7Cc88b1eb5d9144cae2a9d08dc28d0d95a%7C90c7a20af34b40bfbc48b9253b
>> 6f5d20%7C0%7C0%7C638430124676720836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&
>> sdata=8F6fkKukmTBO9hdmi%2F9t0Qye8bzQfAxu3DiphYBWoIg%3D&reserved=0
>> 
>> In addition to the authors' responses to the questions, we hope to hear from Emile Stephan, as an approval is needed from each author listed in the first-page header of the RFC.
>> 
>> Thank you.
>> RFC Editor/ar
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.