CDNI WG Minutes IETF-117 San Francisco Chairs: Kevin Ma and Sanjay Mishra AD: Francesca Palombini Recording: https://www.youtube.com/watch?v=XmokOIBVcqs Chair slides: - draft-ietf-cdni-delegation-acme: shepherd writeup ready; waiting on IPR statements draft-ietf-cdni-ci-triggers-rfc8007bis - Nir Sopher - Nir: New draft added new registries and error codes - Rajeev RK: Are there error codes for both unsupported vs unable to execute operations? - Nir: We did discuss it - Rajeev: Perhaps add examples for different use cases and which errors codes to use - Nir: New draft added "status reason" property - Nir: New draft changed to not versioning the API, instead versioning the objects - Alan Arolovitch: Are the old and new objects mixed? How are they backwards compatible? - Nir: The request/response messages are paired by version, but an implementation could use either - Nir: dCDN can advertise what versions it supports and the uCDN can decide what version to use - Alan: Supporting both is an unnecessary complication - Nir: It is complex but we didn't want to force people to move; not knowing what current usage of v1 is. The dCDN can protect itself by only advertising v2 - Alan: What if a new v2 extension is used, but then a v1 message is used? - Alan: Why not just avoid the complexity by only allowing one version? - Nir: Will add a comment - Nir: New draft split triggers and cancel objects, removed loop detection and bulk cancellation - Alan: SVTA is working with v2 and have some more extension suggestions - Kevin: Not ready for WGLC yet. Happy to get more feedback from implementers. draft-ietf-cdni-capacity-insights-extensions - Ben Rosenblum - Ben: do we need IANA registries? - Kevin: If the authors don't feel the registries are necessary for future interoperability, that's ok - Ben: Potential need for telemetry types registry for updates by future drafts. Don't see a need for limit types registry. Don't see a future draft that just adds new limit types. - Kevin/Sanjay: after one more cleanup pass, try to get to WGLC before IETF 118 draft-ietf-cdni-https-delegation-subcerts - Christoph Neumann - Rajeev: Have we considered the new proposed secrets interface to carry secrets - Christoph: It is possible, but not looked at. - Rajeev: Could add text to this draft not to send inband credentials and use that future RFC - Christoph: That is out-of-scope of this draft; can look at it in the future - Kevin: Agreed it is out of scope, we don't want to have to wait for forward references to publish - Kevin: We should ask for a secdir pre-review - Kevin/Sanjay: after one more cleanup pass, try to get to WGLC before IETF 118 CDNI Metadata overview - Glenn Goldstein - SVTA metadata extensions: 3 draft currently seeding adoption, 2 more planned for IETF 118, 4 more planned for IETF 119 draft-power-cdni-cache-control-metadata - Glenn Goldstein - Glenn: Cleaned up properties and examples, addressed setting multiple policies - Glenn: Ready for WG adoption? draft-siloniz-cdni-edge-control-metadata - Glenn Goldstein - Glenn: Removed and object and cleaned up text - Glenn: Ready for WG adoption? draft-rosenblum-cdni-protected-secrets-metadata - Ben Rosenblum - Ben: Request for WG adoption; it is referenced by a lot of other drafts Chair Polls: - draft-power-cdni-cache-control-metadata: 4 people have read draft / 8 total people answered - draft-siloniz-cdni-edge-control-metadata: 6 people have read draft / 8 total people answered - draft-rosenblum-cdni-protected-secrets-metadata: 7 people have read draft / 7 total people answered - 20 people in the room - Kevin: I think it's a good showing of support; will confirm on the list - Ben: Suggest setting a deadline for comments if it is going to hold up adoption. draft-arolovitch-cdni-named-footprints - Alan Arolovitch - Alan: Propose extending FCI: retrieve footprints separate from capabilities, including different kinds of footprints, footprint overlays for different traffic types, footprint caching, and footprint definition source specification - Kevin: If this is a new interface, we need to see if we need to amend the charter - Kevin: How does this work with ALTO, or does it replace or augment the ALTO interface? - Rajeev: ALTO makes sense as a source for dynamic footprints - Nir: Is it a list or a single footprint? If a list, is it "and" or "or"? (discussion to be continued on the list) Open MIC Logging Extensions - Ben Rosenblum - Ben: Surveyed SVTA participants and defined a core set of logging field, file formats, archive formats, transport endpoints, and privacy transforms, that operators care about (draft to be submitted for next IETF) - Sanjay: Sounds interesting and seems to build on and extend the existing RFC - Ben: Tried to remain compatible; not deprecating RFC7937 - Kevin: New transports make sense. Privacy transforms will need to pass secdir. - Kevin: Will it reuse the existing IANA registries and construct definitions? - Ben: The draft defines all new definitions, some overlap, but it's something that can be looked at - Kevin: If we can massage and reuse what exists, that would be preferable - Chris Lemmons: Support the work. Have tried to use RFC7937, but it doesn't work. Where the current draft falls short, these extensions fill the gap it's an evolution bridging the intervening seven years Request Routing interface - Alan Arolovitch - Alan: Move away from JSON interface to just forwarding the original request (draft to be submitted for next IETF)