INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-04-21 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 Jenny Bui (AMS) / IETF Secretariat Jay Daley / IETF Executive Director 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 Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Applications and Real-Time Area 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 --------------------------------- Roman Danyliw (CERT/SEI) / Security Area Martin Duke (Google) / Transport Area Murray Kucherawy (Facebook) / Applications and Real-Time Area OBSERVERS --------------------------------- Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the official minutes of the April 7 teleconference being approved? I'm hearing no objection, so we will post those in the archive. Andrew: While I probably don't object to them, I couldn't read them because they had a password. Cindy: Your regular Datatracker password should work; if it doesn't, there's something else wrong and we can fix it offline. Andrew: Okay, I'll ping you later. Cindy: I did send the final narrative minutes and I didn't get any comments, so unless there's an objection it looks like the final narrative minutes from April 7 are approved. Thank you. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Murray Kucherawy to find designated experts for RFC 9208, "IMAP QUOTA Extension" [IANA #1229081]. Amy: Murray is away today. o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn) [IANA #1229681]. Amy: Roman also couldn't be here today; this is a new action item for him. * OPEN ACTION ITEMS o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in July 2022. Amy: This is on hold and we'll look at it again in June or July. o Murray Kucherawy to look into updating the guidance in BCP 13 on when to add organizations to the "Standards-related organizations that have registered Media Types in the Standards Tree" list. Amy: This was in progress last time and when Murray gets back he can continue that. o Francesca Palombini to follow up on the public archive of AUTH48 conversations. Amy: This is on the agenda today to discuss as a management item. o Murray Kucherawy to review the media type registration request from standards organization CWL Project. Amy: He has done that and he sent a writeup which is on the agenda as a management item today. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-bier-bar-ipa-12 - IETF stream BIER Underlay Path Calculation Algorithm and Constraints (Proposed Standard) Token: Alvaro Retana Amy: I have a couple of Discusses; do we need to discuss any of those today? Alvaro: I don't think so. There are a couple of emails out on the solutions. Paul, unless you want to talk about the IANA part today? But I think we're converging on that part, I don't know if you agree. Paul: I think we are good. Alvaro: Okay thanks. We're going to require a revised ID. o draft-ietf-sidrops-rpki-has-no-identity-07 - IETF stream The I in RPKI does not stand for Identity (Proposed Standard) Token: Warren Kumari Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this is approved. Warren: Excellent. I did have a discussion with the authors on the document track and while Standards isn't perfect, it's better than any of the others so we're sticking with Standards. Thank you very much. Amy: I have no notes, so this is just going straight to Approved, Announcement to be Sent. Warren: Thank you. o draft-ietf-cbor-file-magic-11 - IETF stream On storing CBOR encoded items on stable storage (Proposed Standard) Token: Francesca Palombini Amy: We do have a Discuss here; unfortunately Roman isn't here to discuss it with you. Do we need any discussion today? Francesca: No, I don't think so. The authors have already answered and they're preparing a new version of it so this will go into Revised ID Needed. Amy: Thanks; this is staying in IESG Evaluation with 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-lisp-vendor-lcaf-10 - IETF stream Vendor Specific LISP Canonical Address Format (LCAF) (Experimental) Token: Alvaro Retana Amy: There are no Discusses in the tracker, so unless there's an objection now, this one is approved. Alvaro: Can you please put this in AD Followup? Amy: Certainly. o draft-ietf-raw-ldacs-10 - IETF stream L-band Digital Aeronautical Communications System (LDACS) (Informational) Token: John Scudder Amy: We have a number of Discusses; do we need to discuss any of those today, John? John: Let me just cover it quickly. In light of the sea of red, and the fact that some of them will be easier to resolve and some might be impossible to resolve, and we've got another way forward anyway with the independent submission stream, I'm going to work with the authors to move it to independent submission. Apologies to you all and to the authors for not having thought of that before I put it on the agenda and wasted people's time, although it wasn't a total waste because there was a lot of very helpful review. Thank you for that and thank you to the authors for working constructively to address those. So it'll be moving to the ISE stream. Amy: It needs a substate before that happens so I'll just put that in AD Followup and let you work on moving it. John: Sounds good, and since this is the first one I will have moved from IETF stream to ISE stream, I've got to work with Elliot since it doesn't go without saying that he will accept it, but any advice offline would be appreciated. Amy: It's not common but it has happened in the past, so maybe folks who have done it can advise you. Lars: Can we take a second? It's obviously up to John whether he wants to move it to the ISE or not, but we have published similar docs on the IETF stream in the past, and even after the streams got created. In TCP, for example, we've described a number of proprietary industrial control algorithms or queuing algorithms in other TSV groups on the informational stream, for the information of the IETF community. This is maybe a little different because it's surveying someone else's architecture, but it's not that different that I personally think it needs to be absolutely moved to the independent stream. Yes, maybe it didn't get enough review and that's probably an issue, but I don't necessarily think documents like that need to go to the independent stream. Andrew: My issue here is that in this particular case even reviewing half the stuff is difficult because you've got paywalls in front of half of the stuff. You have a document where I'm not convinced half the WG could have even reviewed it because if you don't have access to the stuff to review… Lars: Yes, I get that. For example with the experimental congestion control algorithm, we can't review the source code of the Windows kernel either. We have to trust that what the authors are describing is accurate. This seems similar. Alvaro: I'm not sure what RFC that was, but was that before we changed that everything needs to have consensus? Lars: I think it was after but I need to check. It was the original cubic and the compound piece is for Microsoft. If you want to keep discussing, I'll take a minute to look it up. Mirja: I don't want to comment on this document but for the congestion control one there was no stable reference. There was no other organization which had documented it, so there was a clear purpose there. Zahed: For the congestion control that was one of the biggest reasons that we wanted to work on it and push it through, because there was no other way of knowing anything. So we at least have something in the IETF that people can refer to. This is not the case [here]; it talks about use cases and requirements and this is all about this LDAC thing, not about what is in it. If I could, I would propose to talk with the authors to describe LDAC and what it means to the IETF, and RAW could be a big part of this document and we could get it through. But when you have statements like LDAC is the pioneer and most important part of FCI, do we want to have a consensus call on that? I don't know. That was the complex ask I was doing with myself. So I think this is a good document to have, but you decide, John. John: Let me slightly rephrase my previous comment. It seems to me like most of the Discusses, it's possible to work through them. The question is going to be two things. One, at least Alvaro's and to some extent Andrew's Discusses are fundamental process things that can't really be fixed by the authors at all. So I don't feel great about letting them twist while we work through that. I'm not sure that we need to elevate that conversation to the telechat level anyway, to make it a blocking conversation for their document. I'll talk to them again and maybe the impression I got last time was wrong, but basically the impression I have from the authors is that they're fairly pragmatic and we'd just like to get their document stably published. As some of you have pointed out, that's what the ISE stream is for. We can all continue to work on getting it into a different form that everyone perceives to be appropriately shaped to fit into the WG charter, IETF stream and so on, or everyone can do quite a bit less work and put it into the ISE stream. That's the conversation I will have with the authors; I suspect they'll say 5x the work and maybe we get a publication in the IETF stream, or 1x the work and I get a publication in the ISE stream and either way, it's a publication. So I think it's just a pragmatic choice to switch it to ISE. Éric V: You need to be very careful to keep the authors and this team of people still involved with the IETF. We need to get new work at the IETF and this is maybe a first step to get new work. We need to be cautious there as well. John: Right. I would say they have an extremely constructive attitude about this whole thing. They did have a quite similar reaction to one we saw a few months ago from another author who felt suddenly attacked, because they hadn't gone through a lot of last calls or being on the IESG agenda and then suddenly having this influx of what feels like harsh criticism. I think they understand what the process is that's going on and it's okay. But yes, I think we need to keep that in mind in future for other new authors as well. I know we put all kinds of disclaimers at the top but the lesson I'm taking away is that when working with new authors, it may be valuable to have a call with them before putting their document on the agenda just to say here's what you may expect. Any further discussion on this one? Rob: Not on this document specifically, but I do think it would be helpful if we could make the rules easier for people to understand. Even in the discussion between the IESG about whether this should or shouldn't be allowed, it didn't seem like there was definitely consensus there and if we can't really know what's allowed or not, how does anyone in the community have any chance of doing that? So I think that if what's in 2026 has evolved and changed, we should somehow be sharing that with the community, whether that's an update to 2026 or some other mechanism, I don't know. I don't like it being ambiguous, personally John. I absolutely agree. I started that mail thread but I think I am going to propose a topic for the retreat. Any opinions on whether that should be IESG or IESG + IAB? Zahed: You did a very good job sending out this email thread because this is confusing and Rob, you read my mind. This is kind of orthogonal to this document but we need to do something to make sure everyone can understand what we're talking about. John: I think we can move on. o draft-ietf-quic-applicability-16 - IETF stream Applicability of the QUIC Transport Protocol (Informational) Token: Zaheduzzaman Sarker Amy: There are no Discusses in the tracker, so unless there's an objection now, this one is approved. Éric V: By the way, you need to change the consensus setting, right? It's currently Unknown. Zahed: Not on this one, but I think that is one thing I missed somewhere and I was questioning myself where and how I missed it. I don't know if I need to change the boilerplate consensus in the process of putting it in a telechat or in IETF Last Call or when I should do it. Amy: I don't actually know when that happens for ADs, so maybe someone can answer when you click the box or change the consensus to Yes. Francesca: I think most of the time the WG chairs or the shepherd do it. I've never had to do it myself so far. Amy: Great, nobody knows who's doing what! Whenever it comes up as Unknown, we will change it for you. Alvaro: Didn't we change it so that the newer documents have it set to Yes by default? I think it's only a problem with older documents that have been around for a while. Amy: I know that's true for protocol action documents. I don't know if that's true for document action documents; maybe. John: The LDACS one came up with it as No, as several people pointed out, and I manually switched it to Yes after those comments. Alvaro: The other question is that with 8789, that everything requires consensus; does it even make sense to have an option? Francesca: We do have it in the shepherd writeup, right? I always assimilated that field with the shepherd writeup where the shepherd has to discuss the WG consensus around the document. Alvaro: I take that as them explaining why there is consensus. Otherwise we should never see a document that [is Unknown]. Zahed: I'm with Alvaro, I was thinking this is by default IETF consensus. Éric V: At least it should be by default after the IETF Last Call, though. John: It seems like a historical artifact that that thing exists; Alvaro is implying that it came from a time when the IESG would also advance documents that didn't have consensus. Zahed: So about this one, can I change it now? Amy: We'll change it for you if you don't. It's part of the process that anything coming through us with a consensus Unknown will get changed to Yes, unless we're otherwise instructed. So it looks like this document is approved. I have no notes in the tracker, do we need any? Zahed: I think there are some editorial changes and typos. I suspect the authors will address that; maybe AD Followup or Revised ID Needed? Amy: Either one is fine; if you feel very strongly it's going to require a Revised ID that's probably the one to go with. Zahed: For this one I think we can do AD Followup. o draft-ietf-quic-manageability-16 - IETF stream Manageability of the QUIC Transport Protocol (Informational) Token: Zaheduzzaman Sarker Amy: There are no Discusses in the tracker, so unless there's an objection now, this one is approved. Does this also need a revision? Zahed: I think this will need a Revised ID; Lars is having some discussions about the versioning. Lars, do you feel like we are reaching a conclusion on that thread? Lars: I Think there will be. Christian replied also, and I haven't heard from the authors yet; I think there might be an update coming to address that IANA thing. I think it's totally misleading. Maybe Mirja, who's one of the authors on the call, has a feeling here too. Mirja: We'll revise both of them together anyway so that's fine. I'm happy to take in whatever people decide. Zahed: Okay, that's great. So we heard from the authors, the revised ID will be fine. Éric V: By the way Mirja, it was a good job; very clear and useful. Congratulations. Mirja: I'm just a contributor here, but thanks. Éric V: Well, Brian is not here. Mirja: There were also a lot of contributors in the WG, but I'm happy to hear that it's helpful. Zahed: Thanks for working on it. o draft-ietf-v6ops-transition-comparison-03 - IETF stream Pros and Cons of IPv6 Transition Technologies for IPv4aaS (Informational) Token: Warren Kumari Amy: I have a couple of Discusses; do we have to discuss these today? Warren: Just quickly. I believe Éric thinks one is going to be easy for the authors to address and I think they might have responded already. What I was wondering is Roman, have you heard from the authors at all? Amy: Roman is not on the call today. Warren: In that case, never mind. They'll figure it out. Amy: It sounds like this is going to get a Revised ID? Warren: Yep. o draft-ietf-dots-multihoming-12 - IETF stream Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) (Informational) Token: Roman Danyliw Amy: We'll change the Consensus to Yes here for Roman. I have one Discuss from version 11; do we need to discuss this today? Erik, any feeling there? Erik K: I saw that version 12 showed up but I have not yet reviewed it. I'm happy to clarify on the list; I don't think I'm asking for any huge alteration of the text, I just wanted to point out that must use 6724 is not actually sufficient in these cases; maybe they could just drop some useful warnings for a reader who's not really experienced with multihoming ipv6 and all of the joy that will follow from attempting to do something like that. Amy: I'm going to put this in AD Followup so when Roman is back he can take a look and help out with that. We'll let him sort that out with you. 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-briscoe-docsis-q-protection-00 IETF conflict review for draft-briscoe-docsis-q-protection draft-briscoe-docsis-q-protection-03 The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency (ISE: Informational) Token: Martin Duke Amy: I have no Discusses for this conflict review, so unless there's an objection now it looks like the message in the Datatracker is the correct one to go back to the ISE. Hearing no objection to this conflict review message, so we will have this sent on Monday. 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 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: On the previous call there was some discussion on the interaction with liaisons and making sure liaisons have the ability to participate fully, and also recently some discussion on the approval process for liaison statements. The way it currently works is WG chairs and others can send liaisons without real review and approval, and some discussion on making that process better understood and making sure there are some checks and balances and not just any WG chair can send anything to anyone. That's the high level summary. Lars: There's a small group Mirja is getting together that's going to discuss it a little bit more, and I'm on it since obviously how liaisons get sent matters to the IESG. I'm guessing I'll report back to you guys when there's a proposal; at the moment, it looks like there will be an approval step required if WG chairs want to send a liaison and it's probably going to be the AD. There are some details on who can expedite this or overwrite that if they're not responsive or something. I guess we'll hear at some point from that small group and there's also RFC 4052 that talks about how that is handled. It's an older RFC and it might need a revision; if that is the case, you'll definitely see it. Mirja: Today as described in 4052, approval is required but it's easy to circumvent in the tooling. So one question is about how this approval process in general works, but also about how it's realized in the tooling. Warren: Currently the datatracker has a box saying "obtained prior approval" and it's unclear to WG participants and ADs and anyone else what that actually means, which I think is what Mirja was referring to. At the high level, there's discussion happening, and once more happens, we'll tell you about it. 6. Management issues 6.1 Follow Up on the Public Archive of AUTH48 Conversations (Francesca Palombini) Francesca: I just sent an email to the IESG list and posted a Google document I've been working on. My goal for today was to summarize the threads that have been happening on different mailing lists. It took some time. Looking on the mail archive there were 365 mails but these are also duplicates, because most people sent to more than one mail list. Maybe we can just go through the document quickly and then we can discuss the summary and way forward. I identified the questions raised and these are my summaries, and I included links to the mails I summarized so people can go and read the details if they want. These five questions came up. First is what about github, would that be archived and if so how? I can also say what I think the answer is right now. For Github I think that's for later, this is not part of this proposal. Someone brought up why not make this a fixed term experiment and bring the result to RSWG as a policy proposal? There was some mixed reaction to that and others were saying no, the RSWG can tweak this when they get to power and we don't need to wait. Reaction to that was running an experiment is fine but declaring a policy isn't for the IESG and other stream managers. RSWG will be operational soon, we should wait for them. Third question, why not CC the WG mailing list instead of creating this new AUTH48 archive? And trying to make this a send only address which does not receive emails, so if people try to reply to it, they could still reply to authors or RFC editors directly but they can do that now as well. There was a lot of negative reaction to this suggestion. Someone else suggested there should be a separate AUTH48 list for each WG which also people responded to negatively. Others didn't care about one per WG or one for all WGs as long as it cuts the noise on the WG list I actually want to follow. Someone asked me what's the difference between having one list per WG or one list and theoretically there's not much of a difference. The response was why should a lot of people set up mail filters when it would be mirroring functionalities we already do on the IETF side, setting up several mail lists and making it possible to subscribe to different lists. I did check with Robert and he thinks this is a lot more work to set up one archival list per WG than one list for all AUTH48 conversations. Plus he brought up another good point which is that it would also require more work from the RPC because they wouldn't just need to add one mail list, they would have to change the CC based on the WG. Also there was some positive feedback to this proposal, like it keeps the authors in check and avoids the "AUTH48 black hole", and allows someone to see all AUTH48 exchanges. Again, my response to that would be that you can still do that with filtering. The fourth question was why are we discussing a new list and not something like an issue tracker? The answer for me is that this is a simple solution that doesn't require too much work from the tools team. Another question is what would be the responsibilities and accountabilities changes; are we requesting more people to check by setting this up as transparent and allowing people to subscribe? The response to that from someone else was yes, we let people check, we are not requesting anyone to check but people who want to are able to, and this should be viewed as a small additional safety check to the existing mechanisms, which is right now the responsible AD and the WG chairs and shepherd, which are the people who are supposed to check right now. These were the questions. Francesca: Then we got some feedback that was not really questions. I tried to summarize it. We had several people say this seems reasonable, other people saying this seems reasonable but with some feedback and counter proposals, some of which was in the questions above, and the other position was I'm not against this, but I would defer it until the RSWG is in place. There were negative reactions to that, why should we stall something that we could be doing right now? Lars commented if this is supposed to be in the RSWG purview and the response was that if we ask to change RPC processes, then yes it is under the RSWG purview, and the public debate during AUTH48 is a policy issue. The way we deal with that, are we doing mailing lists or issue management, the IESG and other stream managers can have a say on it but the policies around it should be in the purview of RSWG. Even there, it wasn't a very strong opinion on either side, but some people said RSWG should be able to take care of it and others said they should not be. Some people would be concerned that we would be pushing too much on RSWG. It's quite split 50/50 and you can look at the mails in more detail if you want to see what people are saying. Francesca: There was other feedback I've put into this separate section because it's not really about this proposal itself but it's spun from it. Things to think about, let's say. One was to make sure authors can opt out, which I agree with. Another about being informed in real time; this was not how I had envisioned it. I had thought this was a mail list for archival purposes, not necessarily in real time; I wouldn't need to subscribe. I can see how people would want to subscribe for their own archival reasons but people do see an interest in being able to follow up and make sure that mistakes are spotted or that you can see what's happening in real time. Another feedback was in the bigger picture, there are two different concerns about guaranteeing no ill will proper review, to avoid changes that are too big, and the other is dishonest changes that are made during AUTH48. He was saying we should focus on the first and make sure all AUTH48 changes are properly reviewed and he suggested two different ways of doing this. He went one step further of our proposal and suggested some interesting experiments like announcing on the Last Call mailing list when a document goes into AUTH48, with a link that allows you to subscribe to the AUTH48 list for that list. Another option would be to add an announcement to the Last Call mailing list with a link to a diff to the document before it went into AUTH48 and after it exits AUTH48. This would be a notice, not a request for comments on the changes that happened during AUTH48, and the only reason to have that would be so that if people care they can go in, look at the idff, and possibly follow the existing processes like appeals or bring it up to the IESG, etc, to say these changes are too big and shouldn't have happened. This would be an additional step to make sure the AUTH48 changes are properly reviewed. Éric V: I'm a little surprised because the auth in AUTH48 is for authors, no? Francesca: Yes; this would be after AUTH48. I'm explaining this proposal from John which focuses on a different thing than what I had brought up. It's an interesting idea we should probably discuss, not necessarily now. Mirja: It seems like some people want to solve a different problem, which I don't think is a problem, which is that they want to be involved in the review of AUTH48 and I think that's a bad idea. The problem we originally wanted to solve was just providing more transparency so we can look it up later. Francesca: Exactly. This is why I put it into other feedback. I don't have a strong opinion if it's a good idea or a bad idea but it's not related to this proposal. It's something that spun out of this proposal we can discuss if we want. Lars responded to that and said what you just said, Mirja, that the IESG proposal is not motivated by dishonesty or improper reviews, just to add transparency to the process. Thank you Lars for doing that. And John replied to that saying he understands, this is not a proposal, but these are questions that will most likely need to be addressed and can be done in conjunction with RSWG. Lars: On this one, if that happens, I will push back. Because getting the community to participate in the AUTH48 reviews is actually changing the standards process; there's no consensus evaluation at that time anymore. The AD is supposed to pull the document back into the consensus part of the organization if changes come up that aren't editorial. The community might have an interest in seeing that play out but there's no discussion phase. If they want to push back that's not a RSWG thing either because it's not RFC series policy. Francesca: I think maybe I misrepresented John's view. But in his email, it was pretty clear that this is really not a request for comments or another Last Call. he did say send it to the last call mail list, probably because that's what he looks at and he assumes that's where other people look for announcements on documents. But this is not supposed to be seen as a last call, just an announcement that this document has finished AUTH48 and this is the diff between pre-AUTH48 and post-AUTH48 and that's it. And like a timeline when it will be published. It lets people who have interest in looking at it use the existing processes like appeals to say i don't think this went through enough careful consideration from the responsible AD or whoever is needed to approve it. Lars: I get it. Maybe we shouldn't be having this discussion now but I think that's a terrible idea. We've never had a case where somebody appealed because of something bad that happened in AUTH48 and creating a delay for all RFCs just on the off chance….they can already appeal it after it's published and say hey, I looked at the diff and there's clearly something fishy here. Francesca: That's a valid point. Warren: It also seems like if you're putting this step in you're basically telling people 'now you're supposed to review it and raise any major concerns you have before we publish it' so basically you've asked people to get involved in doing the editorial review and re-raised all the concerns they were unhappy with last time. If anybody reads it at all; i suspect nobody would pay attention, but the people who do might be exactly the sort of people who would fuss for very little reason. Francesca: Okay. So that was one of the feedbacks and then another one was raised by Elliot; we should consider transparency when a draft is not published. Elliot asked if the IESG had comments about that. This is also a wider topic. Lars: Can you say what he means by that? Because either it's not published because a WG drops it or it's not published because the IESG kills it somehow and it doesn't get the ballot that it needs, and all of that is public already. Francesca: Basically if the IESG has suggestions about how, for example, a WG that drops a document, what the WG should do with regard to that document so it stays in the history, in a tombstone document or something to improve transparency about why that document had been dropped. Lars: I would argue that we have a mail archive and if somebody is interested they should look at the email, which is easy. Francesca: He also mentioned that it doesn't happen too often and he can think of like four cases that go back 20 years or so. He thinks this will be valuable and asked the IESG to discuss it. I also had a section on Side Conversations. I didn't copy paste all the emails, just the ones I thought were relevant to the conversation to make it easier to go back and see what people were saying. There were a number of side conversations that started from this thread and I pasted the initial threads. For example, the use of Git as an AUTH48 tool started a side discussion; we don't need to go into details. The second side conversation was about different rendering formats for RFCs and who's responsible for checking those. There was quite a long thread about explaining the RFC process that also created a diagram and song lyrics. So if you want to read that you can. A side discussion about what is in purview for the RSWG; i think that's interesting and will give some insight into what might happen with that. And another one was this thread about the long time that it takes for AUTH48 and what can the IESG do about it. I don't know if we want to bring this as a retreat topic but there it is. Lars: Since we have an awesome list here that we should do something with, can you add this side conversation that people said IANA should look at similar mechanisms to provide transparency for the communication they have with the authors. This might be something we want to discuss with IANA but it's not something that stops us from doing something with AUTH48. Francesca: Yes, I think I saw something about that. IANA also has started CCing the WG when they email experts; I think that was something that was discussed and decided and has improved transparency of communication between IANA and experts, at least, that was private before. That's a good point. For a summary, in general I gathered mostly positive reactions with additional thoughts and feedback to consider like we went over before. This should be discussed with the tools team and have a clear view of what's the best way to do it. There are a few things here we should respond to as the IESG so we don't leave them hanging; but I'm not saying we should do that right now. Given the positive feedback, the main question is if this effort should be delayed long enough for the RSWG to discuss it? I think they would just discuss this and then send a suggestion to the IESG to do it or not do it. Just to have a concrete action list, we have these three options: set up the mailing list as we proposed, and RSWG can tweak as needed if they are set up; or, we do the same but run it as an experiment which is kind of a middle step; or, we wait for the RSWG to be up and running and bring this as one of their items and wait for their feedback before setting up. I assume the response will be yes, given the positive feedback here, so this would end up as just a delay. Mirja: If we bring it to the RSWG there's an assumption there will be some policy here, because that's the only thing they are chartered for. Right? So they are not chartered for making any kind of detailed technical discussions. If anything they would write a policy document and then it would be published as an RFC and then it can be implemented, so it's a longer process. Francesca: Yes. The feedback was split as to whether it was in the purview of RSWG or not. Someone needs to call it. Jay: I was going to say the same thing as Mirja, that I don't think the RSWG can tweak anything. That does leave the question of who can tweak things though, but I'm still thinking through that. Francesca: In this case, I think the stream managers are the ones who will then decide. Jay: You're right, I agree. Lars: I was pretty outspoken about this and I've changed my mind now. I don't think this is for the RSWG because it's not a policy for the series. I think it's something under control of the stream approving bodies, which is us for the IETF stream and everybody else. We should just do this, meaning we should do option 1 in my opinion. I don't see the need to run this as an experiment. If it fails, and I don't really see how it can fail, we can always stop doing it even if it's not an experiment. Francesca: The interest of doing it as an experiment is to have someone who's looking at how it's working and set a timeline to say here's what's happening with that thing we started a while ago. I don't see that as a bad thing to have it as an experiment. Lars: What's the success criteria? Francesca: That, for example, people don't disrupt the AUTH48 process too much. Another thing would be to get feedback from the RPC and RFC editors in general to tell us if it worked or not, or see how many authors opt out. Lars: Since we're increasing transparency, we can't really do this as an experiment and then say, that didn't work, let's become less transparent again. if it creates disruption for the RPC we have to deal with it some other way. Francesca: it could increase transparency but make it worse in other ways. Lars: And these other ways we then need to deal with. Other than hiding the emails again. We should certainly talk to the RPC about how this works but I don't think it needs to be an experiment. In the best case nothing will happen; emails will get sent that will occasionally be found in the mail archive and that's basically it. If people really start to have discussions then we need to make the lists read only. Zahed: I can see doing an experiment to get a pilot project going to get the tooling done. Then we cover the corner cases. Otherwise I don't see a need for an experiment. Lars: The tooling is one mailing list that gets CCed. It's actually an RPC tooling thing and knowing the state of their tooling they probably do it manually. Francesca: John, do you want to expand on how a pilot project is different from an experiment? John: A pilot project doesn't have any formal or quasi formal standing. An experiment does. I think Lars's question about the success criteria indicates that. If you do an experiment, you're expected to report out whether you succeeded or not and you are expected to make a decision about whether to continue or not. Doing a pilot project is just saying we need to get some tooling going and we don't want to roll it out to everyone right away so we're going to try it and see. It's strictly an internal mechanical thing. Francesca: Okay. So a pilot project would go into point 1. John: Right. Zahed: I agree with John's definition of pilot project instead of experiment and we may need a pilot to get things up and running. That's it. Mirja: Maybe I'm spending too much time on the IAB but the policy viewpoint here is that i think 1 is the right thing to do, but the only reason for me to go for 2 is because some people might complain about 1 because people are overstepping their responsibilities or whatever; the usual complaints. If you want to circumvent those complaints you might claim it as an experiment. But I think 1 is still the right thing to do. Rob: My concern with that is does that mean that everything the IESG does has to be labeled as an experiment because we're worried about overstepping our mark? If so, that becomes extra bureaucracy and process that we don't really need. Whereas for this we've discussed it, we think it's a good idea, we discussed it with the community and gotten feedback, but we still think this is the right thing to do so we should just do it. Mirja: I don't think there's a lot of difference. The only difference is if you come back in 2 years and say the experiment is over, we're now keeping it. Either you have to send this email in 2 years or you don't have to send this email. That's the difference. Jay: The only way someone can say the IESG are overstepping their mark is because this is going to happen for all documents in all the streams, is that right? Mirja: My thought was people would say we overstepped because there should be some kind of policy behind it and not just a decision under the hood. Francesca: I did bring this proposal to the IRSG and ISE, etc, to make sure everybody is included. We're talking about the IETF stream but other stream managers have also been included and have decided to be part of this same experiment, or this same proposal, if we go ahead with it. We'll try to do it the same way which I think is very good. We don't want to start doing things differently. No, that's not overstepping. I think it's more like, is this something that should be discussed in RSWG and let them have a conversation if this should happen or not. Lars: One reason we're doing this is transparency because of antitrust, so that everything related to standardization is in the open. Whether the other streams do this, I don't care, because they don't do standards. They can, and it would be great if we applied the same thing, but for the IETF stream one reason we're doing this is because we want maximum transparency because of antitrust and other concerns. This is not something the RSWG has a say in. This is us deciding for our stream, and if other stream approval bodies want to do the same for their streams, that's great. But this is us doing it for ours. Mirja: Lars, I fully agree, but I think people will complain anyway that we are overstepping. Lars: Sure, but like I said, we're doing it for our stream and if other stream approval bodies feel inspired to do the same for their stream, we're not overstepping other than by inspiring them too hard. Jay: The other answer you can give is that you're doing this because this is part of the transparency principles already established, etc. if people don't like it, then they need to get consensus to do something different. It's an argument I use regularly. Francesca: I think it would be useful, Lars, if you could help me write an answer to all the comments about waiting for RSWG. Lars: I think it's basically going to be that, thanking people for their input and we know there wasn't unanimous consensus but we believe that the IESG has seen enough consensus to go ahead with this for the IETF stream because of transparency reasons and we leave it up to other stream approval bodies to decide if they want to enact a similar policy for theirs. Francesca: I will be happy to create a version of this document summary to summarize the questions we've had and the answers we agree on as the IESG, just to say we're not ignoring the discussion but we've looked at it and we have these answers. It's a little bit more work but I think it's worth it. Zahed: I would not really bother doing that. I think what Lars said, this discussion is happening on a public mailing list, so if we conclude that we have positive feedback and some discussions about different things, that's good enough. We don't need to provide answers to everything because then it will open up some people who will refer to this document. Francesca: I don't want this exact document, this is just for us for discussion. Zahed: Whatever formal document. I think that if we would like to write a response let's not use the word consensus, let's say we have input, we've reviewed, and this is our decision. If someone is unhappy with it then we can deal with that. Francesca: I think we can talk about consensus on some things, because there was consensus that it was a good idea. Zahed: We didn't ask for consensus, so why would we use that? Francesca: Because there is. You can read through the mail thread and see that everybody agreed. We don't need [consensus] but it's good that we have it, so why not highlight that? Zahed: I don't think we need to highlight it. Francesca: I think it's polite to answer peoples' questions after we've asked for feedback. It shows that we care what people think. Zahed: I think the word consensus might be contentions because we are really relying on this consensus. I don't think we need to reply to everything. We reviewed it and this is fine. Those are two different things. But it's up to you, or up to the rest of us I guess. I just don't like the word consensus to be overused when it's not necessary. Francesca: We can nitpick on the words we use once we have draft text, which I'll be happy to take help with. I had three more points we should discuss. One thing we should be clear about when we announce whatever conclusion we've gotten from this, is clarify the responsibility and accountability of checking a document during AUTH48 do not change with this proposal. The processes do not change and it's still the same people who are responsible for approving a document. It's not an ask to review all the changes in AUTH48. The second point we should decide on is one mailing list vs. many. Robert said anything is possible but he strongly encourages one list, not one per group. One per group is much more overhead for the secretariat and RPC and then anyone that wants to look back later and find all the AUTH48 interactions for a cluster or particular author across many WGs. Finally, we should have an idea on what to do, if anything, for the future or if/when we want to start using Github. Nothing we need to decide now but we can think about it. Thank you for listening to me talk about this. Going through the mail threads was a lot of mail, some of which were completely unrelated and some of which were quite interesting. I just hope now we don't let this die. My personal opinion is I don't really care when or how we do it or how long it would take the RSWG take a look. Maybe I don't know why it would be a problem to do that if it doesn't take too much delay, but I'd rather not have to wait two years and publication of an RFC to do something so simple. From the mail I read, people who were saying to wait for RSWG to be set up, it didn't sound like the discussion happening there would take two years. I would be interested to hear people who know more than me, if you do know why it would take that long. Lars: I don't know if it will take long or not, I don't think it's their decision and that's why I don't want it to go there. It's not because I think it will take too long. Mirja: They might have the discussion and they might find some conclusion but the only thing they are supposed to do is write RFCs. That means they have to write it down, find consensus, send it through the process, publish the RFC, and then you can act on it. Rob: I find Lars's argument here compelling, that this is something we're doing for the IETF stream and not the others. It doesn't come into the equation; I don't see why we would need to [send it to RSWG]. And we've spent a lot of time discussing this; we came to a conclusion and we should just do it. Francesca: The answer is in the mail thread, i'm not saying i agree with it, just trying to bring up the words I read, was that because this changes RPC processes, it is in scope for RSWG. Éric V: It's not about processes, it's about tools. Warren: Some of it is that people don't entirely see this as something that's on fire so they don't see any urgency to get it done. Some of it is let's wait and see if anyone else has any good ideas because I don't really want to do anything now and I'm tired of fighting it and have apathy. Mirja: Replying to Francesca, that's a completely different interpretation. Just because it's an RPC project doesn't mean it's in scope for RSWG. Only if it's a policy that can impact the RPC process. There might be other internal processes that someone else decides on. Francesca: To answer Warren, from what I read in the mails, people seemed pretty strongly opinionated that you shouldn't do it until RSWG is set up, but again, no strong objection to the proposal itself. Mirja: Maybe the reason they want to wait is because they have a different thing they want to do which might impact policy, but this one doesn't. They want something where they can change the AUTH48 process to where they can interact more with the process or something. They have a different goal than just improving transparency. I think that's what they misunderstood from this proposal and that's why they have strong opinions that it should go to the RSWG. That's my interpretation. Francesca: This made me realize there might be more discussion about RSWG unrelated to this proposal that needs to happen with the community to make sure everybody is on the same page, because it doesn't seem to be the case right now. We don't need to solve that right now but it might be good to have it in mind. Warren: I still don't understand how we deal with when people start saying you have to change it this way, no, you have to change it this way. But I've said that a bunch of times. Francesca: Do you mean when people outside of current AUTH48 conversations step in? Warren: Yep. Francesca: I think it is up to the authors and chairs and responsible AD and shepherd. If that happens, which I don't think it would in most of my WGs, it's up to us to say no. Warren: I don't see how people aren't going to view this as you're creating two classes of citizens, those who are the authors and those who aren't. People who are not the authors involved in AUTH48 have to watch but they cannot participate. Francesca: But in the end it's the chairs and the AD who have to make these calls. Right now the AD does this all in the dark with no transparency about that. We're always asked to make the call to review these changes. Having someone outside who can see it wouldn't change that, we would still have to make the call, and I hope that we can all do the right thing and make the call correctly. It's just that it's more public now. Do you foresee that happening a lot, that people will come up and say I don't agree with this change? Warren: I don't know if it will happen a lot, but I haven't heard any useful answers for what we do when it does start happening a lot. Or, when we have for example, the spring document where we had a lot of people who were really pissed. Every change somebody made, you could see them say, no, you can't make that change, that comma should be a semicolon instead. Having a bunch of people who can watch the process happening but cant make any input doesn't seem particularly helpful and having a set of people who can come along and raise concerns each time, i don't know if you remember but a couple of years ago somebody submitted hundreds and hundreds and hundreds of errata for commas and fonts and spaces. I've said this a bunch of times and I feel like either I'm not communicating it well or I don't care enough, this isn't a hill I'm willing to die on. I still don't understand how doing this and not just at the end of the process, maybe publishing what all happened or saying things happen, this is what's in the RFC. It feels like this is just opening more avenues for people to get annoyed and feathers ruffled. John: Can I try to say part of what I heard from you? I think you're correctly identifying that radical transparency opens the organization up to certain kinds of attacks from people acting in bad faith. And that's right. But that's the organization we have. Warren: Or in good faith, but with opinions. John: What I take from that is I think you're right, but it's just a price we pay in lots of different parts of our process. Warren: Radical transparency is great as long as you are okay with people actually interacting. Having radical transparency where you say you can watch us do things but if you think we're doing the wrong thing you're not supposed to get involved is my root concern. Francesca: No, of course. Warren: So if you're saying that's not it, then it's radical transparency and people are supposed to be involved, which is what I heard you say exactly is not what's happening. Francesca: Are supposed to or are allowed is different. I don't think anyone is supposed to get involved, but they are allowed because now they can see what's happening. They have the chance to actually get involved if they want to. Warren: So if someone thinks there needs to be a comma, and there isn't, and they think that's a problem, they should report it? Francesca: I'm going to quote Roman here and say that's why they pay us the big bucks, right? That's where we will have to step in and say something. Warren: It feels like we're solving a problem that no one thought was a problem until we started talking about it. We haven't had people fussing and saying things changed in AUTH48. Jay: There are people who think that the lack of transparency is a problem, and that by showing this transparency, the behavior of certain people will become visible and hopefully change as a result of peer pressure. So, there is a genuine concern there and this is solving something. I think you're taking a slightly one sided view of the way that transparency will have an impact here. There are certainly some negatives, but the overall start of radical transparency within the IETF has actually worked out very well, in my limited knowledge of it. I can't think of an area where radical transparency has led to a failure. It's generally led to the creation of some mechanism which is self-healing and fixes things. I expect there will be some issues that come out of this initially, and they will need to be addressed, but for example, there may need to be a clearer statement of what authors are empowered to do without taking it back to the list, or there may be some better way of saying to people, no, you're out of scope for getting involved in what the authors are saying. But in the end, I don't think that's going to be problematic. I think this is going to end up benefiting quite clearly the entire process as well as those involved in the process. Warren: The bit that feels weird to me is saying you can watch the sausage being made, but you're not supposed to raise concerns if you think someone is putting in too much salt. Jay: I expect people will say, hold on, the author is now making a change that is beyond the boundaries of what the author is supposed to do, they're not just changing a comma. People will see that and will talk about it and will raise that on the list. To me that;s a benefit, because currently that isn't seen. Francesca: It relies on us ADs spotting it and putting a stop to these types of changes. Honestly, all the reactions, it was quite reassuring to see that nobody had concerns and everyone was quite positive this will create positive results. Rob: Is that a choice? If we say people do want to flag something, or raise something, that they should either raise it through the AD or at least CC the AD or something like that? Is that worth saying? Because at that stage, isn't the responsibility of the document with the AD? Francesca: We could definitely encourage it. Now this goes into the sort of text we would send to summarize the discussion and announce what is going to happen next. We can do a lot of polishing on that text. I hope I have answered your concern, Warren, but I'm not sure I have. Or that Jay has, at least. The one question you started with was who is supposed to answer whoever comes to AUTH48 conversations now that these are publicly available? The answer for me will be us, the responsible AD. and hopefully it doesn't happen too often. Sandy: Every once in a while now we do get mail from people who are not AUTH48 parties. At that point we just send it to the authors with all the parties CCed and ask them to please consider whether this is a valid change. The only concern on my part would be how much more frequently we start to see that, but I think internally at least we would somewhat treat this as an experiment where we touch on it regularly to see how things are going and whether tweaks or adjustments are needed. Francesca: Yes. I think we need to have some followup anyway, whether we call it an experiment or a pilot or whatever. We shouldn't set this up and then forget about it. Lars: I want to come to a conclusion on this one and I'd like to know if anyone feels we should not set up the list as discussed. Meaning the single list, not as an experiment. Francesca: I've heard people here say why not an experiment. Lars: That's why I'm asking the question I'm asking. If people think we should not do this, if we should run it as an experiment, then speak up and we can have a discussion about whether it should be an experiment or not. Warren: If you do it as an experiment, how do you ever turn it off? Francesca: That's what Lars was saying. Lars: Who thinks if we do this we should do it as an experiment? [long pause] I don't hear objections against doing number 1 on your list, so let's do it. Francesca: Before we officially decide I wanted to get peoples' opinions who are not here. We are missing Roman, Murray, Martin. Warren: I'm still concerned that it's unclear to me. Maybe it'll be wildly clear to the participants. But it's unclear how much the rest of the IETF is supposed to be involved and how much they are expected to be another set of authors and how much involvement they can have to relitigate. I keep hearing that we'll figure it out later. Lars: We did explain this when we asked for comments on the proposal. This is supposed to be a read-only list that you can subscribe to but if you're not an author or not RPC, you don't have posting rights or if you do post, you get ignored. Jay: You could add, if you think from viewing this list that an author is doing something beyond the scope of what they're allowed to do as an author, please raise it with the appropriate AD. Mirja: Also I think our expectation was not necessarily that you should subscribe to the list. Lars: Right. The main expectation was that this is an archive. [crosstalk] Mirja: Maybe that's also a good thing to communicate, that there's no expectation anybody should subscribe to it. Not to stop anyone from doing it, but that's not the expectation. Lars: My suggestion would be for Francesca and I to write a community announcement message and we'll run that by the entire IESG so people who aren't on the call can yell if they disagree with the high level outcome or the details. And all of you can agree or disagree. Francesca: That sounds good. And once we have that agreed in the IESG we should circulate it with the other stream managers, the tools team, and the RPC, to make sure everybody agrees. Lars: We can parallelize it and tell the other stream managers this is what we intend to do, please consider doing the saem for your stream. Like we did with the terminology. Francesca: We do need RPC and tools team agreement. Lars: Yes, we can also CC them and they're also on the IESG list so they will see it. Sandy: I have an implementation question. It sounds like the posting rights are closed to everyone except the parties that are actively in AUTH48. Does that mean for each document that moves into AUTH48 those authors would get permissions and then lose them once it's done? Lars: No. We discussed this with Robert and basically, it'll be a public list that anybody can post to but we're not going to say that. We don't want to have the overhead of you managing the posting rights on a per-document basis, unless that can be automated. Sandy: Okay. Lars: We could put the list in moderation and if anybody ever responds who's not supposed to you can not approve the post, but that also costs you overhead. I would leave that up to you to decide whether you want it. Maybe we will keep that in the back pocket in case we do see posts happening frequently. Sandy: Makes sense. Amy: I have an action item for Lars and Francesca to draft text for this and with that I think we can move on to our next management item. 6.2 [IANA #1229134] Acceptance of media type registration from standards organization CWL Project (IANA, Murray Kucherawy) Amy: Murray looked into this and sent email just before he went away. He thinks this should be approved. Is there any objection to approving this media type registration? Hearing no objection, so this is approved and we will send the official note to IANA. 6.3 IETF 114 Important Dates (Secretariat) Liz: These are standard important dates; I'm not sure if anything needs explaining. Amy: This continues the early cutoff for BOF proposals, to give you a couple of weeks to work with BOF proponents if that's still what you want to do as you've been doing for the last year. Other than that they're pretty usual. Lars: If they're usual I'm fine with that. Liz: We haven't changed anything here from the defaults we usually use. Lars: I wonder if we want to even announce the second BOF deadline? That's more like an internal deadline. So those BOFs that got submitted by the first deadline that we think need revisions, for those BOFs we have that revise deadline. There's no need to tell the community there's a second deadline because that just causes confusion about when you have to submit by. Mirja: The original idea was that for the first deadline you only have to register your bof but you don't have to provide all the information, you can still edit and add things before the deadline. That's probably not what's happening. Amy: Generally the BOF call will happen the week after the cutoff date for the proposed bof requests. If you don't have all the information you can't make an informed decision. Mirja: Maybe we should be more explicit about which information we need for the first deadline and what information we need for the second deadline. Amy: I think the second deadline was there so that ADs and IAB members who are interested can work with the proponents to refine what the BOF is actually going to be about. Any information they want considered should be in the original bof proposal at the early date. Things like who's going to chair and conflicts and things like that can wait for the second date but everything that they want the IAB and IESG to consider when making a preliminary approval should be on that first date. Lars: My proposal would be that we actually kill the second date because we have the cutoff date for ADs to approve BOFs, which is by when we need to make a decision. If the ADs have time to review updates from the bofs that weren't rejected by the first cutoff, or by the call. Amy: So you want to keep the May 27 cutoff for proposal requests, kill the June 10 cutoff for revised proposal requests, and keep the June 17 cutoff for ADs to approve bofs? Lars: Yes. because all revisions that happen between that first bof cutoff and approval time are in collaboration with the IAB and under the discretion of the AD. and we would still have the bof call after the first deadline. John: I seem to remember that we talked about putting in a date for I-D submission reopening. Liz: That's still the plan; it requires some separate fussing in the Datatracker. It will be listed but we have to do something extra to add it first. John: Great, thank you. 6.4 [IANA #1229681] Designated experts for RFC 8809 (WebAuthn) (IANA) Amy: This is a new action item for Roman. IANA has proposed a potential expert so once Roman is back he can take a look at that. 7. Any Other Business (WG News, New Proposals, etc.)