INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2025-01-09 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Deb Cooley (DHS CISA) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat Sandy Ginoza (AMS) / RFC Editor Liaison Mahesh Jethanandani (Arrcus) / Operations and Management Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Tommy Pauly (Apple) / IAB Chair Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area John Scudder (Juniper) / Routing Area Orie Steele (Transmute) / Applications and Real-Time Area Sabrina Tanamal (ICANN) / IANA Liaison Gunter Van de Velde (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Jim Guichard (Futurewei Technologies) / Routing Area Francesca Palombini (Ericsson) / Web and Internet Transport Area David Schinazi (Google) / IAB Liaison OBSERVERS --------------------------------- Marc Blanchet Alper Demir Abhineet Nayyar Andy Newton Ketan Talaulikar 1.2 Bash the agenda Liz: Does anyone want to add anything new to today's agenda? Roman: Yes, I'd like to bash a little bit, so I think what we still have at the tail end in terms of management items is to talk about alldispatch. Unfortunately, the, the team of Francesca, Deb, and me did not finish everything we needed to do, so we're gonna move that to the informal. And then, additionally, I think we have I know at the end we have an exec session to talk about, I think it's framed as one appeal. We're actually going to talk about both appeals, and we gotta figure out how to split that time up when we get there. Liz: Okay, got it. Any other changes to today's agenda? 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the minutes of the December 19 2024 teleconference being approved? I'm hearing no objections so those minutes are approved and we will post them in the Datatracker. Does anyone have an objection to the narrative minutes of December 19 teleconference being approved? Not hearing objection there either, so those are also approved and we will also get those posted in the Datatracker. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS Last updated: December 19, 2024 * DESIGNATED EXPERTS NEEDED o Murray Kucherawy to find designated experts for RFC 9559 (Matroska Media Container Format Specification) [IANA #1385324]. Murray: In December I emailed the list with two candidates for this. I can message them to you over Slack so we can add the item to approve them later. Liz: Just send us those names and we can add something at the end. o Paul Wouters to find designated experts for RFC 9668 (EDHOC Authentication Credential Types)[IANA #1401194]. Paul: I actually forgot about that. So I have two. I'm still waiting on the confirmation of the 3rd one, so I'll just ping them and get the answer next time. * OPEN ACTION ITEMS o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Murray: Still open, haven't touched it yet. o Roman Danyliw to work on adding a checkbox to the meeting registration system asking people to identify they are willing to serve as WG chair. o Roman Danyliw to take a look at Datatracker documentation of document states and update as needed. o Roman Danyliw to work with Secretariat to update non-wg list guidelines webpage. Roman: The next four are to include that all the ones tagged as me for the next four after that are all still in progress. o IESG to decide whether we are going to collectively agree to opt in to the RPC auth 48 Github experiment if authors are part of the github experiment. Liz: We said we were going to add this to an informal to discuss, so that's still in progress as well. o Deb Cooley, Roman Danyliw, and Francesca Palombini to review the ALLDISPATCH feedback. Liz: We just talked about Deb, Roman, and Francesca to review the alldispatch feedback, you said just a minute ago that that is still in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-emailcore-rfc5321bis-38 - IETF stream Simple Mail Transfer Protocol (Internet Standard) Token: Murray Kucherawy Liz: We have a few discusses, do we want to discuss these now? Murray: I think I can go through them relatively quickly despite their size. So 1st on the comments that double slashed like the C++ style comments, I think that we left those in because some of them were meant to explain why we did something or did something else, but I didn't notice that some of them actually talk about all the old items that have already been resolved, and they just created more confusion than they were meant to resolve, so I apologize for that. That was an oversight on my part. I'll have them remove them all. There's actually nothing for us to worry about in there if you didn't find them helpful, they weren't meant to be harmful, so we'll just clean them out, I think that deals with actually most of our most of the stuff already raised. The stuff about security is meant to be so the the issue just so for everybody's background is that SMTP, as you may or may not know, is an entirely insecure protocol. It was built back in the time when like there wasn't TLS that there's nothing in SMTP to prevent you from claiming to be something else. We added text to this document to actually call that out in a minute, and there are extensions that provide those capabilities now. The decision or the preference of the working group is not to make those core, like it was, it seemed weird to us to create extensions that become mandatory. So, this document still just covers base SMTP and also this the charter for this working group was set to say to move something from the status of draft standard which doesn't even exist anymore into internet standard and change as little as possible, like clarify a few things, remove anything that was that is not in use and then move it forward. So that the delta between the older version and the new version, sorry the 5321 and this one is really what what they were meant to produce is keep that minimal, so don't crack open any old debates about what that term means or this term means, which leads to some of the comments that I saw about why is this the way it is? It wouldn't pass today, but we're very constrained here to only modify a few, the things that have to be modified and clarified like using errata and stuff like that. That leads us to not modernizing it in ways that we would expect a new protocol to be modernized today around crypto and whatnot. The decision was made to put all of that type of material in the applicability statement, which is the document coming after this one and that will all be done as part of a cluster. From the dialogues that I've heard, this can be resolved by making the reference to the applicability statement normative, which the working group doesn't have any objection to. So I think that clears up, part of Paul's objection and some of the other ones like Ekr's and Martin Thompson I believe, and Rob Sayre. And another point that was raised was there was not consensus to proceed because that hadn't been resolved yet. I expected that to resolve as a result of last call feedback. That was also my mistake, it didn't. It was much more of a contentious debate than I expected. So the solution to that will be to run. After that has resolved, the reference thing has been resolved. We will run a second last call to make sure the community is fine with that change as supporting the objection in that case. So I think I'm looking at Roman's discuss which came in kind of late and I think a lot of the stuff had to do with the comments as well like. At least two of yours cover the double slash type things which I said we're just going to remove. There are, there's an outstanding IANA issue that I know we have to take care of. The issue there was that in the IANA consideration sections. The working group presented some stuff for IANA to decide, the idea was this is what the registry needs to say. Iana can present it however they want. IANA doesn't want any decisions left to them. They just want this like basically it should be called IANA instructions as I understand it. And so that's totally fine as well and so they're gonna tighten it up and say do it this way, the working group's gonna make the decision. And Eric's discuss, I am seeing for the first time, I'm waiting for the working group to answer that one. So does that leave anything major unaddressed? Is there, I mean I've given you a long summary to what I'm asked to do a few small changes that should resolve most of all of this while I talked for a long time. Roman: So Paul I'm gonna talk about security stuff that's related to your discuss because I supported yours instead of reiterating many of the things again. So Murray, so the thinking is that we would make a normative reference to the applicability statement and then we would reserve the debate in the applicability statement about what are the mandatory, the MUSTs or the SHOULDs about using particular extensions that would make this viable on the open internet. Murray: There is text in this document now that says this is an old protocol that doesn't have these capabilities. There are extensions that cover it that basically are mandatory on the modern internet. Because we are constrained about how much of a delta we're allowed to create in moving something from the old status to the new status and the charter said you're like, don't do any of those things, they stayed within their charter by not doing that here and it also does seem weird to say that extension is now mandatory. So yes,the short answer to your question is yes, all this discussion about how to take this vulnerable protocol and use it in a contemporary way will live in the AS and there will be a normative reference to the AS, which I think Ekr described as closure of all the material if we make this a normative reference. So the short answer to your question is yes. Roman: And there is still anticipation that there will be a lot of work on that AS document because my read, again, I didn't really review it. I just kind of scanned because it was, it was referenced a number of times. What the AS document does is not as far as I can tell, provide guidance on how to use it on the real internet. What it names is the possibility or the existence of different extensions. So e.g., I did not see language that says Start TLS is a MUST if you're on the open internet or SHOULD. Are we expecting that to be discussed or are we thinking the AS is done in. Murray: No, the AS is not finished and that's something we can lean on. We can be much more prescriptive or advise whatever provide pressure to move the AS in that direction if that's what they want or sorry, if that's what we believe should happen. No the AS is not finished. Paul: I think also if you look at Martin Thompson, Ekr, and me that's what we would require to be in that document. It would basically have to say something like, it's not appropriate to send clear text email without encryption over the Internet. Murray: Right. And I think the working group has already expressed their intent to solve this problem in that particular way. Because 321 bis depends on 5322 bis, and they depend on each other and now the AS is wrapped into that, they're all gonna go as a cluster. So, if there ends up being some small additional text that needs to be added in the bis documents with the AS, they're all gonna go up together and that can be addressed. Paul: So that's good with me. I'm not sure if Roman is good with that. Roman: Sorry. I mean if we make the AS document be normative and we say we're gonna have this security kind of conversation there that would resolve that that would be kind of resolved kind of the substance of my concern with the security. I mean it doesn't resolve any sense I know what the answer is but procedurally it resolves that we're gonna cover it in a different place and we have a normative requirement. The one thing I did see didn't see in the AS document is that I didn't see kind of clear language, in the bis document that said you must follow what's in the applicability statement, and I in the metadata tagging, maybe I missed it in the AS statement, nothing said we're updating the bis document. So I think we need something a little tighter to the languages too. Murray: I've done AS before on things that are like lesser than this and I don't remember them saying that the AS updates the other thing, but I suppose that's also an option. Roman: I'm just looking for whatever is the procedural with metadata or with inline text that it is clear that from one or the other that you must follow whatever is the additional security stuff specified in the other document. I'm flexible on how that happens. Murray: My understanding from talking to Ekr was that that he was satisfied with just the normative reference, and we can also add stronger text in the AS pointing with the saying again I'm sort of babbling of it yes, we can do it this way. Deb: And maybe clear text in the security considerations of this document. Murray: I thought that it was there, but if it isn't. Deb: I think it's a comment. It's one of these issue things. Murray: Oh then yes, we can promote that to real text then. I thought I had them add a paragraph at the top of section seven that said something like this. I can make sure that it's as strong as it should be. Orie, did he cover everything about yours? It's I think yours was all related to these weird comment things that we're just gonna rip out anyway. Orie: Two of them are. The other one is about the deprecations in the appendix and the normative references. Murray: Oh right, yes. Orie: It's mostly just like, you know, this is maybe a style thing, maybe it's not even within the discuss criteria, but it wasn't obvious to me whether this document is performing the deprecations. The appendix has a BCP 14 language and it's telling you very clearly what you must understand and you must do and it just is a little bit confusing that it's in the appendix with all of this normative treatment there. I would prefer to see the exact section as part of the body since it's part of what you must understand in order to implement. I gather this is left over from the desire not to restructure the document perhaps, but does it count as restructuring to move the section without making any changes. Murray: I remember now where we were talking, we talked about this a little bit over Slack too. I think this was relatively easy to resolve. So the only thing I haven't talked about yet is just Eric's, but that's because I came in in the last few hours, and it doesn't look like that's a major thing, so I'll take that up directly with the working group. Eric: It's basically the wrong reference. It's an important one. Deb: So that paragraph you asked for is considered a security section. It's just prefaced by issues that make it sound like maybe it's not. The whole issue was confusing. Murray: It was me that suggested leaving those things in thinking they would be helpful and they ended up being exactly the opposite. So I'm sorry for confusing everyone with it. Did I miss anything or are we pretty much understand what the action items are here for all of them and we can just I can do any follow up and I can ping people individually once a new version is up to make sure we're good. Roman: I just wanted to double check on the IANA. So there's additional work that's gonna be done to clean up the the the some of the IANA stuff specifically I called out one where I don't understand the redefinition of the guidance. Murray: I believe yes, that there's a separate thread. Another thing complicating all those is there's like nine threads live, one with IANA, one with each of you, several of them with me, so anyway, one of them is one of those is renegotiating this text with IANA to clarify it and not leave them having to do stuff they don't want to do. AD follow-up for this, please. Liz: So this document is staying in IESG evaluation with a substate of AD follow up and Murray, just so you have a heads up, once this gets to approval time, this document does have two down refs, so we are gonna ask you if you want those to be added to the down ref registry. Murray: They were part of the last call, right? Liz: Yes. o draft-ietf-nfsv4-layoutwcc-05 - IETF stream Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type (Proposed Standard) Token: Zaheduzzaman Sarker Liz: We have a discuss, do we want to discuss this now? Murray: I'm piping up on this one because I commented on Gunter's discuss. Yes, your proposed suggestion is totally fine with me. Gunter: Okay, cool. So I'll remove this case once it is updated. Perfect. Thank you. Liz: Okay, so this document is staying in IESG evaluation for now and it looks like we're waiting for a revised ID, so revised ID needed. Zahed: That's correct, and thanks for this. Just for your information I didn't reply, but just for everybody, this has been discussed. I mean, I already flagged this out in my AD review so I was waiting for the authors to actually chime in, but this is easily solvable. Gunter: Yes, thank you. o draft-ietf-bfd-large-packets-14 - IETF stream BFD Encapsulated in Large Packets (Proposed Standard) Token: Éric Vyncke Liz: We have a discuss, do we want to discuss this now? Eric: I don't think so and first let me thank let me thank all of you, and I think this one is the, the most recursive ballot because if you look about it, Murray, thanks John, we repeat what Warren said, we will repeat what Jim said. I'm taking all of them in the same thought. Anyway, Zahed, about the padding, that's your plan? So I will work with the authors then specify what is done with the padding field, so it's revised ID needed for sure and thanks again for the review. Zahed: Yeah, so Eric, I mean I got a reply from Jeff. I'm actually seriously confused now with that reply, so we need to work on it. I would like to understand other AD's view I mean this is something this is a specific you must put zeros and then the idea is like to not take a look at it. It doesn't mean anything. At least for me, if I put some MUSTs somewhere, I have an error code or like if I mean, what happens if this is that should be pretty clear. It's not clear, so that's why I put it and discuss and I hope that we can clarify that one when you're discussing this without the authors. John: Just to ask, I mean, so as I understand the draft, all the stuff in the padding is explicitly outside the the the boundaries of the BFD frame per se, which means BFD has no business looking at it. I mean, yeah, I agree it's a little weird to say zero fill this but that's none of your business. Would it be clear enough from your point of view if the spec explicitly said there's no expectation that the receiver will check this? Zahed: Perfect because that's what I mean I think missing. I mean exactly, that was the confusion, so I had two confusion was like am I doing a path part into discovery with BFD, which I don't think we should. And then Jeff said, No, we are not doing it, but it actually not explicitly saying like, I have to more than one hope, I know one MTU, I don't know the other MTU, so I'll try longer packet size and try to understand what is the sustainable MTU. That's basically the thing. I mean that's if you don't call it discovery I don't know what you should call it. And then when I say that ok with this one this 01 said I understand that might be security thing you don't want to link that's why sender should put zero, but what if it doesn't, and what if if the VFD doesn't look at it, let's just split it out. I'm just doing this for the sake of learning the NTU. And I'll BFD will not look into if it is zero or not, this should be handled just exactly what you said, John, like that if you write that thing, I think this is much clearer and I don't have any issue. John: Cool. Thanks. Liz: This document is staying in IESG evaluation and I think I heard Eric revised ID needed for the substate. Eric: This is correct. o draft-ietf-nvo3-geneve-oam-14 - IETF stream Active OAM for use in GENEVE (Proposed Standard) Token: Gunter Van de Velde Liz: We have a discuss, do we want to discuss this now? Gunter: I think there is good discussion going on between Eric and Greg on this thing, some alternative approaches. Maybe Eric, you wanna say something about that, but I think it is going in a good direction. Eric: I would say so. So clearly for me, that's the way it's written right now is a clear and no go, but they are alternative ways. I propose simply using the discard prefix for instance, which is basically a global address. It can be used in destination but will be rejected anyway, so there will be no leak, no forwarding or whatever. And there are other ways of doing it. Erik: Or we just go and allocate something new related to the same discussion on the other document. They've been using colon colon one for a long time, the general PFD and OAM type scenarios. Not a long time, but yeah, anyway, apologies. Eric: The another way is indeed to request a prefix, and it could be easy. Gunter: I think actually, and I think on the longer term it probably makes sense to some degree? Because you also do some delay measurement on links and things like that. And then there is also some prefixes being used in destination, things like that, so it could be worthwhile to investigate. Eric: Now we may want to decide whether we because there was the other one? The MPLS BFD, which is exactly the same thing, the same motors, this is Greg as well. It's a reasonable guy any anyway, so we could block both of them and asking IANA to allocate a prefix, I mean, a /64 that's a no brainer. Erik: Why a whole prefix? Eric: Because if you want to experiment with ECMP, you want to get the additional address varying to provide entropy so you can test all the ECMP path. Warren: It fits in well with the IANA thing, getting an address seems tricky and complicated, whereas /64s are free. Erik: I mean you could just allocate ::2 as an additional loop, it doesn't seem that hard. Warren: Actually something which I think we should really discuss is there's a bunch of places where having the loopback network in V6 would be really helpful instead of simply having a loopback address. There are a lot of places where people who would like to be able to use that. Erik: We had 100 ::/forty eight, I think previously proposed. It got down due to some complaints from certain people as I recall, but that doesn't mean it couldn't be revisited. Warren: Who wants to revisit that with me? Eric: No problem for me, it depends. So if INT ADs are doing then it includes myself when it comes to IESG evaluation, so assuming I'm still reselecting. Warren: So Eric and Erik. Erik: Include Suresh too. Eric: There's basically two things. There is the loopback prefix because it's useful and this one is the kind of, this address is never forwarded, it should not be received. Like pretty similar to the discard prefix for this kind of thing. Gunter: But it's not really a discard, is it? It's a valid drop, you expect the packet to go there. Eric: Yeah, but you don't process it at the IP layer because it's a dummy one. It's simply to test the underlay. What is sending the overlay should be discarded. Erik: Not discarded. Discarded. Eric: But like not forwarded or not processed BFD. Erik: Right. Which is why they want the loopback, but like, I think I think if I understood Warren's proposal correctly, if we allocated say like the the old 100 ::/64 or 48, addresses from those prefixes would be, would appear in the destination address embedded down and encapsulated in these measurements. Warren: I think my suggestion for the loopback prefix is orthogonal to this. It should be similar to 1270008 or whatever it was. I think there are too many zeros, but similar to the V4 thing in V6 because people sometimes needs to stay local to a box. Erik: Not applicable to this particular problem. Misunderstood there. Eric: And for the for this one Erik, we can also try to get /24 for IPv4 for the legacy one in the same document or whatever so it leaves open. It's up to the authors and you, I guess, to see what's the best way to proceed. Cause we can make requests a specific prefix for this and IPv4 and IPv6 for both documents or because if we need to create a new draft, even if we expedite it, it is sponsored. Requesting a kind of I would call it discard for now, even if it's not the right term before and V6 prefixes, it will take months. Gunter: I don't own the other document. Eric: Yeah, it is Jim. I don't think he will be on the call. Erik: If we did a document that allocated ::other prefix, it would, it would have more than just this document to update, I think. There's the MPLS LSP ping document that also uses ::1. Eric: But you can create a document allocating the prefix without updating the other one. Basically, we create a prefix, we offer the prefix to the community. Please use this for your document, and then this one in the MPLS one can refer normatively to it. Erik: I guess I'm saying like you could block this waiting for that document, or or you could not block this given that it's already current behavior and then just have a future document update this. Gunter: But then it will still have it discussed. Eric: I mean honestly Gunter, I cannot approve this document with the same text right now. It's easy to change. I propose a discard prefix for instance. Gunter: That is what I was saying. So even if we do the approach what the other Eric was saying, the document is still blocked because it is doing something which it shouldn't be doing. Warren: So what's the disadvantage to just asking IANA for a prefix for this, this document? Seems like that would be faster than the whole. Eric: The only thing I would say is that there are two documents right now in this by coincidence. Having the same problem. So if we fix for one, the other consideration is if this one has an allocation, but what about the other one? We can ask to please allocate a prefix as the same as draft-ietf-nvo3-geneve-oam. I guess IANA would comply but it's kind of strange. Warren: Yeah, it's kind of strange. You're right. Eric: That's doable. It would be perfect for me but then after if you get other documents, they cannot really refer to this one. No, because that doesn't do anything with nvo3. Gunter: So the real long term solution is to have its own document allocate the whole prefix thing. Warren: No, I think I think the long term thing is we have a document which asks for a loopback prefix and a discard prefix. Maybe one document, maybe two documents, I think we try it with one document and if it becomes sufficiently controversial, we say, Great, we're flipping into two documents. Erik: But isn't there already a discard document? Eric: There is one. IPv6, not for IPv4. Erik: Oh, and we can't just discard all of v4, I guess. Roman: Do we have a plan or do you want to kind of table the continuation of this conversation to work out a plan? Gunter: Let me check on this particular document, let me check with Greg to see if he can live with the discuss prefix for IPv6. And I think on the longer term we probably need to think about the the other two prefixes and the other document which can be used in the future for like other documents doing something similar each from an OEM perspective. Liz: Okay, so then this document is staying in IESG evaluation and AD follow-up or would revised ID be a better substate? Gunter: I think revised ID needed. Liz: This will go into revised ID needed. o draft-ietf-lsvr-bgp-spf-44 - IETF stream BGP Link-State Shortest Path First (SPF) Routing (Proposed Standard) Token: Jim Guichard Liz: I think Jim is still not on the call. So anything you want to go over without Jim? John: Well, I see that Ketan is on and he is the document shepherd. I guess I'd invite Ketan to speak if he wants to, otherwise I think we can just defer this to when Jim gets back. Ketan: I think thanks for your review and I don't think the author or the editors have had a chance yet to respond. I haven't seen at least. So, we probably might need a bit time to go. John: No worries, you know where to find me. Roman: So maybe we mark this since Jim isn't here as AD follow-up. Liz: This one is staying in IESG evaluation with a substate of AD follow-up, and Jim can figure out what to do with it from there. o draft-ietf-acme-onion-05 - IETF stream Automated Certificate Management Environment (ACME) Extensions for ".onion" Special-Use Domain Names (Proposed Standard) Token: Deb Cooley Liz: It looks like we have a discuss, do we want to discuss this now? Deb: I don't think so, but we can put it in revised ID needed. Liz: This one is staying in IESG evaluation with a substate of revised ID needed. o draft-ietf-cbor-cddl-more-control-07 - IETF stream More Control Operators for CDDL (Proposed Standard) Token: Orie Steele Liz: There are no discusses so unless there's an objection now, this one is approved. We can call this one approved. Orie: I haven't had a chance to fully read all of the comments on this. Sorry, I'm running a bit late. Skimming them now? I'd like it to be AD follow up if I can just to make sure to close out any of the remaining comments. Liz: This one is approved announcement to be sent; AD follow up and you can let us know when it's ready. And also Orie, there is a down ref, so RFC 9285, do you want to add that to the down ref registry? Orie: This was on the last call right? Liz: Yes. When you let us know when it's ready to go, if you could just also let us know what to do with that downref. o draft-ietf-mpls-p2mp-bfd-09 - IETF stream Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multi-Point MPLS Label Switched Path (LSP) (Proposed Standard) Token: Jim Guichard Liz: We have a discuss, anything to discuss on this now? Eric: As far as I know, Jim is not on the call. It's basically very similar to the nvo3 draft discussion with exactly the same problem. So I guess the same solution applies as well and this is the same authors by the way. Liz: This one will stay in IESG evaluation and we can just put this in AD follow up for Jim to take from there. o draft-ietf-acme-ari-07 - IETF stream Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension (Proposed Standard) Token: Deb Cooley Liz: We have a few discussions. Do we want to discuss these now? Deb: I don't think so. I don't think they're hard to discusses honestly. Eric: May I ask somebody from layer seven to review my discuss because that's linked to HTTP and I'm unsure. So it's not an IP layer, so I don't know exactly what's happening there, but I think this points. Deb: Right, and we didn't have that review done, which we could do still, right? Eric: I think simply if Orie or Murray can have a look and see whether I'm completely wrong or not. Section 4.1 in the example. Deb: Your question is whether the GET is correct? So you think Murray will know? Eric: I hope so. Orie: It's section 4.1? Deb: If you look at it, it's got both. The current one and the one he thinks it should be. I do think there's some issues with the this is ari, not onion, sorry I'm getting my drafts confused. Example.com is OK for ari, but not ok for onion. Murray: So are you talking about my discuss? Let me bring the doc up. Deb: I'm looking at Eric's discuss. Eric: But I would love to have you take a look at it. Orie: I think this is just an expression, the two possible text options are both sort of, not, oh, I guess the difference is, is there's no protocol example in your proposed text, Eric. Zahed: I mean the thing is like if I definitely look at it, we can have have this discussion, but this get can take URI URL or like resource or a relative reference, relative URI, whatever. The GET method takes quite a while. A lot of different static values, so, I don't know in what sense we should call it incorrect. I think it just should say like you have a GET method with this resource look at her and that's fine. Maybe rewriting this one in a different way would be helpful, but then if you really would like to have an example, GET method, then I can place some example how it should look like. I mean just just go to MDM modular and then find a GET example you'll see how but I agree with Eric like this is not the typical way you put an example GET but yeah I can live with that one, but there is a better way. Murray: Orie would know better than me, can you put a full URL in a GET? I thought that protocol and the and the authority which is the host were part of, like that's part of the connection that's established. Eric: The only time I see a get with your URI is when you're using a proxy. Murray: And that's a proxy language. Orie: The way that this example is structured it is not, it's not sort of precise enough to really tell the intention I think there, and then also like is the goal to support HTTP without the S? I mean because that's sort of implied in the alternative text, but I think we have WIT, this is more a WIT thing. He kind of answered it, I would take his advice. Zahed: That's the only reason I talked about that one. I mean, as I said, I can help you out, but this is fine. The syntax of the GET request target and then the query. That's the syntax, but then you you're fine with saying like if it is absolute part is the related part, I mean, you can go into that details of how these request queries could look like. Obviously we can have a better representative that's what I'm saying. I'm also saying that the way this is written now is not completely wrong. I mean I can leave with that one as I said, but there are examples I think we can just find a good example let me because you can have quite a lot of host access, what not, maybe you can put a full of HTTP headers but that's not the intention, I guess. Deb: So what I get out of this is that his original get request isn't wrong necessarily, but it's not the best. Zahed: Yes, that's correct. Murray: The semantics are there, the syntax is wrong. Maybe that's a good way. Deb: So then what we need to do is make sure that we get a better example that gets the syntax correct. I think he does want HTTPS honestly, you don't want to do this over bear HTTP. So that part is, is correct however we structure that. Okay, so I think I understand what the what the issue is. So Zahed, would you be interested in replying to Eric's discuss in an email? Zahed: If I can find a good way of representing this one. Let me have a look at it because what I'm also struggling is like the request target, it doesn't need to have this HTTP protocol. The GET doesn't care. Tommy: It seems that unless they're trying to make a very particular point about this is different from normal HTTP and like how you would normally construct it. You should just there, there are so many examples in other RFCs of very simple example.com GET requests, just like make it look more like those and we could help point to any number of them, but at this point it does not look like that. Zahed: I mean the the intention was not clear and I that's why I'm struggling with that like because I do have a solution right now in my head. I can just point it to that one just I will read that more carefully and come up with something. Deb: That would be lovely, if you don't mind doing that. Even if you were to reply to your own comment except it wasn't sent, right? So if you don't mind doing that, I would appreciate it. It's definitely revised ID. Liz: So this one is staying in IESG evaluation with a substate of revised ID needed. o draft-ietf-jmap-webpush-vapid-09 - IETF stream Use of VAPID in JMAP WebPush (Proposed Standard) Token: Murray Kucherawy Liz: There are no discusses so unless there's an objection now, this one is approved. Murray: If there's nobody who wants to discuss any of their comments, then let's go with approved AD follow up, please. Liz: So this one will be approved announcement to be sent AD follow up, and you can let us know when it's ready. o draft-ietf-lamps-cms-sphincs-plus-17 - IETF stream Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) (Proposed Standard) Token: Deb Cooley Liz: We have a discuss, do we want to discuss it now? Deb: I think we're mostly resolved here. He needs to push a new update and Paul needs to check it. Paul: That's right. Deb: So revised ID needed, please. Liz: So this one is staying in IESG evaluation with a substate of revised ID needed. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items o status-change-early-hints-to-proposed-standard-00 - IETF stream Status Change for RFC 8297 "An HTTP Status Code for Indicating Hints" to Proposed Standard. (None) Token: Francesca Palombini Liz: So I guess the question is do we approve the status change? There were no discusses, so unless there's an objection now, this one is approved. we also it looks like we have the consensus set to unknown on this so we will go ahead and change that to yes. And since Francesca is not here today, we'll just go ahead and put this in AD follow up, so Francesca can follow up when she's back. 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-pquip-pqt-hybrid-terminology-05 - IETF stream Terminology for Post-Quantum Traditional Hybrid Schemes (Informational) Token: Paul Wouters Liz: There are no discusses so unless there's an objection now, this one is approved. Ok. I'm not hearing any objections so this one is approved. Paul, is this ready to go or do you want to do something else to it? Paul: Yeah, it's ready to go. Liz: This is approved announcement ready to be sent; no substate so we'll go ahead and send that announcement. o draft-ietf-lsvr-applicability-20 - IETF stream Usage and Applicability of BGP Link-State Shortest Path Routing (BGP-SPF) in Data Centers (Informational) Token: Jim Guichard Liz: We do have a discuss. John, do you wanna say anything about this now? Jim is still not on the call. John: I already talked with Ketan in the chat and same disposal as the previous one, so we'll just wait for the authors on it. Liz: So this one is staying in IESG evaluation and we will give it AD follow up for Jim. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-rivest-sexp-12 - IETF stream Simple Public Key Infrastructure (SPKI) S-Expressions (Informational) Token: Murray Kucherawy Liz: We have the consensus as unknown for this one, so we'll go ahead and set that to yes for you. Murray: I can't believe I missed that. Liz: We have a discuss, do we want to discuss it today? Murray: Very briefly, so this document so everybody else knows this finally defined something that was actually referenced back in RFC 2692. It is not actually trying to standardize that necessarily although. So that would have made sense to do at the time. So one of the outs here for and sorry and one of the problems here is that it doesn't pay attention to something contemporary, which is internationalization, and I think that was at least part part of Paul's abstain and a chunk of Orie's discuss. One of the things that we're considering doing is just changing it to historic, which, I don't mean to be flipping about it, but basically we'd forgive it for not addressing that important thing. This isn't meant to be a modern technology. I believe there are other variants of this that are much more current, but it's just meant to document something we should have documented a long time ago. It was last call that was informational. The author has said you guys can change it to whatever status you want, and I said, well, it's not quite that simple, we can't make it proposed standard without another last call. But do, does anybody think that we would need to last call it again to go from informational to historic or was an informational last call good enough to defend historic status? Warren: I suspect that doing a very short last call would make sense, just note that this is all you're doing and so hopefully people will calm down. It seems like one of those things where it's safer to ask just in case, but you should probably kick it off soon just. Roman: I strongly agree with that. Murray: That's totally fine. So the other thing that possible resolution is that he is thinking about adding UTF eight examples, which I guess would also solve the problem. So I will resolve this with the author either by doing a last call on a historic and not changing anything or letting him add those examples and making sure that Orie and Paul are happy with it. And I don't need I don't need to swing Paul off the abstained, but if it does, then great. Roman: I would point to if those not watching the larger IT have discussed manually lists, the larger discussion about what is historic and all of the intended kind of challenges. Liz: So this document is staying in IESG evaluation for now. Murray: AD follow up, until we decide whether it's going to be a status or a new revision. I'll change it as appropriate. Liz: Ok. Perfect. This one will be AD follow-up. 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-irtf-cfrg-opaque-00 IETF conflict review for draft-irtf-cfrg-opaque draft-irtf-cfrg-opaque-18 The OPAQUE Augmented PAKE Protocol (IRTF: Informational) Token: Deb Cooley Liz: There are no blocking comments so unless there's an objection, it looks like this is ready to go. Deb, is there anything you want to add to this or is this ready to send back? Deb: Ship it. Liz: So this one is ready to go and we will send that no problem message back to the IRTF. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o RESTful Provisioning Protocol (rpp) Liz: We have a couple of blocking comments, do we want to discuss them now? Orie: So this is my 1st charter that's gotten to this sort of stage and I've already shuttled some of the IAV review back to the group to propose some changes to the text. I guess I'm just sort of wondering process wise, what is the best way to sort of provide a revision and then check back to see whether the blocking comments have been addressed. Maybe that's better to take offline, but, thank you all for the comments on the document. I think they're all awesome. Roman: Happy to follow up offline, Orie based on the feedback and on the kinds of process stuff. Liz: And so basically the the things we normally would do with these are either wait for instruction from you Orie, send it back to internal review or just put this back on the agenda next time right in the same place. So if you know yet any of those three things you want to do or you can just think about it and let us know which of those you want us to do. Orie: I don't know that it'll be possible to clear these comments between now and the next, so whatever the longer timeline path is. Liz: Ok. We'll just wait for further instructions from you. o Taking IP To Other Planets (tiptop) Liz: I don't see any blocking comments here, so it looks like this is ready for external review. Warren: Apologies for not having mentioned any of this earlier, but and for not being that informed. But it feels strange to me that we need a working group for this, which I thought seemed like a relatively small thing. I thought this was largely can't we just ask the RAR to please set aside some space and move on with life or does it require all of this? Eric: No. It's it's not about IP prefixes So I know that some people in the ready to the potential working group wants to do it, but I think it's really too far-fetched for now. So it's not about allocating, 3000/8 or whatever, for IPv6 to the moon and another one to the mass or whatever. So it's way too premature. It's it's really to check whether the existing protocol can have been tuned in the sense of not modifying the protocol but maybe modifying time. Warren: Ok. I completely misunderstood so no objections. Eric: Thank you all for the review. As you have seen I just updated the charter minutes before the call with the proponent and thank you Erik for changing your point of view. Erik: Thanks for addressing the comments. Zahed: Thanks for the clean-up. Eric: It's cleaner. It's clearly implemented. You change the charter, you change it, you change it, and then it was done before the Christmas shutdown and then I did not look at it and then now it's much nicer. It's much nicer. Liz: So this one is approved for external review. Eric, is this ready to go or do you want to make any other changes? Eric: I just changed the charter so I want to check whether it's correct English because maybe put a comment more or whatever, and I will tell today or tomorrow. 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o Protocols for IP Multicast (pim) Liz: There are no blocking comments so any discussion here needed? Do we approve on this recharter? Gunter: So one little item like a couple of hours ago I made an update. I added a few commas left, right, and center, actually only Oxford commas, funny, but it should say like 08-O2, so I'm not sure if I've done something wrong maybe. Liz: This is just the ballot that was sent out at version that's what that referred to. If you made an update; that's fine. We'll just make sure that's what gets sent out with the recharter announcement. Gunter: Just like Orie, this is for me the first time I go through this. So if it is approved, do I have to do anything else or will secretary do all the magic? Liz: If you wanted to make any last changes, we could wait for you to review it and give us a go ahead or if you're ready to go, we will just go ahead and send the announcements. Gunter: It is ready to go. Liz: Ok. We will send the working group recharter announcement. 5. IAB news we can use Tommy: I don't think there's too much new. We're still confirming the NomCom slate for the future new IESG. Sorry that's taking a while. John: Thanks for jumping in there while I was looking for my mute button. My only other thing was there was quite a bit of discussion with the last one about the whether to do some kind of additional statement about ACH blocking and as far as I could tell the outcome was no we already covered that in RFC whatever whatever number is. No action then replying. Tommy: Although if anyone, you know, on the IESG thinks that something needs to be said about various countries blocking ACH, happy to discuss that. We're also going to be talking with ISOC a bit about that if they perceive any kind of measurements they have around that. It's mainly about watching this space scenario. Murray: I don't quite know how to ask this carefully, so I'm just gonna ask it. Is there any chance that this is gonna take a whole lot longer? And the reason I'm asking is because I just did Tommy: For the NomCom? Murray: Yes, I'm not trying to accelerate the process, I don't want you to do anything wrong. I'm just thinking ahead. Like we only have four telechats left during which we will have overlap with our replacement. So after today I mean, so that's like if we lose another one then like that training opportunity is chopped by 25 % et cetera et cetera, so I don't have to say much more than that. Tommy: Correct, so, I mean the the situation that we're in is most of the most of the slate we have confirmed, but there's some of it we haven't yet, but I think normally none of that becomes official or goes out usually until the entire slate is approved, it is possible that some of it may need to go back. So it is possible it will take a lot longer for at least one or two of the positions. I guess we could talk about and get feedback from the NomCom if the positions that we have confirmed kind of can be announced at least. If they're comfortable with that. Murray: I'm not trying to force you to change process or anything, I'm just getting very sensitive about, and how how little training time it's dwindling. Eric: I am also concerned. And by the way Tommy, I don't think it would be wise to announce part of the slate, even if I would love somehow as I am interested because it basically split the future IESG in two parts. Tommy: I think that's not preferred to do that. I think technically this is in the NomComs hand for what they want to go for. Roman: Yeah, that's exactly what I was gonna say. That's not up to us as the confirming bodies, that's up to the NomCom. John: Sorry one more thing on that tangent is do we at all want to liaise back to NomCom that although we appreciate them following the normal procedure at some point they should think about some partial results just in interest of being able to onboard people? I mean it's still up to them, but they might want to know our opinion. Orie: I'm happy to share our opinion with them speaking as the IESG liaison to the norm comm statement, so if you want me to take an action, let me know. Eric: But I'm not sure whether we have an opinion as the IESG on this one. Roman: My recommendation is to leave it, leave it kind of for now and see where we end up by the time we head into the next telechat. I mean Dean is aware of these challenges. Murray: Here's one suggestion that doesn't tip anybody's, it doesn't require a partial reveal or anything like that, the IAB for the people they have confirmed could quietly nudge those people that they should start attending telechats because it's open anyway. Tommy: I don't think we can do that because technically the nom com can change its selections for any of them. Murray: That's true. Never mind. Warren: It also seems like it would not be unreasonable and I'm kind of wondering why everybody who ran for IESG positions hasn't been showing up on these. Tommy: That's fair. Like you just tell people, hey, if you think you're gonna be on. Warren: I would have assumed that people have started attending them before putting their name in the hat. Deb: I mean if I'm honest, that's the only overlap I got as attending as an observer. 6. Management issues 6.1 Designated experts for RFC 9559 (Matroska Media Container Format Specification) [IANA #1385324] (Murray Kucherawy) Liz: So Murray has identified Dave Rice and Steve Lhomme as the designated experts for this registry. Any objections to approving these two? I'm not hearing any objection, so they are approved and we will get that official note to IANA. 6.2 Executive Session: Appeal to the IESG re WGLC of draft-ietf- lsr-multi-tlv The management issue was discussed in an executive session with IESG and Secretariat present. Observers and liaisons dropped from the call. 6.3 Executive Session: Appeal regarding threat on the TLS Mailing List The management issue was discussed in an executive session with IESG and Secretariat present. Deb Cooley and Paul Wouters recused themselves from the discussion and left the call for this portion. 7. Any Other Business (WG News, New Proposals, etc.)