INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2025-10-23 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Morgan Condie, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Mike Bishop (Akamai) / Web and Internet Transport Area Matthew Bocci (Nokia) / IAB Liaison Mohamed Boucadair (Orange) / Operations and Management Area Morgan Condie (AMS) / IETF Secretariat Deb Cooley (Independent) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Gorry Fairhurst (Univ. of Aberdeen) / 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 Jean Mahoney (AMS) / RFC Editor Liaison Cindy Morgan (AMS) / IETF Secretariat Andy Newton (ICANN) / Applications and Real-Time Area Tommy Pauly (Apple) / IAB Chair 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 Orie Steele (mesur.io) / Applications and Real-Time Area Ketan Talaulikar (Cisco) / Routing Area GUEST --------------------------------- Eliot Lear / Independent Submissions Editor (ISE) OBSERVERS --------------------------------- Donald Eastlake Sandy Ginoza Karen O'Donoghue Nicola Rustignoli Greg Wood 1.2 Bash the agenda Roman: I just wanted to do a quick agenda bash, there is an executive session at the end, just as a reminder, and then we have our Independent Submissions Editor here, Eliot. I was going to move him in before we even start documents but after the action items to talk about an upcoming conflict review. Are there other bashes? Okay, not hearing any, let's get started. 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the approval of the minutes from the October 09 telechat? I’m hearing no objection, so those are approved. Does anyone have an objection to the approval of the narrative minutes from the October 09 telechat? I’m hearing no objection, so those are approved as well. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS Last updated: October 9, 2025 * DESIGNATED EXPERTS NEEDED o Paul Wouters to find designated experts for RFC 9770 (Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework) [IANA #1421561]. Paul: In Progress. * OPEN ACTION ITEMS o Roman Danyliw to take a look at Datatracker documentation of document states and update as needed. Roman: Is in progress. As discussed late last week, I wanted to make sure there was nothing contradictory and I’m still doing that review. o Mahesh Jethanandani and Ketan Talaulikar to work with Dhruv Dhody and Suresh Krishnan to look into potential retreat locations in Asia. Liz: I know this is on the list to discuss at the joint session at the meeting. Anything we need to know about it before then. Mahesh: No, let’s just discuss it then. o Roman Danyliw and Mahesh Jethanandani to draft update to "Guidance on Area Director Sponsoring of Documents" statement. Roman: In Progress. o Roman Danyliw to check with the Trust about whether the IESG Statement on Copyright is overtaken by RFC8721 Section 4.3. Roman: Talked with the trust and the guidance still applies and we need the statement. The action is no action and leave as is. We can mark as done. o Med Boucadair and Mahesh Jethanandani to review "IESG Statement on Proposed Status for IETF Documents Reserving Resources for Example Purposes" and propose what needs to be updated. Med: There was only one minor edit and sent to the secretariat for approval. Otherwise, I think it’s good to go. Liz, Cindy, you should have a pointer to that statement. Cindy: We can get that posted today. o Andy Newton and Roman Danyliw to work on re-chartering dispatch to cover multiple areas. Andy: In Progress. o Ketan Talaulikar, Mahesh Jethanandani, and Roman Danyliw to work on an announcement regarding Datatracker state change for WG adoption. Roman: Tightly linked to the first action, announcement is pending that purview. Éric: Sounds like the WG lunch wants to talk about this topic as well. Med: I confirmed they received an invitation from Robert but I won’t be available to attend. I forward the invitation to Éric and he seems available. I think that the presentation of the discussion will be just commenting that we will make an announcement. Deb: Are there two separate things? That’s a tool change, right? Robert’s talking about a tool change. Med: They’re actually linked but two actions. This one is about communication about that change. Éric: People want to talk about it is my understanding, they were not too happy. Deb: Because it wasn’t announced. Éric: Correct, and this announcement is basically announced afterward. If I understand the complete context. o Deb Cooley to work with Greg Wood on guidance for WG Chairs about how to use the Note Well. Deb: We finished this. If you want me to tell you where we landed, basically Jay said the IESG approved it. I don’t think it’s controversial and happy to add to the agenda if needed. Roman: We did look at it and approved it based on your recommendations. Cindy: I believe this was all closed at the end of the informal last week. Your action with Greg was a little outside of that. Deb: I’m happy to call it done and drop a link in the chat. Basically the do’s and don’t’s are the same and there is now text for what the working group chair might say during the meeting. I would close the action. 6.8 ISE discussion of SCION Eliot: Slide 1: ISE/SCION Eliot: This seems like a great time to talk about ISE procedures since I’m about to drop three large documents on you probably in the next few weeks. This is about SCION which is an alternative IP and control plane system that folks at ETH Zurich developed and it’s actually used in the Swiss banking system. Here we have something that is running code, that is a path based network approach, where the source picks the path. It’s a little different from an independent submission in that we normally see that it's very big. Most of the time I reject things that are very big, but this is interesting for a number of reasons. Slide 2: We Are Here - Independent - RPC - RFCs Eliot: We are here in the dependent stream, that's one of the alternative ways to get an RFC. It’s subject to a RFC 4846 and therefore you guys get 5742 as part of that to review. I want to take a moment to thank those that have been doing those 5742 reviews, Jim I remember and Gorry as well. Slide 3: Three drafts Draft-ietf-dekater-scion-dataplane : Date plane comms (It’s not v4 or v6) Draft-dekater-scion-controlplace : Control Plane (how to learn of what paths are available) Uses an additional level of hierarchy over BGP system Draft-dekater-scion-pki : Securing of the control plane Eliot: These documents interact with each other and are somewhat involved reading because obviously the data plane needs the and the control plane in order to know where to send the packet. The data plane draft is implemented on top of a VPN or something like that and underneath you will find IP hiding somewhere but this is the mechanism that they have deployed. Why would the independent submissions that are considered these 3 drafts you might ask? Slide 4: Where does SCION fit within RFC 4846 Informational discussions of technologies, options, or experience with protocols April 1st RFCs and other humor Informational publication of vendor-specific protocols Discussion of Internet-related technologies that are not part of the IETF agenda Introduction of important new ideas as a bridge publication venue between academia and IETF engineering Critiques and discussions of alternatives to IETF Standards-Track protocols and processes Documents considered by IETF Working Groups but not standardized Meeting notes and reports Tributes Eliot: Reasons we have to publish anything, this one hits about 3 of the different areas. First is Informational publication of vendor-specific protocols. There is a company that is pushing this now that spun off of ETH Zurich. The second is Discussion of Internet-related technologies that are not part of the IETF agenda. These aren’t but could in the future be. Brian Trammell and I have been collaborating and Éric has been part of the conversation at different times in that we are hoping that the SCION work will be an input into PANRG and actually some of the SCION authors. They don’t want the independent submission to be the end of the story. They would like it to be the beginning of consideration for a path-aware networking that the IETF could actually take up. Does that mean that the IETF has to? Of course not. Does it mean the IETF would take their stuff up untouched? Of course not. This is just an input into IRTF work which is then an input into IETF work. Then introduction of important new ideas as a bridge publication venue between academia and IETF engineering. This is the first really good example in a while that is pathware networking. There have been other technologies from long long ago that did source based routing from end to end. This is a new model. It provides a complete security model or mostly complete security model. Does that mean that it’s perfect? Absolutely not. I’m sure people will find flaws but I think this is a really good discussion input which is why I think we are going to see documents come out. Now as a reminder, 4846 says that I should take not only IESG’s input but also input from competent reviewers and I base my decision on the preponderance based on those reviews. Slide 5: The IESG’s Formal Role: RFC 5742 Reviews: Advise the ISE Common Choices - No conflict between this document and IETF work; or Work is related to IETF work done in WG , but this relationship does not prevent publishing; or Publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time; or Document violates IETF procedures for and should therefore not be published without IETF review and IESG approval; or Document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Eliot: I believe in an iterative process, and this has happened before with the IESG where there was a document that involved a new name service and Warren and I worked really well together to iterate through that process to figure out the best way forward to produce that draft. Slide 6: How the ISE processes results of a RFC 5742 review If there is a conflict there are 5 choices for ISE: 1. Consider advice and publish 2. Consider advice and ask authors to make some changes 3. Negotiate an IESG note 4. Delay publication for a time 5. Consider advice and decide not to publish, I wouldn’t ever expect to get to this point. I really work hard to avoid this. Eliot: With SCION there are big differences between it and other versions like new IP. The biggest difference is A. There is a full specification, B. There is deployment and C. Maybe there is something we can learn from the deployment experience. It’s not meant to be standardized in the IETF, it’s meant as more input into PANRG. These documents will probably be coming through in the next few weeks. I’ll probably wait until after the IETF since Brian Trammell is going to do another round of reviews for the authors and we will get you something that is as close to review ready as possible. Questions? Gorry: The obvious place where this overlaps with PANRG, is it correct that it’s not our job to figure out this overlap it is yours? Eliot: Correct. In fact, Brian is a co-chair of PANRG. Eliot: I usually ask that review try to be complete in about 30 days after submission but obviously with these wildly large documents, that’s going to need to be a little longer and that’s going to be somewhere around the beginning of next year assuming that they get to you in a reasonable period of time. Maybe even a little later would be okay. Roman: Hopefully this was helpful for the conflict review we will be doing. The first thing we will need to do is assign an AD but let’s worry about that when the documents come in. Erik: Will we assign 1 AD or 3 AD’s? Roman: That’s a great question. Do you feel like we need to decide that now? Erik: I guess we can decide that when the documents get to us. Will we assign a page count to that? Roman: We can actually do that too. I don’t know the size of these documents but yes, it would make sense if they are as large as they say they are. Deb: I looked them up and they are about 65-75 pages each. I can see splitting it. I could see PKI going one way and path routing and data plane/control plane stuff going another way. Roman: Step 1 is assigning an AD, once we see the size and shape we talk through how we want to stage their processing? Objections? Okay, let’s do it. Eliot: There will be other series like this, CNSA will be coming along next year so you should expect a group of documents at some point in February. Deb: Are you going to put them all through together? Eliot: I wouldn’t have to but they are all being processed together by the authors so I’m not going to hold them for any particular reason. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-suit-report-16 - IETF stream Secure Reporting of SUIT Update Status (Proposed Standard) Token: Deb Cooley Liz: We have a couple of discusses. Do we want to discuss this now? Deb: I don’t, I think the discusses are pretty clear and I don’t believe the authors are on the call. Jim: And Ketan is not here either Deb. Deb: It will be fine, they will noodle this through. Liz: This will stay in IESG Evaluation would you like in AD Followup or Revised I-D? Deb: Revised I-D Needed. Liz: This is IESG Evaluation::Revised I-D Needed. There are two downrefs in this document, 9019 and 9334. Deb: I’m not saying yes, but thank you for the notice. o draft-ietf-core-oscore-groupcomm-27 - IETF stream Group Object Security for Constrained RESTful Environments (Group OSCORE) (Proposed Standard) Token: Mike Bishop Liz: There are no Discusses, so unless there is an objection now, this is approved. I'm hearing no objections, so this is approved. Mike: Thank you! Please put in Revised I-D needed since it has a companion doc that has a few discusses. Liz: Approved - announcement to be sent::Revised I-D Needed. o draft-ietf-bess-mvpn-evpn-sr-p2mp-15 - IETF stream Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication (Proposed Standard) Token: Gunter Van de Velde Liz: We have a few discusses. Do we want to discuss this now? Gunter: There is a new version ready but waiting to get uploaded. I believe the discusses are pretty clear and will be addressed in the next few days. Éric: About the field in my discuss, there is a field called MPLS label which does not contain any MPLS label but contains an SRv6 and I was suggesting updating the previous RFC to change the field name. Basically the authors said no, which is okay, but I think a field called MPLS label doesn’t contain MPLS label, which is quite misleading for the future generation. Asking for your point of view. Gunter: Honestly, I haven’t looked into it yet. I need to further look into it before giving an answer. Erik: I have a discussion going back and forth on the mailing list about what kind of prefix to use for non routable stuff. I believe there were some responses. Gunter: I realize this draft is complex. Thank you for digging through it. Liz: This is staying in IESG Evaluation, would you like it AD Followup or Revised ID needed? Gunter: Revised ID Needed. They already have a new version ready and are waiting for it to be submitted and pick up the remaining comment from Éric. Liz: This is IESG Evaluation::Revised I-D Needed. o draft-ietf-idr-link-bandwidth-19 - IETF stream BGP Link Bandwidth Extended Community (Proposed Standard) Token: Ketan Talaulikar Liz: We have a few discusses. Do we want to discuss this now even though Ketan isn’t on the call today? Okay, I guess not, will leave in IESG Evaluation::AD Followup so Ketan can do what he likes with it when back. o draft-ietf-ntp-over-ptp-06 - IETF stream NTP Over PTP (Proposed Standard) Token: Erik Kline Liz: We have a discuss. Do we want to discuss? Erik: Thank you for the reviews. There is a thread about what to say for DEs. Not too hard to write some text. Roman: I don’t have an opinion on what it should be, but that something should be something. Erik: It’s a little interesting how the IEEE OUI based registry works, it’s a whole new registry just to show this is an NTP message. I can’t imagine anyone will ever extend it, but yes, we should say something. We will get some amended text in there. Roman: Karen, I saw you joined, do you have commentary? Karen: I agree with what Erik is saying, I think we need to finesse the text a little bit. It is an odd relationship. Liz: This one is staying in IESG Evaluation. Would you like in Revised I-D needed or AD Followup? Erik: Revised ID Needed. Liz: This is IESG Evaluation::Revised I-D Needed. o draft-ietf-cose-hash-envelope-09 - IETF stream COSE Hash Envelope (Proposed Standard) Token: Paul Wouters Liz: There are no Discusses, so unless there is an objection now, this is approved. Paul: Please put in AD Followup. Liz: Approved - announcement to be sent::AD Followup. Just let us know when this is ready Paul. o draft-ietf-tls-tls13-pkcs1-06 - IETF stream Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 (Proposed Standard) Token: Paul Wouters Liz: We have a discuss. Do we want to discuss this now? Paul: Honestly, I don’t know why this discuss is still on the document. The entire introduction explains why there are operational considerations that require this document to reintroduce something that the working group hoped to have killed off in the past. I think it’s very obvious and I don’t understand why Med is holding this discuss. At least the TLS chair is pretty unhappy and the authors of this document are really new to the IETF so they suggested maybe agreeing with the change for recommended deprecated which I think is definitely the wrong step, so told them not to make that change. Med, what can we do to resolve this? Med: I spent some time going through this document and I would say this specification actually does not mean deprecated, it means discouraged. The major one is updating the base TLS specification. There are various excerpts in RFC 8446, for example if you go to page 39, page 40 or page 66 it’s my interpretation that it’s affirmative that this cannot be used for the TLS handshakes. With this specification we are relaxing this constraint which is clearly updating that specification for me. I would also say the clarification between the not recommended and discouraged clarification. Paul: Too many issues at once for me. Changing or allowing a new algorithm isn’t changing the core specifications. I don’t think that’s an update. It’s really an extension. You’re adding another algorithm that’s allowed. I don't think that's an update to the core TLS1.3 specification. I disagree with your evaluation that this should be an update on the TLS1.3 RFC. Med: If you see the part introducing the algorithms, for example this value is referred to the signature and is not defined for use in handshake messages. You can find the same statement also under the legacy algorithms in which the same are not defined in science handshake messages and so on. If you tell me that’s my interpretation and it’s not correct, that’s fine. The purpose is just to make sure that we are not breaking something that is already there in the specification. Also under the legacy algorithm, it indicated algorithms which are being deprecated. So if we say this isn’t recommended, I had a concern with that one in RFC 8446 and also bis, that algorithm was evaluated and the text is clear that this is something which is deprecated and is not encouraged. So for example if we put in the registry, this is not recommended and people just say that yeah this is not something because there is no evaluation from the IETF that is a little contradicting with what is recommended or at least recorded in the base TLS specification itself. If they can crosscheck, I just want to make sure we have the same understanding of the text. If you check it and you think it’s right, I can remove my discuss. Mike: I addressed both of these in my ballot comments. Med, the definition for N has 3 possible reasons for using it. One of them is that it hasn’t been through a consensus process, the other two apply to this document. I think N is probably the right choice here. I believe you are right that it does modify 8446. Paul, normally I would agree with you that this would be just an extension using a regular extension point. But 8446 says that you’re allowed to list things with this algorithm for backward compatibility, but they must not be used if you’re in TLS 1.3. This is changing that restriction from must not be used to you can use them in this particular situation. Paul: Is the text still in the bis document? Mike: I believe it is. If the solution is to ask the RFC editor to take it out before they publish it, that’s fine too. Deb: Is it specifically for certificate signature, not regular signature right? Mike: That I would have to confirm. Deb: So this is only the certificate signature extension? Mike: Right. Currently it says that in processing the certificate verify message, you must not consider these algorithms, even if they’re present. This document says that the server can process them but the client can’t. Deb: My only point was to say that this is specifically for client verifications for certificate signature only, not for regular certificate algorithm extensions, not for server certificate extensions, not any of that. There’s not even one for servers, but just for the client certificate. I will go so far as to say that I expected this requirement originally in 8446 was ignored routinely because you can’t get certificates without it. Mike: How do we move forward from here? Do we want to take a look at what 8446 says and then decide if it’s an update? Paul: Yes, I’ll look at that. Mike: Med are you satisfied or willing to be overruled? Med: I don’t remember if in the registry we have some kind of notes where we can point specifically to the applicable application scope, is that something we have currently in the registry or the notes column. The other point is that we are losing the encouragement to transition to the new ones. That’s actually why I had that I would say balance between N and discouraged. We are providing this because we have a trade off and we know we want you to use TLS 1.3, we know that there are downsides of it but we also like to convey that you have something more robust which is currently in the base itself. So if we have a comment of a specific column in that review which we can specifically include some kind of these comments, I would be okay. Deb: There is a very natural cut off for this, and that’s the advent of the quantum based computer. Once the quantum based computer is around, this algorithm will be deprecated along with the rest of RSA and the elliptic curve algorithm. This will go away by itself by the natural course of events. Paul: I can see about adding a note. I’ll double check to see what the history has been for using the note column in that registry. Liz: This is staying in IESG Evaluation, would you like me to put to Revised I-D Needed? Paul: Yes, you can put to Revised I-D needed. Liz: This is IESG Evaluation::Revised I-D Needed. 2.1.2 Returning items o draft-ietf-asap-sip-auto-peer-35 - IETF stream Automatic Peering for SIP Trunks (Proposed Standard) Token: Andy Newton Liz: We have a few discusses. Do we want to discuss this now? Andy: I believe that Mike’s comments can all be addressed. Med, I believe the authors have attempted to address your concerns. Med: I think they are making excellent progress. There’s only one pending comment about avoiding creating a new source of information for the SIP option tags. I provided them with an example of how to solve that and waited for them to see if they could do that. If they implement it, I think that we are done with my discuss. Andy: I don’t quite understand the read-only. Mahesh: It’s the fact that the entire model is read-only, which means that all those parameters they described in the YANG module have to be populated by the system itself, system being in this case SIP device. I was trying to understand how this gets populated. Meaning if you don’t allow anything to be written and an instance created, how does the model get populated? Andy: Okay, so it’s not that the data model can not be read-only, it’s just that we need to understand how that information gets there. Correct? Mahesh: Correct. What I understand is that the enterprise reached out to the service provider to build the config, but then how does the enterprise then populate it on the SIP devices? Andy: I don’t have an answer for that. What I do believe is that this got changed to read-only after the last IESG evaluation on this document. We need to figure out the answer to your question which is basically how that data gets there if it’s read only. Med: One more comment, I think for the interface between the network and the service provider having it as read-only is the right choice because you are just exposing the capabilities and you are not giving the right to the other to modify the capabilities. From that standpoint, I think they are right in the way they are designed but the way this will be managed is something which can be internal , but they don’t have that experience document and I think that this can be straightforward in the explanation. For the interface itself, they are having it right at least from my point of view. Mahesh: Thank you for that explanation. That explains if this is a model that is meant for the service provider to have the instance data. They just need to make it clear, is this for a device? Is this for the enterprise or is this for the service provider? Who is the model for? And it’s for the service provider, it’s read only. I’ll clear my discuss. Andy: I think that would be good for them to clarify. You said you’re holding this for an IANA issue? Which one is that the downref? Mahesh: IANA has put a hold on it. I’ll check if that is still the case. Med: I think that they have cleared it, but please check on your side as well Mahesh. Mahesh: I think there was a point in the document that they didn’t have any consideration for the module. Andy: I believe they addressed that when Med pointed it out. The downref to the IANA crypt-yang model, I think we are going to need some guidance on whether we should be doing that or not. I can’t see any implementations of this, so if we need to point them to something that is better, I think we can do that. I just don’t have enough context and don’t know whether that downref is appropriate or not. I think we can put to Revised I-D needed. Liz: This is staying in IESG Evaluation::Revised I-D Needed. 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 o draft-ietf-opsawg-pcaplinktype-13 - IETF stream Link-Layer Types for PCAP-related Capture File Formats (Informational) Token: Mahesh Jethanandani Liz: We have a few discusses. Do we want to discuss this now? Mahesh: Ketan is not here and I know most of the discusses are around the registry information. The authors have updated the registry information to now make it first come first served without expert review, which I think was one of the points of contention. I don’t know if that is the only thing holding this up at this point. Roman, I don't know if you got a chance to see the responses from the authors on your point. Roman: I have not had a chance to look, but I’m checking in real time. Maheash: I believe this one should stay in IESG Evaluation, Revised ID Needed. Roman: Before we go, I observe that we’re now in a first-come first-served situation, yet we still have a bunch of guidance for registration. What is in a first-come first-served situation? I thought it was literally first-come first-served, but there’s all sorts of text now that looks like that takes some kind of judgment about whether to accept things. Is that usual? Mahesh: No, you’re right. If I read 8126, I think it’s pretty much the source information on what is the reference and pretty much accepted. No, generally you don’t have too much guidance in that case. Roman: IANA can you jump in in real time here on this text? Sabrina: I think I’d have to agree with that as well. Outside of checking that it’s a valid request and making sure that they provided all the information for the required fields, that’s pretty much the extent of what we would check. Also something we're trying to include in the registry is also a change controller field for all first-come first-served and expert review registries. This is just to make it more clear in terms of who is authorized to make changes in the future. Roman: So we probably need another column then for change control? Sabrina: If it’s not included in the document, we would do it. If it’s not something included in the document, it’s something that we’re doing across all registries, all first come first serve and expert review. Roman: The judgment piece that worries me is the test says when the content of a link type can contain a v4v6 header, then the context because the beginning of the link type and the need to clearly specified, that seems like a judgement call that someone has to go find the specification and make an assessment of whether that’s clear of not. That seems well beyond what first come first serve would be. Sabrina: Yes, we won’t be able to do that. Mahesh: One clarification question for myself is the change controller, is that for each entry in the registry? Sabrina: Yes Mahesh: Does each of those entries have to have a change controller? Sabriana: Yes, and if it’s an IETF document, then we would just list it as IETF. We would like to have an entry for each of them. Mahesh: The reason I ask is because this document has had a lot of history on it. It has made a very last minute attempt to try to document what has been in existence, I don’t know for years. There would be a bit of a struggle to try to identify all the sources of why some of those reservations were made. I think I have the answers to my questions. Liz: This is IESG Evaluation::Revised I-D Needed. o draft-ietf-bier-oam-requirements-19 - IETF stream Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer (Informational) Token: Gunter Van de Velde Liz: We have a few discusses. Do we want to discuss this now? Gunter: I think the discusses are quite clear, some of them relate to the BCP 14 language. Then there is also a comment about normative language and Med had a whole bunch of comments on some of the more state of the art announcement. Greg tends to be quite responsive in this area and usually quick to respond. Revised ID Needed for sure. Liz: This is IESG Evaluation::Revised I-D Needed. 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 Web Bot Auth (webbotauth) Liz: I see no blocking comments so if there are no objections now, this is approved. Mike: There was one comment Paul had made and Mahesh seconded about the charter specifying the directionality of fetching additional information and what we had done and discussed offline is making a one word change allowing the working group to decide which way that goes instead of requiring the deliverable. After I make that one word change, then I think we’re good to go. Liz: This charter is approved and we will wait for Mike to tell us it's ready to be announced. o Open Cloud Mesh (ocm) Liz: I see no blocking comments so if there are no objections now, this is approved. Andy: I do need to modify this based on the nit Erik Kline made. Éric Vynke made a comment about the milestone. I thought we had discussed at the last telechat but maybe it wasn't clear. Your objection is we only have one milestone in there? Éric: Basically the vagueness of one familiar specification which is not clear. It’s not about this milestone at all. Andy: The intent is, if they get into the input there’s an input document, right? Here’s what people are currently doing but the IETF needs to look at that and it’s not going to rubber stamp it right? The IETF could change it completely. This is language to say, if they get into it and they need to create more than one doc, that’s what’s going to happen but it’s all one deliverable. Éric: Seems vague to me but that’s all. Andy: I believe it’s purposefully a little vague. Please hold until I make one change. Liz: This is approved and we will wait for Andy to let us know it’s ready to go to send the announcement. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o IPv6 Operations (v6ops) Liz: I see no blocking comments so if there are no objections now, this is approved. Med: I’ve implemented the nits from Erik Kline, Éric Vynke, and Gunter. From Mike, I would say the introduction centers it because for me, unless you have a specific modification that you want to see, I just prefer to keep the current wording. Mike: I’m thinking of it more as a long term direction than a "go fix your text," and it might even belong in a different working group. Liz: This is approved, Med is this ready to be announced? Med: It’s ready to go. Liz: This one is approved and ready to announce. We will get those announcements sent out today. 5. IAB news we can use Deb: A few great discussions on Open Fiber Data Standard by Stephen Song (ISOC). There’s discussion about where this lands from a standards point of view and it’s somewhere between IETF, Open GIS, and ITU-T. The other one was about Human Rights in Standards by Simone Onofri. He’s talking about what the W3C is doing. There was discussion on the IAB Open meeting. Dirk mentioned that SPACERG is having their first meeting this go around and some other interesting side meetings, ARMOR and PAIN. They are both research group related. Tommy: IP Geolocation workshop coming up in December. We received a good amount of contributions to that. We’ll be letting people know soon and the official list of papers and invitees. Matthew: The age verification workshop jointly with W3C and had a pretty good turnout. Deb: It sounds like they plan to have a summary of that at the IAB Open. Tommy: There’ll be a presentation of that and I think the official workshop report draft should be by the end of the calendar year. 6. Management issues 6.1 [IANA #1433997] renewing early allocation for draft-ietf-pce-sr-bidir-path Liz: Any objections for approving this early allocation approval? Liz: I’m hearing no objection, so this is approved and we will send the official approval to IANA. 6.2 Note Well Liz: This is to formally minute the decision that the IESG approved the new Note Well text. 6.3 DCONN session request (Orie/Liz) Liz: We do have an open slot, but Orie has an AD conflict. Orie wants consensus that this is okay and not precedent setting and if someone can cover it for him? Gunter: I saw the LSVR session was cancelled so maybe that slot could work? Roman: I have no objections to adding to the agenda. Andy: I thought Orie said this was a miscommunication and that DCONN didn’t want to meet. Éric: It was a reply to my message asking if they were planning to meet. Liz: The message I got was that they weren’t going to meet so we didn’t save a space for them. Mike: We should accommodate just like any other late request. If we have space, great, and if not. Liz: We'll look at the new LSVR open slot and the Friday slot. If Orie needs AD coverage you may be hearing from one of us. 6.4 [IANA #1433996] renewing early allocations for draft-ietf-ippm-ioam-data-integrity - (Mohamed Boucadair) Med: It makes sense to extend. Liz: Any objections to approving? Liz: This is approved and we will get the official note sent to IANA. 6.5 DRIP Videos (Éric Vyncke) Éric: I’m hoping to have the last 15 minutes from the video/transcript of the DRIP interim meeting on October 15th after the top of the hour was removed. This is where I’m talking in french with the WG chairs for 15mins about random topics after the meeting ends. Roman: I have no issue with this since the meeting had ended. Any objections? Éric: Meetecho wanted IESG approval. I will follow up with them. 6.6 YANG versioning and Semver, and its possible impact (Mahesh Jethanandani) Mahesh: This is meant to be more of a heads up, since there are trial documents making their way through pretty soon. One of them is in the working group's last call, the others will be there soon. Slide 1: YANG Versioning and Semver - How these changes impact the folks in the IETF Slide 2: Trio of documents draft-ietf-netmod-yang-module-versioning draft-ietf-netmod-yang-module-semver Draft-ietf-netmod-yang-module-filename Mahesh: All three of these documents in some form are affecting the way the YANG modules are going to be versioned going forward. Slide 3: Current versioning scheme Strictly Backwards Compatible (BC) Follows a YYYY-MM-DD format E.g., ietf-blah@2018-10-12.yang Slide 4: draft-ietf-netmod-yang-module-versioning revision 2020-08-09 { rev:non-backwards-compatible; } revision 2020-06-07 { } revision 2020-02-10 { rev:non-backwards-compatible; } Slide 5: draft-ietf-netmod-yang-module-semver revision 2017-08-30 { description "Backport 'wibble' leaf"; ysv:version 1.2.2_non_compatible; } revision 2017-07-30 { description "Rename 'baz' to 'bar'"; ysv:version 1.2.1_non_compatible; rev:non-backwards-compatible; } Slide 6: draft-ietf-netmod-yang-module-filename acme-router-module@2024-05-15.yang OR acme‑router‑module#2.0.3.yang. Slide 7: Impact on current process Toolset needs to be updated Datatracker will check for these new versioning statements pyang Yanglint IANA IANA modules IETF modules Slide 8: Community education Working with Greg Wood WG Chairs Lunch Blog post SYN-ACK newsletter Others?? Mahesh: Any questions? Andy: How does Errata deal with this? Does it change the patch number? There are major, minor, and patch. The last number digit is patch. If someone files an Errata, does that mean that the YANG model has to be updated with a patch number? Mahesh: If its editorial it would be a patch and it would be marked as backwards compatible, especially if editorial. If it’s technical and it’s changing the model, then I have to ask the authors to give us an example of what it would do. Andy: Can they register a YANG model prior to an RFC? Anything with a major of 0 won’t be allowed then? Mahesh: Correct. 1.0.0 is the minimum version. Andy: In the REGEX working group there is some work about semantic versioning which isn’t nearly as clear as what you’re describing. I appreciate YANG taking on the challenge. 6.7 Executive Session: Appeals The topic was discussed in an executive session with IESG, IAB Chair, and Secretariat present. Paul Wouters recused himself from the discussion and left the call. 7. Any Other Business (WG News, New Proposals, etc.) Gunter: Would like to combine lunch for RTGDIR and OPSDIR since they are both on November 4th and there is a lot of overlap. Jim: I’m okay with combining. Mahesh: Let’s just be creative with the agenda. Liz: How many people? Gunter: 41 people. I can send an email to Paige. Liz: I can update her as well.