Narrative Minutes interim-2021-iesg-22 2021-10-07 14:00
narrative-minutes-interim-2021-iesg-22-202110071400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2021-10-07 14:00 | |
Title | Narrative Minutes interim-2021-iesg-22 2021-10-07 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2021-iesg-22-202110071400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2021-10-07 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 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 Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Google) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Éricsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Éricsson) / Applications and Real-Time Area Alvaro Retana (Futurewei Technologies) / Routing Area Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Michelle Cotton (ICANN) / IANA Liaison Jay Daley / IETF Executive Director Lars Eggert (NetApp) / IETF Chair, General Area OBSERVERS --------------------------------- Amanda Baber Chis Box Adrian Farrel Colin Perkins Lee-Berkeley Shaw Donald Trump Greg Wood 1.2 Bash the agenda Amy: I have one change to the agenda; we're going to take the dnsop-dnssec-iana-con document first so that Martin Duke can be here for the conversation. Anything new or any other changes? 1.3 Approval of the minutes of past telechats Amy: Is there any objection to the minutes of the September 23 teleconference being approved? I'm hearing no objection, so we'll get those posted. And there were no changes to the narrative minutes of September 23; any objection to approving those? Hearing no objection there either, so we will get those posted as well. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Roman Danyliw to find designated experts for RFC 8739 and RFC 9115 (Automated Certificate Management Environment (ACME)) [IANA #1210257] Amy: This is to alert you that you have this designated expert request. Roman: Perfect, action caught. o Francesca Palombini to find designated experts for RFC-ietf-httpbis- semantics-19 (HTTP Semantics) [IANA #1210675]. Francesca: I have one expert and I'm trying to see if I can get two. What's best? Should we add the item to today's agenda to approve the one I have right now, or is it best to have both at the same time? Amy: That's really up to you. I can't remember if IANA has an outstanding request for this. Francesca: I think it's just from the document being in the RFC Editors' hands. Amy: If there's no urgent request for it, I think you can wait until you have both in hand and let us know so we can put it on an agenda. Francesca: Okay. I have an unrelated question for IANA but maybe we should take that at the end. * OPEN ACTION ITEMS o John Scudder, Martin Duke, and Robert Wilton to review the document shepherd templates and propose changes to include updated questions, cross-area checks, and an expanded section on the use of YANG models. Rob: Still in progress; we're a bit closer to actually progressing. 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. Amy: These two hinge on the first one, so we'll mark these in progress. o Murray Kucherawy to update BCP 97 to provide guidance about handling normative references to non-SDO documents. Murray: There is a draft posted for everyone to review; I emailed the IESG about it, so feedback is welcome. And I am looking for a sponsor for this one. Amy: It sounds like you've done the document; is this a completed item or do you want to keep tracking it? Murray: Either way is fine with me. We can either track this until publication is requested or we can call this done and just run the process. Amy: Any volunteers to AD Sponsor the document? Roman: It seems done to me; let's run the process. I'll have some feedback for you. Erik K: If Roman doesn't take it, I will. Murray: So let's say Erik can [sponsor it] and Roman has feedback. o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in October 2021. Amy: This will happen next time; I have to get updated numbers for you. o The IESG to review the feedback on whether to continue the RFC 8989 experiment 2022-2023 cycle by October 7, 2021. Amy: Lars put this on the agenda but he's not here, so I'm not sure if you'll want to push it to the next meeting. o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot positions" as an IESG statement. Warren: In progress. o Éric Vyncke to work with the Tools Team to update the references to the BSD License in the Trust Legal Provisions in the various IETF Tools. Éric V: I've looked a little bit around in the Datatracker and there's nowhere we see this license except for the RFC Editor. Sandy opened a case with the tools team and I have no feedback yet. Let's keep this item open. o Greg Wood to update the references to the BSD License in the Trust Legal Provisions on the IETF website. Amy: I'm not sure if this is completely finished yet so we'll keep this in progress until Greg is back. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-dnsop-dnssec-iana-cons-04 - IETF stream Revised IANA Considerations for DNSSEC (Proposed Standard) Token: Warren Kumari Martin: I think my Discuss says it all. I don't know that this is a problem with this document but 3658 is obsolete, but the IANA registration information is not in any of the bis-es that obsoleted it. I was looking at one of the IANA RFCs and I guess this is a problem. I did want to discuss this but I'm happy to take any one of three answers. One is that this isn't a real problem, don't worry about it. Number two, yes this is a problem and we'll address it in some other draft, or three, we should fix the problem in this draft since it's here and dealing with this general subject. Warren: Would you accept a combination of all? I think this isn't really a problem. When 4034 and 4035 obsoleted 3658, I think the obsoleting was a signal that we really mean it, but that doesn't make all of the text that was in 3658 completely incorrect or not worth reading, nor did it really seem to replace all of it. The designated experts for the registry had asked IANA to please keep this reference around. So I think we should probably try and in the future do a better job of making sure that when a document obsoletes an existing document, that the registry is updated to either remove the old one or note both. I think in this particular case it's not really an issue. I also think the main thing that 3658 is still being used for in the reference is SHA-1, which is going to be going away relatively soon. Not an ideal situation, but I think it's not worth all of the fuss and bother that would be required to write a new document to fix that. I also don't think this particular document is the place to fix it so we'd have to make a really short document to tell IANA to update the reference. Martin D: I guess whoever is on from IANA, is that fine? Is this a serious policy concern? Sabrina: That's okay with us. If it needs to be updated you can just let us know, and if not we'll just leave it as-is. Martin D: Okay, I'll lift my Discuss and just say that we recognize the issue and might address it in another document. Thanks. Amy: Okay, so if Martin is going to lift his Discuss we have no other Discusses and it looks like it's approved. Warren: I believe so. The authors have agreed to address all the open comments but I can't remember if they've published the new version with the nits and things addressed. So I guess let's do Revised ID Needed. Amy: Okay, so this will go into Approved, Announcement to be Sent. You can pick either Revised ID Needed or AD Followup. Warren: AD Followup is good enough, thanks. o draft-ietf-netmod-yang-instance-file-format-20 - IETF stream YANG Instance Data File Format (Proposed Standard) Token: Robert Wilton Amy: I have no Discusses, so unless there's an objection it looks like this one is approved. Rob: Thanks everyone for their reviews, especially since I put it on the telechat slightly late. I know the authors have been good at updating the docs but I need to check that everything has been fed in. Can we put this in AD Followup please? Amy: Absolutely; we'll put this in Approved, Announcement to be Sent, AD Followup and you can let us know when it's ready to go. o draft-ietf-netconf-notification-capabilities-18 - IETF stream YANG Modules describing Capabilities for Systems and Datastore Update Notifications (Proposed Standard) Token: Robert Wilton Amy: I have a Discuss for this document; do we need to discuss that today? Rob: I don't know if Roman needs to. I think his point is valid and the authors have already sent a suggestion on how to fix this with some relatively minor changes to the security section, so I think it's just waiting on Roman to check if that text is okay. Roman: Indeed. I have a half-written response to the authors. What they clarified is in spirit exactly right; what I'd intended was to have A and C match, but the combination of A and C conflict with B, not that you couldn't mix and match A and C. They did propose some text and I think it needs to be clarified a little more, but I just need to put my fingers to the keyboard to propose some text. I think this one's really clear. Rob: Thank you, that sounds good. Amy: So is that still waiting for a Revised ID? Rob: Yes. Amy: Okay, so it will stay in IESG Evaluation with a substate of Revised ID Needed. o draft-ietf-regext-epp-registry-maintenance-17 - IETF stream Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) (Proposed Standard) Token: Murray Kucherawy Amy: I have a Discuss for this document; do we need to discuss that today? Murray: No. The authors already have a response prepared, I just asked them not to post it in the middle of IESG evaluation. We can move this to Revised ID Needed and that will be their trigger to post it and allow Francesca to clear her Discuss. I think we're all set. Amy: Great; this will go into Revised ID Needed. o draft-ietf-cbor-network-addresses-10 - IETF stream CBOR tags for IPv4 and IPv6 addresses and prefixes (Proposed Standard) Token: Francesca Palombini Amy: I have a Discuss for this document; do we need to discuss that today? Francesca: The authors have not had a chance to respond to John yet. John, you tell me if you want to expand on anything? John: No, I don't really expect it to be a big deal. I just wanted to make sure it didn't get missed, that's all. Francesca: Great, thank you. So we'll need a Revised ID. Amy: Okay, this will stay in IESG Evaluation with Revised ID Needed. 2.1.2 Returning items o draft-ietf-emu-eap-tls13-20 - IETF stream Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) (Proposed Standard) Token: Roman Danyliw Amy: I have a Discuss for this document; do we need to discuss that today? Roman: I'd like to discuss it. Ben, in terms of history, I think Éric said roughly the same thing, which is how do I apply the patch with the updates? And with apologies to the authors, it was my suggestion to use the magic word "amends." The intent was that you have the text in the old document and there was a lot of heartburn about how to modify that text. The thinking was there is new text here, you read the old text and new text and the union of that is the updated version of the document. There was WG consensus not to try to nitpick sentence by sentence, to come up with a unified set of text. So my proposal was that this "amends." Ben: Okay. I don't object to "amending" per se, just grammatically if we say "amended with something" it feels like it should have an interpretation and I can't find it. If we were saying by amending it according to the guidance in the following text, or something like that, that would not be problematic to me. We can tweak a few words and I can write something up, not in the middle of the call. Roman: Okay, so I just want to capture that. If it was more instead of this amends this section, it would say it amends with the text below, that's better? Or do you want to polish it offline? Ben: I think we should polish it offline. Roman: That's fine. Can you help me understand the contrast, you said in the third paragraph, about the replaces vs amends? Ben: Replacing is a pretty well-defined thing, and if you're amending something, at a grammatical level you need the subject, what are you amending, and what the actual action is. Just saying I have some text, unless the contents of the text describe what to do, is not really something that amends the other text. It's providing extra context or information. Roman: Thanks for clearing that up. We'll work on what else to add offline. We can put this in Revised ID Needed. Thanks everyone for giving this a second look. 2.2 Individual submissions 2.2.1 New items o draft-danyliw-replace-ftp-pointers-04 - IETF stream Updating References to the IETF FTP Service (Proposed Standard) Token: Éric Vyncke Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this one is approved. Éric V: It's approved for sure, but I wonder whether Roman can address the couple of comments that came in lately. Roman: Sure; I wanted to wait until you asked me to do that. I didn't want to abuse my AD privilege since I'm also on the call wearing the other hat. The first thing I wanted to say is, boy, I guess I didn't really appreciate the finesse that's required when you want precise spacing when you start with markdown and generate xml. Thank you to everyone that found all of those things. I don't think I caught all of them yet, but I'll get them. The editorial ones are easy and I appreciate those. Martin, yes, we'll use the RFC [url] instead of /in-notes, that makes perfect sense. The one I wanted to talk about is the thing Ben pointed out, which was if we make changes to the urls in the MIBs, do we need to change the last-revised dates for MIBs? I hadn't thought of it. How do people feel about that? It seems right. Are there objections to doing that? Warren: I believe you should because I think a lot of tooling uses last-modified to determine when it should download a new copy of the MIB. So if you make any changes, last-modified should be updated too. Ben: Do we also have to produce the updated MIB file somehow? I have literally no idea how that works. Roman: I need help here, I've never made a MIB document before. Warren: I don't know, it all has gotten complex. Rob: I'll have to ask. Warren: If we do have to update it, do we have to publish a bis document? There's all sorts of messiness here. Ben: I was a little reluctant to actually propose updating the MIB. I was trying to suggest we could finesse the wording a little bit so that the link in the RFC is incorrect, this is what the correct version is, but we aren't changing the published MIB. Warren: That doesn't sound unreasonable, largely because who the hell is using this MIB anymore? Roman: So Ben has a proposal on the table that instead of updating the document, we make a commentary on the document. Does anyone object to that? Ben: I think we have to update the document in some sense, in terms of the RFC document. Roman: Sure. I meant update the MIB. Ben: Exactly. Warren: In the updated document, can you say this document updates RFC blah blah, by changing the last-modified date from X to Y? Roman: Does that mean you're really changing the MIB and we're back in the same situation? Warren: It does mean you're updating the MIB, but that doesn't require a change of the document. It seems very ugly, but we often update information in a document. Roman: How about I do the following; instead of discussing this in the abstract, i will craft the sentence we could use for those MIBs, we'll get some feedback on it, and if I could get some help running the traps for folks that know how to publish MIB documents, how hard really is it? Maybe it's easier than we think it is. Éric: Do we still have a MIB directorate or reviews group? It's worth asking them. Rob: Jurgen will know the answer to this as well. Éric V: Rob, may i suggest that you ask them? You know better how to write this question compared to Roman and myself. Rob: That's fine. There's a bit of me thinking pragmatically that I don't think republishing MIBs for this seems like the right answer. Trying to get to an answer where we highlight the difference in the MIB without having to republish it seems like the right answer. It just seems that republishing MIBs seems like a waste of time and effort and won't help anyone. Warren: This gets back to one of our core problems. We often seem to combine code and narrative in one place and call it an RFC and then it's immutable. Maybe stuff like this should be that the MIB was always stored in IANA where it could be updated without having to publish new versions of documents. Roman: So it sounds like I'll propose some squirrely text and send it around, and we'll do a check with the MIB doctors to get a check on the level of difficulty here, and then we'll decide how to update the document. Rob: That makes sense to me. Éric V: Let's say Approved, Revised ID Needed. 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-lamps-rfc7299-update-01 - IETF stream Update to the Object Identifier Registry for the PKIX Working Group (Informational) Token: Roman Danyliw Amy: I have no Discusses in the tracker, so unless there's an objection it looks like this one is approved. I'm hearing no objection to approving the document. I have no notes in the tracker; are there any needed, or is this ready to go as-is? Roman: I'll confess I did not check all of the comments. I think Russ is still promising an editorial fix here and there; I know he staged it but I don't know whether he pushed it. Can we say AD Followup and I'll figure out what has to happen after I look? Amy: Sure; we'll put this in AD Followup and you can let us know. 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 System for Cross-domain Identity Management (scim) Amy: I have no blocks for sending this to external review; unless there's an objection now, it looks like external review is approved for SCIM. I'm hearing no objection, so it looks like external review is approved and we'll send that review announcement and it will come back for approval at the next telechat. Roman: Since we have everyone on the call, if I could ask a question or two based on the feedback that I'm trying to merge in. Ben, I clearly don't get the standards maturation process. Can you say a little bit more about how the approach to do those revisions is not compatible with the stated goal? Do we not want to make a bis document and then advance the bis document? Ben: The typical thing to do would be to have the bis document and have it go as Internet Standard, but there are also these bullet points about profiling relationships with other protocols, and updating the external ID usage, and updating account state to capture some other stuff. It's not really clear what the scope of those updates would be; if they're developing new functionality or new features that would need to go to Proposed Standard first. Roman: I believe the way I would frame it is that it's the more specific version of the vaguer text at the beginning, which is that there are errata and then there is a different implementation experience, and there's a desire to jam that into the bis document. Ben: It may be a matter of we just have to wait and see what it looks like. I apologize that my comments are not very well formed; I'd been hoping to read a little bit more and update them this morning but it didn't happen. Roman: Not at all; I appreciate the review. I'll take a closer look at it and crosswalk with you to see whether we need to make any more edits. Thanks. Amy: Did you want to hold external review until that happens? Roman: No, I'd like this to go out and we'll use the extra time with external review to polish as needed. Amy: Okay, so we'll send that external review message for SCIM tomorrow as we normally would. 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: No news, just one point. The IAB had an interesting talk from Olaf Kolkmann yesterday on the internet standardization policy landscape. That was really interesting, I don't know if slides can be shared, but if they can you should ask the IAB. Beyond that, no specific point. Éric V: Did Olaf give suggestions to improve? Mirja: The point he made was that we see governments have more and more interest in the standardization space and that's something to have an eye on. The request he made to the IAB was to have a little more connection between IAB and ISOC to make sure we are well aligned and we know how to handle that. We have a few IAB members who will have some side meetings with some ISOC people to come up with some guidelines, and will bring them back to the IAB at some point. Ben C: To add a little to that, there was a question about how ISOC can talk about the IETF and how much the IAB and IESG need to be involved in approving those sorts of messages, recognizing that they need to be able to react quickly and speak about things quickly, so anything that requires them to come back and get various groups to agree on a message probably won't be reactive to whatever problem they're trying to deal with. So part of that small group is to discuss how to deal with that. 6. Management issues 6.1 Continuing the RFC 8989 experiment (Lars Eggert) Amy: Lars added this but could not be here today. Is there anything to discuss or should we put this on the agenda for next time? Rob: I'd suggest putting it on next time. Mirja: Is there actually discussion needed, or did we already discuss it by email? Is this just to minute our decision? Éric V: Do we know Lars's point of view? I'm more positive to continue on this one. Mirja: This is the recommendation we gave when we sent this out for community review so I believe he stands behind this recommendation. Amy: Is there any action to take to continue the experiment or has that action already been taken? I'm not clear. Mirja: I'm not sure if there's any action for the Secretariat. Maybe Lars wants to announce the final outcome at some point. I guess we can just minute for now that there are no concerns and see if anything else is needed when Lars comes back. 6.3 [IANA #1210257] Designated experts for RFC 8739 and RFC 9115 (Automated Certificate Management Environment (ACME)) (IANA) Amy: This is to alert Roman that he has this action item. 6.4 BCP14 terms in non-IETF streams (Lars Eggert) Amy: Lars also added this but he didn't really give us any information on what this was about. Can anyone speak to this, or should we continue this for next time? Mirja: I think this came out of the discussion with the independent stream author about the question of if BCP 14 keywords can be used in other drafts and if we need to clarify that in each stream. I think this should probably wait until Lars is back. Ben: I agree, we should wait to discuss this one. It's hard to stop other people from using those terms, so it's pretty clear that's roughly the desired outcome, but we should discuss how to get there and if we need to publish something. Amy: Okay, we'll keep this on as a management item for discussion next time. 6.5 Update to Last Call Template (Lars Eggert) Amy: This also seems fairly straightforward. Lars wants to add a line to the Datatracker template for Last Calls that will automatically be added to the announcements that says something like "A listing of open IETF Last Calls is available at [URL]." This seems like a good idea to me, but is there any discussion needed? Any controversy? Roman: I like it. We should do it. Éric V: Yes, let's do it. Amy: Okay. It sounds like this suggestion is approved. Éric, as the tools team liaison do you want to take that to the tools team? Éric V: That's fine, I will take it. 6.6 [IANA #1210675] Designated experts for RFC-ietf-httpbis-semantics-19 (HTTP Semantics) (IANA) Amy: Francesca knows she has this designated expert request as we discussed at the top of the call. 6.7 Telechat Dates Between IETF 112 and IETF 113 (Secretariat) A schedule of informal/formal telechat dates for between IETF 112 and 113 was discussed. There was essentially only one option for the date rotation, and it was approved and the dates will be added to the calendar. 7. Any Other Business (WG News, New Proposals, etc.) Éric V: Just a quick update on HOMENET; they still intend to close in the coming weeks or months. Barbara Stark is about to retire and has selected Kiran Makhijani as a third co chair, so Barbara can leave whenever she wants and the rest can finalize the remaining document. 6.2 IETF 112 Conflict Resolution (will be taken last) (Liz Flynn) The pre-preliminary agenda for IETF 112 was discussed and deconflicted. The preliminary agenda will be published on 8 October.