Narrative Minutes interim-2022-iesg-23 2022-10-20 14:00
narrative-minutes-interim-2022-iesg-23-202210201400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2022-10-20 14:00 | |
Title | Narrative Minutes interim-2022-iesg-23 2022-10-20 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2022-iesg-23-202210201400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-10-20 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Roman Danyliw (CERT/SEI) / Security Area Martin Duke (Google) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Alvaro Retana (Futurewei Technologies) / Routing Area Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area Paul Wouters (Aiven) / Security Area Qin Wu (Huawei) / IAB Liaison REGRETS --------------------------------- Jenny Bui (AMS) / IETF Secretariat Jay Daley / IETF Executive Director Francesca Palombini (Ericsson) / Applications and Real-Time Area OBSERVERS --------------------------------- Daniel Migault Lee-Berkeley Shaw Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Any other changes? Éric V: Can we do my drafts at the beginning? I may need to leave for the last hour. Thank you. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from the October 6 telechat being approved? I'm hearing no objection. We also have final narrative minutes from October 6; any objection to approving those? I'm hearing no objection. We also have the BOF coordination call minutes for IETF 115; any objection to approving those as well? Okay, I'm hearing no objection. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn) [IANA #1229681]. Roman: I'd like to close this item without action. I looked at the registry; in the 2.5 years we've had it open we have not added any additional entries beyond the import we get from W3C and we already have 2 well qualified DEs. I don't think we need to add a third. Amy: So for specifically this RFC, you want to keep the two people there? IANA did ask for names to add. Roman: Maybe I'm misunderstanding. The ask was that we used to have three, one of the individuals retired, and proposed another candidate to replace them. I looked at it and I think we have two solid ones, there is no volume on this registry, and there has never been anything beyond the initial registration. Amy: I see. Okay, we will communicate that back to IANA. Thank you. o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth) [IANA #1239251]. o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE) Profile of the (ACE) Framework) [IANA #1239258]. o Paul Wouters to find designated experts for RFC 9237 (An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE))[IANA #1239259]]. Paul: Still in progress on these. o Lars Eggert and Colin Perkins to find designated experts for RFC 8609 (Content-Centric Networking (CCNx) Messages in TLV Format) [IANA #1239154]. Lars: We talked about this but we mostly talked about whether ICN should become a standards group. The chairs are thinking it shouldn't be done. But we haven't really discussed the experts, so let me pick that back up. o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in October 2022. - On hold until next week 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-homenet-front-end-naming-delegation-18 - IETF stream Simple Provisioning of Public Names for Residential Networks (Proposed Standard) Token: Éric Vyncke Amy: I have a number of Discusses in the tracker; do we need to discuss those today? Éric V: First, as some of you may have noticed, Daniel is on the call as an observer. He's the main author on these two documents. He has a couple of revisions based on the reviews and thanks so much for the very very detailed reviews. I did my own AD review with a couple of comments. afaik by looking at the revised id, most discussion regarding the security aspect and the use of TLS has been at least addressed somehow. He has also removed the complicated section about dynamic DNS, because there was no point comparing the two. Hopefully the clarity has been improved. My major concern is your abstain, Lars. I understand your point. It's maybe a bit too late. It would not be the first time we do such protocol work. Lars: But we typically wouldn't do it as Proposed Standard. I'd be fine with it as Informational or something, but PS seems like we really think this is a solution, which I don't think it is. Specifically, removing a section doesn't really help me. I'm not against it but I'm also not for it. The section made it pretty clear that some of these assumptions have changed. There seems to be this baked in assumption that the gateway is somehow trusted and the gateway is the thing that's in the control. I don't trust my gateway, I probably trust my phone more, because it's in my hand and I can actively do something with it. Why should I trust this gateway? I think there are a lot of things here that have changed. Aside from that part, most of the Discusses spelled out how you can't really implement this because it's a smorgasbord of stuff. I really think the time for this solution has come and gone and everybody has moved on. Everyone here is using Dyn DNS. for historical record, sure we can publish this as informational no problem, but as Proposed Standard I don't see it. Probably for the other documents too, because they all tie in to the same architecture, gateway being the thing that is your proxy. Éric V: That's clear for the other Homenet documents. The Homenet WG has been kind of a failure, to be direct, on this one. I'm pretty sure Daniel will work and address all the other Discusses and comments, and then we will come back and check your abstain, Lars. You may have followers on this. Lars: I don't think you can address the Abstain other than not making it a Proposed Standard. And that's fine, abstain is not a block and it doesn't prevent it from being published. This is not a technical thing I can point to to change the protocol and make it clearer, it's this meta argument that times have changed and this solution isn't it anymore. Éric V: I agree. I meant to address the point of your Abstain and it will be the remaining issue once the others are fixed by Daniel. Then we will see if anyone else adopts your position and if we need to do anything about the publication status. Paul: To chime in a little bit, I honestly don't understand how some of this is supposed to work because all of the non-standard IETF protocol stuff is really not specified. I was mostly confused that it says DNS updates and having hidden primaries don't really work, the solution is deploying that anyway, but calling them differently. in the end it's still the same solution, hidden primary, primary, secondary. I'm a little confused by the thought of this not being deployable and then also being the solution. For Me, the DNS updates are secured using various RFC standards we have, and TLS is not one of them because TLS has only transport security, not data authenticity security. So I felt those were kind of mixed up and I don't understand how this solution works from start to finish. Not sure if we should do this on this all, maybe Daniel we can talk at 115 and you can explain it to me. Hopefully it's just the language that I don't understand. Warren: I'll chime in here as well. I will happily note I was unable to figure out how the whole system is supposed to actually work. I was having a sufficiently difficult time reading and parsing it that I couldn't get the bigger picture in my head of how the bits tie together and which bits do what. Most of my reviews were just that I don't understand how to read this and I don't have the bigger picture in my head. My comments were only up to page 13; I have a PDF with more scribbles in it and I don't know if that would be useful to send or not. I did not transfer all the notes. Éric V: I'm pretty sure Daniel would be happy to receive your PDF with your notes, if they're readable. And maybe if nobody objects, I would love to give the floor to Danielt o make a couple of statements about your plan; not for too long, please. Daniel Migault: Hi everyone. Some of the comments are saying it's not implementable. I have a hard time understanding that and I'm happy to clarify that. Then the debate on whether this is going to happen or not, if we don't publish it, it will for sure never happen, but I think we should have the discussion on the technical basis as opposed to speculation on what is possible. Paul, yes, I can clarify many of those things. Éric V: I think the best way to move forward, Daniel, is to try to address all the Discusses and comments in a revised ID and then we can talk in London. Will you be there? Daniel: No, I won't be there in person. I think I already addressed most of the comments I received so far. Maybe I didn't respond to Paul, I'll have to check. My intention is to respond today to all of the comments and I think I've done most of them. Lars: What's your view on moving this to informational? Daniel: My point is that if we want to deploy it at Ericsson, we will need to have it as standards track. Paul: Can we start as experimental? Isn't that how this is supposed to start? Daniel: No. Anytime we want to deploy something in a product, it has to be standard. That's the only reason I want it to be a standard. If Ericsson wasn't interested at all, I'd say fine. Éric V: I think we can close the discussion here. Obviously this will be Revised ID Needed. o draft-ietf-homenet-naming-architecture-dhc-options-21 - IETF stream DHCPv6 Options for Home Network Naming Authority (Proposed Standard) Token: Éric Vyncke Amy: I have a couple of Discusses in the tracker; do we need to discuss those today? Éric V: I don't think so, unless somebody wants to. It's connected to the first document so we can't really talk about this one if the first is not approved. Zahed, on your point about the non-default port, I had the same point during my AD review but the WG says it will be the default port. Lars: This is not for the WG to decide. If an operator decides to deploy this on a non-standard port, it can't work with this. Right? Zahed: There is no enforcement and no text in the document saying it has to be this way. Lars: Unless there is an agreement between the two parties. Zahed: This has to be resolved some way. You can say this is only designed to work on the standard port, but this might be different if somebody else wants to do it on some other port. Lars: There's no such thing as a standard port. There's a default assigned port but each deployment can pull ports out of a hat and if you want your thing to work you have to handle that. Éric V: That was my point in the AD review as well. Maybe they will change it. So Revised ID Needed and thank you for your review on this as well. Amy: This will go into Revised ID Needed, thank you. o draft-ietf-ipsecme-mib-iptfs-09 - IETF stream Definitions of Managed Objects for IP Traffic Flow Security (Proposed Standard) Token: Roman Danyliw Amy: I have a couple of Discusses, do we need to discuss any of those today? Zahed: I can talk about my Discuss. I'm on the verge of clearing it but I had communicated with the authors about something similar to Lars's. I don't know about Lars but it looks good to me and I think with that in place I can remove my Discuss and Lars can decide if he wants to. Lars: They recognize it's a cap so they want to change that text, which seems fine. Zahed: The new text would be clearer about the cap and the condition control. Lars: If it's a congestion controlled mode, it's up to that particular limit, and if it's a non congestion controlled mode, it is that limit. Zahed: Yes. Roman: Having found the mute button, the thing is, the authors have this in hand and the discussion is happening. The key thing to remember is that there is the protocol document which actually says what knobs you have, the Yang and the MIB should not reinvent what the knobs are and what the protocol document says, and whatever's in the Yang text should be the same as the MIB text. That's where we're headed. Thank you for the find. Zahed: If you want me to clear the Discuss now, I can do it. Lars: I will wait until there is a new document so there is no change today anyway. Roman: This will be Revised ID Needed. o draft-ietf-pce-vn-association-09 - IETF stream Path Computation Element Communication Protocol (PCEP) extensions for establishing relationships between sets of Label Switched Paths and Virtual Networks (Proposed Standard) Token: John Scudder Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. John: Thank you everybody. AD Followup, please. Amy: Okay, this will be Approved, Announcement to be Sent, AD Follow Up and you can let us know when that's ready. o draft-ietf-opsawg-yang-vpn-service-pm-13 - IETF stream A YANG Model for Network and VPN Service Performance Monitoring (Proposed Standard) Token: Robert Wilton Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Rob: Thank you everyone for the reviews and comments. This is in good shape but a Revised ID is needed to pick up the comments. Amy: This will be Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-pce-lsp-extended-flags-07 - IETF stream Label Switched Path (LSP) Object Flag Extension for Stateful PCE (Proposed Standard) Token: John Scudder Amy: I have a Discuss in the tracker; do we need to discuss that today? John: Not as far as I'm concerned, it seems like it's moving along. Lars, do you want to talk about it? Lars: It's pretty straightforward. John: Okay. The substate would be Revised ID Needed. o draft-ietf-dnsop-dnssec-bcp-05 - IETF stream DNS Security Extensions (DNSSEC) (Best Current Practice) Token: Warren Kumari Amy: I have a Discuss in the tracker; do we need to discuss that today? Warren: I don't think so. Lars: I would like to, if you don't mind. I'm sorry for breaking the Discuss record on this call. I don't see why this is a BCP. Basically they say DNSSEC is a good idea, here's the document. This is not what a BCP is for. It's written as if it's on the standards track which it isn't. Warren: Much of the original intent was so that there is a single way to refer to the whole set of things, and it is also supposed to be so that a lot of people are not implementing DNSSEC. When you say why aren't you doing this, they say it's not a standard or a thing the IETF has said is best practice. Maybe it's not very well worded, but the intent was to make it so that we think DNSSEC is a BCP. Lars: I think the people who say that don't understand what a BCP is. First off, for these rollnet documents, we have that document and it says here are the gazillion other documents you need to read, and that was informational. If DNSSEC wanted to make it something more, it is a proposed standard now, let's make it a standard. But it can't be a BCP because protocols aren't BCPs. We could have a BCP document that says here are all of the reasons and operational stuff why DNSSEC should be used to secure the DNS system, that might be a BCP. But this is not that document, this is basically a roadmap. Paul: Does it say it's mandatory to implement? Warren: Mandatory for whom to implement? Roman: Yeah. We would need some clarity on who's accepting that MTI? Paul: Anything that is a DNS software library, resolver, server? Just to clarify that DNSSEC is not optional. Just like we clarified that TCP for DNS is not optional. Warren: I do understand what you're saying, but there was a fair bit of discussion in the WG about we want DNSSEC to be a best current practice and I think the thought was that this would be accomplishing that. That seemed to make sense to me, at least at the time. I guess we need to have more discussion with the authors and WG. Roman: Correct me if I'm wrong, I thought the intent of this was to strongly signal that DNSSEC is a really really good idea. I did not think we were signaling a followup statement to that as then it is MTI to implement it if you have a DNS stack and if you are operating DNS you must turn this on. Warren: There are some people who believe that is what we should say, but I don't think that's what this is. What this is really trying to say is that we believe it is a best current practice, it's what people should be doing, and I think we'd thought that by bundling the things together and saying this is what DNSSEC is, this set of things, and marking this document as a best current practice that says it's best current practice to use DNSSEC. Lars: I have nothing against having a BCP that says DNSSEC is a good idea and you should use it. But the text here talks about DNSSEC the protocol and it becoming a BCP, and that is not something we do. Maybe it just needs to be rephrased. It does it in several places, which is why I couldn't just overlook it. We don't have a document that says QUIC is a BCP, or DNS itself is a BCP. Warren: Do you think we could address your concern by wording it more as moving DNSSEC to best current practice status? Lars: I'd talk about using DNSSEC to secure the DNS, that is the best current practice. It needs to give community deliberations. The community thinks that using DNSSEC to secure DNS is the best current practice for DNS deployment. That would be a fine statement. But DNSSEC as the protocol bits, moving them to best current practice status, I think it's just badly written. Warren: Okay. So do you think that it's salvageable in this document to replace all of that? Once we make sure the WG does agree, change it to [what you said], or does it need a whole new document? Lars: I don't think it needs a whole new document. If they made that wording change consistently and look at it with that sort of perspective to see if any other rephrasing would be useful, I think that would be fine. Warren: Now that you word it that way, I understand and that all makes sense. Thank you. Revised ID Needed. Murray: I was just looking at 2026 while that discussion was going on and the definition of BCP seems to include the case we're talking about, at least the way it's written. I agree though that you kind of have to turn your head sideways to see how this fits. As this draft is written. But it seems like there's probably a path to make this fit so I think I agree this just needs to be revised. There was some language in here that made me think this is trying to change the status of DNSSEC without actually changing the status of DNSSEC and that's what felt improper about it. I didn't put a Discuss on it but I'm going to change my position to support Lars's while we figure this out. Warren: Okay. Amy: This will stay in IESG Evaluation, 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 NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-dots-telemetry-use-cases-14 - IETF stream Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry (Informational) Token: Paul Wouters Amy: I have no Discusses for this document, so unless there's an objection now I think this is approved. Paul: I haven't had time to read the comments yet and I'm not sure if it will need a revision. Let's put it in AD Followup. o draft-ietf-rmcat-rtp-cc-feedback-11 - IETF stream Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences (Informational) Token: Zaheduzzaman Sarker Amy: I have no Discusses for this document, so unless there's an objection now I think this is approved. Zahed: Thanks for the reviews. I think we have the critical one, whether some of the references should be normative. We have talked about it with the authors so it felt like these were all informative but there's a thin line here. This is informational anyway. I see Colin might have ideas. I suspect there might be a Revised ID. Lets' see what Colin says but let's put it in Revised ID Needed or AD Followup. Amy: This can be Approved, Announcement to be Sent, Revised ID Needed until you're satisfied with it. 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-smyshlyaev-tls13-gost-suites-00 IETF conflict review for draft-smyshlyaev-tls13-gost-suites draft-smyshlyaev-tls13-gost-suites-08 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 (ISE: Informational) Token: Paul Wouters Amy: I have no Discusses for this conflict review, so unless there's an objection now it looks like this is ready to go back to the ISE. Paul: I had one small related question. The document does say recommended no for the cipher in the column that has TLS WG recommending that cipher or not. Technically, I guess, this is not going to the TLS WG. Someone could change that recommendation to yes, right, and then we would have to stop that from happening. Is that something we could stop with a note? How would that happen? How can I pass this saying 'yes but only if you keep recommended = no.' Lars: You say no if it isn't that. Paul: You mean when it comes back to IESG review? After the conflict review… Lars: Oh, you mean if they change it afterwards? We would need to hope that the ISE would question that change. Auth48 also happens, where we have to trust that the RFC Editor would catch that change. Alvaro: If I understand you correctly, that entry right now is something we would require the TLS WG to agree on? One of the responses is that this document conflicts with IETF stuff because it requires a WG to look at it, or something along those lines. You could force it that way. But theoretically, if you make the comment and they change it, Eliot should be on top of not letting them change it. The stronger hammer is to just stop the document because it goes against IETF policy. Roman: Wouldn't the designated experts also catch that during the IANA procesS? Paul: Yes, but can we stop it if it's the ISE? Warren: We can advise them it's a bad idea, but they can do whatever they want. The only thing we can do is if an ISE document wants to make a reservation in a registry we can tell them they can't have one. But the I in ISE stands for independent. John: You asked what the designated expert can do if ISE publishes, and it depends on what's in the guidelines to the designated expert. If they have reasonable guidance, they can look at this document and say sorry, no. Paul: Okay, thanks. I was mostly just curious about the process. Amy: So I have that this conflict review is approved with the note that's currently in the tracker and we can send that back to the ISE. o conflict-review-irtf-cfrg-vrf-00 IETF conflict review for draft-irtf-cfrg-vrf draft-irtf-cfrg-vrf-15 Verifiable Random Functions (VRFs) (IRTF: Informational) Token: Roman Danyliw Amy: I have no Discusses for this conflict review, so unless there's an objection now it looks like this is ready to go back to the IRSG. This will go into Approved, Announcement 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 Application-aware Networking (apn) Amy: I have quite a few blocks here. Andrew: I've looked at the blocks. I think version 1 of the charter solved some blocks but introduced a lot of others. I would have said this needs a BOF at this point, but at the same time, looking at the blocks and the responses on the mailing list, I think there is zero hope of getting through a BOF at this point. After I discussed this with John and Alvaro at our AD meeting, what we're going to do for now is say this isn't going to happen and return the time slot, and after 115 I'm going to work with these guys to set up a bof at 116. IF I look at the responses from the list on the charter, we got responses from the proponents to address some of the concerns, but I didn't see any other support on the list for modifying the charter, which makes me nervous. I'm going to call this for 115, say it moves to 116, and I will work with them to set up for a BOF then. I don't think we can proceed without a BOF at this point. Comments, thoughts? John: We already discussed this, but it seems reasonable to me. Zahed: Sounds like a plan. Roman: Sounds good. I don't think we can move ahead with what we have, and you have a plan for making changes, so we'll see what that yields. Andrew: What do we do about the time slot on the agenda? Amy: Send in a support ticket and Liz will take care of it. It'll be marked canceled on the agenda. Warren: If it's canceled, maybe you and the proponents can get together in that room or somewhere else to discuss the concerns. Andrew: Yes, I think I can say something like that to the proponents. I just need to confirm that once we cancel the meeting, that room will be available and won't be allocated to something else. Amy: It is likely to be allocated if the room is needed. You can always sign up for a side meeting room or use the IESG office, as that's what that is there for. Warren: That's probably better. Andrew: I'll set up a chat with them. Thanks very much for all of the comments. 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Warren: I don't know of any news this week, I missed the meeting because I was at NANOG. Maybe Lars or Mirja could speak, maybe about the MTEN workshop? Mirja: There was no meeting because of the workshop. The workshop was quite smooth and we had some good discussion. There is no concrete outcome but everyone got a better understanding of the problem and hopefully we can reflect this in a report at the end. 6. Management issues 6.1 Policy Regarding IANA Registry Tombstone Entries (Murray Kucherawy) Murray: This is Tim McSweeney again. He would basically like to cancel everything he's ever done at the IETF, so he's trying to de-register even his provisional URI scheme. He can do that if he wants, but the designated expert for that registry would like to install a tombstone entry showing the IESG as a change controller. Tim objects, saying that's his name and he can do what he wants with it, including leave it blank. My position and that of the designated expert is that once you remove the entry, there's no entry there and we can do what we want, and the right thing to do is to put the tombstone in because otherwise someone comes along later and says they want drop, now you have a collision even though the provisional one was only ever private use. IANA is asking us to make that official, basically. Warren: An option might be instead could a new registration be made which assigns drop to the IESG or something, and then the IESG changes it and puts in a tombstone? OR would that be weird? I'm not sure if what I said made sense. Murray: Not quite. Can you go over it again? Warren: Currently, if there was a registration, and it was to someone, and that person doesn't want the registration anymore, could the registration be made to a different entity and then that entity says let's return it and put the tombstone in? Murray: Why would it not be us, though? Warren: It would be us, I mean a different entity to who originally registered it. Murray: I guess the question is, is it reasonable for him to be able to say he doesn't want anything there including the tombstone? I think he gave up change control when he deleted everything. The name is now available again and IANA or the IESG can choose to put an entry there if they want to. Warren: If only the change controller can put the entry in, maybe the change controller can become the IESG and then we can immediately put in a tombstone. Murray: You mean make that a regular practice? Sure. Alvaro: Two things. In a previous IESG there was some effort to make everything with the IESG as a change controller. That's just a side note. I don't think we should make a decision on this registry. This is a designated expert managed registry. The decision we should make is that the designated expert is the one in charge of making the decision, whatever that is. In this case we happen to agree with the designated expert. In some future case we may not agree with them, but our decision back to IANA should be yes, the DE can make the decision because it's a DE managed registry. If someone doesn't like that decision, IANA or Tim or someone else, they can go through normal channels and appeal. For nowe we should just say that whatever the DE decides is the right thing to do. Lars: The IESG does have overriding power, so the IESG always has the ability to put stuff in registries. But in this case I agree, the expert has made a decision, and I'm happy for us to minute that we approve the decision of the expert, but the submitter needs to accept that IANA is managing the registries by a set of policies and those policies are not leading to an outcome they would prefer. Alvaro: A slight nit to what you said, I don't think we need to approve the decision of the expert, we just need to affirm that the expert can make the decision. Lars: We can phrase it that way, yes. Martin: So to be clear, Tim's name and email and all that will not be present in the tombstone? Murray: Correct, the tombstone would just say there was an entry here, it's no longer here, the name is retired. Martin: I can imagine another person saying look, I'm retired, don't send me email about this registry or what have you. But that's not the case here. I say do the right thing. Murray: In that situation you just described, where someone doesn't want to deal with it anymore, we'd just make the change controller to the IESG. We have a way forward there too. Martin: I think what you're proposing is fine. Murray: Anyone else? If not, I will go back to Sabrina and say that our position is that the DE in each case gets to decide and we're fine with that. Sabrina: Sounds good, thank you. Lars: If IANA thinks the DE is wrong, they should still raise it with the IESG obviously, but if the DE otherwise makes a decision that IANA thinks is a fine decision based on policies given, that's fine. 6.2 Registration for Side Meetings (Secretariat) Amy: We had a question from a regular IETF participant about who can attend the side meetings onsite and whether they are open to the public or whether they are, like any other meeting with the IETF, you have to [be registered for the meeting]. Martin: I think what Lars proposed, which is basically that they have to go through the fee waiver process, is fine. I think it's generally fine to give people an opportunity to participate in these little things without making a big deal out of it, but I can see avenues to take advantage of that. Warren: I have a very closely related one I think is worth mentioning so they can be discussed together. The IEPG meeting is on the Sunday before the meeting starts. Since it was founded it's always been that you don't need an IETF badge or registration to attend but pretty much everyone always has had one. I don't know whether that's worth discussing at the same time. The thing that makes it interesting other than the historical aspect is that it meets before the IETF starts. Alvaro: We've made statements before that the IETF starts on the Saturday, so technically that meeting happens during the IETF week. I think these meetings should be open to anyone who wants to come in. Many of them are about new ideas, attracting people who live nearby, and I think they should be open and free to everyone. But if we're going to make a policy, it should apply to everyone, including the IEPG. Éric V: The same with the ANRW, right, which is also outside the IETF? Mirja: I think everyone who participates in a meeting should register. That doesn't apply to closed meetings. We also provide rooms for people who want to have side meetings and they pay for the room and organize a side meeting. That's not our business. If we pay for the room, everyone should have a badge. That doesn't mean they have to pay for it, since we have the fee waiver. We should welcome people to use the fee waiver for this purpose. We have registration for the ANRW, and the Hackathon, companions, etc. We could have a separate registration but I think people can just use a fee waiver and register normally. Warren: For IEPG in particular, Tim wanted to be able to bring some of his students along from university in London. Having them get a fee waiver if they're just going to show up for two hours of IEPG meeting seems like it would be not quite wasting fee waivers, but using them for a different purpose. Lars: It actually doesn't. The stats show that we have participation we're not even currently tracking. Fee waivers for day passes are no problem. I'd rather people get those. I do want to say that I'm all for having a consistent approach and I recognize that IEPG has been around for so long that nobody remembers. I think it would be good to have this policy. If people want to have a meeting where they control the attendance and they get a room they pay for, they can also meet in the bar or the restaurant, but if they want to meet in part of the venue contracted space, I think it's fair to require that people who attend are registered for the IETF and not charged extra for it. I think somebody tried to have a meeting like that. Roman: To me, there is some cachet in being listed as an official side meeting. The most important thing to me is whether the Note Well applies. If we want to do a solid for some other organization, whether it's by money or just inter organizational relationship, I'm fine with giving them the side meeting rooms, but then in the agenda it's not a side meeting and the time is blocked. If you want the official standing of a side meeting, then the Note Well applies and then we can argue about whether you need to register. The key thing is the Note Well which depends if we give them a side meeting room or some other room. Éric V: On the other hand, if the Note Well applies, so do all our other policies, like the Covid policy. Mask wearing. Mirja: I think the Note Well applies no matter if people are registered or not, but we have to make them aware of it. The people who organize the meeting should make everyone aware. In Warren's case, if they are a student, they can get a fee waiver on the IRTF track as well. If people have an official registration they might stay for more sessions or more days and become a participant, so that's an advantage. Warren: The RFC which created the IEPG says that meetings shall be made openly available. Mirja: Open doesn't mean you don't have to register. Warren: That's true, but I think there's a difference between having to register and getting a fee waiver, which implies there is a fee that is being waived, which makes it not free anymore. Mirja: Open also doesn't mean free. IETF meetings are open, but not free. Lars: The fee waiver is not a heavyweight thing. I get a code from the Secretariat and I just give people the code to register with. If we tell the Secretariat to look for "IEPG" in the fee waiver note I might not even see it and they can just do it internally. Warren: Because the IEPG has always been viewed as not really an activity of the IETF, it does seem weird that the stats should be mixed in. If there was a separate fee waiver we can track it in a separate bucket. Lars: I get what you're saying, but you can't be part of the IETF and not part of the IETF at the same time. You continuously co locate and the vast majority of your people come from the IETF community, you are part of the IETF community. You might not want to be part of it, but for all intents and purposes you are. Mirja: I have no problem having a separate IEPG registration but that is just making it even more formal. Nobody will check the badges anyway. Rob: Question for Lars, if someone turns up quite late to this meeting and is told they have to register then and there, will that work or is that an issue? Lars: They can get a day pass at the registration desk. If the Secretariat is told that people coming to the IEPG should get a fee waiver if they don't want to pay, that can be handled then and there. Rob: I'm happy to make a consistent policy on this. Roman made the point that there are some meetings that don't fit into this and don't put them on the side meeting wiki. Where would you put them, then? Roman: We don't put them anywhere, they're not our meetings. I'm making the case for the meetings that aren't ours. If we do a solid for someone and give them a room, we're not running the meeting or advertising it so they should handle that. Rob: The example might be one from the UK government, the DCMS or whoever. I don't know if they've asked for fee waivers. Lars: They have. Rob: So they're happy and they will get fee waivers. Maybe that's fine for these meetings and if the IESG is arranging a meeting they can give a code. Lars: They have asked for a fee waiver not for the side meeting, but because they want to stick around for the day and go to the IETF. That's where the fee waiver came in. It wasn't because of that DCMS meeting. Rob: Is the DCMS meeting listed on the wiki? Amy: Yes it is. Lars: I thought the ISOC one was but this wasn't. Amy: DCMS is the ISOC one. Lars: Oh, okay. Sorry, I'm confused. Rob: That's the consistency I'm trying to get to. If they're listed on the wiki, does that mean they therefore have to have fee waivers? Roman: The point I was trying to make is that that meeting we just talked about is not an IETF meeting, it's not on the wiki. Lars: But they are listed on the wiki. It's non-IETF people that want to have an open meeting in one of the side meeting rooms during the IETF week. They would exactly fall under this policy. Alvaro: So if they're on the wiki, they have to register, but if they're not on the wiki, they don't have to register. Mirja: I think ISOC is aware that the Note Well applies and everything, and they wanted it that way. Warren: I wonder if the people attending know what the Note Well is. Mirja: I explicitly mentioned that to ISOC and I hope they also provide this to the government people. Éric V: In the same vein, you've seen the side meeting organized by ETSI, right? Mirja: The IPE one? I'm not sure if it's organized by ETSI. Éric V: I got another request to have a side meeting on Saturday for something on Yang. Is it possible to have a meeting room on Saturday? Lars: I don't think we have the meeting rooms available on Saturday. They would need to meet somewhere else. They can sit in the hackathon, but it's not really going to be a meeting room. Why Saturday? Éric V: My understanding is that they are an operator group having meetings Thursday and Friday, so they will stay Saturday and meet with IETF people. I want to get more information from them. The chance they will stay for the IETF week is pretty much zero, I think. Amy: So what I'm hearing is that public side meetings are public in that they're open to any IETF participant. Éric V: Registration required. Roman: That's what I heard. Amy: I will take that back to the participant who questioned and update the wiki. 7. Any Other Business (WG News, New Proposals, etc.) Amy: Remember that our next formal telechat is next Thursday in preparation for IETF 115. 6.3 Executive Session (Lars)