Skip to main content

Minutes IETF117: cdni

Meeting Minutes Content Delivery Networks Interconnection (cdni) WG
Date and time 2023-07-26 20:00
Title Minutes IETF117: cdni
State Active
Other versions plain text
Last updated 2023-08-13

CDNI WG Minutes
IETF-117 San Francisco
Chairs: Kevin Ma and Sanjay Mishra
AD: Francesca Palombini

Chair slides:
- draft-ietf-cdni-delegation-acme: shepherd writeup ready; waiting on IPR

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

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)