Narrative Minutes interim-2019-iesg-18 2019-09-05 14:00
narrative-minutes-interim-2019-iesg-18-201909051400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2019-09-05 14:00 | |
Title | Narrative Minutes interim-2019-iesg-18 2019-09-05 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2019-iesg-18-201909051400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2019-09-05 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 Michelle Cotton (ICANN) / IANA Liaison Alissa Cooper (Cisco) / IETF Chair, General Area Roman Danyliw (CERT/SEI) / Security Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Wes Hardaker (USC/ISI) / IAB Liaison Ted Hardie (Google) / IAB Chair Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Mirja Kühlewind (Ericsson) / Transport Area Warren Kumari (Google) / Operations and Management Area Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Alvaro Retana (Futurewei Technologies) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Martin Vigoureux (Nokia) / Routing Area Amy Vezza (AMS) / IETF Secretariat Éric Vyncke (Cisco) / Internet Area Magnus Westerlund (Ericsson) / Transport Area REGRETS --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Deborah Brungard (AT&T) / Routing Area Heather Flanagan / RFC Series Editor Portia Wenze-Danley (ISOC) / Interim LLC Executive Director OBSERVERS --------------------------------- Chris Box Brian Campbell Darren Dukes Bob Hinden Greg Wood 1.2 Bash the agenda Amy: Does anyone want to bash the agenda? I did get a late management item; any other changes? 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of the August 22 being approved? Hearing none, so those are approved. Does anyone have an objection to the narrative minutes of the August 22 meeting being approved? Hearing none, so those are approved as well. 1.4 List of remaining action items from last telechat o Ignas Bagdonas to propose an additional question on YANG Model format validation for each of the styles of document write-ups. Amy: Ignas is not here so we'll mark this in progress. o Roman Danyliw to draft text to be posted on ietf.org about reporting protocol vulnerabilities via an email alias and possible procedures on how to assign triage resources. Roman: That one is still in progress. o Martin Vigoureux to work with the IESG to create a list of possible IESG Tutorials and will prioritize them for scheduling on a series of Informal Telechats. Amy: Martin is going to be late so we'll keep this in progress for him. o Eric Vyncke to write up draft text for the NomCom to help them understand the rules for the NomCom. Amy: Eric is not with us today so we'll keep this in progress. o Roman Danyliw to shepherd the www.ietf.org analytics discussion with the community. Roman: We have time to talk about this later. Let's just keep this in progress. o Alexey Melnikov to find designated experts for RFC-ietf-core-object- security [IANA #1141664]. Amy: This is a management item today so we'll mark it provisionally done, and same for the next item. o Alexey Melnikov to find designated experts for RFC 8554 [IANA #1142796]. o Alexey Melnikov to find designated experts for RFC 8610 [IANA #1145107]. Alexey: This one is in progress; it probably will be done next time. o Ignas Bagdonas to find designated experts for RFC 7317 [IANA #1146017]. Amy: Since Ignas is not here we will mark this in progress for him. o Adam Roach to collate the list of specific "hot topic" items from each Area that will be provided to document authors and post it on the wiki. Adam: Leave this one in progress. o Barry Leiba to come up with a proposal for moving Last Call discussions to a separate mailing list. Barry: The action is done, we just need to discuss today when to actually do it. o Suresh Krishnan to ask Heather F and Sandy G to introduce the Updates Tags Document (draft-kuehlewind-update-tag) to the RFC- Interest email list for discussion, and inform the community via the IETF discussion list with a pointer to RFC-Interest. Suresh: This is done; we agreed on text last week but the mail itself hasn't gone out. Heather agreed to send the mail and we agree on the text of it. I would say this is done. o Adam Roach to send a message to the tools team cc Roman as liaison about removing the required date associated with milestones on WG Charters. Adam: Also in progress. Thanks. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-curdle-ssh-curves-11 - IETF stream Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 (Proposed Standard) Token: Benjamin Kaduk Amy: There are no Discusses in the tracker, so unless there is an objection now this is approved. Ben: It sounded like the authors were in the process of making a few changes. Let's leave this as Point Raised and I can sync back with them to see whether a Revised ID is actually needed. o draft-ietf-oauth-resource-indicators-05 - IETF stream Resource Indicators for OAuth 2.0 (Proposed Standard) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there is an objection now this is approved. Hearing no objections. I also don't have any notes in the tracker; are there any needed? Roman: Can you please mark it Revised ID Needed? I think there was a change or two that still needed to be made. Thank you. o draft-ietf-mile-jsoniodef-10 - IETF stream JSON binding of IODEF (Proposed Standard) Token: Alexey Melnikov Amy: I have a number of Discusses for this document; do we need to discuss any of those today? Alexey: I don't think so. I'm waiting for answers from the authors. Suresh's comment should be fairly simple to resolve and I think Ben's comments are quite valid as well. So I think this will definitely need a revised ID. o draft-ietf-ippm-stamp-07 - IETF stream Simple Two-way Active Measurement Protocol (Proposed Standard) Token: Mirja Kuehlewind Amy: I have a number of Discusses for this document; do we need to discuss any of those today? Mirja: I don't really think we need to discuss them. Thank you everyone for reviewing with such short notice. They're all valid points. I think the main point here I just want to comment on is that this is really just a testing protocol so there's no public web server or whatever; it's always in your domain where the testing client and testing server know each other and are configured and have to have the same version. The other intention was to make this version as simple as possible so there's no version negotiation, or any kind of negotiation mechanism in here. So the way to change anything is actually to publish a different kind of protocol in a new RFC. That should be clarified in the document. It should also be discussed, like how you change, for example, the HMAC algorithm by basically defining a new version in a new RFC that then both end points have to implement. I will talk to the authors and maybe we can add a compatibility statement or address these points directly. Amy: Okay, we'll go to IESG Evaluation, Revised ID Needed. o draft-ietf-oauth-jwt-introspection-response-07 - IETF stream JWT Response for OAuth Token Introspection (Proposed Standard) Token: Roman Danyliw Amy: I have a couple of Discusses for this document; do we need to discuss those today? Roman: I don't think we need to; we're doing well on the mailing list. Can you just mark it Revised ID Needed? Thanks. o draft-ietf-6man-segment-routing-header-22 - IETF stream IPv6 Segment Routing Header (SRH) (Proposed Standard) Token: Suresh Krishnan Amy: I have a number of Discusses for this document; do we need to discuss those today? Suresh: Some of this stuff has already started and the authors haven't had a chance to respond. I had a chat with them, and Darren is on the call too in case we need something. The idea is we'll make sure discusses are addressed. Barry's point about the IANA consideration stuff is something we'd already thought about. We'll come up with a response for that too. I don't think we need to talk about this on the call but there have been some issues in the WG regarding specifically the security pieces and the HMAC and the optional nature of it and everything. We'll work through some text to make sure we come up with something that's going to hold consensus as well. And for sure this is going to require a Revised ID. Amy: Okay, thank you. We'll put this in Revised ID Needed. o draft-ietf-iasa2-rfc7776bis-02 - IETF stream Update to the IETF Anti-Harassment Procedures for the Replacement of the IAOC with the IETF Administration LLC (Best Current Practice) Token: Alissa Cooper Amy: I have a Discuss; do we need to discuss it today? Ben: Alissa sent this an email this morning, right? Alissa: I did. Ben: Maybe I just haven't had enough caffeine but I'm still a little bit confused. You said we were not asking for the live metadata to change, but we were expecting it to change as a logical consequence? I'm not sure what you meant by that. Alissa: I think the point is that readers of this document together with 7776 should realize that the totality of them doesn't update 7437. Ben: Sure. I agree with that. I'm finding the right button to clear [my Discuss]. Alissa: Thank you all for your patience with this. Magnus: I would note that I think there are some points for us going forward for discussion. I did add the topic for the retreat, around the general topic of updates, refreshing documents, etc and the impact of some steering we try to do. I think we need more discussion on that side. Barry: Adam has started something with that and I think we should continue that discussion. This is a separate one; had I been around when the WG was chartered, I probably would have pushed back on the way the charter was created. We need to restrict scope on changes but we need to be careful about how that's done. That's a separate discussion I think we should also have. Alissa: So Magnus, is there something beyond the discussion we've already had around Adam's document? Magnus: Have a look at the proposed topics; I have it there with three aspects I think should be discussed. It's in the second retreat wiki page. Amy: Okay, so I have that Ben has cleared his Discuss. With no Discusses left, this is approved unless there are any other objections. Alissa: This can go into Revised ID Needed. o draft-ietf-core-senml-etch-05 (Has RFC Editor Note) - IETF stream FETCH & PATCH with Sensor Measurement Lists (SenML) (Proposed Standard) Token: Alexey Melnikov Amy: I have a couple of Discusses for this document; do we need to discuss those today? Alexey: No, thank you everybody for finding various issues. I need a reply from the editors, I believe. Amy: Is this going to require a revised ID? Alexey: Yes, most definitely. o draft-ietf-netmod-artwork-folding-09 - IETF stream Handling Long Lines in Inclusions in Internet-Drafts and RFCs (Best Current Practice) Token: Ignas Bagdonas Amy: Ignas is not with us today. I do have a Discuss in the tracker. Ben, do you have a feeling if this Discuss is going to require a Revised ID? Ben: There are definitely some points that would require a Revised ID but I think we should potentially have a discussion on the last point even though Ignas is not here, because there are a few people that had balloted Abstain and I wasn't sure if I wanted to ballot Abstain as well. I think we should probably discuss the underlying issues. Suresh: I was right on the border too, for abstain or no objection. I don't think this should be in the IETF stream, like Alissa, Mirja and Alvaro said, but I do think the work is useful. Alvaro: I looked very hard to see if there was anything that kept us from publishing it. Like if anything having to do with the RFC format had to be done by the RFC Editor and IAB, but I couldn't find anything. So that's why I ended up abstaining. Ben: Just because there's nothing that says we can't do something doesn't mean we need to think about if us doing that thing is the best way to get that thing done. That's why I felt comfortable with Discuss. I also don't have a great sense for what the nature of the previous conversations with Heather have been about this, and if there would be any interest in trying to undertake a more general work on folding or a code sample folding mechanisms or preferences to apply to the series as a whole instead of just IETF stream. I also think many of these concerns would go away if we did not try to publish this as an IETF BCP and instead tried to publish it as an informational document. That would be heavily relied upon by some of the Yang work, even though the Yang tree diagrams have built in tooling to set the desired line length, because that gets into the chartering question. This WG is basically focused on Yang and this treatment we have in this proposed BCP document is applying to all code samples and similar through the entire IETF, which is pretty clearly not just Yang related. Barry: My comment on their mailing list was that this deserves wider attention and any document saying it's a Yang document is going to be ignored by a large quantity of the IETF that this ends up affecting, and this should be on a wider discussion forum. Ben: That's basically my sentiment. People will say the IETF general discussion list for last calls is a broader forum so by doing a last call it got the requisite amount of review. But in some sense that seems like a polite fiction. Adam: I wanted to weigh in quickly. There are two issues here: whether this should have gone to netmod and a separate question of whether this should come out of the IETF. I want to point out that RFC 2629 is an IESG stream document; that's the xml format for creating RFCs and it's become used across all the streams and is about to become the basis for the format going forward. I think the concerns about it coming out of the IETF is probably something we don't need to worry too terribly much about. Alissa: That document was obsoleted by an IAB stream document. Adam: Yes, but at the time it was published it basically spoke to a tool you could use in creating RFCs, which is kind of what this document feels like to me. Suresh: I think the difference was on the same lines as Ben said; it was an informational document. That's where I was really on the edge. [This is] not just an informational document. Adam: That's a fair point. Alissa: And when did the notion of the streams even start? It was after this document, right? Adam: After 2629? That was 1999 and I thought we already had streams by then. But my memory could be faulty. Alissa: I did a bit of digging to try to figure this out and the stream isn't listed on documents from that time period so I assume we didn't have streams. I don't remember when they started. The thing is, what's the point of having them and arbitrarily enforcing when something goes on one stream vs another? If it matters, it matters, or if it doesn't matter, then why do we have them? Warren: This just provides a way that you can do it. It doesn't say thou must always do it this way. Right? So if other streams choose not to do it this way.... Barry: It is a BCP, so at least of the IETF stream says this is the way to do it. Ben: I agree with Warren that the way the document is written feels more like it's "here's a way to do it" which would feel more like an informational document than a BCP. Warren: I would think that this is probably the best current way to do it. If somebody decides not to, it's not that they are violating some law. They're deciding not to use what we think is a best practice. But that is getting down into semantics. Suresh: I might move to a Discuss on this. I hadn't thought of it that way. But it probably didn't get review from outside the Yang community. If you're going to go with a BCP then probably we need wider review and to call it out better. If not, move to informational. That could be a way forward for me. Ben: That seems reasonable. Of course Ignas is not on the call. I'll just ask if there are any other points people want to make right now or if we should take this discussion onto the mailing list? Mirja: I said this in my ballot but I think this is also completely out of scope for the WG, which is another reason for the IESG to give pushback. Warren: I agree it is completely out of scope for the WG charter. Echoing Spencer, do the right thing. Yes they came up with a document that's not in charter, but it feels like a useful document, so it's worth us not ignoring. Mirja: I think we should make sure WGs stick with their charter because otherwise charters are not useful. Ben: I'm not saying don't publish the document, I think it should be published but we should find a better path to publish the document. Amy: So it sounds like the conversation will continue on the mail list and this will stay in IESG Evaluation. 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-rmcat-nada-12 - IETF stream NADA: A Unified Congestion Control Scheme for Real-Time Media (Experimental) Token: Mirja Kuehlewind Amy: There are no Discusses in the tracker, so unless there is an objection now this is approved. Ben: I ran out of time and didn't finish it all the way through. Do we have something in there about if the level of congestion is such that you can't even support the minimum bit rate for the encoder you should abort the flow? Mirja: I don't think that's explicitly mentioned but it's a very general congestion control concern and I think that would happen automatically based on the scheme implemented. If you really want to finish reviewing we can wait but otherwise I think this document is ready to go. Ben: No, I trust you. Go ahead and mark it approved, don't wait for me. Mirja: We got a bunch of comments which are generic comments for all congestion control schemes. We point to documents in the security considerations that provide further guidance, so I think we're safe. Ben: Sounds good. Mirja: This is ready to go with the editor note. o draft-ietf-iasa2-rfc5377bis-03 - IETF stream Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents (Informational) Token: Alissa Cooper Amy: I have a Status Unknown, is this a yes? Alissa: Yes, sorry. Amy: Okay. There are no Discusses in the tracker, so unless there is an objection now this is approved. Alissa: Great. You can do a Revised ID please. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Audio/Video Transport Core Maintenance (avtcore) Barry: The only question is that everyone who commented said it didn't need external review. Does anyone think it does? Ben: I don't have a great sense of if we have consulted the broader community about if merging these WGs is a good plan. It's not entirely clear to me we should just do the merge without the broader consultation. But if I'm the only one who feels that way I don't want to impose my will on everyone. Barry: I'm good with that. Magnus: There's no real cost to running this through last call. Barry: There isn't. Let's do it. Amy: So that sounds like it should go for the external review and we'll send a recharter announcement and we'll put it back on the agenda for next time. 4.2.2 Proposed for approval o Autonomic Networking Integrated Model and Approach (anima) Amy: There are no blocking comments for this, so unless there's an objection now this is approved. 5. IAB news we can use Mirja: No news this time. 6. Management issues 6.1 Designated Experts for RFC 8613 [IANA #1141664] (Alexey Melnikov) Amy: Alexey has identified three people as experts for this registry. You had a note that you were still waiting to hear from the third one; did the last person say yes? Alexey: Yes, sorry. I sent a message to the IESG but forgot to BCC you. Yes. Amy: Is there any objection to naming these three folks as the experts for this registry? Hearing no objection, so it looks like they are approved. 6.2 Secondary Expert for Emergency Call Data Type (Adam Roach) Adam: We have a document going through right now where the author is also the expert, so we need someone to deal with that situation if it ever arises again. Amy: Okay. Any objection to approving Henning Schulzrinne as a secondary expert? Hearing none. 6.3 Next steps on IETF Website Analytics (Roman Danyliw) Roman: Pre Montreal we walked through what the community feedback was. I'd walked through potential ways to address that. You provided me various feedback on some of the proposals here. What I sent around yesterday was the consolidation of all of that feedback. I just wanted to put a time here on the agenda for anyone that's had a chance to already look at it for questions and feedback. Alissa: I looked at it and I thought it looked good. I think it's ready to go. Roman: Okay, thanks. My notional plan is if I can get all feedback by next Friday we can get it out sometime after that. We can reset the date as required. I think that's all we need, thanks. 6.4 Plans for ADD going forward (Alissa Cooper and Barry Leiba) Barry: What we need to do is figure out who's got the token so it doesn't get lost. We talked about doing some sort of rechartering of dprive to pick up some pieces of work that came from the add discussion, and then whether or not we need to do anything to the dnsop charter to tighten it up and make sure it doesn't wind up bleeding in. So that would bring in Eric and Ace. I see Eric has gotten on the call. Do you have any thoughts about what to do with the dprive charter or whether you want this stuff there? Eric: On this one I would prefer, if you don't mind, that you and I get a separate call on this and chat for 15 minutes. We can do it next week. Barry: That works great. Warren: I'd also like to be on that call if easy, but if I can't make it then I can't. I don't think there's much in the dnsop charter that needs to change. I think the chairs and me are more than capable of saying whether something seems outside our scope or that this is something dnsop can make use of. Eric: It does make sense to have this call with the three of us. Barry: We'll do that next week and then we'll have a path forward. I have the token to set up the call. Alissa: Can we add this to our action items list so you can report back to the rest of the IESG? Thanks. Amy: We'll add that action item. Thanks. 6.5 Discuss creating a last-call@ietf.org list (Barry Leiba) Barry: I don't know that we need a lot of discussion here right now but I incorporated everyone's suggestions and posted a new version of the plan. If we're good with that plan we should go ahead. Does anyone have an issue or need to discuss it further right now? Warren: I think we just need to be fairly careful with the actual messaging. I'm sure that's not a surprise to you. Someone had said something that they hope we're not planning to take this off to a separate list. I had bookmarked that email but now I've lost it. Barry: I remember seeing it as well. The first thing I intend to do is post a message to ietf@ietf.org and I will post it to the IESG list first for a sanity check, saying what we're planning to do and how we're planning to do it and see what people see. It certainly seemed like at the plenary we had plenty of support to do it and I'm sure it's not unanimous. We'll go from there. Other discussion? Alissa: Assuming the first thing you do is reach out to the tools team and the directorate people, as your plan lays out, in parallel should I start finding people who will be moderators for the list? Barry: Yes, I think that's a good idea. The first thing I'll do is post the plan to the main IETF list and see what kind of pushback we get. I'm going to cast it as an experiment, as Alvaro suggested, which also gets around some of the issues with the charter of the IETF list. If that comes out okay then we'll go ahead and proceed and you can start looking for moderators. Alissa: Okay. I thought we were taking a different approach. I know this is subtle, but I thought what we were doing was a sort of "we're going to do this, and here's the plan," and give people some time to comment on it but not gate whether we do it or not based on the feedback. But what you just said sounds different. Barry: I'd like to do it that way. Do the rest of you think it's okay to just do it by feel? Alvaro: There's an RFC that talks about what's okay on the IETF list, right? Barry: Right. The problem is that the IETF list's charter specifically says that last call discussions are appropriate for it. So I think for us to go back from that we need to either get community consensus on changing that RFC, or cast it as an experiment. Alissa: I think casting it as an experiment is fine, but it doesn't say that you can't have last call discussions on other lists. Barry: But if what we're saying is that we're explicitly taking last call discussions off of the IETF list and moving them there, we might or might not get significant pushback about that. Ben: Especially if you ask the sergeant-at-arms to enforce that, and steer people who posted last call discussions off the general list. Suresh: I think we're going to get pushback no matter what. Even with the RFC stuff which really belongs in rfc-interest, we got pushback. Barry: I think it doesn't hurt to post the plan and see what people think. I expect we'll get some pushback but mostly support. We'll see. Warren: I think we need to be very careful to make sure that, especially in the current environment, we're making it very clear that we're doing what the community wants, and we're not imposing our views. Barry: I will point out in my note that this was proposed by the community and we're following up on that. So Amy, there's another action item for me to post the last call list plan to the IETF list. 6.6 Designated Experts for RFC 8554 [IANA #1141664] (Alexey Melnikov) Amy: Alexey, you added this to approve David McGrew and Scott Fluhrer as experts for this registry. Any objections to this? Alexey: I emailed two of the three authors about this earlier and they just replied now. Amy: It looks like those are approved and we will get the note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Eric: If you look at the protocol numbers on the IANA website, you see a few of those without any specification. Like, number 114, "any 0-hop protocol." Another one is "any private encryption scheme." Without any specification of what needs to be done. How can we say to someone whether they can use this protocol number? Michelle: Most likely if there's no specification attached, it was there long ago; possibly something Jon had put in before our time handling the IANA services. We often have to reach out to community members to find out what the background is on some of those registrations. Eric: So maybe send an email to the IETF list? Michelle: If that's the appropriate place you think we should go. Otherwise there might be specific WGs that would be better. It's up to you. Eric: Will do. Thank you. Ben: On a different topic, I have a draft charter for the lake WG that I sent out to a two week call for comments period on the mailing list we had for the BoF. If that goes well I will be sending the charter to the IESG for review. Alissa: Yesterday I circulated some draft charter text for gen-dispatch and I'd appreciate it if people could take a look at that. Mirja: I took a look and I think it looks good. I'm just wondering if we really need to do this for every area now, or if this is more something generic we could say this is the process without having a charter. This is a more generic question we can discuss later. Alissa: That's an interesting question. Roman: I can't answer that generally but in Security we've found having a dispatch actually quite helpful, to provide a forum to talk about ideas that would have struggled potentially on a mailing list. Mirja: I wasn't questioning the approach, just if we need to write a charter for each dispatch area group separately. Amy: I'm hoping to close the poll for the BoF coordination call today, so if you haven't put in your availability please do that today. Right now the frontrunner is during the time of the IESG retreat in Amsterdam.