Session Date/Time: 19 May 2026 15:00
Sanjay Mishra: Hi, this is Sanjay.
Chris Lemmons: Greetings, Sanjay.
Sanjay Mishra: Hey, Chris. Everyone appears to be having a little bit of trouble with Data Tracker this morning.
Chris Lemmons: Okay. Yeah, I- I just had to reset the password, and it- it took a few minutes to get that going, too.
Kevin Ma: Yeah. I- I didn't have any issues logging in. It's- after it successfully logged in, it just sat there doing nothing. And then, like, in the pop-up window, and I closed it, and it was still just at the login screen.
Alan Arolovitch: Oh, interesting. Same for me. Just- I had to reload the page to get in.
Kevin Ma: Yeah, that helps.
Chris Lemmons: Yeah, now, I- I entered my password, like, five times, and, like, the first couple of times, I'm like, oh, I probably just mistyped it. I'm like, no, I- I have this right.
Kevin Ma: Yeah, wow.
Alan Arolovitch: Yeah, that- I think it's a good opportunity to- to be thankful just how flawless it usually has been, like, I- I never had any issues with ZITF, uh, meeting stack. So, it's a first time, so it should be noted that-
Chris Lemmons: Yep. All right. Sanjay, you want to get- you want to get this party started?
Sanjay Mishra: Yes. Uh, let's start with, um- I'm just quickly going to share, uh- I want to share screen. So, I- so, we're moving away from, um, Microsoft Office at our corporate, so I can display PowerPoint. Um, and I want to- it won't let me share screen. Needs the document to be loaded.
Chris Lemmons: I- I can pop the thing up. One second.
Sanjay Mishra: That would be great. Thank you. I- I do have it as a PDF, but I- I figured I could just share it, but it won't let me. I didn't upload the PDF file.
Chris Lemmons: You bringing up-
Sanjay Mishra: There it is. There's the Note Well. So, just like as any standard IETF meeting, this is a- an IETF meeting. So, it is important for us to Note Well, and this is what you see here. Uh, please make yourself fully aware. Um, it lays out various different rules and you can click on those links. Talks about IETF guidelines for conduct, uh, anti-harassment policies, and your contribution to the IETF. So, all of that good stuff, including the privacy statement, is all- all in here. So, just want to make sure that everybody that is attending this IETF session is still governed by the IETF policies as noted in Note Well. So, I think with that said, we're good to go. And, um, Chris, let's see if I can bring the agenda, uh, or if- so, let me at least recite the agenda that, um, in keeping the time in mind. So, we've got, um, what we wanted to discuss in our agenda was to, number one, have, discuss if within the working group we can come up to an agreement to have a fortnightly, um, schedule for going over some of the important documents that otherwise are just sitting there. So, what, as chairs, what we were thinking is that maybe we can, um, schedule a series of interims where we essentially walk through the selected documents. And, and I think the, the ones that we think, um, are, that fall in that category are, um, the metadata expression language, processing stages, and also the logging document. So, we can figure out some schedule. So, we wanted to put that on the table as to how we want to proceed forward, given we've got these documents that are pretty voluminous and we need a way to, uh, schedule some time so that we can at least maybe set up a working session to review those documents. So, that's agenda number one. And, um, other topics that we also wanted to cover, um, includes, um, the, the discussions on where we are with the, um, control interface and triggers. And I know version 19 is out, and, Alan, you're working on version 20. So, we, we can, you know, sort of talk through that, so allocated some time for that, um, and figure out the, the next steps in, uh, revision 20 and, and whatnot. And then the other topic is also, um, the logging document. And I know it, it is also pretty voluminous and we want to get moving on, on that document. So, maybe that becomes part of the, uh, agenda topic as to how do we want to carve out time, um, and discuss that in detail. So, so, but I think, um, one is, is coming up with the schedule for that. And second is, um, at least, um, Ben, if you can walk us through what are the, the key parts in the logging document and what would be the best approach, um, we want to, uh, have to start reviewing the document. Do we review by topics and figure out who are the experts, you know, for that topic? Or we just really go linearly, linearly, you know, in a linear fashion? So, we can discuss, um, you know, just go pages by, you know, page and, and do that way. So, but maybe, you know, we, let's, let's save some time to discuss what you think would be the best approach, um, and just, you know, outline what you have in the document so that, um, we can sort of start to focus on what are the key parts of that document. Um, what else is on the agenda? I think that, that is all we have. Yeah, logging, um, and we also kept time for metadata expression language. Uh, I, I'm not sure, let's see who all is here. Um, if I can see. Um, Alfonso, Ben, we don't have Glenn, um, so need to figure out how we want to handle the metadata expression language document. Um, but these are the three areas we have, plus, um, any, any agenda bashing, anything that we think we should be, uh, discussing on agenda.
Chris Lemmons: I'm going to suggest that with, uh, Glenn unable to make it, that we table the metadata expression language, um, discussion. Um, there isn't a big update to that document to discuss anyways. So, I think we probably want Glenn here for that conversation.
Sanjay Mishra: Agreed. Yeah. Okay. Um, so maybe we rejig the agenda a little bit. Um, maybe we, we go through the item number three first, um, sort of figure out how we want to handle the logging extensions document. And be we can converge on the next steps on the CI, uh, control interface and triggers. Um, and then basically item number two, we, we sort of defer until, uh, Glenn is available to, uh, discuss that. Um, but I do have one, one topic that we didn't add on the agenda. And, uh, I know Alfonso is here and we thought maybe we can use the first few minutes of this call to just get an status update, Alfonso, if you could, you know, come up to the mic and just talk about, you know, where you are with your document and, uh, what are the next steps. And what, if anything, that the chairs can do to help, um, help move forward, you know, given there were substantive and good comments that were, you know, posted on the mailing list. So, just wanted to see where you are and if there's any way chairs can help.
Alfonso Silóniz: Yeah, Sanjay. Hi, everybody. Um, yeah, the, the activity around this document is what you have been seeing on the mailing list. So, there has been received, uh, several comments. First, from the, we have some comments from the IANA, um, registry. Then, um, we also have some comments from the IESG, sorry. Um, but yeah, then, then some ballot was open for the last call, um, and then in that point is where things were getting tricky for me. Um, but I think it was progressing, um, in a good, in a good way. Um, the main, the main concern in the, in this ballot, and there were some discussions opened, is regarding the, the Fetch specification in the document that come from the, um, from the Web standards. Um, because, um, the thing there is that this kind of standards are not versioned, they are live standards. So, the, the main point of discussions were how to refer. First, that it was indicated in the draft as an informative standard and not, not as a normative. Um, but the, the second point was how to refer to this live standard. Um, on that discussion, um, and thank you for some comments in the ballot, it was found that there is a way to do that, to refer to those live standards, that was already proposed inside the IETF. So, after all that, I think I responded to all the discussions points, um, and now the thing is that I need to find some time to gather all the comments and to make the, the next changes in the, in the document, in the draft. So, uh, I addressed all the, all the points of discussions and all the comments. Um, so well, um, to be honest, I, I still don't know when I will be able to do that, but it's something that I have plans to do it in maybe in one or two weeks from now. Um, so mostly it's at that point. Um, but yeah, I think once I, I try to make a change in the draft for addressing this Fetch standard reference, um, probably I will, I will open discussion with, with you guys to, to check if, if it seems to be the, the way to do it and the way to, to address those, those comments in the ballot and try to unlock the, the last call process. Yeah, Sanjay, so I don't know if that answers.
Sanjay Mishra: Yeah, yeah. I just inserted myself in the queue. Yeah, so I think, um, what I would suggest is that the, the easiest way for making the normative reference for a living document is, is sort of follow the suggestion that was made. Um, you know, it, it may be straightforward, right, if, if there's a specific reference to, to that version of the document, you know, so here's the date, um, and, you know, the version number that, um, that goes with it. Um, and they've also given an, given an example of, uh, which says that do not reference this version as authoritative in any way, instead see, and they've given the link https://fetch.spec.whatwg.org/ for living standard. So, maybe follow that, um, for living document.
Alfonso Silóniz: Yeah, I think, well, the proposals, um, I can't recall the, the name of the person that, in fact, was having this kind of discussion on the GitHub of a different standard from the same organization. But basically, for do the, the reference, they proposed to use a GitHub, uh, commit, uh, snapshot of the standard to as, as the reference for the IETF document. Um, and it seemed to be in the discussions that that could be accepted by the, by the different people that has been opening this, for, for this discussion. So, I hope that we can follow that that already was proposed in, in one of the forum of the IETF. So, uh, I think that should be enough.
Sanjay Mishra: Right. And then the other, other comments are sort of, um, just, um, working through and making some changes. I think they're, they're not, um, as heavy lifting as, you know, this, uh, one on the normative reference. So, hopefully-
Alfonso Silóniz: Hmm. Yeah, exactly. But there are, um, a lot of them. So, I need, the, I mean, that was great that there was a lot of reviewers making comments, um, but I need to do the reconciliation of all of them because, uh, uh, I need to be sure that if I change something, um, that is referring by one of the comments, that it's not breaking other of the comments or it's the opposite. So, I need to reconcile all the, all the comments in one. So, uh, they come all, all at the same time. So, uh, I need to, to think carefully. Um, but yeah, the idea is that I will address all of them, um, um, in a new draft version.
Sanjay Mishra: All right. Yeah, that, that sounds good. And if there's anything that needs to be discussed in the mailing list, then, you know, feel free to, uh, do that.
Alfonso Silóniz: Okay.
Sanjay Mishra: Okay, um, so that's on the metadata access control. Um, the other two items that we have on, on the interim that we want to discuss, um, before we go into the scheduling, um, Ben, with respect to the logging document, um, do you think this would be one of the documents that we want to, um, put up for reviews and talk about some scheduling? Um, and what, what are your thoughts as, as the best way to start reviewing this document?
Ben Rosenblum: I mean, people just need to read through it and give their comments on the mailing list. That hasn't happened.
Sanjay Mishra: Yeah, yeah, yeah. But I'm- so, one of the thoughts we have is that to, to sort of get everybody involved, um, in reviewing, maybe one of the options on the table is that we, we schedule, um, regularly scheduled, um, interim where, um, we walk through section by section or, you know, in a linear manner or by topics if that makes sense to maybe, you know, devote, you know, 20-30 minutes, you know, of the session to just go through the document, you know, start, you know, maybe if we go in a linear fashion, we really start from introduction and, you know, on down. That would be one approach. Um, but definitely open to others. What, what you think?
Ben Rosenblum: I mean, we could, we could do that. The, the- I'm not sure, like, if we have people who are going to guarantee participation in that, then I would be willing to put the time into that. But, um, I mean, you see how small this group is right now. So, I think everyone in this group has, uh, has at least gone through the document. Um, I'm not really sure what to say, Sanjay. Uh, like, going through line by line on a call, I don't feel is going to be productive. I, I think people, we need people who are just going to go through the document and write down their comments, like we do with every other document.
Sanjay Mishra: Yeah, and maybe, um, maybe then we, we divvy it up in a way that assign reviewers, you know, for a section and they focus on it, um, so-
Ben Rosenblum: I mean, we can do that. Um, everything's pretty interrelated, though, so I don't feel like you can look at a portion of the document in isolation. Um, you can certainly if you were doing, like, a line-by-line review where you're checking for nits, sure. Um, if you want to do a review at a conceptual level, I think you need to thoroughly read the entire document.
Alan Arolovitch: Uh, to chime in quickly, right? I think just, uh, my experience with the triggers has been that the review has been a- uh, document move forward with reviews. So, I really appreciate the work that Kevin, you did, kind of putting and reviewing the document. So, every time that moved the document together, there is value in once this review is out, that somebody reviews the document, has comments, maybe questions, then getting together on the call and re-kind of discussing them, like, oh, I don't think this right way, well, we think this way, having that discussion. But that's a follow-up to review. I think once review is there, getting on the call and maybe, uh, you know, ironing out some issues, uh, verbally makes sense. Uh, reviewing together on the call never worked.
Ben Rosenblum: Agreed. I don't know, so you, you tell me how you want to proceed, Sanjay.
Sanjay Mishra: Any, any other thoughts, uh, Kevin, Chris?
Chris Lemmons: Yeah, so I'll echo what Alan says. Um, uh, I- I think that we just- I think we really need to get some folks to buckle down and read the document. I know it's long, um, but there was a lot of effort that was put into producing the document. And if we want to get it over the finish line, we're going to have to put some effort into reading, reviewing, and really going through it.
Sanjay Mishra: I agree. Though, I- I don't know, you know, motivating people to go and read it is a different problem. And, um, yeah. There, there are probably some chunks that we could break out, um, just, you know, but if you're going to go through all the fields, you can still go through all the fields. Can you have someone review just the- just Section 4 and someone review just Section 5? 6? I don't know. 6 and 7? Just to get them started. Yeah. So- so, I think what- what I'm- what I'm hearing is that, um, stick with- with the- with how the process is and we just need volunteers to review the document and put comments on the mailing list. Although, um, and so that- that itself is fine, um, and I'm- I'm definitely willing to review. So, um, and I can spend time on reviewing the document. And the- the question is that, uh, follow-up, um, in order to make sure that, you know, we're progressing, do we set some milestones via interim calls and- and just, you know, so we have a date that we're working against and then the reviewer basically- I'm just trying to think that, um, what is the best way to make sure that the reviewer is- is sort of on the hook and, you know, we move things by the date.
Ben Rosenblum: We- we already have a milestone for the document, don't we? I thought we had the milestone for the document. Yeah, we do.
Sanjay Mishra: Yeah, we have the milestone for the document. Yeah, we do, for completion, but, um, just thinking if- if having an interim is going to help or- or, you know, or just review and put the comments on the mailing list and, you know, just let- let that be the process.
Alan Arolovitch: It could be that if there is a review that's due before, then I think it's good, then I think it is, that drives people to do that, right? To- to kind of- if they're on the hook for something that's faster than IETF meeting. So, having one or two interims to which, you know, reviews are due, and then as an opportunity maybe to discuss the review, I think it's useful. Uh, but certainly not bi-weekly. I think that's, you know, a notion that- I don't think we have, you know, the collective energy around the table to do bi-weekly meetings. So, a couple, if there's, like, kind of somebody's- like, somebody kind of gets up and says, yeah, I'll review that by X, and then at X we have a call to review that. I think that will drive, uh, reviewing and will move the process forward. But I would ask for maybe one or two interims between IETFs, if- if that makes sense.
Sanjay Mishra: Yeah, fair enough. Um, so nothing new basically. We continue to- everybody picks a document that they want to review and, you know, they do that, um, and put their comments on the mailing list. Um, and as far as the interim scheduling, interims are concerned, what you're saying, what I'm hearing is that maybe if we need to make sure that the reviewer is on the hook, you know, maybe have it sort of like a monthly check to see, you know, make sure that before the monthly check the comments are posted, so if there's any clarification, you know, then those can be discussed, um, in the interim, but- but leave the process as is, you know, ensuring that we have a reviewer for a document and then have them go through the review and make sure that we are aligning the review with the milestones that we've already laid out.
Alan Arolovitch: What I'm proposing is- I don't know if that's monthly, but I'm- I'm proposing, I think having interim is great, right? I think it's a good idea. I'm happy that we are here today- today, right? Uh, what I propose to use it is to say for every document we need to move forward, have people who are will volunteer to review, and that by next interim they will have to review. Okay? They come in and then they kind of- by the time this is there, and we can jump on the call and- and talk about it. And I think that- between IETF we usually have what, like, four months, right? So, if we have every four-six weeks have an interim and somebody has to complete the review, I think this will help. I propose we do that. Not- not a monthly check, but have a call. Kind of, you have to show up among your peers and say, yeah, kind of, I did it, here's my comments. Or no, I didn't, and then you have to stand in shame that you committed to something and didn't do. Shaming people works.
Ben Rosenblum: True. I'm looking for my laugh emoji button and they don't have it in this interface.
Sanjay Mishra: So, I think milestone-wise, um, the biggest documents that we have, um, the earliest one is- where's the milestones here? Bring them up. So, the control interface triggers is for May, and we're going to get to that document. Um, that's on our agenda to talk about. The other is July for draft-ietf-cdni-delivery-metadata. So, I think on- on that document, it's- it's on my to-do list, um, to review it and post comments. But as far as determining the- the status of that document, whether that goes into the Working Group Last Call, is really dependent upon what, you know, the reviewers, at least including myself, you know, put out as comments. So, the- the comments are due and that will drive, um, the next steps on that. But we have that at least for July, so we leave that and I'll- I have that on my to-do list. The other document that we have for July is the protected secrets metadata, draft-ietf-cdni-protected-secrets-metadata. So, we have that for July. Uh, the idea is at least not for the metadata document because I'm not sure if- if that's going to be Working Group Last Call ready because it hasn't had comments. But with the protected secrets, Ben, is- is July a reasonable timeframe for making the changes that have been discussed, um, and sort of a- a path forward that was discussed?
Ben Rosenblum: What is- what is the exact deadline?
Sanjay Mishra: Well, I think the idea was to try to, you know, take that to the Working Group Last Call, um, at the next IETF, which is in July.
Ben Rosenblum: Yeah, when- when in July is that?
Sanjay Mishra: Let's see. 18th. July 18th through the 24th, yes. Yeah. A week before that, if I look at the schedule, uh- important dates and deadlines. Agenda. So, the submission has to be before July 6th. That's the cutoff date. July 6th is the cutoff date. Um, if- if that's- I think if- if that is completed, um, prior to July 6th, um, I think we had- we had thought about maybe doing a- before doing a Working Group Last Call, um, we- we want to have a review. If you submit a new version, have that reviewed in the working group and then send it for a SecDir review. And depending the outcome of that, um, decision can be made about the, um, Working Group Last Call. Does that sound like a, uh, plan forward?
Ben Rosenblum: Yep.
Sanjay Mishra: Okay. And then moving down the list, uh, September 2026 is the, uh, submissions for metadata expression language, draft-ietf-cdni-metadata-expression-language. And, you know, the whole discussion on this is tabled because we don't have the, the author. But that's at least the timelines that we had put that on, that document. And then logging extension, Ben, draft-ietf-cdni-logging-extensions is targeted for October. Again, it was timed in a way that we can, if that's completed by that time, um, reviews and- and updates, um, then that could be teed up for a potentially a Working Group Last Call, um, prior to the November IETF. Which is in San Francisco and, uh, that I believe is November 14th through the 20th. So- so, I know it's not for you to say yet until we have reviews done. So, the question is that for logging document, if reviewers can start to review this so we have time to go through iteration of reviews between now and- and October. Comments? Anyone? All right. So, it sounds like there are no objections to that. And I think after that is December 2026 that for- that is we're targeting CDNI processing stages, draft-ietf-cdni-processing-stages-metadata document. At least through the end of this year and, um, we need reviewers for that. And we have some time for that between now and- and December, so we can defer discussions on that. Um, so the- that's- that's the- the milestones at least for 2026. Um, so if there are no comments, then maybe we can switch back to what are the next steps for control interface and triggers.
Alan Arolovitch: Uh, sure. Happy- happy to address. Uh, so where we at? Uh, just like a- I'll add a meta comment, like, I've been, like, pushing it towards, a lot, you know, Working Group Last Call for over a year now, and I think now objectively we are looking like we're converging because I'm looking at the amount of reviews that came in after the last draft and they are, you know, dramatically reduced in size. Uh, so, um, there are two sets of comments that we need to address in the version 20. One that came from Jay, my kind of co- co-author on- on that, um, and the comments from Kevin today. Uh, so I'll talk about Jay's first because what happened when we- I published draft 19 without having him fully review that. So, these are kind of comments that came right after and I have mostly addressed them. So, um, apart from several grammar errors and nits, and some of them Kevin you saw and we already have them and some others that he caught that were not there. So, there's a bunch of those. Uh, substantively, I think there- I'm looking just at the- we working in GitHub. So, just watching at what's- what changed in 20, in current, which is work in progress 20 compared to 19. Uh, there- there- one JSON format issue in one of the FCI objects. We publishing CI TURL type and just the way we built it was not- didn't align with others- other objects. That typically we have capability type, capability value, and the value itself is a kind of key-value pair and it was not in this case and we fixed that. So, there's a capability value itself is a CI TURL types and- and the list. So, that's one kind of, you know, nit but more semantic nit. Uh, one issue we need to resolve and I'm- I'm waiting for Jay really to chime in on that before we can come forward is, uh, returning errors. Uh, right now in the triggers, uh, we have two ways that we can reject triggers and we need to figure out if this is okay and how we want to align that. Uh, historically the way that CI TV2 was built, again this draft to remind everybody started twelve years ago, uh, it was built around the notion of basically triggers get created, even if they are in a bad, you know, in wrong state, and then there is a elaborate list of error codes that you return back and saying, well, I create triggers but it got created in the error condition and here is the error. And there is a like a list of custom error no codes in the document that lists that. Which something we have to have because, again, this is asynchronous framework, so things can go wrong at a later stage. Like, I came- I took trigger for processing, it went bad, I came back and here is the list of errors, so there is no HTTP semantic to deliver that. So, I have to build in JSON objects basically to return the statuses. So, dcdn reports back to ucdn I process that and here is what happened, here is error no, there is error v2 object and the list of codes. That's one way. Kind of, over last I guess ten drafts, we've been working heavily towards shifting this spec towards more RESTful semantics. Uh, so another set of errors, and in the recent draft we elaborate on that, is built around REST. So- so, I'm coming to create a trigger, there's immediate error, uh, the kind of error codes that are returned are HTTP error codes. This is not a JSON payload, like, basically the create- kind of REST call fails right away. So, there's two ways. And I think in some places in the document right now, there's a old way, like you create a trigger and it's created in a error- error form and we return error there. Another is basically we fail it right away, so the HTTP return code is not 200, but actually get rejected with, uh, mostly usually 400. And, uh, I think there's a value for both because I think it's- sort of- I don't think it's a good engineering to allow things to- kind of HTTP error code to be 200, but that's actually error. I don't think that's good. I think if you kind of know right away that this is an error, I think you should return it in the HTTP return code, right? And not create an object, or not allow modification, which also something that's new that- modifying triggers something we allow right now. So, if that- you cannot modify that, I give you an error should be right away. Uh, but we need to create a guidance, to basically align set of in which when do we do that, when do we do kind of HTTP return code, and when we do kind of this, you know, returning error objects which provide kind of custom custom statuses. So, this is an issue that I think we need to work through. It's probably most substantive that I see in what's remaining. Again, just aligning- aligning on guidance and so on. But just to give idea, that's I think what we're handling. Uh, I think the rest of that is just grammatical and uh, there's some language kind of enhancements sort of clarifying some things that maybe didn't get clarified, so like three or four places where we do that. So, that's kind of Jay's- Jay's batch of comments and I'm waiting on Jay actually to review that and discuss this issue with error codes that I just described. Uh, switching over to Kevin's comment from today, so I wanted to address them. I read through them and I think it's great that we have this opportunity to talk about it. Uh, just let me pull it up. I had it and it's gone. Right. Uh, so kind of all grammar stuff, like, is either, you know, there or already or will fix it kind of no question about that, accepted and appreciated. Uh, about labels, right? So, 4.4.2 from interoperability perspective Kevin says, I'm not a fan of opaque strings with semantic encoding. How do ucdn and dcdn negotiate a common understanding of labels? Uh, so, um, the notion I think here that labels are there, this is a pattern kind of heavily borrowed from other frameworks like Kubernetes, for example. So, the purpose is not so much as transmit a meaning that's in- kind of that's kind of negotiated out of band. It's mostly there to support monitoring and selectors. So, I can create, let's say- assume you have a bunch of- one use case, right? But I certainly don't want to limit to this, but I want to create a lot of triggers and they may be coming from different types or even different purposes, right? So, I'll be able to create some custom labeling and then observe or select statuses only for those that I- I care about at this moment, let's say I created purge- purge triggers that deal with video, and I'll be able to create a custom- a custom label so the only purpose- so, it doesn't affect processing. There's no- nothing about labels that will say kind of, hey, take this label and do something different about it, um, kind of at this stage, right? Kind of- and I'm qualifying at this stage, uh, I'll talk about it in a- in a second like what- what's maybe coming down, right? Uh, so right now we just want to be able to create labels, basically color triggers and then with the framework to able to selectively poll kind of statuses or select triggers based on these colors. So, there's no suggestion that there's some different processing. Kind of in the future, I think we want to use this kind of for explicit in-band signaling. So, there's some extensions that we've been working on in the SVTA and we plan to bring them forward to IETF is notion of, for example, take a label in the trigger and do a thing. So, for example, one of the things we wanted to do is to apply labels to objects. So, you can actually mark objects, so let's say I'm repositioning something, I'm coloring a trigger particular way, red, right? And the same color will apply to objects and therefore they can be then, for example, purged later based on this color. But this is exactly, I agree with you, I think it's out-of-band thing is not a good thing, certainly in the standard. So, kind of future uses in which we can add extensions and this is something this standard adds, is where you can kind of create, you know, in extension you create a new understanding of what labels should mean, but this is kind of then transmitted separately in- in the extension and say take the color and do this thing and kind of dcdn can say, I don't understand this extension, go away, I don't support that. So, there's whole in-band negotiation of capabilities. But labels generally I think it's- it's- thing that I'm quite fond of. I think it's powerful mechanism, sort of on par with extensions, and it's something we want to use I think in the future for kind of creating more kind of custom processing using extensions. Uh, but again as a baseline is just color and select based on color, right, based on label, which can be custom- custom strings.
Chris Lemmons: Alan, do you want to take questions as you go and have the conversation as you go? Or do you-
Alan Arolovitch: Yeah, yeah, yes please. Kind of, yes, absolutely.
Chris Lemmons: So, I don't have a problem with the color concept. My big problem was having key=value and specific length requirements. And really it's the key=value because it implies that you need to know what's inside this string and how to parse it. And it's not clear to me that that's necessarily useful in all cases and it begs the question, well, what are those keys and values and why aren't they defined? Um, if it was just a string and it's a label and we say use it as a label, don't try and infer anything from it and maybe you want to later have a spec that says, hey, by the way, in this particular case, take this label and parse it this way and it means something. That might be okay. But right now it's very confusing to me to say, well, this an opaque thing, but actually it's not, it's a key-value pair and you have to encode it in this way and I'm not going to tell you what I'm going to do with it.
Alan Arolovitch: Right. So- so, think of it as a- as a color. So, I think if, again, if this is confusing, I think it- it warrants kind of explanation, right? But I think the purpose is really to say, so then later I can say, show me all triggers where key=x, right? Because I think basically because labels are in an array, so this is really- think of it in the same way as- it's- it's a collection of- just as HTTP headers, you have header and a value. If I want to create a match expression, I want to have a key-value pair. So, rather than saying, uh, uh, just value, right, I have- it's more- more powerful selector, but nothing beyond that. So, we're not suggesting that you need to know what the keys are and so on. So, ucdn comes, creates objects, colors them, and then is able to retrieve subsets of objects based on those selectors. That's it.
Chris Lemmons: So- so, I guess two questions. One, why not have an object that is key-value instead of this string encoding with length requirements? And two, I think if you don't define what the keys and potential values are, or say something about it, it's going to raise questions for other reviewers as well. Like, because it's not clear to me how to use this thing. If it was a label that was an opaque string, fine, I understand how to use it. If it's now this key-value pairs, I have to ask, what are the keys and values and what are you going to do with it, right?
Alan Arolovitch: But how does that different? Like, if all I'm doing is I'm saying my- my labels are not single string, but this is a- a pair of things, right? So, I'm just allowing match- I can construct match- match expression. How this really different? Like, again, I- I just substantively, like if we having this discussion, it should be in the document, right? Uh, so that's clear from reading it, not from discussing it. But, based on this discussion, do you think that we need more than kind of- again, we- we could create a key-value, I- I don't mind having this instead of having as a string, we can package that into an object, but that doesn't really change much, right? It just- you know.
Chris Lemmons: No, my- my question is really why do you need key-value? Why can't it just be an opaque string? And then Red works. It's not Red. Right now it's color=Red. And I have to know what that means.
Alan Arolovitch: Um, let me think about that. I think that just off the cuff, I think that this is something that if I know that this is of a particular structure, then I can create a match expression. So, the whole idea that I should be able- not the whole idea, but part of the idea that you want to be able to match things, right? So, show me- take this action in the future based on and only apply that to take triggers that have this- that matches, right? If you have a match- kind of I can do more broadly and allow matches that are kind of different and say basically label kind of only show you label that's X. Um, but why- kind of, why not? Kind of why- why- why do we need- why wouldn't we just take this, uh- that's one construct where kind of you saying my labels are key-value format and then based on that I can create match expressions in which key=value.
Chris Lemmons: I think only because from an interoperability perspective, you've placed a requirement on the CDN to parse this in a specific way and it's not clear why.
Alan Arolovitch: So, then everybody can create kind of powerful match expressions. I think that's- that's the why. Kind of if I didn't do that and I just allowed just a array of strings, then I would be limiting myself, I think, because I wouldn't be able in a standard way create an expression where matches that, where I'm saying, for example, right? As I, as ucdn, want to create families of labels, right? For example, there is type of trigger that's again entirely of my doing, right? I'm- I'm kind of- I'm applying that, there's no understanding of what it is. But there's Type, and there is, let's say, for the sake of the argument, uh, content type, okay? What I'm doing, whatever. Or Department, right? There's Department and there is Type. And then I want to be able to match- create expression which says, show me department=News. Okay? I want to match only that. Because I'm- that's the- and for that you need to have key-value. If I'm only doing strings, you cannot do that. And this is, I think, the best analogy is actually in our world is HTTP headers. I want to say the header- the header X, the value is Y, only match on that. If I don't- if I only have a string, then actually what it will lead me is to be able to match the whole string. I won't be able to match kind of type to value. So, that- that I think is the rationale.
Chris Lemmons: I guess it's not clear to me that that's true, but I- I'm fine. I don't think we need to continue discussing this. I- I don't particularly like it. I don't care. It's fine. Um, but I think it probably needs a little bit more explanation.
Alan Arolovitch: Okay, yeah, sure. I'm- I'm happy to kind of, again, to- to be- kind of, you know, think about it some more and like come up with maybe something that's- that's clear.
Chris Lemmons: Yeah.
Alan Arolovitch: Uh, but I understand- I think I understand now kind of your point of view. So, we can- we can kind of try to accommodate that. Um, so there's- that's one, I think, and the other was about flattening, right? Is that why kind of- so there is in 4.4.2, right? There's a language that says, um, kind of- we using object lists in several places around the spec, right? So, one- one kind of use of object list is actually to feed data into trigger in a structured way. So, I can say, I can construct potentially a custom document, let's say I have a JSON document that includes a bunch of manifests, I can and have JSON of JSONs. So, the idea is that to allow dcd- ucdn to pull in existing objects or build complex list of objects that can feed into triggers and make basically dcdn enroll its complexity of this to dcdn. So, it's easy for ucdn to pull meta- manifests or some maybe custom custom list of objects that are already used in the ucdn workflow to pull it in and make the trigger itself simpler. So, you can actually refer to list of objects by URL and that URL by itself can again include multiple things. So, that's kind of the initial rationale. Uh, and the same way on the return, right? There is a value for dcdn to come back and say, uh, you gave me this list of manifests and that's what I rendered out of that because that's rendering that has to happen dcdn has to basically pull on the manifests, kind of decode them, find out which files are there and come up with a list, right? Uh, and the purpose of the return is to say you gave me this complex input and that's what I decoded and I think this is to support troubleshooting and debug, right? So, there's some let's say some manifests were not available or they not a correct version, so we can find out like I- I thought I gave you a million files and I got five, what happened? Right? So, this is a debug tool. As a debug tool, it's good to sit there not to give back a complex- so actually change- flip the coin and say instead of building structured list of objects to return flat list of objects so you can actually look at what the complex input resulted to- in, right? So, this is a- but at the same time disabling kind of a recursiveness all together probably is a bit too much because for example what I can do is I can come back and say and point that to a- like I decoded a list of objects and I put it into this URL go fetch it. So, it's not actually in the body but it's referred to. Or things like that. So, I think it's more of implementation recommendation, so that kind of would be hey, we trying to support debug here it would be better if you gave it flat, but what is exactly flat what level of flat is- is kind of coming in and enforcing something very narrow maybe not useful, right? Maybe kind of allow dcdn to let's say put together that maybe this is something ends up being three files instead of one, right? Or something like this still usable. So, we're just saying we recommend that whatever you produce, make it operationally efficient as a debug, but kind of go and try to flatten that to the extent we want, but not really mandate that. So, I think that's where recommendation came from is that- but it'd be better if you did that. I think that is implementation recommendation, but we don't want to really force that strictly that it has to be flat exactly. Because for example, I could be- I could for example collect that from different regions and I don't want to like dedupe the files, whatever. So, there can be a reason why it could be somewhat flat but not fully flat.
Kevin Ma: Okay.
Alan Arolovitch: Um, so I think that's the rationale. I think everything else is just we kind of I think kind of the double-T triggers, for example, we caught that. So, yeah, everything else I think will go into version 20. So, yeah, thanks for that.
Kevin Ma: Okay. Thanks.
Chris Lemmons: Awesome. And I think we're going to have to take the rest of the list because we are at time.
Sanjay Mishra: That's right. We passed one minute. So- so, yeah, take it to the list. Quick question. So, I think between now- this is towards the end of May. Um, I don't think we have time to schedule any other interim, um, until we meet.
Chris Lemmons: I concur.
Sanjay Mishra: Yep. So, we- we will just continue the dialogue on the mailing list for reviews and other issues that come up. And, um, I've already scheduled one hour for- for the session for IETF 126 in July. So, we'll definitely meet there and, um, come up with the agenda items. But in the meantime, thanks everybody for participating and sorry to keep you two minutes over the- scheduled session. Thanks everybody.
Alan Arolovitch: Thank you. See you.
Alfonso Silóniz: Bye.