INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2020-08-13 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Deborah Brungard (AT&T) / Routing Area 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 Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline / Loon LLC / Internet 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 Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Robert Wilton / Cisco Systems / Operations and Management Area REGRETS --------------------------------- Jenny Bui (AMS) / IETF Secretariat Jay Daley / IETF Executive Director Wes Hardaker (USC/ISI) / IAB Liaison Magnus Westerlund (Ericsson) / Transport Area OBSERVERS --------------------------------- John Bradley Chris Box Toerless Eckert Timothy McSweeney David Millman Nat Sakimura 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Alissa: I'd like to have an executive session about these terminology threads. 1.3 Approval of the minutes of past telechats Amy: Is there any objection to approving the minutes of July 9? Hearing no objection there, so those are approved. Is there any objection to approving the minutes of July 16? Hearing no objection to that either. We also have narrative minutes for July 9 and July 16. Any objection to approving the narrative minutes for July 9? Hearing no objection. Any objection to approving the narrative minutes for July 16? Hearing no objection there either. 1.4 List of remaining action items from last telechat o Martin Vigoureux with Wes, and Alvaro to work on some mechanism to obtain wider or private feedback from people who are disenfranchised; anonymous flagging of offensive emails to inform leadership; more opportunities for private feedback. Martin V: This is still ongoing. We pinged Pete on the ombudsteam again because we didn't hear back from them. o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov, Martin Vigoureux, and Roman Danyliw to work on more transparency in the Datatracker about how long each phase of doc process takes / New datatracker flag to indicate who has the ball: area directors, authors, or chairs. Barry: That's still in progress. I'm going to have something on next week's informal where we can talk about it. Murray: Should we take off Alexey's name? Barry: We left his name on because we thought he might have input, even though he doesn't have the action item anymore. Murray: Okay. Just curious. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: Still in progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Eric V: Still in progress. o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: Please leave this in progress. Michelle, did you get the links I sent about this? Michelle: Yes, thank you very much. I'll look through those and add our feedback. o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT Systems charter. Eric V: I still need to talk to Suresh, so work in progress. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Alvaro: I'm going to say that's still in progress. The next one is in the same boat. o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to draft text on the framework for a long-term future plan for the IETF. In progress. 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 talked to the tools team a little bit and anything is doable, because it's a relatively easy mod to the datatracker. They have a couple of questions about how we would envision the workflow. Right now when you have the wiki, anyone with a Datatracker credential can create a marker for a BOF. If we move it into the datatracker, would that be a similar expectation, that anyone in the community can spin up something that's the equivalent of an earlier phase of what we now call a BOF or a working group? We may want to think about that. Additionally there were some questions about timing. I'll write that up. Alissa: My initial reaction is we definitely don't want this creating new objects in the Datatracker. This should be a web form that people can put a bunch of information that spits out a table or something. Right? Roman: I'd certainly lean that way as well personally but the way I remember us talking about earlier was that we wanted something with a bit more formalism so a BOF request would look very similar to an already approved BOF or an in-flight but not approved WG, and what we were doing was creating an earlier state for that and us being able to manage it in that workflow. But that creates all sorts of access control things. Mirja: It shouldn't create an object immediately because that means people can jump on acronyms that we want to use later for WGs and block them, basically. That's also something we don't want. We need a state before that. Roman: Why don't I take this to the informal so we can keep moving? There are still a lot of questions here. Let's mark it as in progress and move on for now. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. Alvaro: We're also in progress. Murray: Are errata supposed to be normative references in a document that incorporates them? Alvaro: I don't know. I've always thought maybe not, I've always thought informative references. Murray: I just saw that a document this week had that and I was curious. Warren: I guess it sort of falls into the normal thing of 'is it required that somebody reads this in order to understand it?' If the errata is something that's really important someone knows about, that's one thing, or if it's just more information or clarification. If you were on a desert island would you be able to implement the protocol without it? Murray: I guess that's maybe something this could cover. Since I had a question about it I thought I'd mention it. Thanks. o Magnus Westerlund to find designated experts for the RDMA-CM Private Data Identifiers registry (RFC8797) [IANA #1173341]. Amy: Magnus could not be with us today so we will keep this in progress for him. o Ben Kaduk to find designated experts for RFC 8784 [IANA #1173591]. Ben: That has a management item that supersedes it. o Murray Kucherawy to find designated experts for content SDP Parameters, QoS Mechanism Tokens [IANA #1175036]. Amy: IANA added this not too long ago, so this is to alert you that you have this action item. Murray: Great. I should have something by the next formal telechat. o [All IESG] to follow up on the suggestion at IETF 108 to share a list of grammar checking tools with the community. Alissa: I really wanted to find a stuckee for this so that it's someone's responsibility to collate this list. Eric V: Sounds easy and doable; put my name. Alissa: Thank you. o Eric Vyncke to find designated experts for RFC 8801 [IANA #1175284]. Amy: This is provisionally done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-core-resource-directory-25 - IETF stream CoRE Resource Directory (Proposed Standard) Token: Barry Leiba Amy: I have a number of Discusses; do we need to discuss any of those today? Barry: We haven't heard from the authors yet, so we just need to let them respond. Keep it in AD Followup. Eric V: If you don't mind, Erik and I have a small comment. When we're requesting a change or getting a new code point about ipv6 it would be nice to involve 6man at some point in time. You can just send an email with the draft. Barry: So that's basically to everybody. So how do we make that happen? Eric V: Simply sending an email to the 6man list. Barry: So all the WG chairs have to know to do that? Eric V: There's a reason why I say it here, to the IESG level, so if you see something. It's not mandatory, more like a courtesy and double checking. Ben: This is a good match for some of the hot topics lists that some areas had been making, like ART had one that Adam was driving and SEC has one. We've tried to pass those out to our directorate review teams as a tool for them but also to the broader IESG and also possibly all the WG chairs to get visibility into these hot topics at an earlier stage of review. Erik K: Is this list of items available somewhere? Ben: It should be on a wiki page. I'll see if I can dig up the link. Barry: It would be nice to pull out the items from those various lists that are more global and have a concise list for ADs to reference. We'll do our best but it's going to be difficult to remember all the different pieces. Roman: I think this came up in 2019 and the way we did this was each area came up with the list of hot topics that commonly come up in their area and we were going to try to push it to our directorates and also broadcast it more broadly in the community, for example if you don't want to get ensnared in common security issues, check this list. [https://trac.ietf.org/trac/iesg/wiki/ExpertTopics] Barry: So for this document it's AD Followup. o draft-ietf-lamps-rfc7030est-clarify-10 - IETF stream Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 (Proposed Standard) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there's an objection it looks like this one is approved. Hearing no objection to approving this document. I have an IESG note in the tracker; is this one you want to go with the announcement? Roman: Can you mark this AD Followup? There are some things we need to clean up based on the comments. Thanks for all the feedback with 2616 and changing the errata, that was a helpful reminder. Amy: This will go into Approved, Announcement to be sent, AD Followup and you can let us know when it's ready to go. o draft-ietf-ippm-route-09 - IETF stream Advanced Unidirectional Route Assessment (AURA) (Proposed Standard) Token: Martin Duke Amy: I have a Discuss for this document; do we need to discuss it today? Martin D: No, it looks like the author is on it. This is Revised ID Needed. o draft-ietf-dhc-v6only-07 - IETF stream IPv6-Only-Preferred Option for DHCPv4 (Proposed Standard) Token: Eric Vyncke Amy: There are no Discusses in the tracker, so unless there's an objection it looks like this one is approved. Hearing no objection to approving this document. Eric V: We just need to wait for the approval of the in a couple of comments. Amy: So it sounds like this will go into AD Followup. Murray: I think they're waiting on an answer from me for some stuff; I'll get to that today. o draft-ietf-mmusic-msrp-usage-data-channel-23 - IETF stream MSRP over Data Channels (Proposed Standard) Token: Murray Kucherawy Amy: There are no Discusses in the tracker, so unless there's an objection it looks like this one is approved. Hearing no objection to approving this document. Murray: Ship it. Amy: There are no notes needed, is that correct? Murray: Yes. Amy: Great; we will get this announcement sent on Monday. 2.1.2 Returning items o draft-ietf-oauth-jwsreq-26 - IETF stream The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) (Proposed Standard) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there's an objection it looks like this one is approved and ready to go. Michelle: Not quite yet. It looks like since the last time this was Last Called three years ago they've added a bunch of IANA actions that weren't there before. We have some expert reviews out and we're hoping to get those back so we can continue. Roman: We'll hold the document for all that. There are also some good edits to make based on this subsequent review. I want to reiterate to everyone, thank you for your iterative feedback to get this ready to finally publish. It's been a long way. Amy: So this is Approved, Announcement to be Sent, AD Followup until we're ready to go. Murray: I noticed the directorate reviews for this one date back to the first time it came up to the IESG and there have been 15 revisions since then. Do we have any common practice or guidance around circling this back around to at least some of the directorates before we ballot on it again? Roman: We might want to have a general practice. The reason I felt comfortable with this is that there was one particular issue that Ben was working with the team on iterating, so that was the primary change that went into this document. It just took a long time to get us there. Murray: I could have asked the question on the list, I probably shouldn't have interrupted us here. It just came up because that happened and there was another document on this telechat where the shepherd writeup was terribly stale and someone else brought that up. I'm just wondering if for things that are returning we should revisit some of these things. I'll take it to the list. Ben: The current practice is just at the discretion of the shepherding AD. I don't think we have a more formal policy or anything. o draft-ietf-anima-autonomic-control-plane-28 - IETF stream An Autonomic Control Plane (ACP) (Proposed Standard) Token: Eric Vyncke Amy: I have a number of Discusses here. Eric, do we need to discuss those? Eric V: It would be cool for me and I noticed Toerless the anima wg chair is also on the call. It would be nice to have a short discussion. Roman, [name unclear] suggested some text around your Discuss point. Is the proposed text ok for you? If you've had time to read it. Roman: I did not see Brian's response. He proposed a more general approach about some of the references to put in and I believe I responded to him that those are good. I had one or two more things to put in that text. I think that would resolve that last Discuss I'm holding. Eric V: Okay. That would be good. Ben, if you don't mind, you have a good point about this downgrade attack. I'm unsure about potential action by the authors. Should we add the text in security considerations? Your comments are quite sensible and your explanation text is quite clear, so it would be nice if the authors agree we can just copy paste your text into the considerations. Ben: That would likely be reasonable. The main point I had as a Discuss level there was just to make sure my understanding and summary was accurate. I don't think there's a discuss level we need to make a change to the document if my understanding is actually correct there. It would be reasonable to take something like that text and put it in the security considerations but I was not trying to hold a Discuss and say that we have to add it to the security considerations. Eric V: I get your point about the certificate check based on the prefix, which I think makes sense and the authors will be happy to change it. Barry, I agree the text sometimes could be clearer and is ambiguous at some points and we can fix. Your point about having only two code points and creating an IANA registry and handwaving about extensibility later is another good point. We'll try a change with the authors and see. Barry: On the point about the namespace, the idea was to have the discussion. It may be that the result of the discussion is that it's fine the way it is. I don't mean to insist on a change, I mean to have the discussion. Eric V: Perfect. And the Discuss from the other Erik, [unintelligible] they are previously isolated so shame on me on this one. That's all for my discussion, unless somebody else wants to say anything. Amy: It sounds like this will need a revision? Eric V: Yes, Revised ID is obviously required. 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 o draft-allan-5g-fmc-encapsulation-05 - IETF stream 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) (Informational) Token: Erik Kline Amy: I have a few Discusses here; do we need to discuss those today? Erik K: We could, or we could try to take it on the list. I have not fully digested everyone's Discuss feedback; thank you for all the reviews. I'm not sure what the best way forward is. There was a mention of seeking an EBF liaison statement, there were some IPR concerns raised. Splitting the document into two documents, an independent submission and a separate standards track for the IANA registry. I'm not sure what the best way forward is. If there's time, we can discuss it; if not, we can follow up on the list. Alissa: From my perspective I think an additional Last Call that explicitly states the IPR question the way you normally would in a working group would be sufficient. I don't think you need a liaison statement. There's been a bunch of people chiming in since the ballots started flowing in so I think that's a good demonstration of support for the document. Alvaro: From my point of view I'd like to hear from you whether you think there's IETF consensus or not and why. That's really the question I'm asking there. I may not agree in the end, or we may both agree, but let's start there. We don't have to do it here, we can do it on email, but if you think there's consensus we can move forward somehow. Erik K: I heard no arguments against it. The literal handful of folks who still care about PPPoE and this sort of thing are in support of it. I'm going to guess in terms of measurement scales the activity is maybe too low. I don't know what you can say when... [trails off] Alvaro: Sometimes when you look at WGs there's also very low activity. When I first looked at this I didn't see anything except directorate reviews. After balloting other people came out saying they support it, which is a good thing. I think this was probably not the type of document that 8789 or whatever it is had in mind. It was probably something more contentious than this. It's probably too bad this is the first test. This is not the type of document anyone wants to die for. From my POV I'm prepared. I'm just asking the question; if you think there's consensus we can move forward. I'll think about it and clear my Discuss, I might abstain in the end, but we should be able to move forward. I just want to say one other thing, not for you but in general. Now that we're starting to get these types of documents [like] 8789 from gendispatch, changing IETF process, maybe we need to be a little more vigilant to that. They probably don't get as much discussion or exposure as many of the other work does. There was a lot more discussion on the list about 8789 about this draft but the number of people participating in the discussion is relatively small compared to the whole IETF and it affects the whole IETF. So just a soapbox rant here. Warren: I think this is one of our standard problems in the IETF, is that our definition of consensus by design is very vague. Sometimes it does kind of come down to 'nobody is actively objecting to the document and we think there's value.' Which is different to our normal discussion and view of consensus. When we were doing 8789 I was fairly uncomfortable with it. In some cases this falls into the HBU type thing where there is some value, 99.9999% of the IETF doesn't care, but one or two people think it's worth having. Barry: 8789 was different. I don't think that's really the issue here. 8789 was addressing that it was possible in the past to AD sponsor a document that was informational and never do a Last Call on it. That's all 8789 is addressing, that we need to record IETF consensus by having a Last Call on any document that comes through the IETF stream. That's not an issue for this. The general issue is how do we decide that a document with two reviews has IETF consensus? That's a little more of challenge. This came up some years ago when I tried to hold a discuss on a document because as far as I could tell only two people besides the authors reviewed it, and in the end we let the document through. We need to have a conversation as an IESG at some point about how to make that judgment and what to bring back to the community for their opinion, because I think the community really needs to decide the answer to this question in general. Warren: You're right about what 8789 says. I was using it as a shorthand for the whole consensus question, which used to take an almost infinite amount of time, like can you do an informational document that has No marked in the datatracker. Ben: I think that is the key point, that the process for assessing consensus is fairly vaguely defined and largely subjective. At some point it's a judgment call based on the WG chair or responsible AD as to what the consensus is and whether there is consensus. One thing that's useful to have in mind at least for me as we think about that is if somebody who was knowledgeable in the IETF were to take a look would there be anything surprising in there? We can have already established consensus on general ideas and topics through previous documents and precedent and if everything in this document in question is consistent with that and it's an incremental addition or boring changes, there's more of a presumption that there's consensus. If there's completely new stuff then it's harder to say. That's just something to keep in mind but I tend to agree with Barry that we need to be keeping with what the community wants. We can't keep winging it forever. Deborah: While we all may feel confident in this group of authors and people speaking up on the list, it's really a misrepresentation for a couple of people to come to IETF, do a document, and claim it's needed by another SDO. [muffled] this is an extension request by the BBF. A year or two ago we had that BCAUSE BOF and they were so against it because the document was from a group of authors and they said it was not with BBF and we had to liaison with BBF. It's why we did the whole change control process document on liaison-ing. It was exactly that to avoid that we have groups of authors coming and claiming to have the hats on of another SDO and it just meets the needs of the other SDO. They stand on different sides of the fence. When this group of authors was against the BCAUSE work, they wanted to liaison. Now they're on the other side of the fence and they're saying we don't need to liaison, we represent BBF. You can't have it both ways. And the BBF meets in two weeks so I don't see any difficulty why they can't get a liaison to tell us what meets their needs. Barry: As I said in my response to Donald, or I didn't say this part, the general thing about liaison relationships is that we prefer cross-participation to liaison statements. I'd like not to change that, I don't want us to be starting to insist on liaison statements for all communication between SDOs. Deborah: He totally misrepresented that, Barry. That's actually in these documents, it's in the 7775 and it's in our document on change control. It's in the documents. You need to have a group of authors, according to IETF process, on a document. That document, by the time it reaches maturity, needs to be liaisoned back to the group. You can't just have those people that are on the author team say it meets the needs. We have run into so many problems with this in the past. While this looks very simple and we trust these people that are the lead people, it's just the process how we have said to deal with other SDOs. If they want to keep that sentence there about the Broadband Forum, making it look like it meets the Broadband Forum's outcome, we've got to liaison. Alissa: I think that's a fair argument. I was really concerned about hanging this up for a lot longer but if the impression is that they can send us a liaison statement in two weeks that solidifies it, and we might have to re-Last Call the document anyway, I think we can have all of the needs met. Erik K: We can certainly do that. Deborah: We can say let's have a liaison to BBF see what's in this document, we understand it's a work in progress, does it meet the needs, or we can just expect David Sinicrope to go to BBF, which he does, to say they need to liaison. I have no idea where this document is in all this stuff but Donald indicated it's one of the documents being referred to. Warren: I may have lost the thread somewhere. Looking in the document, I don't see anything saying that this is specifically requested by BBF. What it says is that it acknowledges some comprehensive discussions in BBF. Alissa: He said it on the list. Warren: Thank you. That's where I lost the thread. Deborah: If this was just by a couple of individuals and had nothing to do with BBF, then probably it should just go independent stream because we'll probably have other vendors coming and requesting a code point. We could even have BBF or 3GPP come in with a request for a code point. Warren: I'm not disagreeing. I just wanted to make sure I understood what the actual status was. Having a liaison seems useful. I do think that it would often be nice if we had a slightly easier, less formal way of doing liaison type stuff without doing a liaison statement. I realize it's not hugely onerous but something like we kind of have with the IEEE Yangsters, which is not a great example either, but something similar where we can say we want to get a temperature of the room, does this sound vaguely right? Erik K: Do we need to issue a liaison statement to request a liaison statement, or can we just ask the authors to bring it up with the BBF and have them send us one? Deborah: We can do it either way. I'd just contact Sinicrope and ask what he wants to do. Warren: And also what exactly it is we want the statement to say. Largely, do you think this is something that's useful to you? Deborah: And does it overlap with work ongoing? We have no idea. Maybe like with the BCAUSE bof, they have other stuff going on. Mirja: I'm all into double checking to make sure, because that's what we have liaisons for, but us requiring the other SDO to send a liaison in order to process an action is something we usually don't do. If we want to do this step we should carefully think about it. Erik: Can you repeat that last statement? Mirja: It's usually not us, the IETF, who is requiring other SDOs to send a liaison statement in order for us to do actions. That's a process other SDOs do often, but we don't usually do it. If we want to do it we should consider it carefully. What we should do for sure is we shouldn't publish a document where we don't think it's the right thing to do. We have to use our own procedures to figure out that the document is valuable to publish in the RFC series and we need to make sure that it has the quality and review that it needs to be published here, and we should also coordinate with the other SDO to figure out that there are no conflicts, but that coordination is why we have a liaison relationship and it doesn't need to be formally via a liaison statement. Erik K: I heard if they're meeting in two weeks, it might be possible, I'll talk to the authors to see if they'll send us a liaison statement if that's what they want. I heard Alissa say maybe a second Last Call with an explicit IPR call-out, so that's another four weeks. Alissa: I think two weeks is okay. You have some flexibility if time is of the essence; I don't know if it is. Erik K: I don't know if that's choosable in the Datatracker? Alissa: Just tell the secretariat what you want and they can do it for you. Erik K: Okay. And then there was a question of whether or not it should be expert review or specification required. The IANA registry for these PPPoE version numbers. Warren: Would you mind reminding me how big the code space is and how used it is? Erik K: It has so few values, a single value, that there was never even a registry for it. Eric V: Four bits. Warren: In that case it seems like spec required might be-- Barry: The difference between expert review and specification required is not relevant to that aspect. Either way an expert reviews it. The question is just whether it's important to have a specification explaining how the extension works. Alissa: It just seemed like the kind of thing that would be super useful, in the way that this document itself is, they didn't just go off and do it without writing a spec. Erik K: It seems fair to ask them to point to a TR number. Any other things? I'll take the rest offline, then. Thank you. Amy: It sounds like this is going to require a Revised ID? Erik K: At minimum. 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items o status-change-comcast-congestion-management-rfc6057-to-historic-01 - IETF stream Change the status of Comcast Congestion Management (RFC 6057) to historic (None) Token: Martin Duke Amy: There are no Discusses, so unless there's an objection now this status change is approved. Martin D: Ship it. 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-cooley-cnsa-dtls-tls-profile-00 IETF conflict review for draft-cooley-cnsa-dtls-tls-profile draft-cooley-cnsa-dtls-tls-profile-04 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 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 with the writeup currently in the tracker. Hearing no objection, so we will send that out. o conflict-review-moriarty-caris2-00 IETF conflict review for draft-moriarty-caris2 draft-moriarty-caris2-03 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report (ISE: Informational) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there's an objection now this conflict review can go back to the ISE with the writeup currently in the tracker. I'm hearing no objection so this will be sent. o conflict-review-irtf-cfrg-randomness-improvements-00 IETF conflict review for draft-irtf-cfrg-randomness-improvements draft-irtf-cfrg-randomness-improvements-13 Randomness Improvements for Security Protocols (IRTF: Informational) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there's an objection now this conflict review can go back to the IRSG with the writeup currently in the tracker. Hearing no objection so we'll get that sent. 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 o Network File System Version 4 (nfsv4) Amy: I have no blocking comments for this recharter, so unless there's an objection now this is approved and we will send out the WG action recharter announcement. Hearing no objection; since Magnus is not here we'll check with him to make sure he's okay before the message goes out. That will happen shortly, whenever he is back from vacation. 5. IAB news we can use Alvaro: The only thing I want to mention is that yesterday the IAB approved the EDM program. Tommy had been on the call a few weeks ago to talk about that. Now they're figuring out the logistical details, so keep an eye out for that. 6. Management issues 6.1 IKEv2 Parameters DE updates (Ben Kaduk) Amy: We want to add an expert to complete the set for him? Ben: Right now there are a bunch of registries on that page and almost all of them have a single expert. The idea is to have two experts for every registry on that page, so it's adding one expert to one registry and one expert to all of the others. Amy: Any objection to adding the expert for all of these registries? Hearing no objection, so that is approved and we will send official note to IANA. 6.2 IESG Positions - Desired Expertise descriptions (Martin Vigoureux) Martin V: That was really a trigger to all of you to make sure you take the time to review the descriptions. Some of you have already done so, so that's good. For the specific AD positions, there are 2 elements that might require the attention of everyone. One is the generic description, although I don't think there's any real need to change. One more specifically pointed toward you, Alissa, on the IETF chair position since it hasn't been updated since you took the job. Alissa: I updated it. Martin V: Okay, that's great. Thank you very much. I know Warren did the OPS side, and on RTG we did a couple of updates. So everyone, please take a look at yours and update it. Eric V: Eric and Erik have completed theirs as well. Martin V: Perfect. One question I had was on the generic description. We assume that ADs meet physically and develop a working relationship. Should we change anything with regard to the generic description considering the possible continuation of our virtual meetings, or not? Barry: How would that affect the Nomcom's decisions? Martin V: I don't think it is subject to affect the Nomcom decision, however it is subject to affect the way we work together. Barry: It could affect whether someone was willing to take the position or not. Martin V: I'm not promoting one way or another. Warren: Doesn't this change because some subset of people haven't been willing to run because they don't think they can travel to meetings because of funding or whatever? Or have I lost track again? Martin V: It wasn't really related to funding or anything, it was more related to building relationship amongst the ADs. Warren: I've heard of at least one candidate who is unable to run for a position because they will never be able to travel to meetings, partly for health and partly for money. Eric V: I agree Warren, when I was Nomcom liaison and had access to all the feedback, at least one potential AD declined the nomination because of travel issues. We need to keep this sentence there; who knows when we will meet again. It needs to be there. Alvaro: What is the sentence we're talking about? The one about potential travel? Martin V: That's for Eric to answer. Eric V: The sentence about physically meeting. Martin V: There are two references to travel; one which says that because of the time and travel commitments, we imply travel commitments. Alissa: I think we should keep that, but I think your point is fair, Martin, that people need to be comfortable joining a leadership group that might not meet in person. I think it's fine to add a little bit of text about that. Martin V: That was really my point, in the domain of virtual teams. That's substantially different from occasionally physical meeting. Barry: The question is still open: are we open to having an AD who participates only remotely and does not come to meetings? Do we want to say that's a possibility? Warren: I'd thought it was always a possibility, just that it was heavily frowned upon/discouraged. If for example we could only find an ART person who refuses to leave their country, that would still be okay, but it's worth considering. Barry: The only thing I recall in history is someone whose health was such that there were several meetings in a row they couldn't come to and we worked it out fine. We could use that as a precedent to say, don't rule out somebody just because they can't come to meetings. Warren: I think that should be right. The Nomcom is a bright set of folk who are humans and consider things. If our choice is between having someone who is truly awful who can show up, or having someone who is awesome but can never possibly show up, it's worth letting the Nomcom make a decision. Alvaro: Is there anything in the current description that would preclude that, or is it just that we all assume, including the Nomcom, that we have to travel everywhere? Barry: I think it's the latter. If we want the Nomcom to consider people who can't travel, we should say that explicitly if that's what we want. Warren: There is also something to be said for people who have already participated in the IESG and who are unable to travel. Someone who is relatively known in the community, has already served on the IESG, and couldn't travel, that would probably be more okay than if someone we've never interacted with were to be appointed. Roman: That's really subjective. Warren: Yes. But this is basically a job description, then we interview someone for a job and we hire them or not. All of that is wildly subjective. Alissa: But our part of that is just the description. We should leave the rest to the people whose responsibility it is. We just have to tell people what this job entails, and under normal circumstances it entails travel to meetings because that's where you get all the work done. Warren: Okay; that's all fair. Martin V: I'm not sure, Alissa, if I understood. Should we try to add a few words about physical vs virtual or we should leave that out of the description and consider that part of the decision process of the Nomcom? Alissa: I think your point is a good one, which is to point out the possibility that this person will be joining a team that for the foreseeable future only meets online, and they need to be comfortable with that. This is kind of obvious, to anybody living on Earth, but otherwise I think the text about travel doesn't need to change. Martin V: Okay. I'll try to draft a couple of sentences along those lines and submit them to you all. I still have a week or so. The Nomcom plans on sending the call for nominations on August 25, so we have a little time. I need to explain the IESG in detail to the Nomcom. The descriptions are fine enough but they need to be absolutely finalized by the 24th. That's it for me. Thank you very much for your feedback. 6.3 [IANA #1175036] Designated experts for content SDP Parameters, QoS Mechanism Tokens (IANA) Amy: This is a reminder that this action item has been assigned to Murray. 6.4 [IANA #1173341] Designated experts for the RDMA-CM Private Data Identifiers registry (RFC8797) (Magnus Westerlund) Amy: Magnus has identified a designated expert for this registry. Is there any objection to approving Chuck Lever? Hearing no objection so we'll get official note sent to IANA. 6.5 Designated Expert listing for URI.ARPA (Alissa Cooper) Alissa: Basically, this comes from the discussion around RFC 3172 and it was pointed out that the document presumes the IESG is the designated expert but the registry page doesn't actually list that. The question was whether we could just ask IANA to update the registry page to make that clear. Barry: I'm confused because we have a designated expert, right? And the IESG is always the backup, the IESG can approve any registration. Alissa: I don't think we have a designated expert for this. Barry: I thought Ted Hardie was. Michelle: Just to clarify, which specific registry would this be adding an expert for? Alissa: This was Ted's suggestion and I've lost the thread. Michelle: Graham is the expert for the URI schemes registry. Alissa: But not for ARPA. Michelle: On the protocols listing page, we don't have a registry per se for URI.ARPA because it's a second level zone. So that's why I was trying to figure out where we would be adding this. Alissa: Could you put it on the ARPA zone management page? Michelle: Potentially. Alissa: It's just another place to document what's already in the document, but that was the suggestion. Barry: The IESG approves registrations in URI.ARPA? Alissa: Yeah, exactly. Ben: It seems like it would look weird to only say something about URI.ARPA on the ARPA zone management page, at least the way it's currently structured. Alissa: If people are generally supportive maybe we can work on crafting exactly the precise text and bring that back. Barry: I think that's better. Let's look at this in more detail and figure out exactly what we want to do. Maybe it should be part of the 3405 update rather than doing it as a management item. Michelle: I'll go back and find out what possibilities we have for where we can add information to the ARPA page. Barry: Whatever it is, we should do it right rather than throwing out a management item and being too quick about it. Alissa: Sounds like a plan. Thank you. Amy: So it sounds like this is going to come back? Alissa: Yeah. I'll bring it back when it's ready. Or it might go into the document and not come back. 6.6 [IANA #1175284] Designated experts for RFC 8801 (IANA) Amy: Two experts have been named for this registry. Any objection to approving Tommy Pauly and David Schinazi? Hearing no objection, so we will send official note to IANA. 6.7 [IANA #1175507] Management Item: Acceptance of media type registration from standards organization OPC Foundation (IANA) Barry: I looked into the organization, it looks legitimate, and Alexey as media type expert recommended we accept them. I think we should. Amy: Any objection? Alissa: Seems like a legitimate standards organization. Amy: Okay, this is approved and we'll send note to IANA. 6.8 IETF Datatracker and number of positions required to pass a Standards Track Document (Secretariat) Amy: We thought that when we went from 15 to 14 IESG members that the algorithm in the datatracker would round down to 9 instead of up to 10. The datatracker actually does round up to 10. So for standards track documents we would need ten yes or no objection positions to pass. If you don't want to change that we don't have to, but if you want to change that we can. What would you prefer? Barry: Rounding up is the customary thing that happens. If the US Senate with 100 members needs a 2/3 majority that becomes 67, not 66. That seems like the right answer. If we want to make it nine we can make it nine, but I think ten is not an issue. Alissa: Does anybody know what it was when there were previously 14 members on the IESG? Amy: I think it was nine but that was a really long time ago and the Datatracker was very different. Warren: How often do we run into issues where this is actually important? It doesn't seem like that often so I think we should keep it at ten. Barry: It's not often that it's a long term problem but you see it happening when ADs turn over and we need more reviews. It happens quite often but it's not generally a problem. It would only be a problem if we had four or five abstentions and that happens very rarely. Warren: I think ten. Roman: I say ten. Warren: Does anybody strongly object to ten? Amy: Great, so no change to the datatracker needed and we'll keep 10 as the target number for minimum yes and no objection. Thank you all for talking it out with us. 6.9 IESG Retreat (Alissa Cooper) Alissa: I asked this on the list and didn't get any response so I just wanted to double check. Last time we did Tuesday and Thursday, three hour slot with a break in the middle, from 1400-1700 UTC. I was wondering if people wanted to follow that format or do something else. Roman: That looks great. Let's do that. Mirja: Do we have topics for six hours? Alissa: I'm sure we could talk about how to form consensus for six hours. [laughter] We can do some social time too. What we did last time was block off all the time and if we don't use it all, you can have time back. Let's put it in the calendar and create the page to collect topics and see what we get. Amy: We will block out that time for the retreat. 7. Any Other Business (WG News, New Proposals, etc.) None 8. Executive Session