Minutes IETF113: cdni
minutes-113-cdni-01

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