Narrative Minutes interim-2019-iesg-07 2019-03-14 14:00
narrative-minutes-interim-2019-iesg-07-201903141400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2019-03-14 14:00 | |
Title | Narrative Minutes interim-2019-iesg-07 2019-03-14 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2019-iesg-07-201903141400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2019-03-14 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 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 Mirja Kuehlewind (ETH Zurich) / Transport Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Eric Rescorla (Mozilla) / Security Area Adam Roach (Mozilla) / Applications and Real-Time Area Jeff Tantsura (Apstra) / IAB Liaison Martin Vigoureux (Nokia) / Routing Area Amy Vezza (AMS) / IETF Secretariat Magnus Westerlund (Ericsson) / Incoming Transport Area REGRETS --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Ben Campbell (Oracle) / Applications and Real-Time Area Roman Danyliw (CERT/SEI) / Incoming Security Area Heather Flanagan / RFC Series Editor Suresh Krishnan (Kaloom) / Internet Area Warren Kumari (Google) / Operations and Management Area Barry Leiba (Huawei) / Incoming Applications and Real-Time Area Terry Manderson (ICANN) / Internet Area Alvaro Retana (Huawei) / Routing Area Eric Vyncke (Cisco) / Incoming Internet Area Portia Wenze-Danley (ISOC) / Interim LLC Executive Director OBSERVERS --------------------------------- Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to approving the minutes from March 7? I know that was only last week, so if anyone needs more time to review them let us know. Hearing no objection and no request for more time, so it sounds like these are approved. Any objection to approving the narrative minutes from March 7? Hearing no objection there either; those will both be posted. 1.4 List of remaining action items from last telechat Amy: I don't think any of the people holding these action items are present today. Alissa: Could we ask about these by email? Would you mind sending that mail? Amy: Sure. Do you want targeted emails or a group? Alissa: Just one mail is fine. And perhaps also ask if any of these require discussion in Prague. Thanks. o Alvaro Retana to send email to the IESG with proposed re-labeling of scheduling conflicts. o Suresh Krishnan to discuss naming experts for the registries created by draft-irtf-icnrg-ccnxsemantics with Allison Mankin. o Ben Campbell to write up text on the IESG's expectations regarding conflicts of interest and the disclosure of funding sources. o Suresh Krishnan to draft a new proposed IESG Statement on the procedure to reference material behind a paywall, that includes the existing text and adds comments from the discussion, Eric Rescorla, and Barry Leiba. o Roman Danyliw and Barry Leiba to identify and catalogue common problematic and inappropriate behaviors from individuals in the IETF community both at in-person meetings and on email lists. o Barry Leiba talk with the EDU Team on the Working Group Chairs Forum agenda, possibly adding an item to discuss agenda conflicts and unstructured time. o Suresh Krishnan to report on the progress of the response to the Liaison Statement on "Request to update the IoT and SC&C Standards Roadmap and the list of contact points." 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-mpls-lsp-ping-lag-multipath-06 - IETF stream Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces (Proposed Standard) Token: Deborah Brungard Amy: I have a Discuss in the tracker; do we need to discuss that today? Deborah: I don't think so, unless someone wants to. The authors are in communication. o draft-ietf-6lo-nfc-13 - IETF stream Transmission of IPv6 Packets over Near Field Communication (Proposed Standard) Token: Suresh Krishnan Amy: I have several Discusses in the tracker, and Suresh is not on the call. Do we have a feeling this will require a Revised ID? Ekr: I cannot see how it would not. Amy: That would have been my feeling too. We'll put that in IESG Evaluation, Revised ID Needed. o draft-ietf-kitten-pkinit-alg-agility-06 - IETF stream PKINIT Algorithm Agility (Proposed Standard) Token: Benjamin Kaduk Amy: There are no Discusses in the tracker, so unless there's an objection it looks like this one is approved. Benjamin: Please put it in Revised ID Needed. Ekr: To close the loop on this, I do think the security considerations improvement is important. If you'd like me to take a look at a revised version I'm happy to do it. Benjamin: Thanks, I may take you up on that; although I think I have a pretty good understanding of what you want to see, and I agree with you. Ekr: That was intended merely to help take some load off, since I will have free time. Amy: Okay, this will go into Revised ID Needed and you can let us know when it's ready. o draft-ietf-uta-smtp-require-tls-07 - IETF stream SMTP Require TLS Option (Proposed Standard) Token: Alexey Melnikov Amy: I have a couple of Discusses in the tracker; it sounds like this may need a Revised ID? Benjamin: I think we've been waiting for a revised ID for a while now. Even though Alexey isn't here, do we want to talk about the general topic of having one Proposed Standard try to stick its fingers into a different Proposed Standard and change how it works, without any sort of updates relationship or other indication? I think it's mostly been Alexey, Ekr, and me on the mailing lists; I don't have a sense if other people have thoughts about that. Ekr: My Discuss will expire quite soon, but Ben and I have talked and I think he understands my position enough. We need a new ID, basically. Benjamin: We're basically coming from the same place. (Later, once Alexey has joined) Alexey: Benjamin, can you provide a summary of what you think the outstanding issues are? Benjamin: I think there are basically 2 or 2.5 issues. One is just that we need to be very clear about what the validation procedure actually is for the various cases. The DANE case is quite clear, but there are also some cases where you're using normal web PKI certificate chain validation and I didn't have a clear sense what the rules were for that validation. The other one is this more generic bit about when can one protocol reach its fingers into another protocol and change how it works? What are the requirements procedurally for how we make that happen? Do we see this as being a bug fix that's updating the behavior of these other specs or is it a new thing that's overriding them? This is essentially the same issue as Ekr is raising. And then the half issue is this thing at the end about the tag and the header being mutually exclusive, which is not really a Discuss level point. Alexey: I agree with your first and last issues and that should be relatively easy to resolve. As far as whether this is updating the base text, it's an extension. The hopes are it's going to be used, and we'll see how widespread it's going to be. I personally doubt it will be as widespread as TLS. I think it's improving some use cases, especially the case of actually saying "I want TLS all the way through." Benjamin: That's the part that's not worrisome. I don't necessarily need TLS. I'm not objecting to the desire to do that, I'm objecting to the way we are specifying it and the procedural aspect. I understand Victor's stance to be essentially that DANE and MTA-STS are essentially buggy in that they prioritize strict confidentiality over actually delivering the messages. The current mail infrastructure is designed to prioritize actually delivering the messages. There's a bug in the existing spec and we need a workaround for it. Alexey: The difficulty also is DANE and MTA-STS provide a host level granularity and this extension is more likely to apply to a specific recipient. Benjamin: It's message level granularity. Alexey: It is message level but it's also likely to be used with special accounts, like postmaster. At the moment there is no way of expressing the policy, "please always send me TLS but you can use non TLS for postmaster," for example. Ekr: Why not put that policy there? MTA-STS and DANE overreached and should have had exceptions. This is now adding exceptions in an odd way. Alexey: So you are saying there's a missing piece on the recipient side to advertise this? Ekr: If you can say "Use TLS except for these accounts," then the version of this that says "I don't care if you use TLS" would be entirely unnecessary. Alexey: I think I need to think about this. This is the first time you've phrased it this way. This way it's actually actionable. We might disagree at the end but this is something the WG can discuss. Benjamin: It's unclear to me the use case would entirely go away, but it would drastically diminish. We had some examples about "Do you want to go have lunch?" from one user to another user that was raised as a case where you don't necessarily care about TLS. Ekr: This is a thing I do want to beef up a little bit. I think it's generally a mistake to assume only one party in a communication can decide this communication isn't sensitive. Both sides need to agree. As evidenced by the data leaks you see in Strava when people on a military base get shown. Benjamin: I wasn't saying I accept it, just that's a potential case. Ekr: I feel like the sense of our documents is we should bias towards things being secure, so that's why I'm sad about this. Alexey: Even if the text is edited to say the recipient's policy on MTA might override the RequireTLS, that also probably needs a text edit. I think that's probably going to be less controversial. Okay, so I think I probably need to discuss this with the WG. If you have specific suggestions that would be much appreciated. The discussion was a bit abstract and on some level people were disagreeing with the whole philosophy and it was difficult to figure out what was actionable. Benjamin: My attempt at a minimum viable suggestion was to add an updates header and say we're proposing this new mechanism because we need to update the behavior of these existing specs because they do not work for us in this way. Alexey: If it was a new protocol I wouldn't mind, but this will have a side effect of saying that all these other wonderful extensions which are way more widespread are not updating the base spec. People will start asking why is that. I think we need something more nuanced here. Benjamin: When you say extension, you mean SMTP extensions specifically? Alexey: Yes. Benjamin: I wasn't saying to update SMTP, I was saying to update DANE and MTA-STS. Alexey: Oh, I see. That makes more sense. Fine, maybe updating STS and DANE might be a reasonable thing to do, yes. Did you mention this in email? Benjamin: I thought I did, but given that we're having this discussion I should check. Ekr: We are between two cases: one is the case where the sender thinks the data is insensitive and doesn't care if encryption is used, and the other case where something is actually going seriously wrong and this is effectively a control channel, and you're trying to keep the control channel alive. Those are the postmaster cases. It would be good to distinguish which one this is for. If it's for the former, the philosophical point is that senders should be able to mark things as not sensitive regardless of the desires of the recipient. If the point is we just want these control channels to work, that point is much more strongly addressed by trying to carve out an exception on the receiving side. I'd like to tease out whether or not the proponents of this are actually trying to solve the former case or just trying to solve the latter case but figured this was the easiest way to solve the former. Alexey: It was originally started as the former case, and then the latter case was added. As we started going through it, we realized there are more subtle differences than people anticipated for the latter case. Ekr: I'm having trouble understanding how the "require TLS: no" bit practically gets set? Surely it's not going to get set by users pushing a button. Right? That doesn't seem practical. Alexey: The user aspects are difficult. Ekr: What I was assuming was somehow this flag gets set and then they get processed differently. I don't understand how it gets set other than in the case where I've repeatedly tried to deliver to postmaster and I keep getting a bounce and now I'm going to un-set it. Alexey: It has to be set by the sender because intermediaries are not supposed to mess with this. Ekr: But when you say sender you mean I, Ekr, am the administrator of my domain. I'm sending to your domain and I keep getting bounces from TLS failures. Now I go in and I have some header that says ignore the TLS failures and deliver to them now. Alexey: You have a checkbox saying "send this email, dammit, I don't care about TLS." Ekr: That actually clarifies it and I think that makes my argument more compelling. I'll draft an email. Alexey: Thank you. Ekr: I think this was a good discussion, thank you. Alexey: This will need a new revision. o draft-ietf-mpls-sr-over-ip-03 - IETF stream SR-MPLS over IP (Proposed Standard) Token: Deborah Brungard Amy: I have a couple of Discusses in the tracker; do we need to discuss those today? Deborah: I don't think so, unless someone wants to ask something. This can just stay in IESG Evaluation, Revised ID Needed. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items o draft-faltstrom-unicode11-08 - IETF stream IDNA2008 and Unicode 11.0.0 (Proposed Standard) Token: Alexey Melnikov Amy: I have a couple of Discusses in the tracker; is there anyone who can speak to this? Alissa: I was just talking to Alexey and he got the time zones mixed up, can we come back to this and he might be able to join? (Later, once Alexey has joined) Spencer: We waited for me to clear my discuss until you were on the call so you could celebrate. Please clear mine. Alexey: Excellent. I hope people had a chance to read my summary email of the discussions. I think people on the internationalization directorate are happy for IANA tables to be approved up to Unicode 11, and have this document as a reference. The document itself will need a few tweaks. People prefer to incorporate Unicode 12 into it and that would require another IETF last call. Do people have any questions? Spencer: My first question is, how badly do you think this needs a second IETF last call for trivial additions? Alexey: Basically between versions 7 and 8 there were some editorial changes which I don't think need IETF last call, but some people argue you might have to. For Unicode 12 you need one because it's extra unicode code points and more description of them. The reason why people in the directorate prefer to fold Unicode 12 into this is so when the RFC comes out of IETF it will be up to date with versions of Unicode published so far. Spencer: That seems very reasonable. If we are doing a Unicode 12 version in six weeks, before the first RFC can even reasonably be published, then it's a trivial update. It seems like that's the right thing to do. I saw Ted's thing in the Jabber about adding Unicode 12 seeming obvious, and I think that is a good point. Alexey is saying basically the differences are trivial. We've certainly made bigger changes in IESG Evaluation without doing another last call. That's what I was thinking about. Alexey: I think we need to do a last call because this is AD sponsored. I'm not convinced another four weeks are needed, so maybe we can do a 2 week last call to look at the difference. Spencer: You might want to make these changes in the Unicode 11 draft so it would be a second last call for the same draft, not a two week last call for a new AD sponsored draft. Alexey: I'll figure out the logistics of it. Spencer: I was trying to balance how responsive we can be vs how ugly it would be to get a process appeal on Unicode 12. Alexey: In general, we don't need to publish one of these documents for each version of Unicode, unless experts find some incompatible changes. Which is why this document was so problematic, because the expert wanted to have a discussion about incompatible changes. Certain Unicode code points changed their properties. For Unicode 12 in particular there are no code points that changed their properties so it's going to be much more straightforward. Benjamin: Ted had raised this issue about the relationship between the AD and the I18NDir. Ted: We've had a side conversation about that and I consider it resolved. 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-trans-rfc6962-bis-31 - IETF stream Certificate Transparency Version 2.0 (Experimental) Token: Eric Rescorla Amy: I have a lot of Discusses in the tracker. Do we need to discuss those today? Ekr: Is Adam on the call? Adam: Yes, I am. Ekr: I'd like to understand what you think the scope of the change you'd like is. Adam: There's what I would like, and then there's the minimal change that would satisfy the Discuss. What I'd like is for the specification of the use of URI templates here, because that's really what the use they specified is begging for. But I recognize that's a relatively large change. What people usually do when they come across a BCP 190 violation like this, is they say fine, we'll move it under .well-known and I think that would be an adequate, if somewhat unsatisfying resolution. Ekr: Maybe I don't understand. The effect of the URI template document would be to effectively shove a system defined prefix in front of the paths that it specified in this document? Adam: No, when you provision the location of a log, you wouldn't just put a URL prefix, you'd put a URI template. Which includes slots into which you would insert the information like version and operation they're currently encoding as hard coded strings. Ekr: What do you mean "you"? Adam: In the case of normal CT usage, it'd be the web browser. Ekr: No, it's not the web browser. Benjamin: The log operator, right? Adam: The thing the log operator hands out to clients that would upload certificates or check the validity of certificates. Ekr: Maybe let's take a step back. The system here has a structure where the log operator fixes a prefix, and all of the other URLs are defined essentially by prepending that prefix to a fixed script, correct? Adam: Right. That is precisely what BCP 190 says not to do. Ekr: I'm trying to understand what the wire protocol impact of what you're suggesting is. Adam: Right now the log operator is handing out these prefixes. This is admittedly a provisioning difference, but there's going to be a software impact if you do it this way. Ekr: I need to tell you, this is a dumb objection on the part of BCP 190. Adam: These are two separate approaches. Ekr: My point is that if it's accessible to have it in dot-well-known I don't know why it's acceptable to have it anywhere else. Adam: Dot-well-known is carved out as the one exception, where it's basically the escape valve. It's the equivalent of having the ISE; if we have applications that are unwilling or for technical limitations unable to do things in one of the other two ways mentioned in BCP 190, this is the catchall thing you can do with two lines of prose in an IANA registration to solve the problem. It's not a great solution, which is why I'm saying it's not my preferred one. But it does address the situation that BCP 190 has normative guidance in a BCP about how we treat URLs that went through IETF consensus. Ekr: So did this document. Benjamin: I think I can jump in and clarify somewhat. I'm taking Ekr's stance as saying that in the current version, the server is providing you essentially the URLs to use for these APIs. In the URI template version, the server is still providing you URLs to use for these APIs, just in a slightly different package. The main difference between the two is that if you're using a template, the log server could change around the order of the parameters. The log server is giving you stuff to use. The BCP 190 compliance aspect of that is you're now enabling the server to chose these parameters vs path vs other stuff, whereas in the current version it's just you have to use these particular fixed strings and you have some control over where they appear, but you don't have full control. Is that an accurate summary? Adam: Yes. Ekr: Okay, I think I understand this position. It's ironic that at my last telechat I'm the one complaining about a late surprise. This document is a bis of a document that's already widely on the internet, and we're already having trouble getting people to do it. The reason this is experimental and not standard is we're having trouble getting people to roll out the bis in a timely fashion. I'm not in favor of doing something none of these people are going to care about, so the URI template needs to be off the table. I can try to get back to this with dot-well-known, but it strikes me as an elevation of philosophy over reality. I'll go back to them with this. I'd like a management item to discuss how the IESG doesn't get us into this situation again. How can it be the case we have a standard being developed and we get to the point of IESG approval and nobody knows about it? I'm trying to imagine a situation where we're in QUIC and we discover at IESG time something this major. Can we talk about that at the end of the call? Adam: Sure. I'm pondering; we have a lot of similar things people get hit with when things go through IESG evaluation. Ekr: Sure, but I think this one is silly, so I'm willing to push on it. Some of those are important and some of them are silly. Having this show up at the end is painful. Alissa: It sounds like you're just objecting to BCP 190? Ekr: I more or less am, but I'm saying this needs to be caught earlier in the system. What are we going to do to make that happen? Alexey: Would you like an ART webpage describing common issues and this BCP will be listed as one of them? Would that help? We used to have one of those and people kept ignoring it anyway. Mirja: I think this is why we have IESG evaluation, to catch these kinds of problems. Of course if you can detect it earlier that's helpful, and needs more cross-area work, but that's why we have this evaluation step. Alexey: I'd like to automate validation of this BCP, but I don't think it's realistic. Adam: What kind of regular expression can I throw at drafts as they land in the repository that would find this in particular? Ekr: This strikes me as something that's very important to a small community. Let me take a look at the archives and see how much support this actually had. Here we have something which everybody who designs these protocols wants to do, and yet we have some rules that they're not supposed to do that. That strikes me that it's actually out of touch and not common practice. Alissa: Isn't that how all squatting problems manifest? Every individual wants their own thing to just work the way it has worked before, insofar as they were squatting on some part of the space. But collectively we say if we keep letting this happen, we're all going to be screwed, which is why we did BCP 190. Ekr: I think the question is whether this in fact should share a resource. The fact that Adam's letting us put it dot-well-known strikes me as not actually a shared resource. Adam: Dot-well-known is the escape valve. Ekr: I don't think that's accurate. Dot-well-known's primary purpose is to be something we believe is almost unconditionally controlled by the server. And not controlled by random people on the site. Alexey: It's a side effect. But it's a thing guaranteed not to be used unless you want to use it for a specific purpose. If you want to run multiple services on the same web server, you cannot use dot-well-known; you need to use a different prefix. Ekr: But we have dot-well-known foo and dot-well-known bar, right? Adam: And there is a registry for that. Ted: I think the registry is an important piece of this, because it's where, in addition to the carveout that these things occur in dot-well-known, it's that these things occur in dot-well-known and here's the registry you look at to know what I should be using and where it exists. The combination of those means here's only a tiny part of the URI space that's carved out for this and how it's carved out is determinable. If we just said we were going to carve out dot-well-known and squat there, we'd have exactly the same problem we're trying to avoid. Ekr: I don't think this is an issue of squatting. Imagine a counterfactual where we shift everything left by one and said that when people design a protocol we're going to ensure you need to use this prefix on every IETF protocol we choose for applications that use HTTP. You can have a registry there. The not squatting impact would be the same. There's a question of interference with non standardized applications, but for standardized applications you could put the registry in slash. Ted: If there were no non-standardized applications that would work, but that's not the system we're trying to put forward. Benjamin: I said something in jabber but it might be worth saying out loud. Suppose we did make a well-known URI for this purpose, but we leave the mechanism between the document in place. The server can assign a prefix and you do this after it. If this server wants to have full control over its URI namespace, it can use this well-known prefix and it's all isolated. But the server can also choose to do what it wants. Would that scenario still be considered a BCP 190 violation? Adam: I think that's still problematic, but I'd have to think through it a little more closely. It's prohibited by the words on their face in BCP 190. I'm also trying to unwind the objection to just saying that these prefixes must appear in dot-well-known, and have a registration for that. Ekr: I think I've conceded that I'm going to push them to do that, but I think this is a silly rule. I would like to understand how we get to the point where we don't have a situation where people fall afoul of these silly rules at the end of the process. You don't think it's a silly rule, but I do, so I feel silly going back to the group to rejigger this. I'd like not to have to do that again. In any case, I think this is not a well known rule. The evidence of that is that the last two protocols I've seen that used HTTP I don't think do this. They're both in the Security area, so maybe the problem is SEC. But it would be nice if this was better understood. Adam: So for the conversation which you want to return to later, I do want to make certain we're teasing out the late surprise issue from the BCP 190 issue. It's clear you don't agree with the provisions that are in there, but I think that is orthogonal to the community being unaware of certain things that are required in documents to get them published that they might not find out about until IESG evaluation. Ekr: Sure. My point is the second; the reason these two are intertwined are there are things you ought to know when you're designing your protocol, that your protocol will be extremely bad if you don't do them. Those things, they should be better known. Also things that are just rules which I would be hard pressed to say your protocol would be extremely bad if you didn't do this. So those are the things where we end up with late surprises, that it won't work without them, which this does not. Adam: That's the case with almost any namespace issue. If someone gets to the end of something and has squatted on the code point, their protocol is going to work just fine. But that's still an issue we need to have addressed because you can't just have uncoordinated chaos. Ekr: This is the point where you and I disagree, but what I'm pointing out is that it should be notified better. Adam: I do not disagree with that. That's a large problem with just about everything that we expect of documents when they come for IESG review. I'd argue that the majority of Discusses we ever see fall into the category of things WGs legitimately should have known before sending it to us, but we're bad about having all of this knowledge disseminated across everyone who participates. Ekr: I suggest we table that question. Adam: I think it kind of goes to the heart of the question about late surprises. Ekr: If people want to have this conversation now we can, but maybe we should go through the rest of the documents. Alissa: I think maybe we should take this to Prague. People need some time to think about what kinds of things could be done here, and whether to solve just for this case or more generically things that are late surprises. We can add it to our agenda for Prague. Amy: Talking about this document in particular... Ekr: Revised ID Needed. Amy: Thank you. o draft-ietf-mpls-sfc-encapsulation-03 - IETF stream MPLS Transport Encapsulation For The SFC NSH (Informational) Token: Deborah Brungard Amy: I have a Discuss in the tracker; do we need to discuss that today? Deborah: I don't think so, unless someone wants to discuss it. I'll let the authors respond in email. 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 3.4.3 For action o conflict-review-irtf-cfrg-re-keying-00 IETF conflict review for draft-irtf-cfrg-re-keying draft-irtf-cfrg-re-keying-14 Re-keying Mechanisms for Symmetric Keys (IRTF: Informational) Token: Alissa Cooper Amy: This has been assigned to Benjamin and we will see it after IETF 104. 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Deborah: I don't think there's anything. Ted: Yesterday's meeting was a record for brevity, so there's nothing to report. 6. Management issues 6.1 Approve update to IDNA parameters registry of derived property values (Alissa Cooper) Alissa: The question is if anyone objects to us asking IANA to update the tables once the expert validates them. Ekr: I strongly endorse that. Spencer: Whats the opposite of 'strongly object'? I'm doing the same thing. Alissa: Okay. Do they need an email from us? Probably. Amy: If it was any other IANA thing we'd send an official note on behalf of the IESG, but this is after the expert validates them. Will you let us know when they're validated and we can send that email? Or help us with the text of that email? Alissa: I think you can just take the text of the management item and put it in the email. They know what to do. Amy: So we can send that now so that when the expert validates to IANA and they'll just update the tables. Alissa: Alexey, are you on board with that? Alexey: Yes, it seems reasonable. 7. Any Other Business (WG News, New Proposals, etc.) Adam: I want to flag for the IESG that in the week or so since the 00 deadline, on which three different drafts dealing with operational issues surrounding DOH were submitted, there have been roughly 140 messages of a riot on five different mailing lists. Two of those documents requested time in the DOH session on Tuesday. I've called in Pete Resnick to help chair because one of my chairs can't be in Prague and I don't want only one person at the front of the room. Wanted to let everyone know there's a thing going on and if you search DOH in the mail archive you'll get some notion of it. Alissa: I'm wondering if this needs a little more steering. I was surprised to see 20 minutes of DOH allocated for these drafts. I think if that's going to go forward it seems like people need to be very clear about what the boundary of the WG charter is vs. something people just want to talk about. Warren isn't here but he was thinking of setting up a separate list for this discussion because he was getting all these moderation messages from the various lists people were CCing. If it doesn't fit squarely into any of the existing WGs that might be a useful thing to do to cut down on the administrative load for people on these lists. Adam: There's also a side meeting these various draft authors have proposed where they want to have a conversation on the topic, and I suspect the creation of a mailing list will be predicated on how that goes. Ted: I think they moved the side meeting to Wednesday. Alissa: It's against the modern routing architecture session, which was meant to draw some of those people. Adam: In terms of concrete action items, if people have ideas about how to make this more useful, I'd welcome input. I wanted to make everyone aware. I do intend to work carefully with the DOH chairs so if this remains on the agenda, the ground rules are very well set and made clear this is not within the scope of the WG. Alissa: I have another item. I wanted to call attention to the pre-IETF report. It's in a Google doc and you should all be able to read it now. Please send your comments; I'd like to post it early next week. I'll also be sending around a draft of the pre IETF blog post soon. Magnus: We have a liaison statement from 3GPP round two incoming, which is related to ROC. I think we make a draft reply, circulate it later, and Alissa: This came in already? Magnus: It's submitted but not available yet. Mirja: Gonzalo, who took the action, already forwarded it to the transport ADs, so it should come in officially very soon. Spencer: Do we know if we're having a 3GPP coordination meeting in Prague? Adam: I haven't seen an invite yet, which now that you mention it, is kind of surprising. Spencer: They've done a handoff on their side on the liaison so the new guy may not know he's supposed to push a button. Mirja: Do we know who the new person is? I guess we can talk to Gonzalo. I can ping him. Amy: We have one gentle reminder that the Secretariat needs the area WG shuffle for SEC, INT, and ART areas. We know some of you are meeting in Prague to work that out, and we need that information by Sunday so we can prepare for the changeover on Wednesday the 27th. That's it from us.