Minutes IETF116: cdni
minutes-116-cdni-00

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