CDNI WG Minutes IETF-113 Online Chairs: Kevin Ma and Sanjay Mishra AD: Francesca Palombini Agenda and Slides: https://datatracker.ietf.org/meeting/113/session/cdni Recording: http://www.meetecho.com/ietf113/recordings#CDNI CDNI Footprints (Nir Sopher) ---------------------------- Nir: Draft updated per comments Kevin: any objection to WGLC no objections Kevin: will take WGLC to the list Benson Muite: will review and provide comments on ISO3166 codes CDNI Triggers (Nir Sopher) -------------------------- Nir: example shows different URL specs for prepositioning content and metadata Rajeev RK: if prepositioning different metadata and content could preposition content for which there metadata has not been prepositioned? is the URL spec recursive? [i.e., should the dCDN pull all nested metadata?] Kevin: we don't specify what the dCDN should do [though it makes sense for the dCDN to pull metadata for content it is prepositioning, even if the metadata is not being prepositioned] Nir: the same issue exists with the existing protocol Rajeev: perhaps the draft should specify whether the dCDN should pull all the nested metadata? the new proposal allows for separate urls for content/metadata which create a possibility for for mismatch between content and metadata Nir: error object is ambiguous wrt trigger spec list; proposed empty placeholders in error object RajeevK: there are two levels of ambiguity with the error object - it only lists the spec that has an error: i.e., it's a partial spec, which placeholders could address - it has to match the URL in the spec, but the error could be on a URL that is not part of the original spec, e.g., part of a playlist why use an error object, rather than have a generic status object that can express errors complete state in status messages and upstream doesn't need to maintain state Nir: the protocol has a status message with errors another approach could be to list an error per spec? alternately, the uCDN could just use separate triggers rather than a trigger list [to reach the degenerate case of 1:1 status to error] Kevin/Sanjay: in the interest of time, lets take the discussion to the list HTTPS Delegation (Sanjay Mishra) -------------------------------- Sanjay: cleaned up draft to align with RFC9115 Kevin: will do a shepherd pre-review will attempt to get to WGLC by IETF114 HTTPS Delegation using subcerts (Christoph Neumann) --------------------------------------------------- Christoph: one open issue: MI.DelegatedCredentials is not really metadata alternatives: - use FCI to advertise credentials - create a new interface for exchanging credentials - propose and extension to ACME Sanjay: does not fir with ACME Sanjay: the final subcerts draft uses dtls; does it matter? Christoph: will look at the latest subcerts draft Kevin: the credentials are not really MI metadata. there are security issues with using MI or defining a protocol for exchaning key material defining a new security protocol is not within our charter we need to consider if defining just the structure is enough will respond to the message on the list Kevin: any objection to adoption? no objection Kevin: will take adoption to the list Consumer Technology Association (CTA) Web Application Video Ecosystem (WAVE) (Chris Lemmons) -------------------------------------------------------------------------------------------- Chris: CATs have more claims, are more compact, and specify more intermediary requirements Kevin: do CATs have useful stuff or just extra stuff? is there demand and expected adoption? Chris: yes. there is demand for the additional features Kevin: is this something we should liaise with CTA on? Chris: makes sense to liaise. CDNI may want to add support for CATs Chris: CDNI intentionally leaves out intermediary MUSTs; it would take work to support CATs Sanjay: can you keep the WG up to date in at IETF 114 in July Chris: yes. Pankaj Chaudhari: there is heavy interest from content providers and CDNs for the logical claims and concise format Phil: love standards (that's why URI signing moved to using jwts) if CATs are better, then all for using them CDNI URI Signing (Phil Sorber) ------------------------------ Phil: requesting input on Ben's comment about delegated shared keys the draft has should not, but Ben wants must not Francesca: just saying "should not" is not enough; consequences need to be documented "should not" is for when the author sees corner cases where it is allowed Phil: there is a lot of "not recommended" text, but Ben really wants a must not if people want to do it, they just won't be compliant with the RFC Kevin: we left it in because we know people do it and we wanted to acknowledge that, but it may be the IETF stance should be that this is a "must not", and those who want to do it can, but outside of the RFC Francesca: lets make sure we get Ben's comment addressed even though he is steping down and his discuss will clear Phil: I definitely appreciate Ben's input and will continue to work with him to address his concern Kevin: I'm ok with must not CDNI Metadata (Alfonso Sandio) ------------------------------ Alfonso: comments have been addressed; are we ready for draft adoption? Sanjay: send the updates and clarification to the list to get more feedback Kevin: we might want to consider breaking up doc to make it more digestable to move the least controversial parts through Kevin: everyone please review the the draft and comment on the list Capacity Advertisement (Andrew Ryan) ------------------------------------ Andrew: removed MI.RequestedCapacityLimits; usage wasn't clear enough for now Kevin: everyone please review the the draft and comment on the list session closed