[CDNi] draft-goldstein-cdni-metadata-model-extensions

[Kevin Ma <[e-mail]>]

Hi Glenn,

  Thanks for the updated draft.  This version contains a lot more detail.
As a general comment, I wonder if it would be more manageable if the
metadata were somehow logically grouped and broken out into separate
documents with more use case descriptions (e.g., processing stages could be
an independent draft)?  Detailed comments below (note: I've only made it
through section 2).

  I need to go through the MEL section in detail, but I assume we have
looked to see if there is any existing framework or specification that
might cover these needs without having to specify a whole new MEL?

thanx!

--  Kevin J. Ma

- section 2.1.1: Is header-value an actual key?  or some token derived from
a key?  Where does the secret-sharing API come in to play?
- section 2.1.2: is secret-access-key an actual key?  Could it be accessed
from a vault in some more secure way using the access-key-id, rather than
embedding the actual key?  Where does the secret-sharing API come in to
play?
- section 2.2: add cross reference for HeaderTransform
- section 2.2: @ithout this metadata today, a dCDN is free to choose to
compress?  It feels more natural to make the default true or change the
metadata to DisallowCompress?  Otherwise, without an FCI advertisement of
whether the dCDN supports the metadata, it's hard to know what its default
behavior will be?
- section 2.3: I'm curious about the use case.  The uCDN could just set the
desired cache policy in the response, rather than setting the metadata.  Is
the primary use case where the uCDN does not want to set the cache policy
in each response and wants a default in the metadata?  Or is there
something else?  Is it to have a push interface (note: the triggers API
provides a way to invalidate)?
- section 2.3: "dCDN. overriding" -> "dCDN, overriding"
- sectino 2.5.1: I'm not sure what "List of valid URLs only scheme and host
name" means.  Is that to say the URLs only have a scheme and hostname
(i.e., no uri path)?  And is the port explicity excluded, or is it an
RFC3986 "authority" (i.e., user, host or ip, and port
https://datatracker.ietf.org/doc/html/rfc3986#section-3.2)?  Perhaps "List
of valid URLs (where the URLs contain only a scheme and authority)"?  Note:
In order to find the metadata, a request must already have matched a host
in the HostMatch object, so depending on what is in the HostMatch, this
could be redundant?  Is this something that could be simplified?
- section 2.6: "it may be desirable to cache error responses at the uCDN
for a short period of time to prevent an overwhelmed origin service from
being flooded with requests"?  Replace 's/uCDN/dCDN/' and 's/origin
service/uCDN/' ?
- section 2.6: Could the uCDN specify the cache policies in the response?
- section 2.6: "Sextions" -> "Sections"
- section 2.7: Is the intent that this metadata would be pulled from the
uCDN on every request and that the uCDN would made decisions based on the
requestor: "CacheBypassPolicy only applies to the current request"?  Though
not explicity prohibited by the MI, it goes a bit beyond the original
intent of the metadata cacheability.
- section 2.8: "OcnDeliver yObject" -> "OcnDelivery Object"
- section 2.8.1: Combine the two Mandatory-to-Specify bullets?
- section 2.9.1: Do you envision a registry for the private features?
- section 2.12: I would expect the type to come from the redirection modes
registry (
https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml#capabilities-redirection-modes
)?
- section 2.13: I'm not clear what the two tiers are.  In the case of a
static ID, would the existing ccid metadata (
https://datatracker.ietf.org/doc/html/rfc8006#section-4.2.8) suffice?
- section 2.13: "model sis" -> "model is"
- section 2.14.1: "use cases requires" -> "use cases require"
- section 2.14.1: For ease of understanding, should probably just duplicate
the acquistion-auth, endpoints, and protocol properties
- section 2.14.2: Is the intent to create a registry for load balancing
algorithms?
- section 2.16: "vod" and "live" are fairly video specific; could this be
more generically categorized?  is the intent to convey information about
source acquisition (e.g., you may have to wait for live content to become
available vs you may be able to prefetch vod), delivery pacing or rate
limiting, both, neither, or other?
- section 2.16: "it should be noted" -> "It should be noted"