Re: [CDNi] [E] Re: Request for WG Adoption: CDNI Metadata Model Extensions

["Mishra, Sanjay" <[e-mail]>]

Hi Glenn, Alfonso - OK with your plans for breaking up the document and
submitting a new draft at IETF 115 or later.

For IETF 114, we will set aside 15 minutes for an overall update on your
plans.

Thanks
Sanjay

On Tue, Jul 12, 2022 at 12:37 AM Goldstein, Glenn <Glenn.Goldstein=
[e-mail]> wrote:

> I was out on vacation last week and just catching up now.
>
>
>
> Alfonso has it right. While we will not have an updated draft ready for
> IETF-114, we do plan on breaking the draft up into multiple parts and will
> have that ready for either IETF-115 or IETF-116 at the latest. We are
> continuing to add many new capabilities to the metadata model, including
> TCP connection control metadata and HTTPS/certificate configuration
> metadata.
>
>
>
> Thanks,
>
> Glenn
>
>
>
>
>
> *From: *CDNi <[e-mail]> on behalf of ALFONSO SILONIZ SANDINO
> <[e-mail]>
> *Date: *Thursday, July 7, 2022 at 10:20 AM
> *To: *Kevin Ma <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [CDNi] Request for WG Adoption: CDNI Metadata Model
> Extensions
>
> Hi Kevin,
>
>
>
> Sorry for the late response.
>
>
>
> Thank you for your comment. Indeed this is something we are going to do
> definetively, although probably will not arrive for IETF-114. So hopefully
> we will submit a new version of the draft splitted up after that.
>
>
>
> Best regards,
>
>
>
> Alfonso
>
>
>
>
>
> *De: *Kevin Ma <[e-mail]>
> *Fecha: *lunes, 4 de julio de 2022, 18:58
> *Para: *ALFONSO SILONIZ SANDINO <[e-mail]>
> *CC: *"[e-mail]" <[e-mail]>
> *Asunto: *Re: [CDNi] Request for WG Adoption: CDNI Metadata Model
> Extensions
>
>
>
> Hi Alfonso,
>
>
>
>   I think there is a lot of good work in the draft.  I'll reiterate
> though that the draft is a bit dense, and I think it would benefit from
> being split up at least into a set of non/less controversial metadata that
> could easily be reviewed and approved (similar to the work on request
> routing and footprints) and the more intricate processing stage content
> (which I personally think is interesting and a good addition and callout on
> the original metadata model, but will likely take more iteration to
> converge).
>
>
>
> thanx!
>
>
>
> --  Kevin J. Ma
>
>
>
> On Thu, Mar 24, 2022 at 4:42 AM ALFONSO SILONIZ SANDINO <
> [e-mail]> wrote:
>
> Hi All,
>
>
>
> Following the discussion during IETF 113 meeting, after the changes made
> to the draft attending different comments after IETF 112 meeting, I would
> like to ask for the group to make this draft an adopted CDNi WG document.
>
>
>
> The latest version of the draft can be found here
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__imss91-2Dctp.trendmicro.com-3A443_wis_clicktime_v1_query-3Furl-3Dhttps-253a-252f-252fdatatracker.ietf.org-252fdoc-252fdraft-252dgoldstein-252dcdni-252dmetadata-252dmodel-252dextensions-252f-26umid-3DE7D84ECF-2DE337-2DC705-2D986F-2D90BB1B2A8F7E-26auth-3D19120be9529b25014b618505cb01789c5433dae7-2D471b0f6f2c36c2599dca277e79cd90ad33c3e428&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=19ReISJziNG5ej-rJz5B81sg4GSZAyAHdwcpLOFcS_VkeZzKt33YedT_k1xYGZOA&s=s4h8VpGyqRWF62NXpAnkLP7XTQCG-nHsuoORNNBu7Hg&e=>
>
>
>
> About Kevin suggestion of breaking out this draft on smaller parts I think
> is a very fair point that we will discuss with our colleagues in the SVA
> Open Caching WG, as we want to maintain alignment in the OC documentation
> with the drafts presented to CDN-I for easier referencing.
>
>
>
> As for Sanjay suggestion, I add here the list of comments to the previous
> version  and our responses that were in our slidedeck for the meeting but
> for the sake of time was not possible to present in detail.
>
>
>
> Please, let us know if you agree or disagree with this adoption. And feel
> free to make any additional comment.
>
>
>
> Best Regards,
>
>
>
> Alfonso Siloniz
>
>
>
>
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.2
>
> 2.3.2
>
> add cross reference for HeaderTransform
>
> Missing in v2. Set for v3
>
> 2.2
>
> 2.3.2
>
> MI.AllowCompress: Without this metadata today, a dCDN is free to choose to
> compress? t 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?
>
> Without it, there is no enforcement from the uCDN about dCDN behavior for
> compression. The purpouse of the functionality is to force compression in
> dCDN independently of how the uCDN content has been acquired. Agreed
> probably the name does not reflect precisely the functionality, and
> something like EdgeCompress or ForceCompress would be more suitable. In
> discussion in the SVA OCWG
>
> 2.3
>
> 2.1.1
>
> 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)?
>
> Cache Control directives condition how any cache system in the path
> between the uCDN origin and the user agent should behave. As the uCDN can
> only use one specific Cache-Control header, it has no flexibility to
> control the TTL of the objects in a dCDN cache. It would be the same for
> the dCDN cache and for an intermediate cache system.
>
> As the uCDN can have control over the objects the dCDN stores (as with the
> trigger interface mentioned) it can be of the uCDN interest to have a
> longer TTL for the dCDN Caches (so there is less traffic to the uCDN
> origins) but having a smaller TTL for the end users. Thus, the dCDN
> supports a higher impact on requests, protecting the uCDN origin. For that,
> CachePOlicy permits to define modifications on the Cache-Control directives
> sent by the uCDN origin. Apart of that, the force property permits to
> mandate the dCDN to use those values only in the case the uCDN origin does
> not set the Cache Control directives. (as a default value)
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.2
>
> 2.3.2
>
> add cross reference for HeaderTransform
>
> Missing in v2. Set for v3
>
> 2.2
>
> 2.3.2
>
> MI.AllowCompress: Without this metadata today, a dCDN is free to choose to
> compress? t 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?
>
> Without it, there is no enforcement from the uCDN about dCDN behavior for
> compression. The purpouse of the functionality is to force compression in
> dCDN independently of how the uCDN content has been acquired. Agreed
> probably the name does not reflect precisely the functionality, and
> something like EdgeCompress or ForceCompress would be more suitable. In
> discussion in the SVA OCWG
>
> 2.3
>
> 2.1.1
>
> 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)?
>
> Cache Control directives condition how any cache system in the path
> between the uCDN origin and the user agent should behave. As the uCDN can
> only use one specific Cache-Control header, it has no flexibility to
> control the TTL of the objects in a dCDN cache. It would be the same for
> the dCDN cache and for an intermediate cache system.
>
> As the uCDN can have control over the objects the dCDN stores (as with the
> trigger interface mentioned) it can be of the uCDN interest to have a
> longer TTL for the dCDN Caches (so there is less traffic to the uCDN
> origins) but having a smaller TTL for the end users. Thus, the dCDN
> supports a higher impact on requests, protecting the uCDN origin. For that,
> CachePOlicy permits to define modifications on the Cache-Control directives
> sent by the uCDN origin. Apart of that, the force property permits to
> mandate the dCDN to use those values only in the case the uCDN origin does
> not set the Cache Control directives. (as a default value)
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.6
>
> 2.1.2
>
> "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/' ?
>
> Could the uCDN specify the cache policies in the response?
>
> Removed that sentence.
>
> For the second questions: Same case as for MI.CachePolicy above. In fact,
> this could be considered a particular case of the MI.CachePolicy for
> errors. The uCDN can of course set the cache control directive for those
> errors. But it is typical the uCDN prefers to protect its origin server of
> a flood of requests when a non-desirable situation occur (an HTTP 500 error
> for example), but wanting the UA to try a faster revalidation. Other
> example, in the opposite way: A video fragment is not available yet in the
> uCDN Origin but published in a manifest (Live DASH). The UA requests a
> video fragment to the dCDN, and the dCDN requests it to the uCDN. When
> having an HTTP 404 error (because maybe the object is in the process of
> being available in the origin). If it sets a max-age of 10s in the
> response, the dCDN will not revalidate the object until 10 seconds has
> passed, so every UA trying to get the object will receive a 404 during 10
> seconds. But maybe the resource became available after just 1 second of the
> first request. The first UA that requested the fragment will wait 10s to
> get it again, but the rest of UA trying to access the same fragment will
> get it right away.
>
> 2.7
>
> 2.1.4
>
> 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.
>
> Corrected the description. No relationship with the UA current request.
> This metadata applies after is received in a configuration, for all the
> requests that arrived since that moment that match the MI.ExpressionMatch
> and onwards. For the same resource requested, the dCDN can have a cached
> copy for those requests that don´t match the condition, while requesting a
> new copy for those that match.
>
> 2.8.1
>
> 2.3.4.1
>
> Combine the two Mandatory-to-Specify bullets?
>
> Corrected
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.9.1
>
> 2.5.2.1
>
> Do you envision a registry for the private features?
>
> By definition, the possible PrivateFeatures are implementation specific.
> As there could be a great variability on the possible properties we have
> not discussed the idea of having a registry. An uCDN configuring a
> HostMatch on multiple dCDNs should send a MI.PrivateFeatures metadata in
> the configuration only for those that support it, and the content
> particularized for each of those. As being a point to point configuration
> does not seem needed to have a registry.
>
> 2.12
>
> 2.5.3
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__imss91-2Dctp.trendmicro.com-3A443_wis_clicktime_v1_query-3Furl-3Dhttps-253a-252f-252fwww.iana.org-252fassignments-252fcdni-252dparameters-252fcdni-252dparameters.xhtml-26umid-3DE7D84ECF-2DE337-2DC705-2D986F-2D90BB1B2A8F7E-26auth-3D19120be9529b25014b618505cb01789c5433dae7-2Ddb2bd567f3c0a75f7f0ab7b580d2d1488cd466b5&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=19ReISJziNG5ej-rJz5B81sg4GSZAyAHdwcpLOFcS_VkeZzKt33YedT_k1xYGZOA&s=9DRlBKmGrkDCUZzLNcuxSPufRVpKpL-ledVBjSH8rVw&e=>*
> )?
>
> It is not exactly the same. FCI.RequestRouting and MI.RequestRouting are
> related to how the dCDN will make the Request Routing internally to direct
> the user to the suitable streamer. In the reference mentioned, the types
> HTTP-I or HTTP-R include the interative or recursive methods, while the
> internal request routing in a dCDN is independent of those techniques.
>
> The most typical use case is that a uCDN make a Traffic delegation using
> DNS-I or DNS-R, but wants to be sure that the dCDN is not going to do a
> internal HTTP redirection. Thus, sending MI.RequestRouting as “DNS” force
> the dCDN to use DNS RR internally and to avoid HTTP 302.
>
> 2.13
>
> 2.5.1
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__imss91-2Dctp.trendmicro.com-3A443_wis_clicktime_v1_query-3Furl-3Dhttps-253a-252f-252fdatatracker.ietf.org-252fdoc-252fhtml-252frfc8006-26umid-3DE7D84ECF-2DE337-2DC705-2D986F-2D90BB1B2A8F7E-26auth-3D19120be9529b25014b618505cb01789c5433dae7-2Dafd2e8b1cddd96602ca484de32da58ad6b0c96b5&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=19ReISJziNG5ej-rJz5B81sg4GSZAyAHdwcpLOFcS_VkeZzKt33YedT_k1xYGZOA&s=mt4Ju96eAavEExO5jtDEevrZ01eLTunr9hzdc2hk8k0&e=>*)
> suffice?
>
> Description expanded to clarify that point. This extension permits to
> identify services AND properties in the service. So in the case of a static
> ID without any property identification, Grouping could be sufficient.
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.14.1
>
> 2.2.1.1
>
> For ease of understanding, should probably just duplicate the
> acquistion-auth, endpoints, and protocol properties
>
> Done
>
> 2.14.2
>
> 2.2.1.2
>
> - section 2.14.2: Is the intent to create a registry for load balancing
> algorithms?
>
> In discussion
>
> 2.16
>
> 2.3.3
>
> "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?
>
> The intention is related to the content delivery, not the content
> acquisition. In HTTP Adaptative Streaming protocols, the behaviour of the
> end users consumers (aka ‘players’) is quite different and it affects the
> content delivery resources depending on this type. While a live content is
> mainly RAM consuming, a VoD content is storage consuming. CDNs typically
> can apply different optimizations, including using different hardware
> elements depending on the type of the content. Thus, it is very important
> that in video streaming processes the dCDN knows that information in
> advance so it can apply those strategies, so the QoE will be superior.
>
>
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__imss91-2Dctp.trendmicro.com-3A443_wis_clicktime_v1_query-3Furl-3Dhttps-253a-252f-252fwww.ietf.org-252fmailman-252flistinfo-252fcdni-26umid-3DE7D84ECF-2DE337-2DC705-2D986F-2D90BB1B2A8F7E-26auth-3D19120be9529b25014b618505cb01789c5433dae7-2Db098f48db05f1e43edd0c0d4a67e62aa59059f77&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=19ReISJziNG5ej-rJz5B81sg4GSZAyAHdwcpLOFcS_VkeZzKt33YedT_k1xYGZOA&s=GV9k7_KqxLecCY8ZF90Z66DFJwVJ0pqXQ57pcPXKHHM&e=>
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> 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.
> _______________________________________________
> CDNi mailing list
> [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=19ReISJziNG5ej-rJz5B81sg4GSZAyAHdwcpLOFcS_VkeZzKt33YedT_k1xYGZOA&s=nojsH7qk4LGK9AKMIPN04uQ3myVQ9lj1N1R0Ssu-4QY&e=
>