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

["Goldstein, Glenn" <[e-mail]>]

thanks for the thorough read and all the questions Kevin. We can address some of this in the CDNI working group meeting tomorrow, and then we will follow up with a draft revision 02 that can address the various corrections and questions you've raised.

attached is the presentation I plan on presenting for tomorrow's meeting.

Glenn



________________________________
From: Kevin Ma <[e-mail]>
Sent: Sunday, November 7, 2021 9:53 PM
To: <[e-mail]> <[e-mail]>; Goldstein, Glenn <[e-mail]>
Subject: draft-goldstein-cdni-metadata-model-extensions






CAUTION:
 This email originated outside of Lumen Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.






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<https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fhtml%2frfc3986%23section%2d3.2&umid=13952514-D03E-1C05-AB75-4D3AEF32200A&auth=19120be9529b25014b618505cb01789c5433dae7-ee3c2e700715a664c8e72a10ed35cae02173127d>)?  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<https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.iana.org%2fassignments%2fcdni%2dparameters%2fcdni%2dparameters.xhtml%23capabilities%2dredirection%2dmodes&umid=13952514-D03E-1C05-AB75-4D3AEF32200A&auth=19120be9529b25014b618505cb01789c5433dae7-ea55a991837e016522d30826ec2f015fc49f4ac1>)?
- 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<https://imss91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fhtml%2frfc8006%23section%2d4.2.8&umid=13952514-D03E-1C05-AB75-4D3AEF32200A&auth=19120be9529b25014b618505cb01789c5433dae7-584ff07d9d51f08388f87829f76905b2bc8cb84e>) 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"
This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.