INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-11-21 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, 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 Jim Guichard (Futurewei Technologies) / Routing Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Web and Internet Transport Area 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 Mahesh Jethanandani (Arrcus) / Operations and Management Area Warren Kumari (Google) / Operations and Management Area Tommy Pauly (Apple) / IAB Chair David Schinazi (Google) / IAB Liaison OBSERVERS --------------------------------- Greg Wood 1.2 Bash the agenda Liz: Does anyone have anything to add to today's agenda? Éric V: Time allowing, I'd love to discuss the next steps for DIEM and DEEPSPACE. 1.3 Approval of the minutes of past telechats Liz: We have two sets of minutes to approve today. Does anyone have an objection to the minutes of the October 17 IESG Teleconference being approved? I'm hearing no objection, so those are approved and they'll be posted. Liz: Does anyone have an objection to the minutes of the October 24 IESG Teleconference being approved? I'm hearing no objection, so those are approved and they'll be posted. Liz: Does anyone have an objection to the narrative minutes of the October 17 IESG Teleconference being approved? I'm hearing no objection, so those are approved and they'll be posted. Liz: Does anyone have an objection to the narrative minutes of the October 24 IESG Teleconference being approved? I'm hearing no objection, so those are approved and they'll be posted. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Zahed Sarker to find designated experts for RFC 9653 (Zero Checksum for the Stream Control Transmission Protocol) [IANA #1378063]. Zahed: I've identified but I'm still waiting for one to respond. I should have this by next time. o Murray Kucherawy to find designated experts for RFC 9559 (Matroska Media Container Format Specification) [IANA #1385324]. Murray: In progress. o Erik Kline to find designated experts for RFC 9669 (BPF Instruction Set Architecture (ISA)) [IANA #1394753]. Erik K: I actually already have names for this one, should I send them to you? Liz: Yes, please send the names to support@ietf.org and we'll add those to the end of the agenda. o Gunter Van de Velde to find designated experts for RFC 9666 (Area Proxy for IS-IS) [IANA #1394691]. Liz: Gunter, this is a new one for you. * OPEN ACTION ITEMS o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani, Warren Kumari to write draft of IESG statement addressing issue of credit in documents & the importance of capturing and addressing all comments as a necessary part of the consensus process, mostly pointing at existing advice. Liz: I know this one is done, because the statement has been published. o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Murray: This needs one more round. We were going to do it in Dublin and didn't have time, so I'll get to this. 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 prepare status changes or another way forward for the handful of obsoleted documents Pete Resnick emailed the IESG about on 2 Nov 2024. o Roman Danyliw to take a look at Datatracker documentation of document states and update as needed. Roman: All of mine are in progress. o Secretariat to update non-wg list guidelines to include a link to IESG Statement on Disruptive Posting and detail on list moderation. Liz: We haven't gotten to this yet; that's 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. Roman: Can you remind me what the context of this was? Liz: I don't remember off the top of my head, but I can pull up this section of the notes. Paul: If I remember correctly, this was just that if authors wanted to do the github experiment, that the ADs would always say yes. Not that we decide to do all of it as an experiment, just that we would not be a blocking factor and participate if others decided to do the experiment. Roman: Thanks. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-ace-wg-coap-eap-11 - IETF stream EAP-based Authentication Service for CoAP (Proposed Standard) Token: Paul Wouters Liz: We have a few Discusses here; do we want to discuss these today? Paul: I don't know. Not me specifically, I didn't have time to look at it yet. Francesca: Mine is quite easy and hopefully the authors can just respond. And of course you haven't had time, I just posted it half an hour ago; sorry about that. Éric V: Mine is also very simple, mainly addressing the shepherd writeup because he did not check the IPR and whether authors are willing to be authors. Easy to fix as well. Paul: Okay. Please put it in AD Followup. Liz: Great; this one is staying in IESG Evaluation::AD Followup. o draft-ietf-lamps-header-protection-24 - IETF stream Header Protection for Cryptographically Protected E-mail (Proposed Standard) Token: Roman Danyliw Liz: There are no Discusses in the tracker, so unless there's an objection now, this is approved. Okay, this is approved. Roman, is this ready to go? Roman: First I want to say thank you to everyone for the review of this very long document. Can we please put it in Approved, AD Followup? There are some comments there I want to understand. It's likely to be revised I-D needed but I want to sweep through them first. Liz: No problem; so this one will be Approved, Announcement to be Sent::AD Followup. o draft-ietf-pce-stateful-pce-optional-10 - IETF stream Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects (Proposed Standard) Token: Roman Danyliw Liz: There are no Discusses here, so unless there's an objection now, this one is also approved. Roman: Again, thank you for everyone's feedback. There are a few things in the comments I think should be reflected, so can we have this one Revised I-D Needed? Liz: Absolutely; this one is Approved, Announcement to be Sent::Revised I-D Needed. o draft-ietf-nfsv4-layrec-02 - IETF stream Reporting of Errors via LAYOUTRETURN in NFSv4.2 (Proposed Standard) Token: Zaheduzzaman Sarker Liz: There are no Discusses, so unless there's an objection now, this one is also approved. Zahed: I think I've got some comments on the resilvering. I also picked that up and was told by the nfsv4 chairs that this is a really well known terminology. Maybe we can just describe it in another way so that others can understand. Other than that, I don't have anything else. If this is approved now I will just put it in AD Followup. John: One of the authors replied to my comment and said he'd add a definition for resilvering. Zahed: That's great. It's pretty obvious for them because they use the term day by day but just adding something would be great. Deb: Is this the one with the terminology section where they point to another RFC? It is in that other RFC. Zahed: Yeah. But anyway, I think they can just be descriptive about it. Liz: Okay, so this document is Approved, Announcement to be Sent::AD Followup. Zahed: Thanks for the comments. o draft-ietf-cdni-capacity-insights-extensions-10 - IETF stream CDNI Capacity Capability Advertisement Extensions (Proposed Standard) Token: Francesca Palombini Liz: This one does have a few Discusses; do we want to discuss these now? Francesca: I don't think we need to discuss. I definitely agree with everyone who has raised concerns about this text; I should have seen it. Initially there were no designated expert guidelines. I expect the authors will make the change; it's nothing controversial for me. Unless anyone wants to highlight something, I think we can keep it where it is and wait for the authors to reply. Paul: This is the one with lots of branding and advertising in the first section, right? Francesca: Yes, I saw you had a Discuss about that. Éric V: On the other hand, it's not so much advertising; it's linked to other SDOs somehow. Paul: I think also commercial entities, right? I wondered if it came up during the WG time or whether everyone just read past it. Francesca: They are collaborating a lot with the SVTA. That's why they refer to it in the introduction. Zahed: I don't feel it's a lot of advertising going on, just that this work is related to the SVTA. John: I did my review after you made your comment, Paul, and I tried to imagine reading that without any of the references to the other industry groups and it didn't seem as clear. I think this has some practical use. Francesca: They're trying to motivate the need for this document. I'm happy to work with you, Paul, and the authors to see if there is anything superfluous. Paul: Thanks. Liz: Sounds like this one is revised I-D Needed? Francesca: Definitely, yes. Liz: Okay. This one stays in IESG Evaluation::Revised I-D Needed. o draft-ietf-suit-firmware-encryption-21 - IETF stream Encrypted Payloads in SUIT Manifests (Proposed Standard) Token: Deb Cooley Liz: We have a Discuss here; do we need to discuss this today? Deb: I'd like to wait for the authors to respond to the comments. I do think it needs a revised I-D. Liz: Okay, so this one stays in IESG Evaluation::Revised I-D Needed. And Deb, a heads up for you; when it eventually gets to approval, there is a downref to 9053, so we'll need to know if that should be added to the downref registry. Deb: Okay, thanks. o draft-ietf-pce-stateful-pce-vendor-12 - IETF stream Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. (Proposed Standard) Token: Roman Danyliw Liz: There are no Discusses here, so unless there's an objection now, this one is approved. Roman: Thanks for everyone's review. And thank you for some of the particular text suggestions made. Can we mark this revised I-D needed? Liz: No problem, so this is Approved, Announcement to be Sent::Revised I-D 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 NONE 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 NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval o Update to IANA Considerations (ianabis) Liz: This will be in the GEN Area with Murray as AD. Does anyone have any objections to the creation of this WG? We had a block earlier, but it looks like that's been resolved. Murray: I'm curious what Zahed's comment was. Which documents are you referring to? Zahed: Basically the WG will come up with a new kind of text requirements for DEs, and all the to-dos this group has. At some point this will be executed on future drafts; but what impacts does it have on previous drafts? Will this WG be talking about what's happening with already approved documents, or will there be no impact? Murray: the only intention is to update 8126 with more modern advice. That's the only document we're planning to change and it shouldn't retroactively affect anything. Zahed: Okay. That's basically what I wanted to know; it wasn't clear in the charter. Murray: I don't think we've ever enacted a BCP update that affects already approved documents, so I don't think we need to say it, but I'm happy to go with consensus if others think we should. Zahed: I don't have a strong opinion, I just wanted to know. Murray: Okay. Mahesh isn't here; I was going to ask if he's happy. I replied to his email and never heard anything further, so I'll assume that's settled. You can create this, but I don't have chairs yet. I'm willing to chair it after I've stepped down from the IESG, but I need someone to take it over first. There's no urgency to get it done, so it's fine if that's what ends up happening. Liz: Do you want us to go ahead and send the WG creation announcements or do you want us to wait a little bit? Roman: We can't send the announcements without naming chairs. Murray: Right, yeah. Let's hold this until I find a first chair, and then Orie can add me as a second chair on my way out. Liz: Okay, so this does have approval but we'll wait for instructions from you, Murray, when it's ready to go. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Routing Over Low power and Lossy networks (roll) Liz: This is in the Routing area, with John as AD. There are no blocking comments, so is this ready to go for external review? Or is external review not needed? John: My view is that external review was not needed, and nobody objected, so I'm going to stick with that. Éric V: Please read my comments; the charter includes WGs that are concluded. John: That's fixed now. I think it's completely noncontroversial to take out concluded WGs; if we start adding new ones, we may need to send it for external review. I emailed the chairs to ask what they think and I want to leave a little time for them to respond. Other than that, I think it's ready. Liz: Okay, so this is approved without external review, but we'll wait for you to let us know when it's ready to announce. o Source Packet Routing in Networking (spring) Liz: This is in the Routing area and Jim is AD; we do have quite a few blocking comments here. Do we want to discuss these now? Jim: I think we probably should. One thing that's unclear to me is that a lot of these blocks get removed if I get them to remove that one offending line out of the charter. I wanted to get thoughts on that. Bear in mind, this recharter was really done in response to the SRV6OPS; I promised we'd recharter to make sure it was aligned with that, which it does. The chairs wanted to do this experiment where they try to make it more difficult in the WG to adopt work that's just getting +1s on the mailing list. We thought this was fine to use a wiki because my stance was the chairs are welcome to run the WG however they want as long as the work coming through is within charter. This text seems to have started a bit of a firestorm. I don't know if just removing that works or whether we need to add something to the charter, or what's the best way forward. Paul: I'd ballot no objection if you just removed that one sentence. Roman: I'd continue to block even if you remove that sentence. My concern is that I don't understand what's in scope or out of scope. The way I currently read the charter, it defines what spring is, makes some reference to the other WGs, and then is silent on what it does. I don't know when to close the WG, how to judge whether it's in scope beyond some pattern matching if it uses the word spring. Then I have the architectural question as well. Jim: I think your comments were different from the others. What I was trying to do was clean up the easy ones first, which is getting rid of that sentence that seems to clear Paul and I think Gunter as well. Gunter: Yes. Removed or better defined. Jim: Then once I've gotten rid of those, I can start looking at yours, Roman. I think that's probably the way forward. Does that make sense? Éric V: My block is very similar to Roman's. If you clear Roman's I think you'll be clearing mine as well. Roman: That makes sense to me, Jim. John: Just an observation; Roman, you said you don't understand the scope or when to close the group. I suspect the answer of when to close the group is going to be never. Spring is a new data plane that the IETF maintains; we can debate whether it is or isn't, but it has the characteristics of being another data plane. Just like we wouldn't close 6man, I don't think we'd probably ever close spring. We should keep that in mind when considering the charter. Jim: There's a lot of work they're still doing. When I spoke to the chairs, they felt like it was a lot of work to maintain milestones on work they've already adopted into the WG. They want to use their wiki to manage that work, and I'm fine with that. The text in the charter hasn't changed that much from the previous charter; they haven't added anything. They've taken a bunch of stuff away in an attempt to clean up the charter. It's not asking for new stuff, but they may have gone a bit overboard in removing stuff. I would point out there's nothing new being added. Roman: My finesse is correct; they removed the limited bounds that were there, so they've given themselves even more flexibility as I would read. In a chartering conversation it could be good or bad; I'm kind of arguing that it needs some bounding. Jim: That's a conversation I'll have with them. If they need to put some text back I don't think they'll have an issue with that. I'll clean up the other stuff first so we can see what we have left. Liz: Okay, so this will stay where it is for now, and Jim, we'll wait to hear from you when this is ready to come back on another telechat. 4.2.2 Proposed for approval NONE 5. IAB news we can use John: Their whole session was in executive session [this week]. I saw they reappointed Warren, which is great. I guess we'll find out as they announce their appointments. Roman: There's a whole lot of appointments that need to be happening, and that's the process we're going through right now. 6. Management issues 6.1 IANA JSON Web Token Claims Registry (Deb Cooley) Liz: Deb would like to make a change to the DEs on this registry, to remove John and add Filip and Nat. Any objections to making this change? I'm not hearing any objections, so this is approved and we will send an official note to IANA. 6.2 Adding DEs to the IPN Allocator registry (Erik Kline) Liz: Erik would like to add Ed Birrane and Rick Taylor as DEs for this registry. Any objections to naming these folks? I'm not hearing any objections, so this is approved and we will send an official note to IANA. 6.3 [IANA #1394753] Designated experts for RFC 9669 (BPF Instruction Set Architecture (ISA)) (IANA) Liz: This is the management issue to assign this task to Erik K; and we have some names to approve at the end of the call. 6.4 [IANA #1394691] Designated experts for RFC 9666 (Area Proxy for IS-IS) (IANA) Liz: This is assigning the action item to Gunter to find DEs for this registry. 6.5 IESG Statement on the "IESG approval" allocation policy [IANA #1397447] (John Scudder) John: There's one edit I was hoping to make before the meeting and I didnt get to it. Because of Francesca's comment I added this thing about 7120bis. Having seen Amanda's followup, I think we should also cite the 8126bis efforts; it makes sense to roll this into that document. I'd want to do that little update. I'll also note that she basically said no objection to the statement. The substance of her email was that it's weird to put this in 7120bis. I don't think I saw any stop the presses from any of you, so I'd like to propose this is agreed? Roman: I was going to propose a stop the presses. I'm trying to remember, why can't we just handle this in IANABIS? What's the pressure to put this out? John: We could do it in 8126bis. Basically this was typed on the fly during our meeting when we had an IESG approval code point. My sense of the room was that it would make sense to do this as a temporary allocation, which will give us a little rope to tell the applicant to come back with a spec. If I remember correctly, the situation was the applicant came to us and said give me a code point, here's an IOU for a spec. Normally I would not do that with something from another registry, so my preference would have been to do that as a temporary allocation which gives the applicant plenty of time to pull together their spec. There were several people in the room at the time who said we have no history of doing temporary allocations with IESG approval and we don't even know if we can do that, let's not invent this as we go. Generally, it's like the anecdote about the farmer and the leaky roof. Hey farmer, why don't you fix your leaky roof? Well, when it's not raining it's as good as anyone's, and when it's raining, it's too wet to work. So my concern is that right now it's not raining; we could fix the roof, or we could wait until the IESG has another thing they'd like to do as a temporary allocation -- and that might never happen. It doesn't really affect me anyway because I'm rotating out in a few months so if people think it's not important enough to publish, that's fine. I just don't know when 8126bis is actually going to be published, but I don't think it's going to be soon. Roman: What you're saying in terms of documenting process makes sense to me, if we didnt have the WG. we were in the position of not knowing what to do and what the process was, we're going to invent the process, and then we're going to have a new WG to do it in. It seems like having the community consensus process would be better. I appreciate all the work you did on this and it's fabulous, but given that we have the WG, it might be worth just taking the risk that we'll wait until a durable fix with community consensus. Francesca: I totally agree with the content. I was also wondering about the process, if this is the right way to handle this. I also think we shouldn't be so restrictive with IESG statements. When you add the text about IANABIS and revising RFCs, that's going to be the word of law. I'm totally in favor of also publishing this IESG statement because who knows how long that will take and I don't see any harm in doing more statements to let people know what the IESG thinks. Count me in favor. Éric V: John, thank you for taking the case. It was based on an IP protocol number for Homa that we discussed on the Friday. Thank you for the followup. It may not happen; I think it should be in 7120bis but like Franesca, we can publish it as a statement if you want. It's ready, so why not send it? But we need to keep it for IANABIS. John: I hear a Discuss from Roman, a Yes from Francesca, and some No Objections. Based on that I'd say we're not going forward. Francesca: I also want to say, I haven't read Amanda's email in full. I'm trusting you that her email is basically a NoObj. Maybe someone from IANA can speak up. Sabrina: Just to confirm, yes. We don't have any concerns about publishing the statement but we do have some clarifying questions. It would be good if we could get some guidance on how to handle this in the future. In terms of this, we don't have an issue with publishing it at this time. To Eric's point, with the recent request we weren't sure what to do there. Roman: John, you were asking about the way ahead. If everyone else feels it would be helpful to put this out there, I'll yield and just ask that we clarify the note at the bottom and also mention that this may be revised by the future WG but we feel the need to clarify where we are in place. Some weasel words like that, in addition to whatever IANA wants as clarification. Zahed: I was going to say something similar. I'm fine with putting it out, but are we telling this new WG that this is what they should write in the bis? If that's it, then we have an issue. The WG can decide something totally different. If we can say we have no intention of influencing the WG, then I'm fine with it. We'd also need to say how the optics look like. I don't want to say the IESG was telling the WG what to write in a bis document. John: Formally speaking we do not have the authority to tell them what to write. This is something we're offering to the WG for consideration, which the WG can either carry forward or decide not to carry forward. Whatever RFC eventually comes out of that WG supersedes whatever we write in a statement, because that will be a consensus document. I think that's all captured in existing process; maybe whatever that final paragraph gets revised to can give you some additional comfort about it. Zahed: I agree with everything you said, but people also push on the process and point out when they think the IESG is misusing the process. I just want to be clear on our intentions. John: When I read that last sentence, it looks to me like it already reads what you said; if it says something about the IANABIS wg isntead of 7120bis. Would that cover the concern you have? It seems to me that it should. Zahed: It should. What you should make clear is that if this bis is in progress and we know about it, what's our intention to send the IESG statement. That should do. John: I think what I'm hearing is we go ahead with this, rewrite the final paragraph. Roman, do you want to propose a rewrite of that paragraph, or should I? Roman: Would you mind taking the first stab at it? John: Sure. Will do. Liz: We'll wait to hear more details on that, thanks. 6.6 [IANA #1384918] renewing early allocations for draft-ietf-ippm-ioam-data-integrity (IANA) Liz: This is one of Warren's, and he's not on the call with us today. This does expire in a couple of days so we need to make a decision. Any objection to approving this early allocation renewal? Éric V: Has anyone checked whether this draft is still active? Sabrina: I can confirm that Warren did check with one of the authors and they said it is progressing. I think they're hoping the document will be published by the end of the year. Éric V: Okay, perfect. Liz: I'm not hearing any objections to approving this, so we can call this approved and send that official note to IANA. 6.7 [IANA #1384950] renewing early allocation for draft-ietf-bess-mvpn-evpn-sr-p2mp (IANA) Liz: This is another early allocation renewal, and this is one of Gunter's. Gunter: One of the requirements of this WG is to have multiple implementations before it goes on. Both the chairs and I have said we should renew these code points. Liz: Any objection? Okay, we'll call this approved and send that official note to IANA. 6.8 Important Dates for IETF 124 (Secretariat) Liz: These are the same as usual except the final two have been pushed back a little more because they were originally going to fall on US Thanksgiving and right before Christmas, and since a person does actually have to push a few buttons for those we've moved them a bit later. Also, now that we're opening registration earlier, the registration opening date will probably change -- but we don't yet know what the schedule will be for those, so we'll just change that manually later. Any comments or concerns? Okay, hearing none, so we'll go ahead and get those important dates published. 6.9 [IANA #1400018] Management Item: Acceptance of media type registrations from Trusted Computing Group (TCG) (IANA) Liz: Murray, I think you were looking into this one? Murray: For people who weren't following the threads, TCG thinks they have a liaison relationship to us. We do not have an official one back to them, but TEEP is chartered to interact with the TCG on a regular basis. Roman: TEEP has it in their charter, RATS has several documents that reference specs normatively coming out of it, and NIA (?) in the past had some TCG documents. Murray: There's ample evidence to suggest this is legitimate and not someone working out of their basement. I suggest this is approvable. Roman: I concur. Liz: As usual, there are two questions in here; 1, should IANA approve this request, and 2, should they be added to the list of standards-related organizations that have registered media types in the standards tree list. Are we saying yes to both of those? Murray: As long as the first step includes sending it through the DEs, yes. Roman: I concur with that too. Liz: Great, so we will send that official note to IANA. 6.10 De-assignment IANA port based on draft-boucadair-netconf-port-numbers (Zahed Sarker) Zahed: Mohamed wrote a draft saying we're going to deallocate some of the ports that have been assigned to a particular registry. Then IANA responded saying you don't have to write a draft, the ADs and IESG can just allow it. I was thinking, if we have any kind of procedure of how to do that? I don't know if anyone has looked into this netconf-port-numbers draft. There's a netconf port number allocation registry with a bunch of entries with no use. So we can just unassign them with IESG approval. Does anyone see a problem or a process violation? Murray: Is that document going to be published as an RFC? I haven't looked at it. Zahed: IANA's response was that they don't need the document at all. Roman: I think there are 2 questions; do we need to, and do we want to? Murray: If we do this without a document, it looks like the IESG decided to do it ourselves. If we do publish it, then it was a consensus decision. Roman: I'm exactly where you are, Murray. Zahed: I don't really care. Murray: Zahed, to turn this question abc to you; how appeal-proof do you want this decision to be? Zahed: Nobody is using the entries there, so it might be a waste of time. If we approve it, IANA will free those up and put a note about what happened. That could just do. Murray: I'm fine with us doing whatever you decide, I'm just trying to give you some suggestions about how to decide. Zahed: Anyone else have any comments? I'll be looking at whether anyone has deployed anything on those port numbers, but I have no way of getting a 100% accurate answer to that. Roman: Talking through the process concern, we had previously had a community consensus action to do this allocation and now we're saying with IESG fiat, we can reverse that community consensus to have these allocations. Orie: Don't do that. Roman: Personally, I think a document would be better. Murray: I'll give you one last anecdote. When I came in, there was a suggestion I inherited from Alexey to deallocate a port. I asked the community if people wanted us to do it and I was roundly slapped and told I was nuts. So I would definitely do the document if I were you. Zahed: Okay, that's a solid direction. Does anyone from IANA want to add anything? Sabrina: Ordinarily to release or change registrations made by an RFC, we'd ideally want another RFC to do that. In this case, I believe the RFC 6262 didn't tell us to actually register the UDP port. I think that's why we suggested we could just ask an AD to sign off on it and we could list it as reserved. That's our current practice, if we only assigned a TCP port we'd mark the UDP as reserved. I believe the other two registrations were changed to Historic back in 2012 but at the time we didn't make any changes to those. I'm not sure exactly what happened then. If it would help to consult with the port experts we can also do that. Zahed: I wanted to know how the port was allocated. But to be sure, I'll ask if anyone has deployed it and if there's community consensus to deregister this. I'd like to have consensus and then we can escape all the other questions. I'll say let's go ahead and work on the draft to publish an RFC for it. That's my takeaway. 6.11 Next steps on DIEM and DEEPSPACE (Éric Vyncke) Éric V: I'd love to talk about these two BOFs which may go forward. DIEM currently has a narrow charter, but it's typically not in INT. I can help the creation of the WG with my previous contacts and context, but right now the chartering process needs to be done by the final AD, not me. I think it should be either SEC or ART; sorry to pass the hot potato. If we could have a volunteer AD today, or a process to select one, that would be cool. Paul: I have some issues with whether this can actually move forward or not. From what I can tell, there have been two BOFs, both with a complete split in the room of what should be covered in a charter. I'm a little surprised it's now marching on with an apparently revised charter that must clearly not include half of the room, and continue to start a WG. Éric V: I understand the confusion. There was a small use case, the ICRC thing, and a much broader one. The charter right now is basically just the ICRC one. Paul: But even that case was not really clear. Sure, there was a discussion about medical vs journalism, but even the ICRC thing itself had complete un-clarity and a split of 50/50 whether this should be physical assets or data assets, and is a router data or physical, and is a database data or physical, and is a hard disk data or physical. There seemed to be complete non-agreement on everything. Éric V: Have you read the discussion on the mailing list? Not everyone is fully aligned on the charter, but I think it's converging. Paul: Wouldn't the process normally be to have a third BOF? Éric V: No no, we cannot. Suresh checked and we can only have two. No way. Paul: That's a little weird to me. The second BOF gave no way out of the fundamental problem, so how can you have a WG? Éric V: Because we restrict the problem. If there's an objection to DIEM continuing, let's stop the chartering process. Roman: The way ahead would be one of potentially two things. You had your two BOFs and now you need to work out consensus for a charter text on the mailing list, or you could make a radical departure to say we learned a lot from the BOF, we've now rescoped it to something else, and we want to start a whole new process around it. Orie: To Paul's point, after the BOF, the discussion on the list did seem to address the BOF questions on the digital or analog topic for assets. They included new text in the charter to account for that. The narrowing piece of this is to the inspection case where the asset isn' aware that its emblem is being inspected. They've narrowed descriptively around the approach, but they haven't narrowed specifically to eliminate one of these use cases like press or humanitarian relief. They haven't narrowed to distinguish between digital or analog/physical assets. To the question of area, to me this seems similar to WIMSE in the beginning. If WIMSE was going to be doing fundamentally new security work, it should have maybe been in the security area. If it's just using off the shelf building blocks that have been built in other parts of th eIETF and assembling them into an application protocol without making major security changes to them, it does seem more properly ART than SEC. I have the same concerns as you, Paul, in terms of continuing with the numbers we had at the end of the BOF. My only other comment is that this is another WG looking at this pseudo-three party model scenario without picking a specific technology. One way to handle the fact they've been through 2 bofs is good news, you're not inventing any new security work, there are WGs that maintain the security building blocks you're intending to use and you could take this as a use case to one of those groups. I don't know which of those paths is recommended for this charter, but as the ART person speaking, I'm happy to entertain the idea of this being in the ART area if that's where folks think it belongs. Éric V: So Orie, can we say that you have the ball right now, with my support? Orie: I'll take it, but I'd also like to understand how the rest of the IESG thinks we should handle this; there have been 2 BOFs, the charter is in this state, and there's silence on the list. I can kick the list but in what direction should I be prodding them to think about proceeding? Francesca: You kick the list, you get them to react to a charter, and then you bring it to the IESG. then discuss it more from there. If the proponents and the people who are involved are happy with the text, then it's internal review, IETF wide review, and IESG again. Paul: Would it be possible that a WG would pick up both tracks and see if they could make something work? Looking at both digital and analog assets, and maybe one of those two legs will fail, but then you've got everybody in the room and some kind of consensus for working on both of those things. Orie: Do you mean a new WG, or an existing WG? Paul: One new DIEM WG that would work on both. Orie: I think the way the charter is framed right now is to support that. Both digital and analog assets are in scope, and the only constraint on the use case is that the asset can't be aware of its emblem being inspected. An interactive authentication model wouldn't work. Paul: So in a way it's pretty similar to DULT; we basically have a tracker that's broadcasting things. Roman: I think one of the critical differences between this and DULT is that before we chartered, we defined the architecture. When we chartered DULT, we had most of the ecosystem of implementers on board. Éric V: That's a big difference. So Orie, you are up for probing the list? Orie: I'll take the draft charter from here and come back to the list. If it seems like there's agreement within the list and proponents that it's ready for wider review, we can proceed. I agree with your comment, Roman, on implementers and ecosystem being in the room for this. At this point, if they're not on the list and they're not part of the wider review piece, I'm not sure how we would address that point. Éric V: Okay. Let's go to the last one, where the implementers point can also apply here; DEEPSPACE. This one could stay in INT, even if just for parity with DTN. The name needs to be changed. I would suggest that I try to find, with the help of the list, a nice acronym that's less ambiguous as DEEPSPACE and start the chartering process as AD. Paul: Before we get to that part, it was unclear to me being in the BOF whether there was agreement on this end to end principle. It seemed that all the manufacturers/deployers of satellite things dint really see a use for end to end. It seems like some people in the IETF are like, end to end is cool, let's do this in space. I didn't feel the BOF actually addressed that question, that this is something someone wants. I think that would need to be answered before we start chartering a WG. Éric V: So you want something about end to end in the charter so we know the scope? Paul: I think there was some question about the architecture, whether it would be completely end to end or whether there would be some use of the existing bundle protocol that would then get attached to an IP layer protocol. Éric V: I was hoping this one would be easy. I see time is flying; the appeal is more important than this right now. I'll bring this back to the next formal, if everyone agrees. And think about an acronym for the WG, meanwhile. Thank you. 6.12 Designated experts for RFC 9669 (Erik Kline) Liz: Erik has identified David Vernet and Alexeiy Starovoitov as designated experts for this registry. Any objection to approving them? I'm not hearing any objection, so they are approved and we'll send the official note to IANA. 6.13 Executive Session: Changes to the IANA CBOR Tags Registry (Orie Steele) Discussed in executive session with IESG, Secretariat, and Sabrina Tanamal (IANA Liaison). 6.14 Executive Session: Appeal Discussion (Roman Danyliw) Discussed in executive session with IESG and Secretariat. 7. Any Other Business (WG News, New Proposals, etc.)