Narrative Minutes interim-2021-iesg-14 2021-06-17 14:00
narrative-minutes-interim-2021-iesg-14-202106171400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2021-06-17 14:00 | |
Title | Narrative Minutes interim-2021-iesg-14 2021-06-17 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2021-iesg-14-202106171400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2021-06-17 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Ben Campbell (Independent Consultant) / IAB Liaison Michelle Cotton (ICANN) / IANA Liaison Martin Duke (F5 Networks Inc) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Google) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area 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 Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / Security Area Mirja Kuehlewind (Ericsson) / IAB Chair OBSERVERS --------------------------------- Tim Costello Amy Creamer Bob Hinden Julian Reschke Lee-Berkeley Shaw 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 minutes of the June 3 teleconference being approved? Hearing no objection. I also saw final narrative minutes from June 3; any objections to approving the narrative minutes? Hearing no objection. The last set of minutes we have is the BOF Coordination Call minutes; I received no comments on these. Any objection to approving those for posting? Hearing no objection, so we will get all of those posted. 1.4 List of remaining action items from last telechat o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: I sent Robert a pull request that resolves all the open issues. When he does that I think we can pull that ready to go, unless the IESG wants one more shot at it. I’ll post to the list when he does that and if anybody wants to reserve that right of review, great, otherwise we’re ready to go and we can call this done. I don’t know if that means we should keep this one more cycle or take it off the list. Amy: We’ll keep an eye out for that email and let’s keep it in progress for now. o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to investigate ways to recruit, recognize, and retain volunteers in the IETF. Warren: That’s still in progress. o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs asking them to always confirm author/contributor status. o Alvaro Retana and Martin Vigoureux to draft text to include in the I-D submission tool warning about too many authors. Alvaro: These are both in progress. o John Scudder and Martin Duke to review the document shepherd templates and propose changes to include updated questions and cross-area checks. John: I think I’m still holding the token. Still in progress. o Rob Wilton to draft text to expand the document shepherd write-up section on use of YANG Models. Rob: This is in progress. o Zahed Sarker and Michelle Cotton to draft text for prospective Designated Experts on the basics of the IANA request process and "how to be a designated expert." Zahed: Michelle and I just confirmed that we agree on the text we have, so we plan to send it out for the rest of the IESG to have a look and comment. Michelle: Just a reminder that this is text you all can send to prospective experts, so when we let you know you need to find experts you have something to send them with a little bit about the process and what’s expected. Once they’re confirmed as designated experts we have slightly different text we send them, but this is to gauge their interest and try to reel them in to be experts. Hopefully you find this helpful. We’ll wait for your comments. So this is done. o Rob Wilton to follow up with the IESG on small group project assignments regarding topics identified through the poll taken at the IESG retreat. Rob: I was hoping we could discuss this at an informal. I’ve started sending emails and I think I can close this over email. We can take this off the list. o Eric Vyncke and Francesca Palombini to draft text for guidelines/ best practices for directorate reviewers. Eric V: This is in progress; we’ve already had one meeting and we have another next week. It’s slowly moving. Francesca: I just wanted to say for everyone’s information that I will be adding some pages to the IESG wiki, so I know that’s moving anyway. o The IESG to report on the RFC 8989 experiment. Lars: This is formally for us to report to the community but it’s actually based on data the current and previous Nomcom chair need to gather. After some discussion I think they are off crafting a survey to last year’s and this year’s Nomcom pool to get the data we and they might need to write that report. This is ongoing and I guess nothing really can happen until the Nomcom pool is finalized. Let’s leave it on there and come back to it in a month. o Erik Kline to find designated experts for RFC 9031 [IANA #1198928]. Amy: This is on the agenda for later to approve experts so this is provisionally done. o Murray Kucherawy to update BCP 97 to provide guidance about handling normative references to non-SDO documents. Murray: Not started. I’ll probably have a draft for everyone to start looking at next cycle. o Murray Kucherawy to find designated experts for RFC 9036 [IANA #1199105] Amy: This is brand new for Murray. o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in June 2021. Rob: We haven’t done anything on this. I was just thinking about what we need to do here; previously we’ve given a report in the plenary, and is this the best place we should aim it to? We’re talking about the statistics of drafts published, right? Alvaro: I believe so. I think what we need to do is catch up with...I'm not sure who exactly gave Alissa all the stats she shared before. Amy: That was us. I have updated that same document Alissa was working on. That’s been updated for January through May of 2021. Alvaro: Great, then we have made progress! So we need to go look at the document and say something next time. o Lars Eggert to update BCP 45. Lars: This was basically one of the promises the previous IESG made for when the Last Call experiments closed. BCP 45 is the charter of the IETF discussion list. A couple of weeks ago there was a discussion about what to do with that list in general but it’s been kind of quiet on gendispatch about this so I think I’m going to try again to push this minimal update to BCP 45 that basically says, here are these other lists where some topics that originally were in scope should go. This is still in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-idr-bgp-optimal-route-reflection-25 - IETF stream BGP Optimal Route Reflection (BGP-ORR) (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker, so unless there’s an objection now, this document is approved. Alvaro: I think this is ready to go but can we please put it in AD Followup so I can catch up with a couple of things? Ay: Of course. Approved, Announcement to be sent, AD Followup. o draft-ietf-httpbis-messaging-16 - IETF stream HTTP/1.1 (Proposed Standard) Token: Francesca Palombini Amy: I have a Discuss in the tracker; do we need to discuss that today? Francesca: Thank you all for the comments first of all. I see we have Julian here, one of the authors. Ben, do you want to discuss [now] or do you prefer to take this offline? I’ve seen there are some exchanges on the mail list but I haven’t followed in detail. Ben: I saw that there was some exchange between Mark and Martin and I didn't quite understand all of the points that were being made. I don’t think I'm in the best position to be discussing this particular question, in terms of what's the right change to make in response. From my perspective it’s fine to let this continue to evolve on the email thread. Francesca: The WG also has an interim later today, in six hours. I’m not sure if there is agenda time for discussing this but I would expect that this would be one of the agenda items. If you’re available to join you’re very welcome to do so. Martin D: My discussion with Mark was about semantics; are we talking about the same thing here? Ben dropped my name so I was a little confused. Ben: The other Martin, Martin Thomson. Martin D: Oh, sorry. Francesca: So I think anyway this is going to need a Revised ID. It can stay in IESG Evaluation for now and we’ll continue on the list. o draft-ietf-httpbis-semantics-16 - IETF stream HTTP Semantics (Proposed Standard) Token: Francesca Palombini Amy: I have a Discuss in the tracker for this; do we need to discuss that one? Ben: No, this one I think we have a pretty clear resolution to. I think Mark put out the request for objections, but there’s a default resolution for this otherwise. Francesca: Julian, you can also speak. Julian: Thanks for all the feedback we got in the last seven days. I don’t think we’ve ever had so much feedback before. We have copied everything to our Github repo for commenting so if people want to see how we are progressing with the comments they can look over there. The Discusses are currently processed by Mark mainly but they are not trivially resolvable, so this will take a few days. Regarding what you said earlier about our interim, I don’t think we currently have this on the agenda but maybe they will get onto the agenda because now we have Discusses which we didn’t have a few days ago. I’ll talk to Mark about that. Francesca: I think that would be useful. I put this document on this telechat specifically so if Discusses came up we would have the interim to discuss them. So I guess this will also require a Revised ID and can stay in IESG Evaluation while we clear this up. Martin D: While Julian is here, I made a few comments on this but I eventually gave up because there were so many instances, but there seems to be a real aversion to using normative language throughout this draft. There are a lot of oughts and cans and I just was curious if there was a philosophy behind that or if it’s just that the active wordsmithing has missed some of these cases. Julian: Funny that you mention it, because I talked about that very type of feedback with Mark a few days ago. The main reason is that we are revising something that has been deployed widely and we are very reluctant to make changes and normative requirements which are not really backed by security aspects. So we are changing normative requirements when they are objectively incorrect, but of course there is always some wiggle room and also we avoid normative language when it really doesn’t affect the interoperability. Some of the feedback was why don’t you use BCP 14 keywords in your requirements to people registering new code points, and the answer to that is we don't do it because we don’t use BCP 14 keywords for registration procedures, we just use prose for that. So if you look at the specs we are revising you will see the exact same type of mixture between BCP 14 language and just prose. When we did this project of revising the specs we didn't plan to change that. Martin D: That sounds reasonable. I think maybe two of my comments are along this line; feel free to ignore them now that you’ve explained. Julian: Just to be sure, we will look at every piece of feedback and discuss with editors, but that’s the main reason things are the way they are. It’s not sloppiness, it’s intentional. Francesca: Thank you. So revised ID for this one as well. Amy: Great; this will stay in IESG Evaluation with Revised ID Needed. o draft-ietf-httpbis-cache-16 - IETF stream HTTP Caching (Proposed Standard) Token: Francesca Palombini Amy: I have no Discusses in the tracker, so unless there’s an objection now, this document is approved. Francesca: I believe this will also require a Revised ID. Julian: Just to be clear here, these are three documents who are essentially siblings, so we will revise them all. Approving an earlier version would not be useful for us. Francesca: This will be waiting for the others too, so this will also require a Revised ID. Amy: Okay, so this is Approved, Announcement to be sent, Revised ID Needed. o draft-ietf-payload-rtp-jpegxs-16 - IETF stream RTP Payload Format for ISO/IEC 21122 (JPEG XS) (Proposed Standard) Token: Murray Kucherawy Amy: I have no Discusses in the tracker, so unless there’s an objection now, this document is approved. Murray: I’m chatting with Zahed on Slack and he’s got the same concern that was raised by some other people, which is that the ISO document to which this refers normatively is not actually visible for review. It’s up to him whether he wants to place a Discuss and hold it until we get a copy. I encouraged him to do it, because this is not the first time this has come up recently that there’s something behind a paywall and we get asked a bunch of questions about it. So at minimum it will be AD Followup but it’s up to him. Zahed: I basically raised the question of when this was done in the WG, was it made available to the WG? Even if we are talking about packetization, the document is written in a way that defines some terminology which asks me to read the specification, and I cannot read the specification. So I don't really know if what they are defining is true or false or what. Ben and I talked about it and there was some unintended error in the VP9 payload which might have been crashing the whole thing. Either you don’t define the terminology you want me to read, you write it in a different way, or you make it available. I don't know what we should do. My other colleagues are fine with reviewing it so I didn't put a Discuss but I can put a Discuss or defer on it and try to see if the specification could be made available to us. Murray: I’m fine with however you’re comfortable handling it. I would note that two other ADs chose not to block it but also pointed out that this is a thing, and if three of us are saying the same thing, this is maybe someplace we should push back a bit. I’m fine with however you want to handle this; defer, discuss, or doing neither and leaving it to me to follow up is fine. Zahed: If you want to follow up that’s fine. Murray: If I take the token to follow up, the ballot will close. That's why I'm wondering if you should do something instead. Zahed: Okay. In that case, I would like to defer. Can I do it now? Murray: Defer will force it onto a telechat later and i don’t know if that’s necessary. Maybe Discuss is the better thing to do. Zahed: Okay; I’ll put a Discuss on it. Murray: So because of the Discuss, AD Followup is probably the right disposition. Amy: Great. So it will stay in IESG Evaluation and go to AD Followup because of the new Discuss. == Ben: Can I jump in? I failed to mention during the HTTP document discussion, but I was a little surprised that we didn't have a conversation about progressing these at Proposed Standard vs at full Internet Standard. I saw in the shepherd writeup for [draft-ietf-httpbis-cache], Martin Thomson had implied that it should be going for Internet Standard, but the datatracker lists all three as going for Proposed Standard. I wasn’t sure if that was something the IESG should talk about or if there’s a story there. Murray: I suggest that because the messaging is inconsistent we ask them and make it a management item next time. Warren: We do this so seldom I’ve forgotten the process. Does it require anything like an IETF Last Call if it goes PS to full? Ben: I think we would specifically want to have a last call that indicates it’s going for IS. Alvaro: I think so too. Warren: To me it sounds like this is one of the few times when it’s clear something probably should be an actual standard. John: I presume others would also want to give it a quick eyeball again looking at the different requirements for full Standard. Francesca: Julian, do you have the background there? I admit I’m missing the background so I couldn’t answer you, Ben. [pause] Maybe he has left. I will talk with the chairs and authors and come back with that. Thanks for raising it. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items NONE 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Oblivious HTTP (ohttp) Amy: I have a number of blocks on the charter. Francesca: This is a WG that is supposed to be in the Security area, with an ART AD, so I will be the responsible AD. This is a collaboration with Ben and Roman. We have a number of Discusses and I've seen a lot of mail coming in. I wanted to mostly talk about the fact that this should really go for a BOF. In general, I want to hear what you all have to say about that and if you do all think this should go for a BOF I’m willing to reconsider. I wanted to explain why it hasn't gone to a BOF in the first place. This has been discussed on various mailing lists and it has been presented in SECDISPATCH, so it has been presented to the community and discussed. We made a judgement call with Ben and Roman and we thought the discussion was supportive enough of the work and the scope was clear enough that WG was okay. If the comments now are saying the opposite I'm willing to reconsider but I wanted to just bring this forward and also I don’t want to delay things too much when it’s not necessary. I’m not saying it’s the case this time, it might be the case that we need to delay to clarify the scope, but i wanted to say that if we don’t accept to create WGs from items that are dispatched from SECDISPATCH, DISPATCH, other dispatch WGs, then we should all agree with that. My personal understanding was that it’s totally reasonable for an item to be dispatched to a WG via dispatch without needing a BOF, and now I'm getting this feeling of resistance. Lars: It’s possible to go to the dispatch route, and we often do, but sometimes the consensus in the dispatch groups isn't the consensus of the IESG or the broader IETF and I think this might be a case like that. Francesca: I’m talking about the general case rather than this case. This might be a case when a BOF is a better route. It was confusing because we got some comments coming in before it was sent for external review, so this is only an internal review, but discussion has started. Ben: I think this protocol proposal is not changing http, it’s just something on top of http the same as all the other things we do on top of http. Just because you’re not changing the core technology, that doesn’t mean we should clearly do it in the IETF. Obviously the things we want to do in the IETF need to be good ideas in their own right if we’re going to claim IETF consensus for them. But I'm a little confused about the opposition because in this particular protocol scenario you really need cooperation among all the three parties in order for it to be workable, the client has to trust the proxy and the origin server has to trust the proxy as well. You can’t use this protocol with unrelated parties that don’t have a prior relationship. In that sense, this is documenting something that all consenting parties opt into and it’s not clear that we need to be super reluctant to take on that sort of work because we don't expect there to be harmful impacts on bystanders. Eric V: As I was the first one to raise a block on this, I think my position is not so much about the work itself, even if I have some questions there. Basically it’s coming mostly out of the blue if you didnt attend SECDISPATCH, and maybe it was discussed in HTTPBIS. But also it’s quite fuzzy. There is no explanation, no context. I’m pretty sure other people will have comments as well. I really believe on this one it’s too vague and should be analyzed by more people. A BOF is really the way to go. About the delay, I don't buy the argument, one point being we can still progress on the document itself. Everyone can do it and we can adopt it later. So that’s one point. And I've never seen that we need to rush a document because of delay. We would love to get a short delay, but as a reason to bypass this? I don’t buy it. Francesca: It’s not about delaying the document. I don’t think there’s an absolute hurry to publish this document. It's more about delaying the work getting started. It’s more that this had started being discussed in January and it’s now June, and it has taken a while to get the document to SECDISPATCH and then it has taken a while for us ADs to figure out how we want to deal with this after we heard the community. I don’t necessarily disagree with you that a BOF might be a good thing, especially if we get more comments about the scope of the charter. If the charter is not as clear as I thought it was, then maybe a BOF to discuss the charter and its scope would be better than an endless external review. I’m not disagreeing with you but I just wanted to point out what I think delay means. Lars: There’s another option, since this is an internal review. We could do a slightly unusual external review and send it out and ask the community if they believe a BOF in this space is warranted. Then we could make the decision when that comes back. We don’t have to do it now, we can ask, if you feel that’s helpful. If the answer is yes there’s no delay; the answer is no we don't need a BOF, we all understand and this should go forward. I'm guessing if that would be the community feedback the IESG would probably charter it. Francesca: What worries me is that today we are supposed to approve the BOFs. it’s more of a process thing. If we do send out this call…. Lars: We can block a slot for it, either for a WG or a BOF, and we can return the slot at some future time. That doesn’t necessarily need to be a concern. Francesca: Are you saying we would unblock this, send it out an email -- Lars: It’s up to the block holders. At the moment it can’t go out for external review because there are blocks on it. One proposal would be to ask the people holding the block if a way forward into external review would be to make part of the external review on the question of whether a BOF is needed or not. If the answer is no, we continue to discuss more. If that would lift the blocks we could do it and then in two weeks see what the broader community has said, and then either it goes to BOF or it goes to WG or we give back the slot because it’s so conflicted we don’t know what to do. Rob: The people that I’ve asked about this in the ops area were not’ aware this was happening; they've all suggested that having a BOF is a better way forward. There was someone else I asked in the security area and she also said she thought in the SECDISPATCH meeting she thought it was a bit premature to go straight to a WG and she suggested a BOF as well. The people I've spoken to seem to be saying a BOF is a good idea. From my perspective, my concern is to do with how DOH landed on the ops community. I don't think they're necessarily that happy about it and this seems to be a further step towards that in terms of increasing privacy in that area, and from an optics point of view I’d like to have that discussion earlier on and make sure the community has had a chance to say, rather than have that later in the process. That’s where I was coming from, that it’s safer for everyone if we have a wider discussion first. Warren: I didn't ballot, but I largely agree with what Rob said. I think a number of people have never seen or heard of this before and will be very surprised if there’s suddenly a working group. Francesca: I understand that, but isn't that part of the external review, to gather the community feedback? This is going against what I was saying before, that we’re not allowed to charter a WG from dispatch, because dispatches are not attended by everyone. As dispatch chairs we ask the authors to please try to make this available for the whole community and the authors have done that and forwarded it to WG mail lists they think will be interested. I understand the concern for this document, and I'm willing to go for a BOF if you think that’s the best way to solve this, but I think this might come up again. Martin D: Francesca, could you say some words about why this didn’t go into HTTPBIS? We wouldn't be having this discussion if we’d just put it in as a WG document. That’s why I'm stumbling over the BOF requirement. Francesca: I'll have to go into the details of the SECDISPATCH minutes and also to the thread in HTTPBIS. Martin D: We don't have to do it in real time. I’m of two minds about this. I think having a BOF is actually five weeks of delay. If we do it this way -- Francesca: If we can get the BOF for the next IETF there is no delay, in my opinion. The BOF will be about the charter, rather than the meeting being about the draft itself, but-- Martin D: But on the other hand, if this had just been adopted by HTTPBIS I wouldn't have blinked at all and we would have had none of the outreach people are complaining about. I would be fine with either outcome, I don’t think it's a huge deal which one we do. I do think there are some problems with the wordsmithing in the charter, but I am confident from the email exchanges and Martin Thomson’s draft that they actually know what they mean and all these questions actually have answers, the charter just needs to be rewritten to reflect those answers and tighten up the scope. But I don't think there’s confusion on what they’re actually trying to do among the proponents, it just needs to be written up better, in my personal opinion. Zahed: I think I got the whole process thing a bit wrapped up in my head. I saw this one as a BOF proposal in the wiki and then I saw there was a ballot for external review and I got confused. In the slack I asked what’s going on, and that was the reason. I thought this was a BOF. Francesca: Let me clarify. This was not for external review, it was just internal review, and the mail got forwarded. Apparently that’s the way it is, the mail gets forwarded, and the community is already aware that this is for internal review. The reason there is a placeholder in the BOF wiki is because I was told to do that by the secretariat to schedule it into the 111 meeting. I did write that there is a charter. Zahed: Having said that, my comments were not really about BOF or not. It was more that I didn't really follow. I read the charter and my judgment call is that I'm not really sure what’s going on. The charter went very low on the context of it. What’s going on? I know the technology, I work with http things, so I can read a lot between the lines, but the charter should not let me read between the lines. It should be pretty clear. Especially if it’s coming from a dispatch, i think it should be much more on the background, much more giving examples, much more on the context to the reviewer saying this makes sense. Obviously I think the other comments we are getting is basically because it touches on different layers, not only on the http layer, and I think that makes some of us maybe a bit concerned. But my block was not about BOF or no BOF, it was about clarification in the charter text. Francesca: Okay. So what I'm getting is that the charter is not clear. I have seen that the proponents have been trying to answer emails. If that still doesn’t help I'm not against going for a BOF and i would like to have the BOF at IETF 111. Martin, I agree with you. Martin D: I want to be clear here, I think their answer is completely satisfactory. The email replies have cleared up all the problems. The issue is that it needs to be in the charter. The answers are out there, they're just not written down where they need to be. Francesca: So if I manage to work with them to update the charter, you would feel that would be satisfactory for you? I think others have said no. Eric would prefer a BOF. Eric V: I’m sorry but I think it’s quite a touchy topic, having possibly multiple impacts, and we are five weeks from the BOF. I don't see the opposition to run the BOF. We can still work on the charter, of course, that’s no problem. They can still work on the document. If the BOF and the charter are okay we can approve it in a matter of weeks. If we want to say wait until November, this I understand is not too good. But we can work on it. Francesca: Rob, you also had a discuss. Rob: My thoughts are the same as Eric. I think holding the BOF is safer for us and it doesn’t look like we’re pushing this through. I think we can have a BOF at 111 and work on the charter at the same time, and I have no issues if they have a side meeting at 111 as well to discuss the document. I just think having the opportunity for people to comment is the best thing. I don't mind removing the block to ask people if they want to hold a BOF but I think that would slow things down. I think we should just do the BOF. Francesca: Ben, what do you think? I’m the responsible AD but this is in the security area. Ben: I personally don’t think we should need to have a BOF. I think the intended scope of the work, even if it's not very clearly defined in the charter text, the intended scope is such that it should be able to go ahead. On the related topic, I think we should be able to progress to chartering directly from a dispatch outcome without having to go through a BOF. I think you touched on how it’s not always going to be reliably that case and there may be some situations when having a BOF is the right thing to do even if dispatch recommended to go straight to a WG. But the flip side is that I don't have an argument that can override the concerns people are raising. We do have blocks from other IESG members that are presenting reasonable arguments a BOF is the right thing to do here and I don't have any reasoning that would contradict that in a clear and strong way. So from that sense it seems like we’re going to be doing the BOF because we have AD objections and we don’t have reasoning to claim that the objections are not valid. Francesca: I understand you are agreeing with going ahead with the BOF and hopefully we can approve the BOF today together with the other BOFs. Ben: Right. Francesca: And again, I'm fine with this and I think the proponents are mostly fine with it. I’m not going to speak for them, they might not, but I’m just concerned in general if items coming out of dispatch, this could apply to any item coming out of dispatch. Dispatch is usually attended by people in a certain area. Rob: On that point, i definitely think it should be okay for dispatch groups to be able to create WGs, but I feel that that’s the case when the charter of the WG is clearly tied to that area. In this case it feels like it potentially spans, or impacts, more areas. That’s the reason why I feel that a BOF is helpful. In the general case I have no issues with that. Francesca: Thanks, that’s helpful for me. Zahed: I completely agree. I don't think you need to worry about it. Whenever it’s cross-area i do believe people need to have a wider view. That’s what external review is for. This is a special case, this is not an example. Francesca: I'm okay with this also because if ADs have concerns, this will come up in external review of the charter and that might delay creating the WG even further, while a BOF might actually solve the problem. So I'm happy with this. Thank you. Amy: Okay, so it sounds like the OHTTP charter is sort of on hold. We’re not approving it for external review so we’re going to wait until we get instructions on that. Francesca: And we should add OHTTP to the list of proposed BOFs for IETF 111. Thank you for the discussion, everybody. 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 Martin V: Not much. IAB got an interesting talk yesterday from Wes on root servers, but beyond that not so much news from IAB. 6. Management issues 6.1 [IANA #1197180] Renewing early allocations for draft-ietf-bess-evpn-optimized-ir (IANA) 6.2 [IANA #1197184] Renewing early allocations for draft-ietf-bess-evpn-ipvpn-interworking (IANA) Amy: This early allocation is about to expire. Michelle: Just to remind everybody, we had this on the prior telechat but it was requested to wait and bring it back because Martin wasn’t with us. I think there might have been questions about if this was actually going to move ahead. Martin V: The first draft is about to enter IETF Last Call. Michelle: That’s good news. Amy: Are there objections to renewing the early allocation for this document? Lars: I think we pushed this and another BESS document because Martin wasn’t here. One of them we saw was coming very soon and the other one looked like it was further away. I think that’s why we decided to move them both. This must be the one that’s closer to us. Martin V: This one is closest to us. The ipvpn-interworking is about to enter WG Last Call. Lars: Okay. Thank you. We were just wondering when you weren’t there. It sounds like we can just approve them and hope we’ll get them soon. Martin V: In BESS, the WG tends to do early allocations pretty early, so we have to renew them at least once, often twice. Hopefully the documents reach us in time. Amy: I’m hearing no objection to renewing the early allocation to both of these BESS documents, so it looks like both of those can go on to IANA as approved. 6.3 [IANA #1198995] Acceptance of media type registration from standards organization ISO/TC 184/SC 4 - Industrial Data (IANA) Amy: This was also placed back on the agenda from last time and I think this is only here to minute that this specific ISO instance is approved. Is that correct? Michelle: Yes. I did want to mention that we got a response back from Barry, who was involved in the first ISO approval we did. It was his opinion that ISO as a whole should be added. I just wanted to throw that out there. I know we had quite a bit of discussion last time that it should just be the subcommittees. I just wanted to let you know what his opinion was there and see if it changes anybody’s minds about ISO as a whole vs. only adding subcommittees. Murray: I don’t think I know enough about the structure and politics of ISO to be able to say either way which is the best path. Warren: I think we decided last time that we don't get very many of these so it’s not particularly onerous for us to approve one at a time. If there was a huge spike and we were getting a lot of them we could always reconsider. Michelle: That sounds reasonable, that if there’s an uptick in requests from ISO then we can revisit. This is just to officially put it in the minutes and you can send us a message and this will be done. 6.4 IETF 111 BoFs decisions (Secretariat) Amy: We have four proposed BOFs that have been provisionally approved and this is now your opportunity to approve them for scheduling. Eric V: I was about to say, about MADINAS, we got a couple of comments two weeks ago that I shared with the proponents and the potential chairs. They modified the draft charter, so they moved something there. Martin V: Should I go on APN? You heard the very brief summary and you saw my message a few weeks ago following the APN interim, so I won’t go back on that, but I think in general it was useful. For the last few days we’ve worked with the proponents and the BOF chairs. I don't know if I'd given you the name of the BOF chairs, Adrian, Bob, and Daniel. We’ve worked with the proponents and the BOF chairs to draft a quick first version of the charter. Please don’t take that as a definitive version of course, but it was really for having something in the wiki for you to see. It’s been uploaded in the wiki since yesterday and you can take a look at that. I believe the consensus in our previous call was to approve that BOF and i still believe we should because i think it's time to have that discussion. I do have some outstanding questions as AD, whether that best fits in RTG or in INT, because I know Eric V is particularly fond of that technology and wants to be their shepherding AD. That’s a real question, where does it fit best in INT or RTG? If the WG gets formed, where will the technology be developed? For example if they are a data plane extension impacting ipv6, should that be done in 6MAN or that WG? Same for MPLS and and for NVO3. The same question applies to the protocol extensions, PCE, BGP and so on. These are questions I will expect during the BOF to get feedback from the community. So unless anyone strongly disapproves I believe we are good to go. Amy: I know renaming it had been discussed, is it staying APN? Martin V: I’m still working on finding a good name. I originally thought there would be some opposition from the proponents to rename it but they are not completely opposed. I’m working on finding a good name, particularly removing the application because that’s the one causing concerns. Amy: Do you have an ETA on a new name? Because to put it into the scheduling tool we need a name and acronym attached. Martin V: What’s your deadline? Amy: Tomorrow. Martin V: I’ll do my best. Amy: I’m not hearing any objection to approving APN, so it looks like it’s approved pending a name and acronym change. Please let us know as soon as possible. Moving back to MADINAS, I also didn't hear any objection to that so it looks like MADINAS is also approved to go forward as a BOF. Regarding DANISH, I hope Roman left some instruction with someone; Ben maybe? Ben: I’m pretty sure we want this to go forward as well. I have some text from him. We should go ahead with this and consider it approved. Amy: Okay; unless there’s an objection, it looks like this one is approved. You’ve got some conflicts as TBD but we do have BOF chairs identified, so that will help. That brings us to OHTTP. From the discussion of the proposed WG it sounds like the BOF is definitely a yes, so unless there's an objection it sounds like OHTTP is approved. Lars: Is there anything you need to do in the datatracker to make it flip over to being a BOF? Amy: I think we just move it from PWG to BOF. I think that will do the right thing. Lars: That’s something the secretariat needs to do, right? Amy: You may have the permissions too, but we’ll take care of it. Francesca: Process wise, because I put all the information in the wiki, is there anything you’re missing? Amy: BOF chairs need to be named. Francesca: Okay. I will try to. Ben, I hope you can help me with that. Amy: That’s for all of them; if they’re not in the BOF wiki, we do need chairs attached. Francesca: This also has a deadline of tomorrow? Amy: No, you have more time for the chairs. Getting it in the datatracker for a scheduling request, you already did that piece. So this is ready for scheduling and Liz has the information. BOF chairs can come later; we generally want those the week before the meeting at the latest. We’ll start hassling you for those in about three weeks. Amy: Okay, I think we know what’s going on with the BOFs and we have four of them. Eric V: When I saw the BOF wiki, I saw a last BOF request from SCIM at the complete bottom which is mostly empty. Amy: Oh, this is new. Eric V: I don’t know when this came in. Amy: Did anyone add this System for Cross-Domain Identity Management as an Other Session, not in an area? Lars: What does the history say? Pamela Dingle at microsoft.com added this, apparently. Ben: SCIM is a somewhat well known thing in the web identity security space. Erik K: The responsible AD would be from Security then, Ben? Ben: Probably. Amy: They’re a proponent and they put themselves in as a BOF chair. This sort of sidestepped the process for talking about a BOF. Cindy: Also, SCIM was originally an ART area WG that concluded in 2016. Warren: Is that the same SCIM? Ben: Yes, the proposal is referencing the existing RFCs. Lars: This was done six days ago, did they make the timeline? Warren: Its acronym is SINS, it kind of seems like we have to approve that acronym. Francesca: The approval deadline is tomorrow but wasn’t the request deadline the 11th? Lars: It was the 11th, yes. It was submitted on the 11th at 5 pm UTC. So they did make it, they just didn't tell anybody about it. Which is a great example of why we shouldn’t have the BOF call with the IAB before the final deadline. Warren: However, while what they did was wildly suboptimal, they didn’t actually do anything wrong. Lars: They should have told the AD at least. Warren: Definitely they should have. But if it’s trying to do more stuff with something that was an existing WG, it’s possibly not completely crazy, having no idea what they really meant. Lars: My suggestion would be for the SEC ADs to reach out to the proponents immediately and try to figure out what this is by tomorrow. Warren: Is it definitely SEC? Because someone was saying the original SCIM was in ART. Amy: They’ve also put in chair conflicts: none, technology overlap: none, key participant conflict: none. Ben: They have some links in the BOF wiki, including a github page which claims they’re having biweekly meetings and they're using the IETF SCIM mailing list. Lars: Which I guess nobody is still on? Martin D: Should we have an emergency BOF coordination call tomorrow, when someone has read this and understands where they’re at? Lars: There have actually been quite a few mails on the SCIM mailing list. Francesca: This is non-WG forming. Warren: If it’s non-WG forming, it’s continuation of existing work, and there have been emails about it, I'd likely say ‘why not.’ Lars: I’d still like to have ADs to reach out because i don’t recognize any of the names that are participating in this discussion. Warren: I was meaning, if the SEC or ART or whoever ADs think it’s reasonable, I’ll bow to their better judgment. Lars: That seems like a good approach. Francesca: Does this have enough input even? I see just a bunch of links but I don't really understand the motivation behind having this meeting. Lars: I think that needs to be found out. Rob: Maybe we should remove the “Other Sessions” part of the wiki and force people to put it somewhere else? Warren: Maybe we shouldn’t have an “Other Sessions” area. Eventually this will all go in the Datatracker. Ben: One potential question here is what do they gain from being an officially scheduled BOF vs an unofficial side meeting-like thing? I guess the theory would be to get more visibility, but I don't have a great sense for who would show up to a BOF. Lars: All of these require someone to talk to the proponents. Erik K: People who were involved in SCIM the first time around, presumably? Ben: We don’t really have enough information to make a decision right now, so we need to find a stuckee to reach out to the proponents and find out what the story is. Lars: Leif Johansson was one of the original SCIM chairs, Alexey was the AD, and I don't recognize the other name Morteza. We could figure out if Leif and Alexey at least Ben: Morteza is a known quantity but I think not really active in the IETF anymore. I’d considered making them a designated expert but I got some feedback that they’d retired, basically. Eric V: Other than the fact that we are falling out of the sky with this proposal, it looks sensible to have a BOF on this. The format is not correct, and the way they did it is suboptimal, but I see no problem. Martin D: This is obviously a shortcoming of both our process and our tooling, that there’s no second meeting or notification. The proponents seem to have done the minimum, but met our requirements to be considered. Maybe we can just pencil this in the schedule and punt the decision, waive our own deadline so we have some actual time to discuss this? I think the driver is Liz and we can decide later than we normally would. Lars: Cindy has a point though that we need a new acronym. The datatracker doesn’t like to reuse acronyms. Warren: It’s SINS; SCIM Industry Next Steps. That’s a new acronym. I don’t think they’re trying to reuse the existing one. Ben: We don’t even have much indication about how timely it is, if this would be a big deal to do this at 112 vs 111. Amy: Usually when you have all of these types of questions for something, usually BOFs don't get approved, they get shunted to a side meeting. I don’t know that we’re going to answer all the questions you want before… Rob: My concern is, if they’ve met the deadline, we still need to go through the process to evaluate it. Otherwise they've in theory met the deadline but we reject them because it wasn’t the deadline we wanted them to meet. John: Considering that they have no chair conflict, no technology overlap, and no key participant conflict, what’s really the difference between a non-WG forming BOF and a side meeting? Warren: How many people see it. Amy: It’s on the official agenda. John: Isn’t there a cap on the number of non-WG forming BOFs you can have on a topic? Or is that for WG-forming? Rob: I thought it was five for Covid times. Francesca: It gets time on the official agenda but it has conflicts with nothing so we don’t even know… John: If they don’t have any conflicts with anything, that means they think they can be scheduled any time at all, and it doesn't seem like telling them to have a side meeting instead of a BOF would be that onerous. Alvaro: I agree with what Rob said before, unless we really go through the process of examining what they want to do, we should approve, because they met the deadline. Now we can have a bunch of people submitting the last day and we’d have to approve everything. Warren: The other option is we could do a better job of checking the wiki page at the deadline date. This was our failure. I’ll admit it didn’t occur to me to look. Lars: I did look on the wiki page but I didn't see it because it was all the way at the bottom. Francesca: There’s also no responsible AD suggested. Warren: We’ve approved ones before that are at least this messy. Lars: My suggestion to make progress on this is that the ADs of the areas it might fall into reach out to them now and see if there’s any more material to be had. We can tell them look, you added it on the last day and you didn’t tell anybody; we’re trying our best but it might not get approved simply because we don’t have enough time to evaluate. If we get something within the next 24 hours we can talk again tomorrow. Martin D: In lieu of the informal next week can we have a coordination call with the IAB? Liz: We’re doing conflict resolution at the informal next week, because the preliminary agenda is published next Friday. It really should be decided before next Thursday. Alvaro: Unless we get something in the next 24 hours, we can’t approve anything, because we can’t go through the process. Eric V: To gain some time, whoever is contacting the proponents can put the IAB and IESG in CC so we can see the replies. Lars: Do we have a volunteer to write email on this? Ideally someone from the US who still has a bit of time in their day left? [long pause] I can send an email to them tomorrow saying we didn’t see it in time and unfortunately it won’t be approved. Unless i see an email on the IESG list indicating that somebody contacted them before i get back to work tomorrow. Amy: So SINS I guess is in a gray area and we will continue on with our next management item. 6.5 [IANA #1198928] Designated experts for RFC9031 (Erik Kline) Amy: Erik has identified two possible experts for this registry. Any objection to approving these two, Malisa Vucinic and Michael Richardson, as designated experts? Hearing no objection, so we will send official note to IANA. 6.6 [IANA #1199105] Designated experts for RFC 9036 (IANA) Amy: Murray was assigned to this action item at the top of the call. Murray: I’ve already got a candidate, but we can do it next time. 6.7 Finalization on blog on "Unofficial side meetings at IETF meetings" (Lars Eggert) Lars: I don’t think we can finalize it yet because there are comments in the Google Doc that I don't think Jay has seen yet. We’ll try to finalize this by email. I think this stuff is relatively minor but I want to give Jay a chance to take a look, since it’s his text. 6.8 [IANA #1199760] Renewing early allocation for draft-ietf-idr-bgp-ls-sbfd-extensions (IANA) 6.9 [IANA #1199761] Renewing early allocation for draft-ietf-idr-bgp-ls-app-specific-attr (IANA) 6.10 [IANA #1199764] Renewing early allocations for draft-ietf-idr-bgpls-srv6-ext (IANA) Alvaro: [These three] are all in the same boat. They’re all BGP extensions and all three are in my publication queue. All three have implementations; IDR requires implementations for everything. We should renew all of them. Amy: Any objection to approving the renewal of early allocations to all three of these? I’m hearing no objections, so we’ll send official note to IANA. 6.11 [IANA #1199765] Renewing early allocations for draft-ietf-lsr-dynamic-flooding (IANA) John: There’s implementation of this and they are planning to Last Call it soon, so it should be renewed. Amy: Any objection to approving the renewal of early allocations to this document? I’m hearing no objections, so we’ll send official note to IANA. 6.12 [IANA #1199786] Renewing early allocations for draft-ietf-idr-bgp-ls-flex-algo (IANA) Alvaro: This is almost the same as the others. This one already passed WG Last Call; it was actually already sent out for publication but I returned it because the corresponding ospf document is not out of the WG yet. So we’re waiting for that, but there are implementations of this already and we should renew this one too. Amy: Any objection to approving this? I’m hearing no objections, so we’ll send official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Martin D: I’ve agreed to be the stuckee on this SINS thing because it’s the right thing to do to not leave these people hanging, but I don't know anything. I’m soliciting what this email should say exactly. Do we want to discuss this verbally or on slack? Lars: Even for a non WG forming BOF, we’d want to have a little more information about what the new work would be. There’s a small presentation of new work for feedback from the larger group, but some indication of what it actually is that they might want to do if a WG is formed, and what it might take to get there. The other option is AD sponsored but it might not even need a WG. Francesca: There might be other options, like dispatching. My question would be what Eric wrote, which is why is this different from a side meeting? Martin D: Let’s just say they’re incredibly responsive and we iterate very quickly. What is the timeline here on how quickly things need to happen? Let's say this sounds super interesting and we want to discuss it with the IAB. In fact, I'm going to add the IAB to the thread. Do we need to have all the information by Tuesday? Wednesday? We can pencil it in to the schedule. Liz, when is it that we release the provisional schedule to the community? Liz: That’s on Friday the 25th. Martin D: So we have to absolutely decide by next Friday. Eric V: We should put the pressure on the proponents to say please reply by Friday midnight UTC. Lars: Their charter has actions to talk to an AD, and make acquaintances in the area, and all this stuff they haven’t done but put into the wiki. I don’t know if they ran out of steam or what. It seems like they know what they should be doing but they haven’t done it. Martin D: Is this in the wiki or in the github? Lars: There’s a link from the BOF page to an interim version of the charter which is not on github. ‘Collaborative HackMD version’. That one has other stuff in it. Francesca: Could you also make it clear, Martin, that if we don’t have enough information we might need to reject the BOF for now and possibly ask them to request it for next time? Martin D: I’d really appreciate if the people who actually know something about REST and security participate in the thread. I’ll get it started but I'm going to be out of my depth pretty quickly. I’ll start a separate thread without the proponents with the IAB to try to identify a time for this meeting if we need it. Does that sound acceptable to everybody? I think we need to have two BOF coordination meetings per cycle, but that’s a separate issue. Eric V: It’s assumed those won’t be used anymore when we use the BOF feature in the Datatracker, right? Amy: I believe the BOF feature of the datatracker will automatically send email to folks when things are added, so we won't have this surprise when that’s ready. Francesca: One more thing. I wanted to get your opinion. I have this SEDATE WG that is now in external review and I've got some comments, more than I expected, so the charter is getting worked on with the proponents and the people who have comments. My question is more of a process question. I've put in a placeholder for IETF 111 because I think this should get chartered by then, but what happens if it doesn’t, or if it doesn’t clear all the steps? Amy: They can still meet. You have now two formal telechats, you’ve got July 1 and 15. It’s in external review now so the next step is approval, and if it doesn't hit approval on the 1st it can still come back between the 1st and the 15th and be approved. They can still meet during 111 and if the proposed charter is approved they just meet as any other WG. If it’s not approved maybe they can use that time to fix the charter to get approved, but you have two formal telechats before 111. Francesca: I was just wondering what if it doesn’t. Thanks.