Narrative Minutes interim-2018-iesg-09 2018-05-10 14:00
narrative-minutes-interim-2018-iesg-09-201805101400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2018-05-10 14:00 | |
Title | Narrative Minutes interim-2018-iesg-09 2018-05-10 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2018-iesg-09-201805101400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative Minutes of the May 10, 2018 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Deborah Brungard (AT&T) / Routing Area Ben Campbell (Oracle) / Applications and Real-Time Area Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Ted Hardie (Google) / IAB Chair Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Warren Kumari (Google) / Operations and Management Area Terry Manderson (ICANN) / Internet Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Alexa Morris (AMS) / IETF Secretariat Eric Rescorla (Mozilla) / Security Area Alvaro Retana (Huawei) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Jeff Tantsura (Nuage Networks) / IAB Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area REGRETS --------------------------------- Heather Flanagan / RFC Series Editor Mirja Kuehlewind (ETH Zurich) / Transport Area Portia Wenze-Danley (ISOC) / Interim IAD OBSERVERS --------------------------------- John Bradley Mike Jones Andrei Popov NARRATIVE MINUTES --------------------------------- 1.2 Bash the agenda 1.3 Approval of the minutes of past telechats o April 19, 2018: Any objections? Hearing none, these will be posted on the public archive. o April 5, 2018 Revised Narrative Minutes: No objection, those are approved and will be posted. o Narrative Minutes for April 19, 2018: There were no changes. With no objections, those are approved also. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS o Benjamin Kaduk to find a designated expert for RFC 5793 [IANA #1050763]. Amy: This is a management item later in the agenda so we will call this provisionally done. o Alexey Melnikov to find a designated expert for RFC-irtf-cfrg-xmss- hash-based-signatures [IANA #1053888]. Amy: This is also on later in the agenda as a management item so we will pick that up then. o Benjamin Kaduk to ask the designated experts for the AEAD Parameters registry to update the registry noting that draft-nir-cfrg- rfc7539bis will obsolete RFC 7539. Benjamin: Alissa and I have tried to get in touch with the expert but it doesn’t look like the expert has taken any action yet. We continue to attempt to contact them. o Ignas Bagdonas to find a designated expert for RFC 8350 [IANA #1108549] Ignas: Two authors have agreed to serve as experts. I have responded to that email so what is the formal process to get those names through? Amy: You add it as a management item for general approval from the IESG and it will come up as a management item. If you send those names in as a ticket now we can probably get it up on the agenda before the end of the call, and approve them or not as the IESG will. Ignas: Okay, will do. o Alexey Melnikov to find a designated expert for RFC 8323 [IANA #1108770] Alexey: I became aware of this today so this is in process. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-tokbind-https-14 - IETF stream Token Binding over HTTP (Proposed Standard) Token: Eric Rescorla Amy: I have an open position here for Martin, did you want to state a position on anything that might be open? Martin: I don’t have any objection on my side, sorry. Amy: I currently have a couple of Discusses in the tracker for this, do we need to discuss those today? EKR: To be honest, I found the text Ben is citing impenetrable as well. I think we may have some of the authors on this call, maybe they can speak up and explain what this means. John, are you here? No? Okay. Ben, I assume if this is clarified you’d be happy—it’s that you don’t understand it, not because there’s something majorly substantively wrong? Ben: I’d be surprised if they came up with an answer to clarify and I wasn’t okay with it. It’s not that big a piece of the overall draft. EKR: I’ll take the action item to get that done. Alissa raised this point about eTLD+1. I was expecting to look at this quickly and find the answer and I was unable to do so. I was hoping to get some guidance from my friends in the ART area about whether this is a well-done proposal. Alexey: Are you asking about the scope of cookies or the public suffix list, which we used to have a WG that concluded with proposals and people couldn’t agree on anything. EKR: As I understand it, Alissa’s complaint was that the document claims that you can’t find anything lighter than eTLD+1, but cites 6265, which is not in fact anything like that. Then it needs some kind of normative reference to what eTLD+1 is. Alissa: Exactly. I was surprised when I went back to 6265 because I would have thought it does what this document says it does, but that didn’t seem to be the case. It’s a clarification point; This document doesn’t have to be constrained by whatever 6265 does, for any particular reason as far as I can tell, but right now it’s just wrong. Alexey: Do they want to ask the HTTPBIS WG? EKR: I can do that. There are 2 problems: one is that we need a normative reference here somewhere, either a reference to a policy which you could supply, or a reference which gives us normative content. So if there were some document that provided we could reference that, if not we’re proposing a new thing here and we need to work with PSL. Alexey: PSL is a big elephant in the room. We tried to do something in IETF and failed. EKR: I don’t have a problem with normative referencing PSL, but others might because it’s not a stable reference. John Bradley: This is a problem for pretty much everyone. The facts on the ground are that the browser vendors through the WG wanted to but coming up with a normative reference someplace is hard. If someone can help us with that it would be great. Essentially the rule is no wider than the scoping of cookies, but finding a normative reference to have cookies, good luck. EKR: I’ll take the action item to email the HTTPBIS WG about this. Can we all agree now that this may be a little crusty when we get to it and we’ll just have to accept the resolution? Alissa: Sounds good. EKR: I just want to make sure we get this document published. I don’t want to boil the ocean on this. John: There is a difference between user agents as in browsers, which tend to be passive things and aren’t actively involved in the upper level protocols that are using the token binding; vs a native app on a phone which may have its own privacy concerns or want to scope things narrower or broader if it knows there’s a security concern. If you have a correlatable token that you’re using between two points, jumping through hoops to not use the same token binding ID may be unreasonable for some implementations. We’re trying to leave a little flexibility for native apps that have a better notion of what their own privacy and security profiles are, as opposed to say you must do it this way, which is a more reasonable thing for browsers which tend to be generic and not have a knowledge of the upper level parameters. There’s something in there that we’re not clear on. We can work through and try to sort that out for people. That’s the basic idea. Ben: So what you said there is great; I didn’t get that from the text. I think it just needs some clarification about what you mean by the differences there. Another thing I noticed is the text described it from the perspective of the server; if the server is going to work with native applications it needs something. I assume what you mean is to allow this kind of flexibility. John: The server doesn’t know anything about it, it’s how the client itself is constructed when the client isn’t another server. Ben: That’s another place where I didn’t get what you just said from Section 6. I’m perfectly happy with what you just said. So if that can be clarified then I would clear the Discuss. John: I’ll work with the authors to get that turned around, because that’s what it was intended to be. We really do have two classes of things, one which is a user agent which may be relaying HTTP connection through, or if we can ever get the WG to get that sorted, have javascript which is doing things that involve running over token-bound connections but not necessarily reaching down into the stack. So that’s on the server side with javascript vs something that’s native app on Windows which has token binding to native applications … they have some control over where the keys are created and stored. EKR: Are we ready to move on from this document? I think we have two action items. I’ll send HTTPBIS mail pronto. Amy: I’m hearing that this is going to require a revised ID. EKR: Oh yes. I’d prefer Ben and Alexey keep their discusses so that’s a placeholder in the system for what needs to be fixed. John: A lot of the other comments have already been addressed. The authors put out another draft last night, which I don’t expect anyone has read. Hopefully it addresses a lot of the other comments. EKR: Thanks to the authors for being so productive. Amy: That will go into Revised ID Needed and we’ll move on to our next document. o draft-ietf-tokbind-negotiation-13 - IETF stream Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation (Proposed Standard) Token: Eric Rescorla Amy: I have no open positions, but I do have a Discuss. Do we need to discuss that today? EKR: This has the exact negotiation mechanism TLS had prior to 1.3. I don’t think TLS did a very good job of giving semantics to major and minor. It’s almost a naming convention. I’m going to be pretty resistant to the idea of actually changing the negotiation mechanism. If people would be happier treating this as a 16 bit integer I wouldn’t have any problem with that. But I don’t want us to revisit the question of whether we’re going to do highest version negotiation at this point. Alexey: That’s okay with me. Are there likely to be future versions of this? John: Yes. Obviously the authors and other people in the industry anticipate this will become a major feature, as the browsers and the large sites start depending on it. From this perspective it’s seen as a way protocols can meet AFL3 in sp800-63, so these will never mention private sector interests. It’s going to evolve over time, now the question is: as we go forward, if we want to change the negotiation method we would just define a new mechanism and extension number. Likely both things will happen over time. I expect this to be around for a while. EKR: Alexey, do you think some change is needed here? Alexey: I’m not convinced the version number is needed because the rest of its sensibility is already good enough. This was discussed in the WG, so I’ll just clear. John: When we were developing this, having a version number allowed us to do interop testing. Alexey: Early drafts. John: Going forward for testing and other things it will be useful, rather than having to go and ask for a new code point to have a different extension. We want to be frugal on the extension points. If there is a big change likely it would be through a new code point. The version number allows us to have better control over testing and some potential conflicts going forward. Some people think version numbers and version negotiation leads to bad things, but there are also benefits. I’m sympathetic to that position. Practically, getting it out in the world, version numbers help. Alexey: I’m not objecting to versioning, I just think the documentis underspecified in how it’s going to be used. I’ll clear. John: So essentially there were the 2 points, one was around the negotiation mechanism and one was around the meaning of the version number. If we clear the version number, are we okay with the TLS 1.2 type negotiation? EKR: I was hearing Alexey say you can do both. Alexey: Yeah, I’ll just clear. If you want to stop calling them major and minor that would be an improvement, but. .. John: I think there’s a general feeling in the WG that having 2 digits for the version number is somehow more humanly comprehensible. On the other hand people might believe there’s more significance to it. We could keep the common format and add some text around ‘don’t believe that there’s any difference between incrementing a major number and a minor number,’ something like that? Amy: For this document I have that Alexey is going to clear but that hasn’t happened yet, right? Alexey: Give me two minutes. EKR: John, do you believe the authors have covered all the other points? John: I think so. EKR: Since I haven’t had a chance to read that document, why don’t you mark it Revised ID Needed, and I’ll read that relatively soon. John: If we only need one revision past this, we’ll be so lucky. EKR: John, if you could do me a favor and let me know when you think it’s ready for approval? Per the previous document, I emailed the HTTPBIS WG and Alissa two minutes ago. Hopefully we can resolve that quickly. Amy: Once Alexey clears, this will go into Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-tokbind-protocol-18 - IETF stream The Token Binding Protocol Version 1.0 (Proposed Standard) Token: Eric Rescorla Amy: I have no Discusses in the tracker for this doc, so unless anyone has an objection it looks like it’s approved. John: There was a new draft put out last night that should have addressed everything. We need to go through and make sure we’ve actually captured all of it. In the questions there was lingering confusion about why we’re not addressing. .. no that’s another one, so we’ll leave that. For protocol we’re good. EKR: For the same reason, let’s mark it revised ID needed. Once we have the Discusses cleared I’m going to go over all three. Amy: That will go into Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-bess-evpn-prefix-advertisement-10 - IETF stream IP Prefix Advertisement in EVPN (Proposed Standard) Token: Alvaro Retana Amy: I have a Discuss in the tracker, do we need to discuss that now? Alvaro: No I don’t think so, the authors seem to be waking up to the fact that they need to respond so I’ll give them a chance to do that. We’ll definitely need a Revised ID Needed. Amy: This will stay in IESG Evaluation and Revised ID Needed. Moving on. o draft-ietf-homenet-babel-profile-06 - IETF stream Homenet profile of the Babel routing protocol (Proposed Standard) Token: Terry Manderson Amy: I have no active Discusses. Unless there’s an objection, it looks like this is approved. Terry: It will definitely be Revised ID Needed please. Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID Needed. Terry, let us know when it’s ready. o draft-ietf-hip-native-nat-traversal-28 - IETF stream Native NAT Traversal Mode for the Host Identity Protocol (Proposed Standard) Token: Terry Manderson Amy: I have a couple of open positions. Ignas, did you want to state a position? Ignas: Let this be a No record, I did not do a detailed analysis. Amy: Okay, no record for Ignas. Warren? Warren: No record, I didn’t look at it. Amy: And Alexey said no position. I have a couple of discusses, do we need to discuss? Terry: No, there’s no point in discussing the discusses yet, I’ve not seen any meaningful responses from the authors to address EKR’s or Mirja’s discuss. I’m going to have to make this Revised ID Needed. Amy: This will stay in IESG Evaluation and go into Revised ID Needed. o draft-ietf-secevent-token-13 - IETF stream Security Event Token (SET) (Proposed Standard) Token: Benjamin Kaduk Amy: I have no open positions and no discusses, so if there are no objections it looks like this is approved. Are there any notes needed? Benjamin: I don’t think so, the authors have been good about pushing updated IDs as comments come in. I think this one can go into Approved, Announcement to be Sent. o draft-ietf-uta-mta-sts-17 - IETF stream SMTP MTA Strict Transport Security (MTA-STS) (Proposed Standard) Token: Alexey Melnikov Amy: I have several Discusses in the tracker, do we need to discuss those today? Alexey: Yes I think so. For EKR’s, that discussion is ongoing and should be settled by email. Adam, yours is relatively trivial but I’m waiting for a response from the authors. Do you agree? Adam: I suspect what is intended here is that TLS RBT [Correction: TLS RPT] needs to change, and this document probably reflects consensus, but however it plays out they just need to say the same thing. Alexey: Yes, the other one is not approved yet, so I think that’s fine. Warren, would you like to talk about your discuss? Warren: Yes please, I would love to. This document reserves _mta-sts.domain name —— which makes me a little twitchy that it does it by just burying it in the text. However that’s what we’ve been doing up until now. That’s the standard way of reserving one of these TXTs. Dave Crocker is working on creating a registry to record these. So what I think would be a reasonable way forward is to carry on with this document as it is and suggest that Dave please add this to the document he is working on. That seems reasonable. What is more concerning is that the document also reserves the label mta-sts.whatever the domain is with no underscore. This is something I don’t think has been done before. There’s nothing that says you can’t do it, it just feels weird and sketchy. I also think it sets a dangerous precedent, but seeing as there’s nothing that says you can’t do it, I can’t really fault the authors that much. We also currently do that kind of - for example, even though it’s not documented anywhere, everybody assumes the web server for foo.com is www.foo.com. It’s not written down in a standards document. What might be a reasonable thing, but it would require a change to the document, is that the underscore text label would specify the name, or label, that then you use to look up the policy. You could specify a label of “foo” and then preset foo and that tells you where to find the policy. It feels odd to at this point suggest that they’ve done things wrong. I don’t really know how this should proceed. I don’t know if the WG would be open to just adding this; it seems like a simple change. Alexey: I have no idea. I suggest you ask the question. Maybe there are good reasons not to do it, or maybe everyone says it’s fine and let’s do it. Warren: I will also apologize to them for not catching this earlier. Ted: I went back and looked at this and the closest I could find to a reservation like this was really early notes on conventions. There was a group of FAQ like descriptions of what the dimensions were where network services were commonly - postmaster was reserved as a mailbox but the convention for where you got to send mail was SMTP. None of those were reservations and there’s a note in them that basically says if this doesn’t work, you need to find out another way of finding out what the correct one is because there’s no necessity that it be this one. Benjamin’s point in the jabber that some people are going to be too cool for the convention is definitely true. There’s no enforcement mechanism here that says you must use this one. The only thing that will happen is that if someone doesn’t reserve this name according to the way the document is currently written, they can’t use this standard at all. I think it would be fine for them to say, here’s how you specify a label in the record, but you could also say conventionally this is mta-sts, and absent such a label expression, that’s where you should go. If you did that, it goes back it not being a convention. Too, anyone who’s already done it this way, it will work, but we’re not trying to tell the entire DNS community thou shalt reserve this. We’re simply saying, anybody who’s already using this, this is what it means, and if you want to do something different, here’s the protocol mechanism for making that work. I think there’s a way of going forward that takes security into account but also doesn’t break anything that’s already out there. Warren: I really like that. There is a concern that if someone’s not expecting this and has a machine called mta-sts, they will suddenly be getting a lot of queries for things they don’t know what to do with, but oh well - if you have a machine on the Internet, you’re going to be getting queries you don’t know what to do with. I like that. Alexey: Ted, if you could write something in jabber, that would be amazing and then I can cut and paste. Ted: Will do. Adam: One thing I’d be careful with: we want to look at the security properties of doing this, vis a vis somebody standing up a server that is publishing false policies and somehow getting banned from the DNS. Warren I guess that’s true; if I can register that name in a domain I can break mail by having a bad error or something. Adam: The scenarios I’m concerned about are you have a domain with subdomains under it that are under different control. Similar to what Alexey mentioned, having something more like roguedepartment.something.edu would cause the same issues. I think someone needs to sit down and think about the security aspect of having this become unpinned from a known name. It just warrants a little bit of time. Warren: It looks as though there are likely to be solutions. I don’t know if I should leave my Discuss. Alexey: Leave your discuss, send an email, and we’ll see how the discussion progresses. If we can conclude on this particular topic in a week or so that would be great. The only other issue on this document is I’ve sent email to IESG saying that registration doesn’t quite fall under current tools, so I’d like to approve an exception for this document. I hope people are okay with that. Alissa: Did you talk to Mark about that part, that we would approve the exception? Alexey: I did tell them that I would ask for an exception. Alissa: Okay, that’s fine. Alexey: This document will definitely need a new revision. Amy: Great. We will keep that in IESG Review with a substate of Revised ID Needed. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-teas-sr-rsvp-coexistence-rec-03 - IETF stream Recommendations for RSVP-TE and Segment Routing LSP co-existence (Informational) Token: Deborah Brungard Amy: I have no active Discusses in the tracker, so if there are no objections, it looks like this one is approved. Deborah: We’ll do this Point Raised. Amy: Certainly. This will go into Point Raised, Writeup Needed, and Deborah you can let us know when that’s ready. o draft-ietf-hip-rfc4423-bis-19 - IETF stream Host Identity Protocol Architecture (Informational) Token: Terry Manderson Amy: I have no Discusses in the tracker for this document, so unless anyone has an objection it looks like it’s approved. Any notes needed? Terry: Actually I think this needs to be a Revised ID Needed. I didn’t see comments being addressed from the authors. If you could put it as Point Raised that would be great. Amy: I can do either Point Raised or Revised ID Needed. I’ll put it in Revised ID Needed. Terry: Thank you. No notes are going to be needed either. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-hoffman-dns-in-json-15 - IETF stream Representing DNS Messages in JSON (Experimental) Token: Alexey Melnikov Amy: I have no Discusses in the tracker for this document, so unless anyone has an objection it looks like it’s approved. Alexey: Can I have this in AD Followup? There are some comments which I think also reply to the comments in the revised document but I would like to catch the rest. Warren: There had been some discussion about should this be informational or experimental? I don’t know if the IESG needs to decide ahead if it’s okay for that to change? From what I remember the authors said do whatever you want on that front. Alexey: Shepherding AD says I don’t really mind either way. Warren: Does anybody object wildly if it’s changed to Informational, ad that way the AD can decide? Spencer: The amount of review we ask for is the same so I would not have concerns about changing. Alexey: Let’s change it to informational then. Neither would require another last call. Amy: Okay, so this is going to change the intended status from experimental to informational. It’s Approved, Announcement to be sent, Point raised. Are they going to do a revision of the document so the header says informational? Alexey: I don’t know. Let’s do Point Raised, AD Followup. Amy: You’ll figure all that out? Okay. 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.3.3 For action o status-change-kerberos-3des-rc4-to-historic-00 - IETF stream Deprecating 3DES and RC4 in Kerberos (Status Change) (None) Token: Eric Rescorla Amy: There was a document that went along with this that we probably should have had on this agenda as well, but we missed it. EKR: That document was on a previous telechat and had discusses that were about this. I think what needs to happen is that Mirja needs to clear her Discuss and then we proceed. We’re now pretty far into the weeds as far as process. Amy: I think you’re right, the document now has its status change and both the status change and the document will go together. If the document has a discuss on it, that needs to clear before this can go as well. It’s not something we do very often. EKR: Maybe I should just ping Mirja and ask her to clear her discuss. Amy: I think you’re right. Then when her Discuss is cleared, that document can go as well as the status change can be sent at the same time. You can just let us know when that’s done and we can get them sent together. 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 Messaging Layer Security (mls) Amy: I currently have no blocking comments for this chartering effort, so if there are no objections this can be sent for external review. Hearing no objection, we will send that and put it on the agenda for the next telechat. 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Benchmarking Methodology (bmwg) Amy: I do currently have a blocking comment. Warren, do we need to discuss that? Warren: Yes please. There are two requests in it; one is the milestone for one of them. The document which is currently referred to in the milestone is overly broad, and sounds as if it’s doing more than it’s intended to. The authors have promised they will fix it, largely by removing Section 2. I fully agree that they’re not the WG to do that. I don’t know how Deborah wants to handle that, if she wants to trust the authors and WG chair and myself to make sure that the document is more narrowed, or if she’d rather that we removed the milestone or something. Deborah: What I found lacking was any description of taking on this type of work in the description. They have a huge several paragraphs that they’re going to do DNS now. If you look at the existing older type work, none of this fits any of that. I think if they even think they want to be looking at adopting those documents they need a couple sentences to say what they’re planning to do with it. Warren: I think what it’s supposed to be is only scoped for benchmarking and measurement. The document was adopted when it was way more broad. It’s supposed to be simply explaining how you — Let’s see whether you, myself, Elle, and Sarah have a chat? I believe this will be narrowed down purely to cover benchmarking stuff, which I think is covered in their text. Deborah: We can talk among ourselves. Even if they could just add a couple sentences. If they really feel this fits in that’s fine. Still, they need to add a sentence to say, because everybody from the other groups will pick up on these acronyms, they need a sentence to say they’ll coordinate with those other groups when needed. Warren: Chairs also suggested they add something saying they will continue to work with people like the operating community, etc, and coordinate with other IETF WGs as well, as they are already doing. We will chat more offline and I think that’s the only blocking position. Amy: Are we just going to wait for instructions from you about when this might be ready for external review? Warren: I wasn’t quite sure how the process on that works. It’s not a document so we do meet much less often. If it were a document I’d guess it stays like this until the equivalent of a discuss is cleared, then I guess I send email saying I think it’s happy to go. Amy: You could do that. If you think it requires an external review we can do that. Warren: I don’t think it needs external review. Deborah, do you think it needs external review? Deborah: If the appropriate wording is added I don’t think it needs external review. Warren: Excellent. We will chat, and once we’ve decided I will send mail to the Secretariat. 4.2.2 Proposed for approval NONE 5. IAB news we can use Deborah: No news. I can give an update. They’re still discussing to scope their work items. The other item is what they will do for the technical plenary for the next meeting. As soon as I have some news I’ll let you know. 6. Management issues 6.1 Designated Experts for WOTS+ Signatures, XMSS Signatures, XMSS^MT Signatures [IANA #1053888] (Alexey Melnikov) Amy: Alexey has taken this and recommended that two of the editors from the draft-irtf-cfrg-xmss-hash-based-signatures be approved as experts. Any objection to naming Andreas Huelsing and Stefan-Lukas Gazdag as the experts? Hearing none, we will call those approved and send an official note to IANA. 6.2 [IANA #1108549] Designated expert for RFC 8350 (Sabrina Tanamal/IANA) Amy: Sri Gundavelli and Li Xue have offered to be experts. Any objection to them? With no objections, they are approved as experts. 6.3 [IANA #1108551] Management Item: Acceptance of media type registration from standards organization ETSI (Amanda Baber/IANA) Amy: We are looking for a blank permission approval. Alexey: Amanda asked me whether we should just register them but I said it requires full IESG approval. I think this can go in parallel. The main point of IESG approval for this is a sanity check to make sure we recognize them as an established organization and we have some confidence they usually know what they’re doing. Ben: I was a little surprised by this because they’ve brought the Tetra audio codec to the PAYLOAD wg. These appear to be related to that, but I guess they don’t make sense for PAYLOAD. So maybe it makes sense like this. Alexey: Would you like to follow up with them? Ben: I don’t see it as a problem. These are all related and it’s clear this is all part of a bigger system. PAYLOAD is probably the only place where we have a WG for what they’re doing. Adam: This sort of thing could be done as a draft through DISPATCH, as it’s just a registration of a MIME type. But I think having it registered directly by ETSI makes more sense. Ben: How accessible are their documents these days? I don’t know if that changes anything. Alexey: Typically expert reviewers will see the documents for the formats. They’re not accessible for everybody to see. Ben: I guess that’s better than nothing. I didn’t mean any of that as an objection, just for your information. Amy: I’m not hearing any objection to approving this? Alexey: Yes I think we are approving ETSI and a designated expert will review registration separately. Amy: Okay, with that approval we will send the official note to IANA. 6.4 [IANA #1108770] Designated expert for RFC 8323 (Sabrina Tanamal/IANA) Amy: We will mark this as in progress, since Alexey is now aware of it. 6.5 Designated Experts for RFCs 5792 and 5793 [IANA #1050763] (Benjamin Kaduk) Amy: Benjamin would like to approve Steve Hanna, Jessica Fitzgerald-McKay, and Charles Schmidt as experts. Any objection? Hearing none, they are approved. 6.6 Current IESG procedure for allowing Secretariat to manage telechat queues (Alexey Melnikov) Alexey: I think the last message in the thread suggested that we should email the Secretariat when we issue ballots, since this does not happen automatically. I just want to agree that’s the process. I already issued three or four ballots and I want to know what to do with them. Amy: Speaking for the Secretariat we would greatly appreciate if we got word when you issue a ballot and something is ready to be put on a future telechat agenda. Until the tooling catches up; we’ve asked for tooling changes for that. We need to know when you all think something is ready. Alissa: Don’t the ballot issued emails go to the IESG list? Alexey: I think you’re correct. Alissa: Why isn’t that sufficient? Cindy: The sheer volume of traffic makes it hard to track what we need to follow up. It’s much much easier if it comes to us as a ticket. If we try to track that on the IESG list we will almost certainly miss things. EKR: Can you filter? Most mail systems have a way to filter. Warren: It does feel like something that takes a copy of this and forwards it to the ticket system, I’m guessing Glen, writes a - - Adam: I imagine the change to the Datatracker is less than one line, and pushing out a new Datatracker release is easy. Instead of asking Glen to do something we should ask Henrik. Warren: Sounds like an answer to me, if Henrik has time. Alissa: We were worried about getting the GDPR compliance stuff done but it sounds like Henrik will have that finished up this week. I assume Henrik could do this next week since it takes like ten minutes. Do you disagree, Alexey, Ben, EKR? Alexey: This can be done with tools, that’s fine. Ben: So does that mean the change in procedure doesn’t start until Henrik does that? Spencer: Seems much easier, if we start the procedure when that tool becomes available. Doing it the other way doubles the number of emails we send to the Secretariat. Alexa: So just to be clear, are we asking them to just add the notification to send mail to IESG Secretary, or the further automation of actually doing the initial loading of documents onto the agenda that Amy and Cindy will manage, which was the other solution we proposed? Ekr: I thought they’d send mail to the ticketing system. Alissa: I think the email is the short term solution. The alternative was that we send those emails manually. We can figure out prioritizing the larger piece of work later. Alexey, since this was yours, do you want to email tools about this? Alexey: Okay. 6.7 Proposed note re agenda experiment at IETF 103 (Alissa Cooper) Alissa: I sent a revised version of this yesterday and wanted to see if there are any objections to it going out. Looks like no objections - I will send it sometime today. 7. Any Other Business (WG News, New Proposals, etc.) No new business.