Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-09.txt

Hi Frederic,

  Thanks for the quick turnaround.

  wrt the comment on section 1, you are adding an entry to an existing
registry; you are not proposing a new registry.  I still don't think that
last sentence is correct.

  wrt section 3, I still don't think the section is necessary.  There's no
need to explain how FCI works.  (Note: The example is also not correct,
"delegation-methods" should be "metadata".)

  wrt the example in section 4, I don't think you need the HostMatch
example, and the ACMEStarDelegationMethod example is still missing the
"generic-metadata-type"
field, which is critical.

  wrt the security considerations, it would be helpful to explain what is
critical about the contents of the ACMEStarDelegationMethod metadata, and
why it should be protected.

thanx.

--  Kevin J. Ma

On Mon, Aug 1, 2022 at 10:35 AM <frederic.fieau@orange.com> wrote:

> Hi Kevin,
>
>
>
> Just posted the last version taking into account your comments.
>
>
>
> Section 1. and 3
>
> We removed FCI.SupportedDelegationMethods,
>
> There is still the MI.AcmeSTarDelegationMEthod object to register. So the
> IANA section is not empty.
>
>
>
> Section 4.1
>
> Removed the explanations of section 4.1 and moved the example at the
> bottom of section 4.
>
>
>
> Section 6.
>
> We added a recommendation  to protect the critical parts of the objects.
>
>
>
> Nits taken into account.
>
>
>
>
>
> Regards,
>
> Frederic
>
>
>
> *De :* Kevin Ma <kevin.j.ma.ietf@gmail.com>
> *Envoyé :* vendredi 29 juillet 2022 15:47
> *À :* FIEAU Frédéric INNOV/NET <frederic.fieau@orange.com>
> *Cc :* cdni@ietf.org
> *Objet :* Re: [CDNi] I-D Action:
> draft-ietf-cdni-interfaces-https-delegation-09.txt
>
>
>
> Hi Frederic,
>
>
>
>   Some comments on the updated draft below.
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
> section 1:
>
>   remove "Furthermore, it includes a proposal of IANA registry to enable
> adding of delegation methods."  There is no longer a new registry?
>
>
>
> section 3:
>
>   I don't see any need for a new FCI object.  RFC8008 already has an FCI.Metadata
> object, and MI.AcmeStarDelegationMethod can just be advertised through that
> existing object?
>
>
>
> section 4.1:
>
>   This section seems to mostly just explain how the Metadata interface
> works?  I don't think it is necessary.  I would just remove this section.
>
>   The final example of what a serialized MI.AcmeStarDelegationMethod
> generic metadata object looks like should be in a section 4.2.1 (including
> the generic-metadata-type) and referenced from IANA section 5.1
>
>
>
> section 6:
>
>   If the ACME delegation objects were divulged, what would be the impact?
> Yes, they should be protected by the proper/mandated encryption and
> authentication on the Metadata interface, but I think it is best to
> document what is at stake (if anything)
>
>
>
> nits:
>
> - section 1:
>   "holder of a X.509" -> "a holder of ane X.509"
>   "on-demand a X.509" -> "on-demand an X.509" (multiple places)
>   "use of certificate authority" -> "use of the certificate authority"
>   "an upstream CDN (uCDN) and a downstream CDN (dCDN)" -> "a uCDN and a
> dCDN"
>   "based on mechanism specified" -> "based on the mechanism specified"
>
> - section 4.1:
>   "CDNI Delegation metadata" -> "ACMEStarDelegationMethod metadata" ?
>   "an HostMatch object" -> "a HostMatch object" (multiple places)
>   "The existence of delegation method in the CDNI metadata Object" -> "The
> existence of ACMEStarDelegationMethod in the CDNI metadata"
>   "set of Host" -> "set of Hosts"
>
> - section 4.2:
>   "(i.e. dCDN)" -> "(i.e., the dCDN)"
>   "end-user client, a short-term" -> "end-user client a short-term"
>
> - section 5.1:
>
>   "see Section 5" -> "see Section 4.2.1"
>
>
>
>
>
> On Sat, Jul 9, 2022 at 9:55 AM Kevin Ma <kevin.j.ma.ietf@gmail.com> wrote:
>
> Hi Frederic,
>
>
>
>   (As Chair) Thanks for the updated draft.  If we think this is pretty
> close to final, I will start my pre-shepherd review.  I encourage everyone
> to please take a look, as we would like to try and finish up this work by
> IETF 115.
>
>
>
>   I fully support updating the name of the draft to deconflict it from the
> subcerts draft.
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
>
>
> On Fri, Jul 8, 2022 at 1:22 PM <frederic.fieau@orange.com> wrote:
>
> Hi all
>
> I've submitted the -09 version of
> draft-ietf-cdni-interfaces-https-delegation-09. Changes are mainly on the
> abstract and introduction.
> Also I would suggest to change the title to : "CDNI metadata for HTTPS
> delegation using Short-Term Automatically Renewed Certificates".
>
> Feel free to comment.
>
> Thank you,
> Regards,
> Frederic
>
>
>
> Orange Restricted
>
> -----Message d'origine-----
> De : CDNi <cdni-bounces@ietf.org> De la part de internet-drafts@ietf.org
> Envoyé : vendredi 8 juillet 2022 17:31
> À : i-d-announce@ietf.org
> Cc : cdni@ietf.org
> Objet : [CDNi] I-D Action:
> draft-ietf-cdni-interfaces-https-delegation-09.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Content Delivery Networks Interconnection
> WG of the IETF.
>
>         Title           : CDNI extensions for HTTPS delegation
>         Authors         : Frederic Fieau
>                           Emile Stephan
>                           Sanjay Mishra
>   Filename        : draft-ietf-cdni-interfaces-https-delegation-09.txt
>   Pages           : 9
>   Date            : 2022-07-08
>
> Abstract:
>    This document defines a new Footprint and Capabilities metadata
>    objects to support HTTPS delegation between two or more
>    interconnected CDNs.  Specifically, this document outlines CDNI
>    Metadata interface objects for delegation method as published in the
>    ACME-STAR document [RFC9115].
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-cdni-interfaces-https-delegation-09.html
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-interfaces-https-delegation-09
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>
>
>
> Orange Restricted
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>