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

[Kevin Ma <[e-mail]>]

Hi Frederic,

  Thanks for updating the draft.  I've reviewed it and provided some
comments below.  Most are nits, but please note the section 3.2 and section
5 comments.

thanx!

--  Kevin J. Ma

Abstract:
- "RFC 9115 allows delegating entity" -> "RFC9115 allows delegating
entities"

section 1:
- "In such case" -> "In such cases,"

section 3:
- "uCDN delegates a dCDN" -> "uCDN delegates to a dCDN"

section 3.1:
- I suggest changing the object name to just "ACMEDelegation"
- "STAR and non-STAR delegation objects" -> "STAR and non-STAR delegation"
- "several properties as shown below" -> "the properties shown below"
- the Source object reference could point to section 4.2.1.1 of RFC8006
- "TimeWindow" property name should be "time-window"
- the TimeWindow object reference could point to section 4.2.3.2 of RFC8006
- "TimeWindow is defined by defining \"start\" time of the window, and
\"end\" time of the window" -> "TimeWindow is defined by a window \"start\"
time and a window \"end\" time"
- "In case of" -> "In the case of the" (in both places)
- the Time object reference could point to section 4.3.4 of RFC8006 (in
both places)
- remove "In the case that the delegation is STAR-based, the following
properties are mandatory to specify:", this statement is redundant, it's
already stated in the Mandatory-to-Specify text

section 3.2:
- I suggest changing this to be section 3.1.1 to keep it with the metadata
object specification
- ACME-delegation is defined as a Source object, but this just shows a URL
string?  A Source object requires "endpoints" and "protocol".
- TimeWindow is defined as a TimeWindow object, where the start and end are
Time objects (i.e., integer epoch values), but this uses ISO8601 time
strings?
- The HostMatch/HostMetadata example is superfluous

section 4.1:
- "Interface: MI" -> "Interface: MI/FCI"

section 5:
- The security considerations could do a better job explaining the the
nature of the data held in the metadata object and what happens if it is
compromised.  It currently just says the delegation objects are "critical",
but I'm not sure what that means.  If an attacker get the information, what
can they do with it, if anything?  I would ultimately expect a reference to
section 8.3 of RFC8006, as that is what actually protects CDNI Metadata.
- "Section 3are" -> "Section 3 are"


On Sun, Oct 23, 2022 at 9:46 AM <[e-mail]> wrote:

>
> 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         : Frédéric Fieau
>                           Emile Stephan
>                           Sanjay Mishra
>   Filename        : draft-ietf-cdni-interfaces-https-delegation-12.txt
>   Pages           : 11
>   Date            : 2022-10-23
>
> Abstract:
>    This document defines metadata objects to support delegating the
>    delivery of HTTPS content between two or more interconnected CDNs.
>    Specifically, this document defines CDNI Metadata interface objects
>    to enable delegation of X.509 certificates leveraging delegation
>    schemes defined in RFC9115.  RFC 9115 allows delegating entity to
>    remain in full control of the delegation and be able to revoke it any
>    time and avoids the need to share private cryptographic key material
>    between the involved entities.
>
>
> 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-12.html
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-interfaces-https-delegation-12
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>