Minutes for CDNI, IETF 119, Brisbane, Australia

Chairs: Kevin J. Ma, Sanjay Mishra, Chris Lemmons

IETF 119 Agenda: datatracker.ietf.org/meeting/119/agenda
Charter: http://datatracker.ietf.org/wg/cdni/charter/
Mailing list: cdni@ietf.org
Tuesday, 19th March 2024, 09:30-11:30 Australian Eastern (Brisbane) Time
, Room: P3, Brisbane Convention & Exhibition Center

Intro/Agenda Bashing: Chairs (5 min)

• Virtual Bluesheets
• Note well was well noted
• RFC 9538 is published!
• WGLC: CDNI Metadata for Delegated Credentials ⇒ March 24
• WGLC: CDNI Capacity Capability Advertisement Extensions ⇒ March 30
• Missed milestone dates for TLS Subcert draft, but is progressing
• Missed milestone dates on a few other drafts, but they are also
  progressing, most in this meeting

Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition, Jay Robertson (10 min)

draft-ietf-cdni-ci-triggers-rfc8007bis-11

Jay Robertson presents the slides.

Conversation on Timezones:

Rajeev RK: Does the DateLocalTime trigger suffer from risks of
double-triggering if there are time shifts like Daylight Savings Time?

Jay: One of the main use cases is to run a trigger at a range of times.
There's usually a start and end time and the dCDN has leeway when it
schedules it. The idea is that purges can be scheduled in timezone of
the cache to avoid primetime in the region of the cache.

Rajeev: That's the point I was making. What if the downstream node is in
a TZ that has this shift happening and the end window is in the shift
zone. Do I stop my cache fill at the first or second occurance of the
time point.

Nir Baruch Sopher: This aligns with the principles Jay explained.
Changing DST, if you look from the point of view of peak or low hours,
the usage of this time, if it repeats or you shorten the time, it will
align with what the user wants. I agree that there's something missing
and maybe some errata that needs to be addressed. But perhaps we can
specify some behaviour around those areas. The concept of extensions is
that we can add more and more based on our use cases. In the future, it
might be wise to define another extension that fits better with
timezones.

Rajeev: I'm fine with there being a caveat here.

Nir: I would not change it, but I would clarify the definition. I would
like thank Jay for joining us and working so hard on these things. It
really brings this forward.

Rajeev: I agree with Nir. If we add a little clarity to implementers.
Consider: "In these kinds of scenarios, it's the decision of the caching
node which time point to apply." If we have a little sentence in there
to clarify, it makes it easier to handle.

Sanjay: Moving on to the last slide...

Capacity Capability Advertisement Extension, Ben Rosenblum (5 min)

draft-ietf-cdni-capacity-insights-extensions-04

Ben Rosenblum presents the slides.

Logging Extensions: submission overview, Q&A, Ben Rosenblum (10 min)

draft-rosenblum-cdni-logging-extensions-01

Ben Rosenblum presents the slides.

Adoption request for this draft.

Sanjay: This seems in charter and appropriate for adoption.

Kevin: We need more reviewers that aren't chairs. Please review the
documents and comment on the list.

Proposal for additions for the CI/T v2 triggers draft beyond the current v11, Alan Arolovitch (20 min)

Alan Arolovitch presents the slides.

Kevin: Alan, you're going to talk to Jay about how to incorporate these.
Do you know when you're going to have a decision? I'm not necessarily
opposed, but it suggests we have more work to do on the draft.

Nir: There are several things in the core. For extensions, we'll need to
choose a pair extension. I think we should aim to get something
relatively close for the next IETF meeting. I won't be the one pushing
it forward. I can't commit to that.

Kevin: So we'll have a proposal on how to move forward, but not
necessarily a draft?

Alan: I think we can do that. I don't think it will be too much of a
difference.

Nir: We've already had a lot of discussion, but we are running into time
limits.

Sanjay: For the timeline, we really want a sooner than later consensus
into what goes into -13. And then we can look at WGLC for 120. It would
be good to have a draft ready for reviews.

Alan: This is feasible. We've done reviews already and I think within a
couple of months we can have the draft.

Glenn: As we get into the next round of work in the SVTA, the
orchestration API, we will rely on triggers. As we do that, we may want
to pile on minor changes or extensions. That may not be work we get to
for a few more months.

Alan: I'm aware. We have an extension mechanism that we can rely on. But
that's something we can work on in a separate draft using the existing
framework. What we're doing now is what has to be done in the core that
cannot be done in an extension.

Kevin: As chairs, we would prefer this not drag on for months and months
and months.

Content Delivery Network Interconnection (CDNI) Named Footprints, Alan Arolovitch (10 min)

draft-arolovitch-cdni-named-footprints-01

Alan briefly presents the slides.

Glen & team to cover the following drafts (50 min)

Glen Goldstein presents the slides. These were moved through quickly on
account of time pressure.

• CDNI Processing Stages Metadata:
  draft-goldstein-processing-stages-metadata-01
• CDNI Metadata Expression Language:
  draft-power-metadata-expression-language-01
• CDNI Cache Control Metadata:
  draft-ietf-cdni-cache-control-metadata-01
• CDNI Protected Secrets Metadata:
  draft-ietf-cdni-protected-secrets-metadata-01
• CDNI Client Access Control Metadata:
  draft-chaudhari-source-access-control-metadata-00
• CDNI Source Access Control Metadata:
  draft-chaudhari-client-access-control-metadata-00
• CDNI Edge Control Metadata:
  draft-ietf-cdni-edge-control-metadata-00
• CDNI Delivery Metadata: draft-bichot-delivery-metadata-00
• CDNI Private Features Metadata:
  draft-warshavsky-private-features-metadata-00

Request for adoption for Processing Stages Metadata.

Sanjay: In order for this to be the CDNI specification, there needs to
be interconnections between the uCDN and dCDN.

Glenn: I've updated the labels to make it clear.

Kevin: It could be a tCDN, but for this discussion, this is fine.

Cache Control Metadata request to go to WGLC.

Request for adoption for Source Access Control metadata.

Request for adoption for Client Access Control metadata.

Consensus in the room that Client Access Control new protocol type names
seemed reasonable.

Edge Control Metadata seems about done, request to move for WGLC.

Request for adoption for Delivery Metadata.

Request for adoption for Private Features Metadata.

Request for review of Protected Secrets Metadata. Not ready for WGLG,
needs consensus on the list.

Kevin: On Private features. Are you creating a Generic Generic Metadata?

Glenn: Yes, that is essentially correct.

Kevin: I have concerns about that.

Glenn: This doesn't stop you from making up MI objects as you wish. But
this puts a framework around it.

Kevin: We've already got a registry.

Glenn: Read the draft, but challenge it on the mailing list.

Kevin: The other Metadata objects make sense, but the private features
don't seem to be as useful.

Francesca Palombini: As AD, please be careful of the charter scope.
There's a lot of work here and it looks like some of this work may
require rechartering.

Sanjay: Ditto to what Francesca said. The chairs will take up the work
of verifying each of these things are within the charter. Even if
everything were in scope, we need reviewers so that the chairs don't
become the bottleneck on reviewers. It would be good to have official
names assigned for review. We also want to know about implementation,
who and where. That will show support in the IETF community for
implementation.

Glenn: One requirement for a reviewer is that you're not an author?

Sanjay: Yes.

Kevin: This is basically a request for shepards.

Glenn: I'd usually look over at Chris for some of this, but he's a chair
now.

Chris: Yes, I've agreed to look at some of this.

Kevin: For the new drafts, I want more eyes on them. We also need to
have a chair discussion on the charter. The h2 conversation may require
rechartering.

Francesca: We may want to have a rechartering to cover the maintenance
goals.

Glenn: Much of what we have are just definitions of MI objects that
could have been in 8006. We are just making new objects that fit into
that framework.

Kevin: 8006 was designed to be extensible. But we need to do our due
dilligance that ensures that we are within our charter.

Glenn: What do I ask for, a shepherd?

Kevin: Anybody can review. But the chairs will start assigning
shepherds.

Wrap up

Sanjay: AOB? Remote or in the room?

silence

Meeting concludes.