Session Date/Time: 20 Jul 2026 09:30
[00:00:35] Chairperson: Good morning, and welcome to CDNI. If CDNI
[00:00:40] Chris: is not what you're planning to discuss, then you may be in the wrong room, and we invite you to stay and learn something new. Alright. This is the note well. We are on Monday morning. If you have not seen the note well and are not, have not yet noted it well, then please carefully read the relevant documents, not all of which are on the screen, but all of which apply and are very important. Some meeting tips. A lot of these are most important for remote participants. Make sure that your audio and video are off unless you are sharing, and headsets are strongly recommended. Please do make sure to sign in via the data tracker or the QR code in this session. You want the in person tool if you are sitting in this room. If you connect with the full audio and video and you don't have your audio and video settings set correctly, this meeting becomes very noisy very fast. So please don't do that. We actually don't have an agenda slide on here.
[00:02:25] Sanjay Mishra: Keep going down? Yeah. Keep going down.
[00:02:33] Chris: Yes. So the agenda, starting off with administrivia. That's where we are now. We're going to have a conversation about the CI/Triggers draft from Alan. We are gonna discuss protected secrets and see see how close we can get that to the finish line from Ben. Then we will have a good conversation on MEL and where that is and where that's going, then logging extensions, and then we will have any other business at the end. Does anyone have any agenda bashing? Would somebody like to operate in a different order? Hearing no objection, we will continue. You wanna talk through our milestones and see where we are? Yeah.
[00:03:40] Sanjay Mishra: Alright. So I'm Sanjay Mishra, one of the co chairs, and just wanted to give a quick readout on where we stand. And it's important from the standpoint that we have a lot of documents, and we wanna make sure that we are keeping up with the pace of how we wanna move. So the so there are a couple of important documents that we have that basically drive some other documents as well, and that's processing stages and MEL. So these are the two documents that we're trying to keep our focus on to get those two draft going that will allow us to then proceed with other three or four documents that actually rely on that. So that's one of the folks we have. We wanna have the working group to focus on. And what you see here, though, this is just in the order of the milestones that we have published, And we're probably gonna have to adjust the milestone based on, for example, the control interface and triggers. We had that for May. We're in July now. But I think the good news is that there's been significant progress there, and then Alan is gonna talk about it. So, hopefully, today, we can get a better sort of sense of the timing, and then we wanna try to, you know, keep with that pace for the the timing, whatever we agree with. So it's gonna move from May, but we're gonna, you know, already we're July, but we'll figure that out. The other things are, the first document on the list. Alfonso is not here, but the document is is progressing. He has submitted, based on the IESG reviews. So I think we're we're kinda close to it, and, Gorry might have a have a sense to what that is, not to put you on spot, but, at at some point, you can sort of speak up to that point where, you know, if you have any concerns or things that we need to be aware of, Gorry, on the document. I think
[00:05:39] Will Hawkins: the
[00:05:39] Sanjay Mishra: rest, are, let's see. Yeah. The metadata expression language and the and processing stages, those are the ones we wanna work on. The others, we have put in some comments like the protected secrets. There are new set of comments, and we'll have Ben reconcile, you know, the the older comments and the new comments that Chris has posted to see where his draft is with that. And then Kevin has a lot of comments on logging documents. So, hopefully, Ben can sort of, go through those and and figure out, you know, how that aligns with the timelines. We'll adjust that. Next page. And I'm I'm trying to see if I can quickly wrap this up because we have one hour only today. The other one, processing stages, we covered that. Cache control, I I think we can start to review that document. We had pushed that out to February because of its reliance on processing stages. The and then there hasn't been much progress on the client access, so we've also pushed that out to June 2027. And same thing with the source access as well. And the c d n name name footprint is on the back burner right now until Alan comes back with something more updated on that. And so I think for this year, for 2026, page one has pretty much all the ones that we need to be focusing on. I think that's all. I was gonna offer questions, but I don't think we have time.
[00:07:10] Chris: And as a point of order, before we can move forward, I do need someone to volunteer as notetaker. Ideally, two someone's that can collaborate, especially if one of those people is speaking. Do we have any remote people that can, volunteer as notetakers?
[00:07:37] Kevin: I'll take notes.
[00:07:39] Chris: Fantastic. You are your favorite person.
[00:07:43] Will Hawkins: I can also help, from remotely. I'm sorry. I just didn't know the protocol. So
[00:07:47] Chris: Absolutely. Nope. That's that's exactly how it works. If you have any questions as you go, we'll be monitoring the chat as well. And if you would like me to say something in the mic, on your behalf, preface it with Mike in the Jabber chat, and I will, voice that for you. Let's try this fancy next deck button. It's new. Oh, it didn't work. And then I think, Alan, you can request control of these slides, or you can say next slide, and I'll hit the button.
[00:08:44] Sanjay Mishra: Can't hear you, Alan.
[00:08:47] Alan: Let me try to request that.
[00:08:49] Chris: Yep. We hear you now.
[00:08:51] Alan: Yes. I was muted. Request control. Request request screen share. No. Well, Chris, why don't why don't you drive it? Yeah. I'll I'll just ask for
[00:09:03] Chris: it.
[00:09:03] Will Hawkins: Yeah.
[00:09:04] Alan: That's easier. Right. So next slide, please. So we're gonna talk about the CI/Triggers version two statues. So where we are with this is a draft 19 has been published prior to the meeting, and we had our interim in May be before which Kevin kindly provided his review of that, and I kind of responded provided some response to the kind of at the meeting. So that has been integrated into a pending draft of 20. So I wanna talk about the current contents of that. So we have not so that includes kind of Jay, my co author review of the draft 19, responses to Kevin, comments, and some of the kind of internal follow-up that I'll summarize here today. So the plan is basically to to to finalize our internal review of this and then push it out kind of probably I'm I'm, like, optimistically August, but we'll we'll we have to see where actually where it ends up. The review is pending. What is the scope? As part of the review and things that came up, we knew kind of we noted that there's an an issue around inconsistent error codes, way we return return errors. So that's been sort of that drove the first two items on the scope. So changes in the two styles of error reporting that we have to reconcile and how that worked in cascaded CDNs where you actually have to kinda move errors from kind of across the chain of CDNs. Those are first and probably heaviest changes. But, also, I I wanna just point out just we are down to that. The these when I'm saying we're kind of driving to to, hopefully, the the draft 20 gonna be the last call one. So that's the kind of major change we we we having as opposed to, like, major rewrites we have, like, from draft 14 and onwards. Third item, trigger labels is something we discussed in May and kind of actually and initially, I kind of I defended the current position from Kevin had some questions and challenged that. But, ultimately, we actually cons kind of upon talking to Jay about it, we actually conceded into Kevin's position. So I'll talk about that. Key value strings. The rest are really minor things. So there's extended statutes enforcement language that we change. There is some updated language on counter aggregation and editorial, but I'll I'll go through them in more detail. So what what what's next for us is to finish review of this and and and publish draft 20. Chris, next slide, please.
[00:12:05] Sanjay Mishra: So
[00:12:07] Alan: error errors in two styles. Right? So the history of the draft have been that initially that was really created kind of as asynchronous for form of framework that lacked actually proper restful semantics. And part of rework we've done is actually building restful semantics, including some better support for changing modification of triggers and and certain condition and so on. So as a result, we ended up we have two styles of error reporting. And and one of them is actually upon API call, you you kind of d c d n can respond with immediate error providing four x x, five x x status code. And, for example, if you are creating a trigger that wouldn't be created, it's it's an error. Or if you're modifying that operation doesn't succeed, that's kind of restful or synchronous error. That's not sufficient because you do have situations when error happens later. So you take something for processing and something comes up later and you have to and the operation already started. So you have to report a tree a kind of an error, and there is actually quite developed framework for kind of advanced differentiated error codes that happens synchronously. And that's done by returning error v two description object in the trigger and then setting the stale the state of the trigger to failed. So in the past, what kind of we we kind of what we said one of the examples of two different style is that if the DCN didn't support the trigger action of spec subject, any any kind of parts of trigger were not supported, actually, trigger was created immediately in a failed state. That's not a good good good engineering. Right? So so it's inconsistent. So some places, we we are failing right away and others, we're not. We kind of and, accordingly, there's no that can be implementation specific, so interoperability hurts. At the same time, the on synchronous errors, we didn't provide actually enough detail. So we we would fail that. We would we wouldn't say exactly what was an issue. So those error v two extension codes that you can provide, for example, there's some issue with the extension. I'm not supporting those. Like, application specific error codes would not be returned. And thirdly, there was an issue with cascading. So you basically if you error is reported, if you have more than two CDNs in the chain, UCDN, transit CDN, and, let's say, another DCDN, one could be returning things asynchronously, another kinda synchronously. So how do you match that? That's that's enough. So there's three three issues we have to basically clean up. And our position, we take in the draft, draft 20, that for for all synchronous separation, whenever it's possible, this is a preferred style for error reporting and rejection because that that's first of all, that's standard RESTful HTTP semantics. So UCDN would build retry status monitoring. Did it work? Did it not? Where do I stand? And it's easy integration. So you don't create something and then, oh, only to find out that was erroneous, and then you have to come back and check for stuff later. So just if there's some if there's a problem, it's important right away, and there's no resources to clean up. Right? So there's nothing that created and full kind of it didn't do it. It it didn't get created. So so that's that's a good way to do that. Right? So so and we we kind of clean it up and and separated that. And, next slide. So all synchronous errors. Right? That's on kind of if there's something is known at the time that the the request has been made, And there are three types of request, creating a trigger. So if there's an error, it doesn't get it doesn't get created. If there's modification, it's not happening, so it's not modified. And if if you're trying to delete something, you can't. You won't delete that. So the operation will not happen. Error v two style reserved for only those situations when things happen asynchronously, which usually means that something has been kinda pending for processing, then you kind of you started processing, you encountered something. Like, you couldn't get retrieve parts of the content, kind of and so on and so forth. So any any lack of support for any type of trigger would have to be floated right away and and and not later stage. And to kind of remediate the situation of sort of two styles, but synchronously, kind of, you would lack this ability to provide extended statues, kind of what exactly went wrong. So we are asking that d c d n will return providing the error response body would return actually the existing error v two description in the body of the response, which provides the structured detail about errors reusing existing existing work that goes into asynchronous reporting.
[00:17:23] Kevin: Alan, just to note, you've only got two minutes left.
[00:17:26] Will Hawkins: So Yeah.
[00:17:26] Kevin: I'm not the one that's long. Thanks.
[00:17:29] Alan: So that's that's kind of the async versus sync. Next slide. Yeah. I'm I'm seeing the counter. So and the way we do cascading is that therefore, cascading embedding that in the error v two detail in the response in the cascading, what happens is that if you transcend the CDN accepted the request and for kind of and forwarded that down the chain, So it it will create a resource and provide to x x. But if it needs to provide an error on that and get it gets in Corneus rejection from down the chain, the old information is available. So there is no loss of information, and any any error information from down the chain is is propagated upwards. And that's and the sequence diagram actually includes that right now. So the this particular particular example. Next. On the labels, like, Kevin, you kinda pushed them back pushed on that and sort of upon looking into this. Right? So so the inspiration to this framework has been other frameworks. So Kubernetes in particular. So it's a way to create labels that that kind of provide a way to sort and select and filter. So do trigger selection was one of the key key use cases. But down the road, we certainly see other other ways where actually parties do agree about on the meaning. Right now, the only purpose of this is is provide kind of a container for selection. So I can create some triggers and then selectively pull them or check their statues. In Kubernetes, right, this is kind of it's some kind of context. You see this as being one string, and that happened to be not a data model, which was a mistake on our part. Right? It's it's just a way to serialize things. So these are presented the strings that kind of the JSON object in Kubernetes is a key value, and we converted that to this. So I think now you're seeing more of a kind of JSON object as opposed to just a set of strings in a particular format, which is our arbitrary. So so that went back to to where I think everybody agrees it needs to go. Next slide. And really, the rest is just kind of minor nits and fixes. And there was, a kind of some language around what happens if so UCDN can ask for extended statues. A DCDN has to advertise that. So whereas must, where should, the notion is that, yes, you can request it even if it's not been advertised. But if you didn't advertise as a DCDN, you have to kind of and you don't support it, you have to reject that. So that that's been clarified. Some typos in the FCI stuff. So the URL type support that was fixed, and the payload registry kind of kind of the down the road from there. Language on total attributes that it's it's accumulative. We recommend that it's it's the DCDM provides accumulation, including d c d m, including the chain. So if I got some counters from so if I'm have multiple nodes that report total number of objects, for example, so the recommendation is to provide it as accumulation, including ones provided by kind of a chain in the CDN. So the CDN downstream comes back with a counter. I sum it across all my nodes and sum it up. There's, like, three three attributes of this type language around that was clarified. We brought back recommendation to provide estimate. Kind of I felt that it would probably wouldn't be needed. Jay kind of pointed out that in industry, it's common that the CDNs do have an estimate even they cannot tell you when exactly that was finished. The stitches, they can provide an estimate, and it's a good thing to recommend. That estimate would be provided as opposed to just kind of, I'll do something and, you you you don't know it's when. And the rest of the tutorial. Really, this is where we stand. K. Pending review, I think we we're gonna push it. And at this point, I'm optimistic that that's gonna be last call, but I I was optimistic before. So we'll see how it goes.
[00:22:01] Chris: Alright. And briefly from Kevin?
[00:22:04] Sanjay Mishra: I
[00:22:04] Kevin: think great progress on the draft. Thank you, Alan, and thank you, Jay. I'm looking forward to the new draft. Just one comment. I did have Claude go through and look at the JSON, and it found a couple of just typos and bugs in it, I would just do that on the draft 20 before I republish.
[00:22:22] Chris: Okay. Great. Thanks.
[00:22:23] Alan: Thanks.
[00:22:27] Chris: Alright. Next up, we have Ben with protected secrets. Hello.
[00:22:39] Ben: Alright. No no slide deck for me. Can you all hear me?
[00:22:45] Sanjay Mishra: Yes. Yes.
[00:22:47] Ben: Okay. So the the change in this draft versus the last one is the elimination of references to HashiCorp Vault. So after all of the discussion back and forth on that, we decided to remove it from the draft. And now in its place is a generic external store type without reference to any particular vendor. So that was essentially a swap out throughout the whole document, and that's the entire scope of changes on the new draft. I do wanna thank Chris for, Chris for your detailed comments. So I will address those in the next draft. But, yeah, I I know you had you had done a review a few months ago, and I just had not had time to address all the many things you pointed out. But we'll we'll get that all settled for next time. And then I think beyond that, Sanjay, we had discussed that we need to have an external security review of this document. So that's that's the thing I'd like to settle right now and figure out how we're gonna do that.
[00:24:12] Chris: Kevin's in the queue.
[00:24:17] Kevin: Sorry. That was from Alan. I forgot to take my hand down.
[00:24:21] Chris: Well, then I'll join the queue and, respond to some of that. My first observation is that, this document is not ready for security review. We at least need to probably hash through some of my observations about the fact that we've got, like, one sentence of security config considerations. And given that this is a document for exchanging secrets, it probably needs at least two sentences or or maybe to point to point to documents that have lots of sentences. So I I think that we're we're directionally correct for sure, but we're not quite ready for to to ask the security people to take a careful look at this.
[00:25:03] Ben: Can I ask Agree? Can I ask the context of what you think we need to, have reference to in the document? Because we do rely primarily upon the RFC for the CMS format, which does extensively detail that format. I'm I'm so I'm not I'm not exactly sure what you're you're saying we should add.
[00:25:27] Chris: Yeah. So things like things like transport security and because this is going over the wire that should probably be discussed. The CMS format doesn't have allows you to kind of bring your own algorithm and has lots of algorithms that can be used, many of which are a terrible plan.
[00:25:47] Ben: Can we can we discuss transport security given that this is just essentially defining configuration object and not the medium over which it's sent?
[00:26:00] Chris: So it is possible to send these things over HTTP. We should probably say that's a bad idea. Right?
[00:26:06] Ben: Right. Okay. So a recommendation rather than a requirement?
[00:26:12] Chris: I I would argue for a requirement, but, that text isn't written, so I don't wanna I don't wanna argue about text that isn't written yet.
[00:26:25] Kevin: These are metadata objects. Right? So at a minimum, they should conform to the security requirements of the metadata interface.
[00:26:32] Chris: Right. And so I I suspect that we could, like, point to the security considerations for our metadata interfaces to do a lot of the heavy lifting. I I don't know that we need a ton of text, but we probably need to point to the right text.
[00:26:46] Kevin: Yeah. Okay. It should say something. A lot of documents just reference the metadata security considerations.
[00:26:51] Ben: Right. Okay. We can do that.
[00:27:00] Chris: Alright. We will be moving on and reclaiming our four minutes. Next up is the metadata expression language. Let me pull up the slides.
[00:27:27] Alan: Yeah.
[00:27:28] Glenn: Can you hear
[00:27:28] Kevin: me?
[00:27:29] Sanjay Mishra: Yes, Glenn. We hear you.
[00:27:31] Glenn: Yeah. So we'll go to the slides there if you wanna or if want to draw. Yeah. If could drive, it's just a few slides.
[00:27:39] Will Hawkins: Alright.
[00:27:39] Glenn: And then we are gonna after that, we're gonna cut to, Will Hawkins, and he's gonna share his screen. But we'll start here. Awesome. Next slide. Great. Yeah. So we just recently submitted, draft number two of this. The big change in there and thanks to Will Hawkins who's really dove in and started to look at look at this, and he'll he'll speak about what he's done. Something we'd wanted to do for a while, we there was a BNF in there that was originally done defining the language, and I just switched that over to ABNF, which my understanding is through RFC fifty two thirty four, that is the right way to do this for IETF drafts. I'm seeing a nod there from Chris. So good. And Claude helped me create the a, b, and f, so we'll review that a little bit. But that was very helpful. Some minor typos fixed and, something there's an FCI object defined in there that allows a a DCDN to define, which MEL features they support. And there was a little issue there that we cleaned up, so nothing that big. So, really, what I wanna get done over the next couple of months, depending on, you know, how much people's availability is, finalize that a, b, and f. The two major topics that Will's gonna talk about in, just a few moments here will be, things he had pointed out. Thank you, Will. Again, on some looseness in the documents about, or really, silence in the document about operator precedence and associativity. There were some of the that that's the big stuff. Some definitions of core variables, we need to clean up some things. There's a bunch of nits and other little items Will has pointed out, but not worth talking about here. Overall, this thing needs more review from working group members. I think as we pull together, the changes I've just highlighted into a draft three that we would put out, that would be a good time for people to to dig in and start looking at
[00:29:47] Will Hawkins: this
[00:29:47] Glenn: thing. And I think what I'll do is is we'll as we get a little bit further and maybe after we do a draft three or in going into that, I would like to set up a time where I'm really sitting there editing the doc, and a couple of people can participate, and we can, you know, do almost sort of a little group edit session for a few folks. Next slide. Yeah. So, you can go look in the latest draft, this draft two, but I just wanted to put it out there. This is the a, b, and f, generated completely by Claude. From the b and f, I've spot reviewed it. I think Will Hawkins has reviewed it a bit. It looks pretty clean to me now as we make some other clarifications. We may move some things around or make some additions to this, but this structure looks pretty clean to me. I kinda like it. It's there were and it it addressed some things that were not even in the original b n f. Like, right I'll just point out right at the top in expression, the parentheses expression, parentheses. Some of these other operators weren't even in the list there before, so it makes it a lot cleaner. Next slide. Yeah. So, Will, I'll turn it over to you in just a moment, you can share your screen and walk through your notes. But I'll just point out that in the current draft, there's a table that shows all the operators and their names and and what they do. The idea is simply to add a couple of columns there that that that identify the associativity and the precedence. And, without me wasting any more time here, Will, why don't you take over? You should be able to share your screen. The guys can help you with that if that's a problem, and we'll go from there.
[00:31:31] Will Hawkins: Great. I attempt I hit the request button, so I hope I did.
[00:31:35] Chris: I know. I'm I'm attempting to I think I have to stop the existing one of the
[00:31:39] Will Hawkins: Okay. Sorry for that. There we go.
[00:31:43] Chris: I Maybe?
[00:31:45] Will Hawkins: I I got I just have to allow things here. Hang on just a second.
[00:31:48] Chris: Excellent.
[00:31:50] Will Hawkins: Are you able to see that?
[00:31:52] Chris: Yes. We are. Yes. We see your entire screen.
[00:31:55] Will Hawkins: Okay. Well, then I will make sure that I'm not doing anything untoward while I do this. But thank you for giving me that chance to present. It's been really fun to to get to work with everybody on this. As Glenn said, I jumped in starting with the interest in doing an implementation, and that led me to seeing some opportunities for changes to the document. So I don't want to necessarily waste everyone's time going through the the knits of the precedence and associativity that, Glenn and I have sort of settled on as a straw proposal, but, they are there. And the the rationale for the decision for the the straw proposal of precedence and associativity is based on looking at the commensurate, I think that's right, operators and their precedent associativity in c plus plus, Lua, Rust, Python, Java, JavaScript, so on and so forth. So that was the the goal of our research was to figure out sort of approximately how they're done in most common languages and go based on that. The biggest the biggest variable here was the conditional or ternary operator. Some there's there is a little bit of variability in how languages define that, but we've we've settled on one of those as a proposal. The other thing that came up when thinking about the associativity and precedence was actually whether or not the dot, which is in the grammar as a way to sort of nest into higher order not higher order, but non primitive types, whether that should actually be an operator or should be defined directly in the language. And I think Glenn decided that it might be a good idea to have that be called out as a operator in particular. So we've also looked at how that associative precedence is handled in other languages and have proposed that here. I think there is a benefit of simplicity with not defining a particular access operator and just saying, look, here are the variables that are in these that are available in these expressions. They happen to have a period inside of them, but that's just part of their name. There is some simplicity in that. But, having a member access operator, I think, may give us some, flexibility in the future if we wanted to allow user defined types and make an expansion of the structured, composite types that we have, in the draft now. So, as Glenn said, we would really appreciate feedback on, these proposals and whether or not you think they would work. But that's really all I wanted to to say about, associativity and precedence of the operators. And so just in the interest of time, I would love questions or, you know, I think Glenn would be would be really interested in questions. But I just wanted to note a few things about the core variables as well. One of the things that is particularly interesting is from an implementation perspective. I didn't notice this until I started looking at the implementation. But in the draft, the headers are the the values of the headers are available in these core variables as rec dot h dot. And then in the draft, it says they are the next thing should be the header name. And header names have dashes in them and other things that don't particularly look like variables in any traditional programming language or in the way that other variables are specified in the document. So one of the questions that is outstanding, I believe, is how we should, normalize the header names for inclusion in this, core variable. I have, in my implementation, I have a straw straw proposal just to make them all lowercase and turn any dashes into underscores, but there's tons of options there. The other one that was very interesting was the opportunity in the expression language for, for instance, the URI. URI is accessible as rec dot URI. And if you access rec dot URI as a variable, that gets you the entire URI. But there are other core variables sort of underneath that as well. Rec dot URI dot query, rec dot URI dot something something something. And because each of those, you know, accessing rec dot u r I would have a different type, a sort of user defined type that has all the different components of the URI and rec dot u r I dot query, rec dot URI dot path, those would be strings. So having those those two things with two different types seems like an opportunity to, to to clean it up. And I sort of rhetorically asked whether we could change the ability to access rec dot u r I and get everything with making that only accessible as rec dot u r I dot all, for instance. But I think that's I think that's all of the major pieces for the associativity and precedence of the operators and, also the the big pieces of the core variables. And as Glenn said, we're he's done a fantastic job getting the grammar fixed up, and we've just got a few more things to to tweak out. And I'm looking forward to it.
[00:38:04] Chris: Most excellent. Alright. We've got a few folks in the queue. I'll start. With my chair hat on, I wanna thank you so much for coming and bringing your expertise and contributions here to the IETf. They are very much what makes things run. Implementation experience is worth significantly more than its weight in gold. This is this is very good stuff.
[00:38:31] Will Hawkins: That's how I got involved with IPPM and other places. So I love doing this kind of stuff.
[00:38:35] Chris: So Yeah. This is wonderful. I really appreciate it. I did have so chair hat off, individual hat on. I have some observations about the selected PCRE for the regex language. It's regex directed, not text directed, and we should probably have a serious conversation with the security implications of that. Also, it's not defined in a in a standard you can reference. So we should we should discuss the flavor of regex that is required in order to meet your goals. And second, we probably need to have a talk about the the the processing model. For example, you can create arbitrarily large variables in here that obviously a processor isn't gonna be able to process. We need to talk about talk through some of the implications of that. But I think that that I I think we're directionally correct. I think we're going in the right directions, And I think that all of those things can be specified by adequate text. We just need to be thoughtful about how we do that. And I'm not gonna put you on the spot and try to ask you to answer any of these questions right now unless you happen to know the answer, but
[00:39:54] Will Hawkins: yeah. I just I put myself in the queue because I didn't wanna violate any protocol. But
[00:40:00] Chris: Yeah. No. You ask me a question, you can answer. It's okay.
[00:40:02] Will Hawkins: Okay. Great. No. Okay. Alright. So and sorry about that. No. I don't wanna take over I don't wanna speak for Glenn or anything, but I'm just speaking as for my implementation status. But I think you're exactly right. I think the PCRE is very interesting, and I think, there is again, I'm not trying to speak for Glenn, but I do believe that that selection of PCRE isn't something that seems to be set in set specifically. And, also, I would be more than willing to talk to you about the sort of processing model that I've come up with in my implementation and whether or not we're generating code, whether or not we're interpreting, which is required, which is optional, and so on and so forth. So you've, I think, brought up excellent points. And, I don't wanna speak for Glenn, but I am absolutely here for helping do all of that. This is what I love to do and, you know, picking nits and making things very clear is is, I think, what what we need to do here. So
[00:41:00] Chris: Awesome. Glenn, you're up.
[00:41:02] Glenn: Yeah. Great. Yeah. Thanks a lot, guys. This is really good. So, yeah, I'm speaking on behalf also of my, former colleague from from Lumen level three, Will, who the other Will, who, who originally put this together. Was hoping he could join us. He he he's act we're all you know, obviously, level three is gone, but all of this work is based on work that Will and others had done at level three in the original, CDN implementation there. So he'll have something to say about all of this. I'm hoping that'll better get his attention. He did say he wanted to participate a little bit. His name is still on this thing. And I know that the Regex flavor, that was always looming within the SVTA of what we were gonna do with this thing. So glad that was brought up. Just a couple quick points on what Will Hawkins here had brought up. My feeling is that the rec dot header dot name that we actually should stay exactly with header names as those headers are defined. I don't maybe it's a yeah. They don't really look like variables, but they I think starting to change them and changing hyphens to other scores and other things may cause more confusion than it's worth. You know, we can hash that out a bit. And then I totally agree, the rec dot URI, which could be a monster. Maybe we just kill that and say, you know what? You don't that directly or maybe your ID, direct that URI at all. But I think accessing the URI as pieces, dot path, dot query, I think that's probably sufficient. Let's remember what people are trying to do here. You're using this expression language to examine a request or response to make some decision about how you're going to either allow or disallow that request or how you're gonna cache it or or, select what, you know, DCDN node to serve it from. So given that, I think we can probably, come up with some limitations there. I'll say when we when we do set up, like, some sort of a working session, we can also go through that list that Will Hawken just started of miscellaneous issues. I think, Will, that one document, that's probably a good place for us to just keep our running tally of stuff we need to deal with. So go ahead and put the PCRE, you know, issue in there. And I think he's got Will's got a version of that note doc that's open to edit so we can have others come in there as well. So I think that's it. We're on time.
[00:43:23] Chris: Indeed. Briefly, did you wanna respond, Will? K.
[00:43:27] Will Hawkins: I'm 100% in agreement I'm 100% in agreement with everything he said.
[00:43:31] Sanjay Mishra: Yeah. I think I I just wanted so I don't have a comment, but just a compliment, really. And I I wanna really say, Glenn, first of all, that you started this work. And so happy to see Will Hawkins, you actually implementing it. So this is really Chris was saying earlier, so I don't want to repeat myself, but this is really awesome. And just keep up the work that you guys are doing. One thing I do want to say on the record is that it'll be great if there's a volunteer that can give the name to want to review this, the work that Will is doing and Ben is doing. That would be wonderful if if this if there's an expert here that can review it. I think that would be very, very useful. Thank you.
[00:44:11] Chris: Alright. And, Ben, you are back up with logging extensions.
[00:44:21] Ben: Alright. Thanks, Chris. So the new logging draft is has no changes. It is a version bump from the last one to keep the document active. So I did see that we got our first big batch of comments. I wanna thank Kevin for his extensive review that he submitted very recently. So I've not had time to to go through that review yet. But I since we have a couple minutes, I wondered if we could just address the high level questions that that you had asked. So you had you had mentioned that, I'm just bringing it up here, that you thought we we needed something, to relate it to the previous logging draft and show how it all fits together and evolves from that. And and as part of that, that you're not a fan of of file naming conventions. So I wanted to address the latter first, which is that there is quite a bit of debate over how to address metadata and how it's attached to these log files. And the reason we ended up with the separate files is to accommodate formats like like CSV and possibly things like XLS spreadsheet formats that will will not where you can't just stuff metadata in as, like, a header or something into the file because the file format is already predefined and is already in use outside of what we're specifying here in the, in the draft. So to do that, we came up with this idea of having a sidecar file, which is the the JSON metadata that lives alongside it. And because it's a separate file and because we don't have anything like a index file or anything like that that we've defined, the naming convention was kind of, like, the best way we could come up with to do that. So if you have if you have a better idea for how to handle that, I I think we're certainly open to that. We just this was kind of like the the the compromise that allows allowed us to retain use of these legacy file formats that people use for logging.
[00:46:53] Kevin: Yeah. I think that goes to my my second question my second question, which was, you know, how are we intending to use this? And are these existing formats? And if they are existing formats, how are we, you know, making them fit in? I guess the the sidecar solves that problem. I don't know that I have a better solution. It's just it confined you to, you know, the upstream CDN resolving what happens if it already has that same file name and where it's gonna store it and, you know, there are other complexities that that brings. And if we can avoid those, it would be preferable. And, you know, munging file names is always painful thing. But so I I don't know. I think it's something we should talk about from a from the other question, you know, how is it gonna work with streaming, and how is it and then is it the UCDN's job to then define those file names and make sure that it follows the same conventions. It gets a little funny. It gets funnier when you start combining things from multiple downstream CDNs, and you have to merge them together. What does that mean? And do the downs do the transit CDN file names take precedence over the downstream CDN file name? There's there's some complexity there. And so I I don't have a great answer. We should talk about it, but I think to the general question, from my read of the doc, the the technical pieces are fine. Right? We we need to add these properties. We wanna have support for these logging fields. That that part's all fine. We wanna do sampling. But how it all fits together, yeah, was really my my question, and I think that's gonna be most reviewers' questions. How does this relate, and how are we going to do it?
[00:48:35] Ben: Yeah. That's fair. So so there is a there is a few placeholders near the top of the document Yeah. Where I think I have something that's, like, insert diagram here. So we actually have a bunch of diagrams that exist. They're just not in a textual format that can be dropped into the RFC. So I think that if we we can get those converted to ASCII and put in, I think that that will help provide the necessary context to understand how all the pieces fit together. Obviously, you could probably use some additional textual description of that as well. But the the diagrams, I I do feel like like, can can help come to an understanding of of the flow of all of this stuff through the participants.
[00:49:25] Chris: Yeah. And and there's a editorial note on that. The new formats allow you to have both the ASCII diagram and also an s v SVG sidecar so that when it's being rendered in a higher resolution format than something that fits on a dot matrix printer from the eighties, it will you you have an option there.
[00:49:48] Ben: Okay. Once you do have figure out how to do that.
[00:49:50] Chris: You do have to have the dot matrix version. Okay.
[00:49:57] Kevin: So I would encourage other folks in the working group as a chair, please go and review the document. We we do need more eyes on it. It's a big document, but it's not I mean, a lot of it is, you know, boilerplate for putting in, you know, properties and things like that. And so it's not a hard read, but everyone, please go and review it. Thanks.
[00:50:19] Ben: Thank you.
[00:50:24] Chris: Alright. And with that, that brings us to any other business. And I have one last piece of business, which is that we've decided that we wanna have a fall interim, and so I put together a doodle poll. QR code is there. Link is there. This link will be sent out on the mailing list as soon as this meeting is over. And please indicate your availability for the fall interim at some point before August 7 so that we can get the interim requested so that, you know, Corey has time to tell us if we can meet and get it on the schedule and and people can plan. Alright. Gorry has thoughts for us. Guide us.
[00:51:17] Gorry Fairhurst: Hi. Gorry Fairhurst, responsible AD. You have one document that's in IESG evaluation. Indeed. There are discuss comments there. You probably need to encourage the editors or anybody else to try and formulate words to respond to the discusses and complete them. So I don't think there's any particular news for that. That's just the process. And please organize an interim. Yes. But dot at the same time as the IETf meeting.
[00:51:46] Chris: Indeed. Yep. Yeah. It it on on that doodle poll, you'll see the we picked a couple of weeks, middle middle of the weeks, Tuesday, Wednesday, Thursday at some point, middle of September. So
[00:52:04] Sanjay Mishra: And going to your other point, I'll work with Alfonso on the document to see if we can clear up all the discusses that are still out there.
[00:52:15] Gorry Fairhurst: Yeah. Sure. It was just a notification of the status so that everybody knows what's going on. I'm sure that will work out nicely.
[00:52:22] Chris: Yeah. Yeah. He he he wasn't able to make it to the meeting, so we didn't allocate time for him. But it's certainly on our overall agenda. Alright. And with that, I will leave up the doodle poll for for a little bit, but I think we're done with the meeting.
[00:52:41] Sanjay Mishra: Thanks, everybody.
[00:52:49] Chris: Thank you.
[00:52:59] Sanjay Mishra: We actually finish at a at a time. We do. Efficient. I like that.
[00:53:21] Chris: Now it's lunch.