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
>>
>