Narrative Minutes interim-2021-iesg-01 2021-01-07 15:00
narrative-minutes-interim-2021-iesg-01-202101071500-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2021-01-07 15:00 | |
Title | Narrative Minutes interim-2021-iesg-01 2021-01-07 15:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2021-iesg-01-202101071500-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2021-01-07 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1.1 Roll call ATTENDEES --------------------------------- Deborah Brungard (AT&T) / Routing Area Jenny Bui (AMS) / IETF Secretariat Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Roman Danyliw (CERT/SEI) / Security Area Martin Duke (F5 Networks Inc) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Wes Hardaker (USC/ISI) / IAB Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Loon LLC) / Internet Area Magnus Westerlund (Ericsson) / Transport Area Martin Vigoureux (Nokia) / Routing Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Alvaro Retana (Futurewei Technologies) / Routing Area Amy Vezza (AMS) / IETF Secretariat Eric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Jay Daley / IETF Executive Director OBSERVERS --------------------------------- Nick Banks Mike Bishop Chris Box Rob Brown Lars Eggert Adrian Farrel Brenda Lyons David Millman Lucas Purdue Rene Struik Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything to add to today's agenda? Any other changes? Hearing none. 1.3 Approval of the minutes of past telechats Amy: Does anyone object to the approval of the minutes from December 17? I'm hearing no objection. Any objection to approving the narrative minutes from December 17? Hearing no objection to approving those either. 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 have a version out for review. Alvaro and Barry have been commenting and I just sent it out to the whole IESG and I'll also remind Sandy and Michelle to look at it, so everyone finally has something to review. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Alvaro: We haven't made progress since last time. We're going to pick up the discussion and probably include Warren, in the next week or so. o Roman Danyliw to draft text for a request to the Tools Team to move BoF requests from the BoF Wiki to the Datatracker. Roman: I haven't done anything since we last spoke, I'll pick this up now in the new year. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. Alvaro: We also haven't done much on this one, we should pick it up soon. o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the process for using EthicsPoint incident management software as the mechanism of private feedback and anonymous reporting. Martin V: I haven't worked on this for the past few weeks, I need to pick it up again. Let's keep it in progress. o Erik Kline to find designated Experts for RFC 8915 [IANA #1179647]. Erik K: No progress. o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to investigate ways to recruit, recognize, and retain volunteers in the IETF. Warren: This one is actually still in progress. Not a huge amount of updates since last time but we have met since the last telechat and we've reached out to a couple of other organizations to ask how they interact with their volunteers and help recognize them. o Erik Kline to find designated experts for RFC 8928 [IANA #1183445]. Erik K: In progress. o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035]. o Ben Kaduk to find designated experts for RFC 8879 [IANA #1184206]. o Ben Kaduk to talk to Kathleen Moriarty about status of draft-seantek-ldap-pkcs9 Ben: All three of these are in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-emu-eap-tls13-13 - IETF stream Using EAP-TLS with TLS 1.3 (Proposed Standard) Token: Roman Danyliw Was deferred by Benjamin Kaduk on 2020-12-16 Amy: I have a couple of Discusses in the tracker for this document; do we need to discuss any of those today? Roman: I think there's two flavors of Discusses. One is around the binding to the TLS WG, and I think we need to keep talking on the list to resolve that. Our discussions here aren't going to resolve that, so thank you Ben for bringing that up. I guess I wanted to talk with you though, Robert, on your more process editorial related set of feedback. I sent something three minutes before the conversation so I think the bottom line is, the way we talked at the last telechat, we don't have common semantics on "update." I don't disagree with everything you're saying in terms of the clarity we'd get with streamlining, but there's a bunch of work associated with that and since we don't have common semantics, it seems to me at least that it's a nice-to-have, not a need-to-have. Rob: I think the key one is actually whether the previous document should be obsolete or not. Obviously by it being an update to it, you can't obsolete the one that's got a dependency on TLS 1.2. Roman: Right. Rob: So is that something we want longer term, to have the one that relies on TLS 1.2 hanging around and not being able to be obsoleted, when TLS 1.2 has been obsoleted? I guess that's the key question. Roman: I don't know whether we have the WG feedback that we're obsoleting it despite the fact that TLS 1.2 is obsoleted, in terms of the cascading effect on EAP. Rob: But presumably we can't obsolete this document if we're updating it for TLS 1.3. That's the bit that doesn't make sense to me, if this is the one going forward, and updates that one that we then obsolete, doesn't that by definition mean that the one for TLS 1.3 would end up being obsoleted? That's my main concern. If it's that this is too much work to change and it would be too hard to do, fair enough, I'm not going to block on this. But it does feel that it's going to be probably confusing and potentially causes issues longer term. Roman: I'll take this offline with you. I guess I'm missing something here and it'd probably be more efficient to address it offline. Rob: Okay, that sounds fine. Roman: I think we're good, in terms of talking about this document. Amy: Is this going to require a Revised ID to clear those Discusses? Roman: I think it will, yes. Amy: Okay, this will go into Revised ID Needed. o draft-ietf-tls-external-psk-importer-06 - IETF stream Importing External PSKs for TLS (Proposed Standard) Token: Roman Danyliw Amy: I have a Discuss in the tracker; do we need to discuss that today? Roman: We do not. I think that's good feedback. I think we're going to need a Revised ID here. Amy: Okay, this will stay in IESG Evaluation with Revised ID Needed. o draft-ietf-quic-transport-33 - IETF stream QUIC: A UDP-Based Multiplexed and Secure Transport (Proposed Standard) Token: Magnus Westerlund Amy: I have a few Discusses here; do we need to discuss any of those today? Magnus: I think we could spend a little time to just check where we are on things. Let's start with Ben's. Ben: I was trying to take some notes in the earlier part of the call. So I think I got some good responses from several people, actually, and probably things would be better if some of the information that came out in email could make its way into the document. In particular, to summarize my current understanding, currently I think we have two ways that you can find out, and do a kind of service discovery that you can talk QUIC to another end point. At least in terms of some in-band method, if you have some out of band thing that's your own custom thing. We've got the HTTP alt service and I think the service B DNS record. If I understand correctly, both of those will tell you which version of the protocol to use, and that would obviate the need for in band QUIC version negotiation at the present time. So there's in that sense not an urgent need for the negotiation. I was trying to double check what the current text in the document that is not slated for removal actually says, and if my notes are correct we say it is left for a future version of QUIC to define this, but we don't give any qualifications on who would be doing that, what future version it might be, in particular it seems like a future non IETF version of QUIC might feel empowered to do so, and that might risk a free for all. I would kind of expect we'd want to limit this for a future IETF version of QUIC to define, and that would give us more freedom to make sure we get it right and to avoid the explosion of competing things that only sort of work. So I think some of the key points from the email to get into the document are about how we decided it's better to not have anything than to have something that's broken, if you only have one version then you don't need the negotiation, we plan to have it in the future in a future IETF version, and until there is the official version negotiation you effectively have to treat each version as its own thing. I think the practical effect is that we prohibit in-band version negotiation until there is an official version negotiation method, and in light of the current state of discovery and whatnot it doesn't sound like that's going to be a problem. Obviously I'm just reading some of these emails this morning so I still have to digest everything, but that's sort of my current thinking on what the right thing to do is. Magnus: Yeah. The WG is already discussing having a draft solution for the version negotiation problem, but it's on the WG's table going forward now after version one being approved. So we can focus more on that. Ben: To reiterate, I do not think that we need to delay the publication of this document until we have a version negotiation thing. Magnus: It sounds like you're maybe asking for a clarification or a tightening of the language around that saying that due to versions you need to check if there exists a mechanism and then use that IETF mechanism that's specified for this. Ben: That's my understanding of what my preferred outcome would be. Magnus: From my perspective it sounds reasonable. Let's go check that with the WG and I hope that should be fine. Ben: I will send mail on that thread after the telechat. Magnus: Okay, good. Rob? Rob: Yes, so I'm quite conflicted on this in terms of the spin bit. I'm not really happy with how it's defined at the moment, but at the same time I appreciate that there's been a lot of discussion on this in the past that I've not been involved in and the WG consensus is on the text around where it is. I don't like the fact that the behavior is entirely unspecified if you don't support it what you're meant to do, and that's left really ambiguous. It feels to me that the option to introduce random noise when the spin bit is turned off is entirely pointless in a sense you're able to filter it out, so I don't understand why the spec would actually encourage someone to do something that takes effort to do and has no benefit. However, I appreciate that trying to get these changes would be contentious and I think I'm probably in the rough, so I'll probably change my position to Abstain. That's the pragmatic answer here. I don't want to block a QUIC draft going forward. Magnus: From my perspective the rough consensus has been fairly rough in establishing, getting to this point. Starting this discussion I think could take significant time to reestablish if that's okay, etc, and people might go further into this requesting additional changes. I'd prefer to not change this, I think it's one of the most tricky. Warren: I agree with what Rob said. I think it's fairly clear that a number of the people in the WG really did not want the spin bit, so I think the way that it's being defined and implemented to me feels like it's intentionally made difficult to use and less useful. But I think I'm in the rough here. I think it hurts manageability but I understand that's my view, and many operators' views. I think this is a case where having the protocol move forward is important so I'm holding my nose. Magnus: On the aspect of when the spin bit is spinning, it has been proven that getting a signal out of that when it's actually spinning compared to being randomly set or fixed, etc, is not a real issue. There is an implementation experience with that. Rob: Yes I agree, but I think the question is then, why go to the effort to introduce the random noise in the first place? Does it actually have any benefits? Warren: To me, adding random stuff, not just saying make it always be zero if you're not doing spin, makes it significantly harder to implement and use. It makes it so that it's really hard for me to, for example, in a router type device, try to figure out stuff from this. It basically makes it almost unusable for network devices to actually get and act on this data. Ben: I think it's making it very explicitly clear that this is not a reliable signal in any means. Even if the thing that ends up requiring an eighth of connections to not use it, that also makes it not a reliable signal but it was sort of a reliable signal for the other ones. The random thing is, this is definitely an unreliable signal so don't build key infrastructure on top of it because it's not reliable. That's sort of the vibe I was getting. Warren: But it's not just that it's not reliable, I can't even now make heuristics based upon it. Magnus: So yes, you need to capture multiple RTTs, etc, of a sequence of packets for a flow to determine what is the actual RTT sample. But there's an aspect of why this is random which I think should be clear, which is that in case this fails in deployment in some sense, by actually setting it random etc, there's no built in middle box behavior that will not accept, etc. I think that's one of the aspects where this random comes from, it's ensuring that by exercising the bits, independent of if the spin bit is used or not, those bits are active and live and it's not assumed that they will have a particular [inaudible, Webex beep] and it's only that we let through. This is part of this. Warren: To me this does not feel like greasing, to me this feels much more like we don't actually want this to be usable by middleboxes, or at least by router type middle boxes, so we make it so you'll need to pay a lot of attention to the stream. Whatever the case, I'm abstaining. I disagree with this but the protocol itself is sufficiently useful. Martin D: Magnus is right, it's about greasing. We're not sure how widely deployed spin bit is going to be, and we have some indication, but if it turns out to be a relatively small part of internet traffic.... The general principle in QUIC has been to grease everything we can. This is another example of that. If spin bit turned out to be very unpopular in the wild and it always turned out to be zero, that would be an ossification opportunity. Warren: I think setting it like this makes it that it's almost definitely not going to be deployed, because my big expensive routers cannot look at it so I'm not going to deploy it. But you know, whatever. Rob: Just in terms of the greasing, it sets it once per connection, either to zero or 1. Would that not be sufficient to grease the bit? Does it need to randomly change on a per-packet basis? But again, I'm with Warren here. I don't know if we need to discuss it further. Magnus: I don't know if it would be sufficient or not. I guess we're not going to get further here. Mirja: I think the two options exist because they are implementation tradeoffs. If you do it on a per-connection basis you still have to hold state. If you do it on a per-packet basis it's really easy to implement. Rob: That's very useful information. I don't know if that would be worth saying in the document. It hadn't occurred to me. Mirja: I don't think the document gives a strong recommendation about what you should do, it just says you should kind of grease it or not set it to a permanent value, right? Rob: It says you should either set it randomly per packet or you should set it-[cut off] Mirja: These are the two options you have. Rob: The third option is to set it to zero. The only other comment here, while we're talking about greasing, the behavior if it's not supported is undefined. If you don't support the spin bit at all, implementations can set it to zero or one or do whatever they like. It's only if you support spin bit but it's disabled, you're obliged to follow those two SHOULDs. Mirja: I think that's a good point we should address. Rob: I'll put that back to the authors, and I'll change to an Abstain. Thanks for the discussion. Eric V: About all the QUIC documents, the chair put all my comments and most of the comments from others in GitHub, which is fine, but I would still be curious to see the reply on my comments. If the WG could be nice enough to reply by email, that would be really cool and appreciated. Magnus: On that point, I haven't discussed it but your reviews resulted in 150 different issues and because it's a combination of the WG's GitHub process here, this looks like so many comments are late. I will take that discussion with those who brought it up. I think this is one aspect of GitHub and comments-[interrupted] Mirja: I believe the request was similar as Lucas just put in the link to each GitHub issue he created, as soon as that issue is resolved he can send one more email saying this is resolved here, this is resolved here. I think that's the request. Eric V: Yes. It's just a wish. Alissa: In mine they tagged me so I got email automatically. Martin D: You can also subscribe manually. Mirja: I do fully understand the request to get some notice that everything has been resolved so you have a trigger to look at it again if you want to, rather than feed the whole discussion into email. Magnus: Yes, but I think in this case you are going to get to see a revision where this is resolved. Unless you want to engage in particularly I think you probably have to look into GitHub and follow your issues, or you can see this is what the WG concluded on your comments. I think that's where we're probably going to end up here, so you will get a new revision. So on this document, this is Revised ID Needed. Amy: Okay, so this will stay in IESG Evaluation, Revised ID Needed. o draft-ietf-quic-recovery-33 - IETF stream QUIC Loss Detection and Congestion Control (Proposed Standard) Token: Magnus Westerlund Amy: There are no Discusses in the tracker, so unless there's an objection now, this is approved. Magnus: I still think we can put all the QUIC documents in Revised ID Needed. They are too interlinked. Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed and you can let us know when they're released. o draft-ietf-quic-tls-33 - IETF stream Using TLS to Secure QUIC (Proposed Standard) Token: Magnus Westerlund Amy: I have a Discuss in the tracker; do we need to discuss this or have we covered it? Magnus: Ben, are you happy with the discussion? Ben: I'm pretty happy with the discussion. The second point is not an issue. The first point I think we have agreement on what to do that will require some text changes, in that I think Martin proposed something and I proposed that we should do that. I think Martin may be asleep or buried under a deluge of IESG comments on the cumulative documents, so I have not gotten that explicitly confirmed yet. But I don't think we need to talk about it today as the IESG. Magnus: Okay, good. Amy: So like the others it sounds like this is going to be a Revised ID Needed. o draft-ietf-quic-invariants-12 - IETF stream Version-Independent Properties of QUIC (Proposed Standard) Token: Magnus Westerlund Amy: There are no Discusses in the tracker, so unless there's an objection now, this is approved. Magnus: Put it also in Approved, Announcement to be sent, 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-detnet-security-13 - IETF stream Deterministic Networking (DetNet) Security Considerations (Informational) Token: Deborah Brungard Amy: I have a number of Discusses in the tracker; do we need to discuss any of those today? Deborah: I don't think so, unless someone wants to. Thanks everyone for their careful reviews. The authors are communicating so I'd say keep it in IESG Evaluation and Revised ID Needed. Amy: Thanks Deborah. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-carpenter-eligibility-expand-09 - IETF stream Additional Criteria for Nominating Committee Eligibility (Experimental) Token: Alissa Cooper Amy: Consensus is currently set as Unknown; I'm going to change that to Yes. There are no Discusses in the tracker, so unless there's an objection it looks like this is approved. Alissa: Great! Put it into Point Raised just so I can check with the authors. Amy: Okay, I'll put this into Approved, Announcement to be Sent, AD Followup. 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-yang-tls-tls13-sm-suites-01 IETF conflict review for draft-yang-tls-tls13-sm-suites draft-yang-tls-tls13-sm-suites-06 ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 (ISE: Informational) Token: Benjamin Kaduk Amy: There are no Discusses in the tracker, so unless there's an objection now, this conflict review can go back to the ISE. I'm hearing no objection, so this is approved with the note that's currently there and we'll send this no-problem message 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 Alvaro: I missed the IAB meeting yesterday but I can report that the IAB confirmed the IESG slate from the Nomcom and it was minuted last night. Hoping we'll all have news soon. 6. Management issues 7. Any Other Business (WG News, New Proposals, etc.)