INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2025-02-06 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Mike Bishop (Akamai)/ Incoming Web and Internet Transport Area Mohamed Boucadair (Orange) / Incoming Operations and Management Area Jenny Bui (AMS) / IETF Secretariat Deb Cooley (DHS CISA) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Gorry Fairhurst (Univ. of Aberdeen) / Incoming Web and Internet Transport Area Liz Flynn (AMS) / IETF Secretariat Jim Guichard (Futurewei Technologies) / Routing Area Mahesh Jethanandani (Arrcus) / Operations and Management Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Jean Mahoney (AMS) / RFC Editor Liaison Cindy Morgan (AMS) / IETF Secretariat Andy Newton (ICANN) / Incoming Applications and Real-Time Area Francesca Palombini (Ericsson) / Web and Internet Transport Area Tommy Pauly (Apple) / IAB Chair Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area John Scudder (Juniper) / Routing Area Orie Steele (mesur.io) / Applications and Real-Time Area Ketan Talaulikar (Cisco) / Incoming Routing 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 Warren Kumari (Google) / Operations and Management Area David Schinazi (Google) / IAB Liaison OBSERVERS --------------------------------- Antony Antony Marc Blanchet Francois Clad Nick Doty Sandy Ginoza Tommy Jensen Felix Linker Ronald in't Velt Mauro Vignati Greg Wood 1.2 Bash the agenda Liz: Does anyone want to add anything new to today's agenda? ANy other changes? 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the minutes of the January 23 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 the January 23 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: February 4, 2025 * DESIGNATED EXPERTS NEEDED o Paul Wouters to find designated experts for RFC 9668 (EDHOC Authentication Credential Types)[IANA #1401194]. Paul: I'll try to send them a DM at the end of the meeting. o Erik Kline to find designated experts for RFC-ietf-ntp-update-registries (Updating the NTP Registries)[IANA #1412130]. Erik: In progress. I'm collecting a list of victims. * OPEN ACTION ITEMS o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Murray: I will finish before I step down, but it's still in progress. 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 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. Roman: So for the next couple are mine, those are in progress. I'm gonna take ownership of the last bullet based on, I think two informals ago. I need to talk to Jean about what is the experiment the RPC wants, and if we can't quantify the experiment, then we're gonna kind of defer it, but I think we'll probably be able to do that so mark the next three in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-manet-dlep-credit-flow-control-17 - IETF stream Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items (Proposed Standard) Token: Jim Guichard Liz: We have a discuss, do we want to discuss this now? Jim: I don't think so. It looks like there's some exchange through email going on. I think we'll just let that play out and and frankly, the next three documents are the same. So unless anybody wants to bring anything up specifically, these four were difficult because there's two of the authors are now deceased, so we've been trying for quite some time to kind of clear these out of their queue and my intention is to to to figure out whether we keep this working group open or not. We've been having that discussion, but there's a lack of engagement and these documents are kind of like the last piece of the work they've been doing for quite some time. Paul: If it wasn't for that, I would have probably suggested somehow rewriting some of these documents into one to avoid all the duplicated intro of all the documents where basically the entire document is like one IANA registration, but i'm not sure I want to do that know with the deceased authors there. Jim: To be honest with the working group itself, it's pretty much the chairs that are helping to get this pushed along, so the engagement is almost nonexistent. I've got Donald Eastlake has kind of picked up on it, so, and he's one of the chairs and he'll get the work done. So I think most of this will just get fleshed out through the email and then we'll have the conversation about what to do with the working group. Sandy: Sorry, quick question. This is Sandy. Are the diseased authors still listed as authors on the documents? Jim: I've got an editor on there, so it was all very complicated because actually getting the documents published was difficult because we had to do some jiggery pokery with the XML itself to actually get it to even work so there's a long history behind. Sandy: Get all of it. Understood. So we can rely, we'll work with the editor once the documents are in the queue and hopefully you would approve in place of the of the other authors that were listed. Jim: Yes. Liz: so Jim, this one's gonna stay in IESG evaluation for that discussed. Do you want it in AD follow up or revised ID needed? Jim: It's gonna be revised ID needed and I suspect the next three documents are the same so put them in, actually put it in AD follow up for all four, I think. Liz: This one is going to stay in IESG evaluation with a substate of AD follow up, and then just for completeness and so we make sure we know what we're doing, let's just go ahead and take a look at all of these even if they're all gonna have the same outcome. o draft-ietf-manet-dlep-traffic-classification-13 - IETF stream Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item (Proposed Standard) Token: Jim Guichard Liz: We do have a few discusses here, so this one's also gonna stay in IESG evaluation and to go AD follow up? Jim: Yes, please. o draft-ietf-manet-dlep-da-credit-extension-20 - IETF stream DLEP DiffServ Aware Credit Window Extension (Proposed Standard) Token: Jim Guichard Liz: We have one discuss on this one, this one is also IESG evaluation with AD follow-up. o draft-ietf-manet-dlep-ether-credit-extension-08 - IETF stream DLEP IEEE 802.1Q Aware Credit Window Extension (Proposed Standard) Token: Jim Guichard Liz: This one doesn't have any discusses. Jim: Right, but it's reliant on the other three documents really. So that they're kind of like a package of four. So just put this in AD follow up. I'll release it once the other three are sorted out. Liz: This one will be approve announcement to be sent; AD follow up so Jim you can treat all those as a group. o draft-ietf-spring-srv6-srh-compression-22 - IETF stream Compressed SRv6 Segment List Encoding (CSID) (Proposed Standard) Token: Gunter Van de Velde Liz: We have a discuss, do we want to discuss this now? Gunter: Which one is this? So I think there is a new version just released -22. I have a suspicion that it is all clear right now. John: I reviewed that version to release my own discuss and it it looks to me like it also satisfies what Erik was complaining about, but of course Erik should be the one to say that. Erik: I just cleared my discuss. 7AM brain, it took me a little while to read. Liz: Look at that. We no longer have a discuss on this one. Erik: THanks everyone for circling the issue. Liz: So that means with no discusses left, this one goes to approved; announcement to be sent. Gunter, do you want this in AD follow up? Gunter: Yes, AD follow up, please. I want to because there were there were quite some comments I wanna double check if everything actually has been addressed or at least responded towards it so thank you. Liz: This one will be in approve announcement to be sent; AD follow up and you can let us know when it's ready. o draft-ietf-idr-sr-policy-safi-13 - IETF stream Advertising Segment Routing Policies in BGP (Proposed Standard) Token: Roman Danyliw Liz: There are no discusses, so unless there's an objection now this one is approved. Ok. This one is approved, Roman, do you want to move it straight on through or do you want some more time with it? Roman: I very much appreciate everyone's kind of thoughtful review. There's a number of comments I'd like to to look at. I haven't had the opportunity to look at the diffs because I know there's been updates, so if we could just put it in approved announcement to be sent; AD follow up, please. Liz: Of course, so this one will be approve announcement to be sent; AD follow up. Roman, this document does have two down refs, so once we get to the final steps, we're gonna ask you if you want to add these two to the down ref registry. That's 4272 and 6950. Roman: Will do. Thanks. o draft-ietf-lsr-flex-algo-bw-con-19 - IETF stream Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints (Proposed Standard) Token: Gunter Van de Velde Liz: We have a couple of discusses, do we want to discuss this now? Gunter: I don't think that necessarily has been discussions and communication going back and forward. The authors are working on an updated draft. I was assuming it would have been like released before the telechat, but apparently, they didn't make it so, but I think everything looks good going forward. So unless anybody who mentioned to discuss something else to say, please do so. Liz: I think there has been a new version within the last couple of hours, I think, but I don't know if anyone's had time to look at it yet. This one will stay in IESG evaluation and do you wanna put it in AD follow up? Gunter: AD follow-up for the moment, I'll figure out what to do. Liz: This one is staying in IESG evaluation with the substate of AD follow up. o draft-ietf-bess-evpn-redundant-mcast-source-14 - IETF stream Multicast Source Redundancy in EVPN Networks (Proposed Standard) Token: Gunter Van de Velde Liz: This one does not have any discusses, unless there's an objection now, this one is approved. Ok. I think this one is approved. Gunter, is it ready to go or do you want to put it in AD follow-up? Gunter: AD follow-up, please. Liz: This one is approve announcement to be sent; AD follow up and you can let us know when it's ready. o draft-ietf-dmarc-dmarcbis-38 - IETF stream Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Proposed Standard) Token: Murray Kucherawy Liz: We have a discuss, do we want to discuss this now? Murray: I don't need to so I guess AD follow-up. Liz: This one will stay in IESG evaluation with the substate of AD follow up, and Murray as an FYI, once this gets to the eventual approval, this one does have two down refs, so we will want to know if 7489 and 7960 should be added to the down ref. Murray: This is oh this is the obsoleting 7489, so does it have to down ref it? This is the one that Roman you and you emailed Elliot about. Roman: Talk me through the thinking between the link of the the obsoleting versus kind of getting approval from the ISE to do this. That was what the that's what I meant with the permission from the ISE. Murray: Right, they happen to be the same document, the linkage is very weak. I'm reminding you that we're talking about the same reference here. The issue is that 7049 is a reference, but also we're not depending on it normatively for anything. It's more like this was the document that was there before. Do you have to make it a down ref for that? Liz: Well, you definitely don't have to add it to the down rough registry, so the answer to my question can be no. Francesca: It's a down ref right now because it is normatively referenced. That makes it a down ref. Murray: I might want to do back and have that changed to informative. Let me look into that, but it's being obsoleted and if it doesn't say that it really should. Alright, I'll follow up on that point too. Deb: It doesn't have to be in the registry, you just have to down ref it. That's not a problem, right? Murray: No, I don't think so. I'm just trying to be neat and tidy, that's all. Eric: But if it's obsoleted, there's no point adding it to the down ref registry anyways. Murray: Right. Nothing else should have to down ref this. Eric: So don't put it there. Francesca: I guess the question is, if you're obsoleting it, do you want it as a normative reference for the document that is obsoleting it. That's the question. Murray: Right. That's the other tidy, that's the other way to tidy this up. o draft-ietf-ipsecme-g-ikev2-20 - IETF stream Group Key Management using IKEv2 (Proposed Standard) Token: Deb Cooley Liz: We have a couple of discusses, do we want these now? Deb: I think it's fine, the discussion si already happening behind the scenes so I think we need this in revised ID needed. Paul: Most of my discussions points have already been addressed by Valery in email. I just have to go through and clean up, but this will be done like in the next two days. Liz: So this one will stay in IESG evaluation with a substate of revised ID needed. o draft-ietf-ipsecme-ikev2-rename-esn-03 - IETF stream Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) (Proposed Standard) Token: Deb Cooley Liz: This one doesn't have any discussions though unless there's an objection now, this one is approved. Deb: Put this in revised ID needed. Liz: So this one is approve announcement to be sent; 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-ntpv2-ntpv3-to-historic-01 - IETF stream Status Change of NTPv2 and NTPv3 to Historic (None) Token: Erik Kline Liz: There were no objections to this so I think this is ready to go through. Does anyone have anything else they want to discuss about it? Francesca: No objections. This is what some of those brought up by Pete. Erik? Erik: Yes, this was one of the inconsistencies that Pete Resnick observed. Francesca: Right. I just want to say that you know the the other documents I took the action items not so not on this status change, but I started the status change last call on on the other documents that Pete had suggested that we move to historic and it has created a bit more discussion than I expected, so I need to really carefully read through the last couple of comments before I bring it to the telechat. I hope to do it before I step down. But if I don't, then I will need someone to take over that. Erik: Even this generated a little bit of discussion in the NTP group working group, but it was almost entirely around what does historic mean, what do words mean. Francesca: It's sort of the same on, on the other one and it was more about, oh, but it seems we have a bigger problem and why don't we fix the bigger problem and this is confusing and high level comments like that. Roman: One narrow difference I observe between the bigger one you're talking about Francesca and the one on deck here is that we have an active working group here and they're reasoning about that, and as I understood some of the larger kind of conversation, it's exactly how you framed it. It's a more general problem, maybe there's the working group maybe kind of there's not, it's really a question of how to handle that status for everything holistically. And that's throwing it out. Francesca: I'll try to bring it back. I might bring it as a management item rather than a status change to discuss more widely with the rest of you guys. Liz: Erik, this one is approved, is this ready to ship? Erik: I saw no comments, so I guess I don't know what the next step is. Liz: The next step is either we go ahead and send the announcements or you take some more time to check it over and make sure that it's ready. Erik: I would change nothing, so I guess let's proceed into the fire. Liz: So approved announcement to be sent, announcement to be sent, and we will get that all taken care of. 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items NONE 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 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-nmrg-green-ps-00 IETF conflict review for draft-irtf-nmrg-green-ps draft-irtf-nmrg-green-ps-04 Challenges and Opportunities in Management for Green Networking (IRTF: Informational) Token: Mahesh Jethanandani Liz: We have a discuss here, i'm guessing we want to discuss this now? Mahesh: Sorry for the confusion around this document, this is the 1st time I was dealing with a conflict review. So I put my own document in and discuss which well I just wanted to have a discussion around the conflict. I naturally thought it was put it in discuss when I could have left it in yes and still had the document reviewed. So from a process perspective, my first confusion was with the response. So there in the choice of responses basically was don't publish because there's a conflict or publish go ahead, not a problem. And what I was trying to articulate in my conflict was something in between and I mentioned that even on the chat. So that was a bit of a confusion on my part, not understanding how to articulate the fact that there is some ballot text that it will explain. Anyway, it invoked that response from Alex about wanting to challenge the decision which we are still only discussing now. So that is from a process perspective, then from a content perspective, as I'm as I feel I think the document has some overlap with the text in Green or the charter in Green, so that's I think even Roman saw that in the document and I did discuss it with Colin. Colin agreed and said that yes, he thinks the document needs to be revised. And so we that's the conclusion we left with. But now it's a question of I guess waiting for the document to be updated. Roman: Let me jump in here with process, I'm gonna step back and repeat what I think some people know, because we something we infrequently run the conflict group process, but we don't often end up with the results not published, so kind of let me level set us here. So what's gonna ultimately gonna happen here is we're gonna come to a conflict review result. Once we get to the point of clearing the ballot to make a decision, Colin and the authors can kind of process it. Of course, the authors in Colin can watch what it is that we're talking about. But the question for us is, can we as the IESG get to a decided on conflict review position? And to get that we have a proposed conflict review position which is not to publish kind of at this time. So my question to you, Mahesh cause I'm just looking at because everyone else did no objection or yes, which means they support the conflict review position of not to publish. You have a discuss which procedurally means you disagree with the conflict review position of not to publish, so what I'm asking you is not to change your mind, but what it sounds like is you agree with the do not publish decision that you put in. But what you're trying to do is put some text in to explain why you're holding the position very much the same way I wrote to explain my position. So I think procedurally, if your intent is to say, I agree with this conflict reposition, let me explain why I think that way, then your position is not discussed because in this case like it's not like a document might discuss holds the document here then you're supporting the position of not to proceed and so the ballot is comment or yes or whatever is that then we get a decision from the IESG and then can be actioned. If that makes sense. Mahesh: So it’s clearly a case of too many double negatives that got me off. Roman: So that's the succinct way of putting it. This is a double negative situation. Mahesh: So yes, my position would be a yes, and then now it's a question of what text we want to agree on. Roman: I mean if we say don't kinda publish, I mean it's very helpful to be concrete on what it is that is raising concern because that provides options practically to Colin and the authors to figure out how they respond to us and procedurally I wanted to everyone, this is ultimately a recommendation to the other stream. They can choose to ignore this as I recollect the process, this will go back to Colin so being more specific helps and provides options. Zahed: I kind of viewed Mahesh on doing the review and he's also discussing his own decision. So I thought like what we could do here is Mahesh goes to no objection or yes and then puts his comment. He kind of explained why he has this conclusion like the recommended text and that is basically the reason I mean, do we need to be more specific than what Mahesh says and what you said also because you have been more specific giving suggestions. Is this not good enough for the RG chairs to reconsider? Roman: Again, I want to be very sensitive to the separation of kind of power here. Like I am an AD just like the rest of you equally validating, so I am not in a position to tell you what to ballot. I am just being persuasive and explaining the process. So do you want to be more specific? You don't have to be. But I recommend that you would if you think you need to be, and then procedurally, I think what needs to happen is if you and now I'm looking back at you Mahesh. If your position is you support it, like you gotta flip your ballot because flipping the ballot, is how you you it's deconflicts the double negative situation that we've ended up in. So if you can be more specific that's winning you don't need to be more specific. Zahed: This is a recommendation from you to be more specific, but I think process wise as I think Mahesh keep this double negative because I think there was some confusion I think anyway, he doesn't want to discuss his own decision there. So I think you need to change your ballot, Mahesh. Roman: Sorry, I didn't start a kind of a queue. You have a suggestion kind of Paul, but Deb I think you were trying to jump in to comment on what side was doing, so if we can just keep the thread and then we'll pick you up Paul and I'll start the queue so we can better balance. Deb: I thought there was a provision in the conflict reviewed statement that allowed you to add optional text. Mahesh: You can do that in the ballot text. Deb: That's what I meant. Eric: I think you can put it below. The first line is basically publish or not published. Then after you can put something below, I think. Mahesh: maybe when I pulled up the template I think it was one of those template responses and then something that IANA can add. I didn't think that that was the place for me to add extra text. What Roman and I discussed Roman said put it in ballot text. So that's when I went and put it in the ballot text. Eric: Both are OK for me. Deb: I don't know which is correct because I thought I saw a provision for making optional comments when you did a conflict review. But I mean I've only done a couple so maybe i'm wrong. Cindy: It's a boilerplate response that goes out includes a line that says something to be effect of the IESG would also like the IRTF to review the comments in the Datatracker and then it points to the ballot. Mahesh: That was my understanding. Deb: I understand, I think. Eric: What basically matters is Colin getting our comments and the authors. Roman: Paul, you had a proposal for us. Paul: I didn't ballot because I was confused by the situation and I think I want to have some time to reinterpret this now with with Mahesh's vote changed to yes because I am leaning actually towards that I want this to be published, so I wanna think about this some more now that we've changed the context. So, can we punt this to the next telechat? Roman: So procedural levers, if I can just be reminded. Can Paul just hit the defer button now? Cindy: Yeah, a document discussion can be deferred during a telechat. He can hit that button or we can do that. That's fine. Roman: And that's procedurally, OK? Cindy: Yes. Shall we go ahead and do that for you? Paul: Yes unless there's people who have stronger objections to coming back to this next week. I don't think there's an urgency here. Roman: But again, kind of separation, any AD can say I need more time, and so if you are saying you need more time, it's your prerogative to hit kind of defer. Paul: Okay, well let me hit the defer so the record shows that I am to blame. Cindy: I just wanna double check because the states for conflict review are slightly different. There may not actually be an official defer on this. Let me see if that's true or not. Oh, there is, ok, so yes, you should be able to. Roman: There is a defer ballot. I've never done it before, i've never seen it before, but I think we have the lever. Liz: If the button works. Cindy: If it doesn't work, we'll sort it out, but just know that like the some of the the point raised et cetera, states aren't always there for conflict review stuff. But if defer is there, then yes, Paul, if you could hit that button, then that would be great. Liz: Paul is deferring this one and we will put it back on the next telechat for further discussion. o conflict-review-irtf-cfrg-kangarootwelve-00 IETF conflict review for draft-irtf-cfrg-kangarootwelve draft-irtf-cfrg-kangarootwelve-16 KangarooTwelve and TurboSHAKE (IRTF: Informational) Token: Deb Cooley Liz: There are no objections here, so unless anyone has a comment now. It looks like now this is approved and can go back to IRSG. Deb: Unless Eric V has actual comments on this, I think it's ready. Eric: Let me check my comment that I put there. Deb: There is a third order PPM relies on a VDAF draft, which is also a CFRG draft, which relies on this draft, also a CFRG draft so there's a very indirect link to PPM. I did check with PPM just to make sure, so that's why I put it on there. Eric: Okay, anyway, you can put this into a conflict. I don't see a conflict, but if you think there is a conflict or an overlap, that's fine. Anyway, it doesn't prevent publication. Deb: Exactly. It just says there's a relationship there. It doesn't say there's any reason to not publish. Liz: This conflict review is approved and Deb, is this ready to send? Deb: Ship it. Liz: Approved announcement to be sent, to be sent. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Domain Keys Identified Mail (dkim) Liz: I don't see any blocking comments. Is there any objection now to sending this for external review? Murray: i've got nothing pending on it, if that's it then let it rip. Liz: We will go ahead and send this external review announcements with a separate message to New Work and we will put it back on the agenda for the next telechat for approval. o RESTful Provisioning Protocol (rpp) Liz: Is this ready for external review, we have no blocking comments? Orie: I hope it's ready. I believe it's ready. First time getting to this stage, so any process advice for me? Liz: I don't think so. If you want to take a minute and just double check it and make sure it's ready, we can hold off or if you think it's ready to go, we can just go ahead and send the external review announcement now. Roman: I haven't looked at it and I haven't looked at it where I always like to check the markdown that it's rendering right. Orie: Okay, I'll do a final check on the markdown and I'll follow up sometime later today. (later during the telechat) Orie: On the RPP charter, I looked at the markdown and it looks good to send so I don't want to wait for another round of cycling before approving that. Liz: OK great. We will go ahead and announce the RPP external review now without waiting for anything o Digital Emblems (diem) Liz: We do have a couple of blocking comments here, do we want to talk about this now? Orie: Yeah, I would like to chat a little bit about it. So first of all, I appreciate the comments from everyone who's left them on the document. The two abstained positions sort of align well with what Paul had said. I think and also I think basically everyone is saying the same thing about the document. There's some history here in how we got to this point for the document. I think it is possible to be more precise in narrowing the charter on use case or narrowing the charter on technologies that it's gonna be supporting, and there's sort of, maybe a pros and cons for taking either approach here. But I wonder if for any of the folks who've left a block comment whether they have an intuition on what the right path forward would be. Paul: So speaking for me, I actually don't have any idea because like I was at both BoFs and the room was completely split over what to do. And I thought the charter would then pick a subset of it and say like let's do this first and do the other one maybe later. But the way it's been phrased now, it sort of included everything again with like sort of weird weasel wording, and so now I'm not sure because now you're hitting the point where the reason why I half the room set no to some of this was because they thought that one solution couldn't basically target both of them. So you cannot have one solution that targets digital assets and also physical assets and it's sort of being merged into one now. And I have no idea how that would work and then specifically what I said too, one of the conditions I heard during the BoF was like a validator should be able to validate things without being known that he's there so that, an army can do a reconnaissance flight, see what medical things are there without telling them that they're about to bomb the area around the medical stuff. That seems to have been sort of dropped off and that falls squarely into the digital versus analog asset and what's the media, is it the QR code? Do you need to be physically near or is it the broadcast that goes over the entire city? And with all of those sort of unresolved I'm not sure if the working group can actually get work done. Roman: Since you're asking Orie procedurally I want to open with like it's up to the community to decide how they wanna do that. From my perspective, like Paul, like at the BoF I heard we had two very clear camps. One of them seemed to have very much more narrow use case, which could actually explain what a digital kind of emblem is. It constrained it very tightly. They had what sounded like a very descriptive and clear use case as to what the deployment would look like. And then we have something else that I think was this is more the digital case. It certainly was more kind of sweeping, more comprehensive and some of the ambiguity as you said is because we put those together and let's be very, very fair to the different proponent camps. The IESG told them to do that, to put them together. Now having having seen them to attempt to put them together, I wonder whether we should revisit that decision and the different camps should make a pitch, perhaps using the word hard fork, for different charters on their perspectives and would those distinct charters to satisfies those different use cases. Could they bring us to the next step? Would that bring us to the next step that some of that work could be done in existing working groups? I'm thinking kind of SPICE, maybe we're doing a bit of a compare and contrast with a new charter, help us tease out what are the specifics here and what's the novelty here that might get us to the next step. But I think it would be very hard to clarify what I heard on the BoFs, some of the questions that got posed here, but I'm open to rereading. Paul: So just one clarification on that Roman. You mentioned SPICE, but SPICE is very much a interactive protocol, right? You get like a client server responses back, I think and in this case, it is very much more of a broadcast data and receive it. I don't see that as much related to. Orie: So SPICE has a line in its charter about creating profiles for different credential use cases and the classic JWT and CWT credential formats that SPICE is sort of targeting extending. There is a bearer mode of them. I tend to think of these digital emblems as basically bearer tokens that are displayed very publicly. That's just my my take on the technology side of it. I think we could potentially be a little bit more precise in terms of the interaction model, the media, the transports in the charter, and still keep the use cases sort of open for DIEM. I think in order to do that and to get consensus, we would have to be much more precise about like, securing mechanisms or, discovery, like we would have to use text in the maybe in the body of the charter to constrain that part of what the work would do and then leave the data modeling, and attribute extension stuff sort of open. Roman: The other possibility to build on what you're talking about is that the work, the workgroup as chartered right now could just be less ambitious. It could target where there is consensus and the rest would be out of scope after the after progress has been made on some subset of that. And I know it tries to do that now, but with an ill defined in my assessment version of kind of what a first MVP would look like for a particular use case, but I'm arguing maybe even be less ambitious to not really solve everything for one use case or perhaps that's option A option B might be, well, wake, we're not even gonna do any new protocol work. We're gonna really nail down the notional architecture use cases and requirements to hammer on it further, but we're gonna need a recharter to do anything more. I don't know what's gonna what's gonna proceed but that's some more additional options. Orie: The last part, I've not seen a working group charter that only did, informational or architecture documents, but, are you saying that perhaps some of the protocol data format pieces of DIEM could be done in other working groups and DIEM would just cover an interaction model informationally or what do you mean by that? Roman: So everyone else is gonna help me because these are all working groups in your area, but I think like IP wave, as I recollect didn't have protocol work in scope. I think Eric, I'm looking at you like MEDINAS was really only doing requirements architectures, is it through MOPS? Eric: To come back to Orie, I was the responsible ADs for the two BoFs so thank you Orie for taking the lead there. If we do create a working group only doing informational documents basically and the IETF provide nothing to the use case, I am really concerned that the people will go outside of the IETF. So we think we need to deliver a charter with something concrete usable, operationally and securely, of course, after. So I would really we may reduce the use case, but please deliver something with proposed standards there. And if we narrow the charter, we can start immediately and approve it maybe next telechat. We can approve a second charter on the same BoF. That could be this one complete informational. Orie: One of the the challenges that I've been having with this work is it it doesn't there's a security component to it, but it's not a living well within an existing security community working group, like it's not CMS, it's not JOSE, it's not COSE, it's not, PGP. That would really help me a lot to sort of see some narrowing on those dimensions. I don't know what security ADs in particular is that the kind of thing that you think would help here or, is that maybe not the right place to try and narrow on the technology front? Like I'd like to come back with a charter that narrows both use cases and technology. Paul: I think right now we don't know enough of where it would go to actually pick the right technology. Like are we just looking at like presenting a signed certificate with a non refreshness and then looking at like is this still acceptable on the validator or do we need something else that that like I think it really depends on on other things also it doesn't have to go over Bluetooth or something? There might be transport constrictions there that like sort of interfere with things as well. So I don't think you can right now say which security technology you want to use. Unfortunately that is going to be a large part of the actually working group work. Orie: Thanks for the comments here. I think what I'll do is I'll have a chat with proponents and I'll try and get a sense as to where we can do a narrowing, and I'll try and prepare a revised charter that narrows. I would like for it to narrow on use cases and technologies. I think we do know a little bit about the intended deployment model here enough to pick among some of the securing technologies at this point. Paul: And I think if you can limit it to physical assets, that would help too, because this whole online asset thing is really kind of weird because an online asset also doesn't have a location and so that makes things really super complicated. And you can always and you can always say like, this is the uplink modem of the hospital. So it's a physical asset even though you really mean that you're protecting the online connectivity. Eric: But on the other end, right, I could see during a TLS handshake to a web server or somehow, this is one that is protected by international law. This is an easy win. Orie: I think right now the there is a general alignment that at least some new RR type or _prefix, and I'm looking at you, Paul, might be something where there could be consensus and maybe just constraining them to one proposed standard document in that space is a good starting point for an initial charter. Roman: So I don't know whether this is useful Orie, but you were talking about narrowing maybe I think that that's certainly an approach to the other set of words I would use is provide specificity, even if you're not narrowing. I think Eric just brought up like a really good one. If you were able to provide specificity that, and maybe this is the equivalent of narrowing I I'm kind of not sure like if you actually define what an emblem is, it's or you define it that an asset is things protected by international laws that might help us iterate us to a solution. With large caveats that recharters are possible, but we gotta start somewhere. Orie: Understood. Thank you for the comments. I'll try and provide a revised charter as soon as I can. Paul: Feel free to reach out to me for a draft text or questions. Eric: Do we have a placeholder for IETF 122 for DIEM? Orie: Ee have a placeholder BoF request, but this is a group that's already bought multiple times. So I think, procedurally what we're on right now is we have this charter we need to do some revising on top of it. If we can get the charter to the point where we feel like it's ready for external review, great. If we can't get the working group landed in time for 122, there won't be a meeting of the working group at 122 and there won't be a BoF. Perhaps there could be a group of proponents that can still chat about where we are in the process and all of that and i'm happy to support on that front, but that's kind of where we are in the process. Liz: I will probably though, just because it's always easier to take away a session than fit in a new one, so I probably will put in a session request for it and schedule it as if it's gonna happen and then just take it away if it's, if it's not gonna go as opposed to the other way around cause then the conflicts would be a mess, so you will probably see a session request for it, but that doesn't mean we still won't know for sure if it's going to be scheduled or not unless we know it's going to be approved. Orie: Awesome. Thank you. Liz: So we will just leave this where it is for now, Orie and you can let us know when it's ready to maybe come back another chat or what you want to do with it. 4.1.2 Proposed for approval o Taking IP To Other Planets (tiptop) Liz: There are no blocking comments, any last minute objections to approving this charter? Eric: And if not, thank you so much for bearing with me all the the revision of this working group specifically for Paul, Roman and David if he's on the call. I think now the charter is pretty clear. We never intended to change TLS and I would guess if they want to do security or transport work in the working group, there will be no security except really if Paul and Deb wants us to do it, but under your supervision. Paul: No, I mostly just wanted to point out that you don't want to be too quick to just say 'oh, we can use QUIC on this.' Because like it is there's a reason for the bundle protocol outside with these people. To batch things up and send them because that just works better over large distances. So I just wanted to make sure that, you're not committing yourself to using QUIC, whether it is QUIC or a changed version of QUIC. So that was my main point. Eric: The working group could be no QUIC is not workable or it's workable to the moon, let's say or but not to mars. So that's a useful thing to do. I mean, it's a pointing but useful thing to do. Erik: Well, that kind of question seems like it could have been answered in a research group, but they didn't want a research group. They wanted a working group and they didn't want to do the work in DTN. We began to open up the charter of DTN to see if we could include the work there, but they decidedly we're not interested in doing DTN. And the charter has text it won't interfere with DTN, so that seems fine. Liz: Eric, is this charter text ready to go or do you wanna make any other changes to it? Eric: I would not dare to make any changes to it now. Let's ship it. Liz: The text is approved, but we still do need chairs. Eric: I got a couple of suggestions I'm finalizing with them tomorrow and to be honest, I think I can say it right now. One of the chair could be one of the active outgoing AD. So I'm not sure whether I can already select a chair which is an outgoing AD in Dataracker. Cindy: Funnily enough, we're gonna have another discussion later. I think technically, we can, it's it's a question of optics and I would suggest if you have multiple chairs, it is cleaner if you wait until after the plenary to name an outgoing AD as chair. Eric: That was my plan. Roman: I 100% agree on that. Eric: That was also my plan. You will get a chair tomorrow afternoon, my time. Liz: After we get the chair, who is not an AD we will go ahead and send the announcements. o Heuristics and Algorithms to Prioritize Protocol deploYment (happy) Liz: There are no blocking comments, so it looks like it's approved unless anyone has any final objections. Zahed: I'm getting really good at creating new working groups and creating charters, but I think a very good run on this one. I don't see like anything that I should be editing. I think this should be very focused and it has got some other people who are interested looked into that one. So it's ready unless somebody has a complaint right now. Liz: I'm not hearing any, so I think we can go ahead and call this one approved. Zahed, is this ready to go or do you wanna make any more final edits? Zahed: You need chairs, right? So I need to pick chairs. I'll get it to you as soon as possible. Liz: Ok great. Approved but pending the addition of chairs, and we will wait for those from Zahed. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o IP Security Maintenance and Extensions (ipsecme) Liz: There are NO blocking comments here, so any objections to approving this recharter? Deb: Eric V posted two comments, and both Tero and I replied to him as long as he think those are OK. Eric: That's ok anyway, you could fairly ignore it. No problem. Deb: It's ready to go. Liz: This is approved and ready to go, so we will go ahead and send the working group action recharter announcement. o Link State Vector Routing (lsvr) Liz: There are no blocking comments for this either, so does anyone have any final objections to approving this recharter? I'm not hearing any objections so I think it's ready to go. Jim, is this ready to be announced? Jim: It is, please ship it. Liz: We will go ahead and send out this recharter announcement. 5. IAB news we can use John: That always catches me by surprise, news we might Well, anyway, the news that I noted down are, one is the IAB was having a long and involved discussion about whether they need to have security considerations in their documents instead of putting any of this section left blank, they'll decide whatever they decide, they believe decided to have a second IABopen session at 122 just to talk about WSIS which is the World Summit on the Information Society. And other than that scheduling meetings is hard across global time zones, which they're even worse often than we are. Anything to add, anybody? Tommy: We will have that second WSIS session at the next IETF meeting. These are both gonna be short meetings, so we don't want to take up too much agenda time. The only other thing to mention is we should be sending along the ISOC board of trustee appointment for IESG confirmation soon. So you'll see that coming to you. Liz: And just the detail on the time zone comment for whoever might want to be the liaison to the IAB in March, so their meetings are gonna be moving one hour earlier, at least for the first six months or so, maybe reassess at the next daylight savings in the North American Fall, but so their meetings are gonna be on Wednesday at one hour earlier than these telechats start so take note if you want to IAB liaison. 6. Management issues 6.1 Final BoF Approvals for IETF 122 (All) The management issue was discussed. See the minutes of the IETF 122 BOF Call meeting for details. 6.2 [IANA #1412130] Designated experts for RFC-ietf-ntp-update-registries (Updating the NTP Registries) Liz: This is just the official action item assigning this to Erik Kline. 6.3 IANABIS Scheduling at IETF 122 (Murray) Liz: IANABIS was approved back at the end of last year, but it's still listed as proposed in the Datatracker because there aren't chairs and so Murray will become a chair once he steps down, but if we want to schedule a session for this at 122, it gets a little complicated. Roman: So Murray, is the fix here you make me responsible AD for this? I find or we find, a chair to sit with you and then we can do this switch after? Murray: I think the something close to that, I can't be AD and chair, but someone could appoint me chair or we could find someone who's just we tell them you are the chair, you don't actually have to do anything. This will change after Wednesday. We just need a name there that isn't an AD. (crosstalk) Francesca: But Murray, you would have a co-chair, right? Murray: Yes, but we don't need that to get started, but I haven't identified a co chair yet, so that's kind of why we're stuck. I don't have a co-chair. Francesca: I think you should find a co-chair. Murray: I mean Harald's been running mediaman by himself for all this time, so let me try to find one and that would solve this problem. I’ve just been parked on me being the start that for so long, I haven't even thought about it. Deb: Are you claiming to be as good as Alvestrand? Roman: Murray, i'll give you a hand on this. We can work this on this offline because we definitely want a co-chair either way. Murray: I've exhausted my usual suspects, that's all I was going to say. Francesca: I was going to say is I don't think it's any problem to have Murray like assigned as chair even if he's finishing his AD duties as long as he's not the responsible AD. It's a bad look if an AD is chair, but given that he's stepping down as AD, it's obvious and they have their first meeting at 122. It's really not like there's really not anything that he can do that is going to be a bad look. Roman: I mean the responsible AD that's outgoing, delegating themselves the working group chair is a very bad look. Francesca: I'm saying once he's not the responsible AD. Eric: We were just talking about TIPTOP in the same situation, and I will defer. You do whatever you want. I don't mind but be consistent here. Roman: The right answer is we should have a co-chair irrespective of who is the other chair that might be Murray. We will work on that. Murray: I'll look around. How soon do we have to pull this off, Liz? Before we can't schedule it. Liz: I mean hopefully as soon as possible I think I can put in a session request. Actually, I'm not sure if I can put in a session request for it right now. I will look into that. Murray: Do we need to create a fake BoF placeholder just so the Datatracker is happy? Cindy: There's already a Datatracker group for this so you should be able to create the session request and I think that like if it's not sorted out by the time the preliminary agenda is published, it's gonna have that new proposed tag on it that shows up on the agenda. I think then you just have to figure out at what point you want to pull it when you don't have the chair stuff sorted out. Liz: I can just go ahead and submit a session request for it now. I don't need you to do a BoF placeholder, but just before we know who the chair is, it's hard to know what conflicts are gonna be so the scheduling and it has to be on Thursday because, you'll be AD until Wednesday so yeah it might get a little tricky with scheduling, but I can go ahead and pretend like it's gonna be real and scheduled as it will be real. Murray: I'll work this out with Roman. I'm already pinging a couple of people. Liz: Should we go ahead and change the responsible AD for that group now or just wait? Murray: Roman, this is a GEN area thing anyway? Roman: Yeah, you can give it back to me. Murray was giving me a hand which I greatly appreciate to move this ball forward because he knows the most about this, but regardless, it's GEN. Murray is rotating out whether he takes another leadership role or not. Liz: We will make Roman the responsible AD, and I will put in a session request for it. We will wait to hear about chairs. 6.4 Retreat Logistics (Cindy) The management issue was discussed. IESG agreed to move forward with proposal 2. 7. Any Other Business (WG News, New Proposals, etc.) Francesca: The next informal that the you guys secretariat is doing the presentation? Cindy: No, that will be on the 27th. The next formal has the agenda deconfliction on it. Francesca: Just making sure that the new ADs are on for both, I guess. They should definitely join your presentation and they probably should also join the agenda, they're deconflicting since they will be a part of it, correct? Cindy: Certainly for the onboarding one. Liz: For agenda deconfliction, it's always nice to observe one before you have to do one. It might be confusing but it's good to observe next week. Cindy: Depending when in the week a working group is scheduled also the incoming ADs may be the ones who have the conflicts. Francesca: Please join if you can. Roman: Any other topics? As a reminder that the next formal telechat two weeks from now, it's a little over 500 pages so next week might be a good reading week. We want to blow the back log out.