CDNI WG Minutes IETF-116 Yokohama Chairs: Kevin Ma and Sanjay Mishra AD: Francesca Palombini Agenda and Slides: https://datatracker.ietf.org/meeting/116/session/cdni Recording: http://www.meetecho.com/ietf116/recordings#CDNI Chair Update: Sanjay and Kevin - Kevin: ACME HTTPS Delegation draft is in WGLC draft-ietf-cdni-https-delegation-subcerts: Christoph Neumann - Christof: Are we ready for WGLC? - Kevin: I sent comments to the list, we should address those, but otherwise the draft is looking good. - Kevin: CDNI does not have a Metadata push interface for pushing new credentials; CDNI has triggered pull. We should make the language more generic to support both. - Kevin: Probably need a couple revisions to clean up text before WGLC. - Sanjay: Is the maximum number of credentials supported a hard limit (e.g., tied to number of servers)? - Christof: dCDN announces how many it knows how to handle. - Sanjay: What if the ucdn gives extras? - Christof: The dCDN will not use them, it only needs what it asked for. draft-ietf-cdni-capacity-insights-extensions: Ben Rosenblum - Ben: Capacity Limit Scope Object removed from latest version - Ben: Kevin posted comments to the list; to be addressed - Kevin: The draft probably needs a couple more revisions before it is ready for WGLC. - Kevin: There is a configuration object still TBD. Is it going to be defined or pulled out? Would it be better to use an opaque string rather than an undefined object? - Ben: It's a generic container. Validating a string is still not validating the config, so I don't the difference/benefit of a generic blob; a string is no better. - Chris Lemmons: People will just put json in the string, but may improperly escape it - Ben: We can cleanup the language and the TBD draft-ietf-cdni-ci-triggers-rfc8007bis-04: Nir Sopher - Nir: Large document, a lot of changes, plan to submit an update by IETF 117, then WGLC? - Kevin: slide 8: If the list is not ordered, how are duplicates handled? - Nir: Have not considered it yet, but the list should be additive - Kevin: slide 11: Are generic extension advertisement via FCI? - Nir: Things that are mandatory to understand may not need to be, but extensions should be advertised, though perhaps an error code for specs. - Kevin: Before we think about WGLC, everyone should go read and comment on the draft. - Sanjay: It is a big draft with a significant change, so it needs a lot of reviews between now and IETF 117. - Glenn Goldstein: Are async notification of completion part of the standard. - Nir: There is not a notification, but there is a status object that can be polled. There have been no changes to the protocol itself, only changes to the objects - Glenn: The SVTA has discussed the value of async notification for long running actions (e.g., purge or preposition). - Kevin: The original design was for a RESTful interface with a status resource. It's a big change. Do we want to couple it with the other changes? - Nir: It could be implemented as an extension. Overview of SVTA Configuration Interface Metadata Model: Glenn Goldstein draft-power-cdni-cache-control-metadata: Will Power - Kevin: I send comments to the list. Content looks fine, just needs some editing. draft-siloniz-cdni-edge-control-metadata: Alfonso Siloniz - Sanjay: I will be sending out comments to the mailing list. - Kevin: I have not had a chance to read it, but will do so and send out comments to the list. draft-rosenblum-cdni-protected-secrets-metadata: Ben Rosenblum - Kevin: MI/FCI objects containing data/configuration seem ok by themselves, but when building something on top, we are not chartered to develop security protocols, so I'm nervous about getting too deep into how to specify/exchange/use keys. - Ben: Using existing protocols for specifying the messages. We could include use cases for why these messages are needed. - Kevin: Use cases will probably help with SecDir review. - Chris Lemmons: This is useful for some URI signing scenarios - Chris: We probably need to specify PKI for interoperability. And then, maybe we are building a security protocol; but we shouldn't handwave important pieces. - Ben: We also don't specify how authentication occurs or how trust is established, which is also out-of-band. - Chris: They may be the same questions. If trust is established, could just specify the transport for interoperability. - Ben: Since this uses X.509, we could reuse the TLS transport certs. - Chris: +1 - Ben: This draft is probably not the place to specify that. - Kevin: We should all read the draft and find a way to address the lingering concern. I will read the draft and post comments to the list. - Sanjay: Agree that use cases could help clarify. Open MIC draft-arolovitch-cdni-named-footprints: Alan Arolovitch - Kevin: Changing the understanding of what a footprint is (i.e., endpoint coverage vs different types of traffic within the CDN) is something we can discuss but not something we should take lightly. I encourage all to ready the draft so we can have that discussion. - Nir Sopher: 1. Where is the footprint hierarchy defined; is it in FCI? - Kevin: Cutting discussion to give Ben time to speak - Nir: 2. Need to take the alto draft (RFC 9241) into consideration. - Nir: 3. We may need a new footprint type for the named footprint? - Nir: 4. Wrt alternate definitions of footprints: one could define a capability to achieve different footprint behaviors - Alan: 1 and 3 are in the draft. 2 and 4 can be discussed offline. - Ben: Question about milestones and rechartering: is there a hard deadline? - Kevin: We can adjust dates and add milestones for items with our charter, or recharter if we need to. The existing dates should not be a significant concern. - Glenn: MI Secret Values example Chair Closing: Sanjay and Kevin - Please review the drafts and provide comments on the list