Narrative Minutes interim-2020-iesg-21 2020-09-24 14:00
narrative-minutes-interim-2020-iesg-21-202009241400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2020-09-24 14:00 | |
Title | Narrative Minutes interim-2020-iesg-21 2020-09-24 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2020-iesg-21-202009241400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2020-09-24 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 Jenny Bui (AMS) / IETF Secretariat Alissa Cooper (Cisco) / IETF Chair, General Area 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 Wes Hardaker (USC/ISI) / IAB Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Loon LLC) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area 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 Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Magnus Westerlund (Ericsson) / Transport Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Michelle Cotton (ICANN) / IANA Liaison Jay Daley / IETF Executive Director Mirja Kuehlewind (Ericsson) / IAB Chair OBSERVERS --------------------------------- Pablo Camarillo John Leddy David Millman Dan Older Dan Voyer Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from September 10 being approved? Hearing no objection. Any objection to approving the narrative minutes for September 10? Hearing no objection to that either, so we will get those posted. 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. Alvaro: Still in progress. We have a slot at the retreat to talk about this. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: In progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Eric V: I still need to write a page with similar content, modified with Alvaro's comments, and then send it back to the IESG. Keep it in progress. o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: Michelle just sent me some feedback for the IANA section so my next step is to merge Ben's changes and see where we go from there. Expect more on this in two weeks. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Alvaro: We're going to call this in progress. 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. Amy: I noticed this is on the retreat agenda, so let's keep this 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: We're in progress. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. Warren: In progress. o Murray Kucherawy to find designated experts for content SDP Parameters, QoS Mechanism Tokens [IANA #1175036]. Amy: This is a management item at the end of the call so we'll mark this provisionally done. o Eric Vyncke to follow up on the suggestion at IETF 108 to share a list of grammar checking tools with the community. Eric V: Still need to compile it, so work in progress. o Barry Leiba to discuss possible datatracker feature request regarding flagging who is responsible for the next step for a document; the document authors, the WG Chairs, the AD Discuss Holder, or the Responsible AD, with Robert Sparks. The feature request should include a "length of time in state" flag. Barry: Technically that's done because I've sent a message to Robert, but let's leave it on until I have something to report back. o Robert Wilton and Warren Kumari to draft a charter for a proposed IOTOPS Working Group. Rob: In progress, we should be able to share it with the IESG fairly soon. o Martin Vigoureux to find designated experts for RFC-ietf-babel- rfc6126bis [IANA #1178016] Amy: This is just to alert you that you have an action item. Martin V: This is in progress. o Barry Leiba to find designated experts for RFC 8908 [IANA #1178597]. Amy: This is also just to alert you that you have this action item. Barry: Mark that complete, because when we get to the management item I'll tell you who the experts are and we can approve them. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-extra-imap-fetch-preview-09 - IETF stream IMAP4 Extension: Message Preview Generation (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: I don't think so. We've been discussing it by email and I think we're fine with that. Robert, quickly, if we remove that one phrase, would that be enough to clear this? Rob: Absolutely. Barry: Okay. As I said, I believe Michael has already said he's going to remove that, so I think we'll be good. Thanks. Leave this in Revised ID Needed, please. o draft-ietf-bess-evpn-na-flags-06 - IETF stream Propagation of ARP/ND Flags in EVPN (Proposed Standard) Token: Martin Vigoureux Amy: I have a few Discusses in the tracker; do we need to discuss any of those today? Martin V: Let me check. Maybe I'd like to discuss Erik K's. Thank you all for your reviews and comments and Discusses. Erik, do I understand correctly that you are asking or suggesting that there is a linkage between that document and any future NA flag or ND extension? I wasn't sure. Erik K: My concern is that it's really just dealing with the ARP function of ND. The whole ND infrastructure in v6 can do more than just link layer resolution. People propose at various times that we should include a new message for this, and a new message for that, and so IPv6 ND proxying is notoriously tricky to get right. We don't even really have a document about how to do it. We have an experimental proxy ND protocol, I think it's still technically experimental, and some other text in other places, but it's never been really codified anywhere. This is partly why. It's not just this link layer address resolution feature. I'm worried that it's an embrittlement of the protocol, the idea that you couldn't deploy a new on link neighbor discovery feature because BGP didn't allow it seemed kind of humorous to me. Martin V: This I understand but I don't view things that way. I think whatever future work would be done in the context of ND is not blocked, and I don't see how it could be blocked by that document. I believe whatever is defined in the future, in the context of ND, is not necessarily needed for the BGP EVPN. Erik K: It might be, or it might not be. It depends on the deployment context; it's not blocked by the document per se, it creates a deployment where it wouldn't work in that deployment. Warren: And the fix is relatively easy, isn't it? It's not that this requires a significant change to the document, it just shoves all this stuff here instead of shoving it there. Erik K: I have two proposals, and the one that you've described there is untested. I basically tried to list off the cuff all the things I could think of, in part to show there are some considerations here. The other thing I think is reasonable is just don't do ND proxy, and instead just relay the messages. If you see features you don't support. Warren: I'll happily admit I think adding new stuff to NA is a bad idea, because at some point we're going to run out of NA packet size. But with that said, we don't yet know what might be added that might end up in basically all NA packets in the future. In which case, if you don't do this for ones you don't understand, there's limited utility in this. Eric V: Unless you update it later. Warren: Unless you update it later. Lets say we keep adding new flags, we're just going to have to keep updating this document, which seems annoying. Erik K: But at least the new flags could be used on this network deployment, right? It would bypass the ND proxy and be less efficient, and it would be up to the implementation to let some operator know that ND proxy was not being used. Warren: It seems like having a more extensible design would be a really good outcome. I thought it would just copy the flags as they were. Erik K: That might generally be the case, however in truth probably 6MAN should do the work to say if that's true or not. You never know what's involved, right? The Nonce value, it probably should change on every NS/NA, right? You probably shouldn't cache those things if you see them. There might be other things you don't want to cache but an implementation wouldn't understand them. It's tricky for this reason. It's not just an ARP function. You could include node identifiers and things like that. I don't know if that makes any sense. Martin V: I think it makes sense. What I'd like is to hear back from the authors and have them engage in discussion with you. I primarily wanted to better understand what you had in mind. Now I think it is clear. I understand the rationale; let's see where the discussion goes. Okay? Erik K: I think the simplest thing is just to advise that if you see any flags you don't expect, as listed in this document, can you see anything other than a TLLAO [crosstalk] Notice that this document is already fixing a problem with proxying because the flags are gone. This has been seen in corporate IPv6 wireless deployments. For example, wireless APs tend to have a proxying and deproxying function. We had several devices attached to an IPv6 capable SSID and then immediately hop off because compliant implementations saw the ARP flag disappear from the device that was the RA. Not immediately, it works for a couple of seconds, then compliant implementations hop off. This document attempts to address that but that already shows that there's complexity. Martin V: Let's take things the other way round and say the BESS WG thinks a new flag would be useful. Does it mean that this should be done elsewhere? Erik K: A new flag in ND? Martin V: Yeah. In the extended community. Erik K: The immutable flag makes sense to me. It made sense in the document that there are two flags involved, one is the set of ND flags, or logically mappable to the set of ND flags, and the other is a set of flags specific to the ND proxy operation. Ben: There's quite a bit of space in the extended community, so you could easily have a separate location for flags specific to EVPN or BESS and flags that are inherited. Martin V: So the field would be split between things which are specific to VPNs and those that are inherited from NDP. They don't use the S flag, do they? Anyway. Let's wait for Jorge to reply and see where it goes. Thanks. The other two Discusses, thank you too; I think they are pretty straightforward to address and shouldn't pose any issue. I believe we can mark this document Revised ID Needed. o draft-ietf-i2nsf-capability-data-model-12 - IETF stream I2NSF Capability YANG Data Model (Proposed Standard) Token: Roman Danyliw Amy: It looks like this document was supposed to be deferred but didn't quite make it? Roman: I clearly hit the wrong button; I thought I hit 'defer'. Amy: You did hit defer, which is why I'm asking. I think we got caught up in some Datatracker weirdness. We'll put this on the agenda manually for next time; is that what you wanted to have happen? Roman: For everyone's benefit, let's do that. I may pull it back after I have a real chance to talk to all of the authors and the WG. I apologize if folks didn't see it sooner. Ben: What you did was from the document status page, just changing the State? I think normal usage is from the IESG Evaluation Record page, the ballot page. There's a "defer ballot" button there which has effects besides changing the state. Barry: You can also manually change the telechat date. Ben: Yes, which I'd argue for in this particular case. Roman: Okay. Thanks for guidance on how to do that right and sorry again. o draft-ietf-mpls-sfl-framework-10 - IETF stream Synonymous Flow Label Framework (Proposed Standard) Token: Deborah Brungard Amy: I have a couple of open positions here; Alissa and Warren, did you want to state a position here? [No for both.] Okay. There are no Discusses in the Datatracker so unless there's an objection now, this is approved. Deborah: Let's do it as Revised ID Needed to incorporate some comments. o draft-ietf-calext-jscalendar-30 - IETF stream JSCalendar: A JSON representation of calendar data (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: No, the authors need to respond to it. Just put it in Revised ID Needed please. Ben: Quickly before we move on, does anyone have anything to add to my comment about the slash character in time zone identifiers? I'm pretty confused and I don't know if it's just me. Warren: I seem to remember reading that, thinking someone else understands it, and stopping reading. Ben: It's number 6 in the Discuss section. Barry: I'll have to go check. Ben: We don't need to talk about it today. Barry: Slash characters are normally used in time zone identifiers but I'll have to go check the references. Also the authors need to respond anyway and they'll probably have something to say about it. o draft-ietf-spring-srv6-network-programming-20 - IETF stream SRv6 Network Programming (Proposed Standard) Token: Martin Vigoureux Amy: We have some Discusses here; do we need to discuss any of those today? Martin V: It really depends on the ADs who raised the Discusses. I'm happy to. My understanding is that [the author] is really on top of that and has already addressed some of the comments and is planning on replying to each and every Discuss. I didn't see anything critical; I did see some very good points, thank you. There is one aspect I would like to discuss, Alvaro, your point 5. This point is for the IESG to discuss. I'd like to better understand what you are looking for, because I have a possible concern with that suggestion. This document has IETF consensus, or it will ultimately have it when I approve it, right? Alvaro: Yes, correct. Martin V: So that means everything which is written has IETF consensus. I think it would be very confusing to find in that RFC a note which reduces or scopes the level of consensus for a particular part of that document. Alvaro: This is what I think. Maybe I'll just throw the ball over to Eric. Yes you're right, this is going to be an IETF consensus document. What it says about 8200 in that section is what the WG reached consensus on. Or that interpretation of 8200. Of course, 6MAN has discussed how to interpret that part of 8200 at least 3200 times. I don't think they have reached a consensus other than 'you can interpret this in different ways.' By leaving it the way it is now, it seems to imply that the IETF agreed this is the implementation of 8200. I don't think 6MAN has reached that consensus. In other words, there could be documents in the future that interpret 8200 this way, and that's perfectly fine. There could be documents in the future that interpret 8200 in a different way and define a different behavior. That's probably fine, but this document shouldn't be the one that calls the consensus on how 8200 is interpreted. Warren: I agree with that. I think it's awful we might have to have this whole set of discussions again about what 8200 means. I really wish that 6MAN could come to a consensus agreement on what it actually means. I would go further and say that for this particular use 8200 is interpreted in this particular way. It's not that the consensus of SPRING is that, but for this document we're interpreting 8200 in this particular way. Eric V: I don't agree when you say 6MAN agrees that it's 8200 or not. 8200 is an IETF consensus document, so it's not under 6MAN ownership anymore. Warren: Sure, but it's unclear what 8200 means. Different people have different interpretations, and in 6MAN when the document came out and people asked what exactly did you mean, some said they meant Y and some said they meant Z. The fact that 6MAN can't explain what the actual consensus was shows that where the document came from is unclear and having other WGs interpret it for the entire IETF seems interesting. Martin V: I understand the point, but still the whole IETF had the opportunity to comment on that specific sentence. Eric V: IETF Last Call, indeed. Martin V: So I'm concerned by the fact that we would be now saying that specific sentence is only SPRING. Warren: I think when people read this and commented on it, some people assumed it meant one thing and others assumed it meant something else. That's a discussion we've had. To me this feels like while trying to use one of our documents we've discovered an ambiguity, almost like an errata. I don't think we should actually do an errata, because this is much too large a problem to solve with an errata. Erik K: Two errata were already filed. And a draft was written as well to clarify this point, and that draft failed to get consensus. We're in the state where the document has shipped and the current feeling in the WG, which might not always be the case, can't come to agreement yet about how to revise or clarify interpretation of this. Warren: Which is exactly my point. Having SPRING decide for them feels .... Martin V: SPRING didn't decide anything for anyone. SPRING produced a document and submitted it to the whole IETF. Alissa: The precedent that this kind of thing sets is pretty atrocious. We have documents which are supposed to be consensus of the whole IETF but we start picking off sections and sentences saying this part isn't the consensus of the whole IETF, just this one WG. That will degrade very quickly if it happens repeatedly. I don't see how we can claim the whole text has consensus of the IETF except this one part that doesn't. Alvaro: For what it's worth I'm fine with Warren's warning, which was that for this application, this is how we interpret it. The opposite of what you just said is also true. If a WG can't agree on what they wrote, and some other WG interprets it for them, that's also a slippery slope. Ben: My sense here is that 8200 is a flawed document and when I was reviewing the SPRING document in front of us I was forced to read the words on the page of 8200 and take what they say, for lack of a better option. Not wanting to reopen 8200 as a dependency of this document. On the other hand, it does seem like 8200 is the crux of the issue here. It occurred to me that in light of some points raised about 8200, the text in 8200 is seen as adding a feature that was not in 2460, we could do something crazy like make a status change document to take 8200 back to Proposed Standard, which is what it should have been. Eric V: I don't think we need to reread again 2460 to be sure that this behavior was most probably already there. Ben: I didn't read 2460 either. The question about deleting may have been differently specified. The prohibition about inserting has been there for a long time but the text about deleting may have changed. Warren: As far as I understand, when 8200 was published, the group admitted that this part was intentionally left open to interpretation or vague. That now it's being interpreted in a specific way and written down as what they must have meant, feels incorrect. Martin V: I don't think the text in that draft says this is the only possible interpretation. Warren: It doesn't say that it chose to interpret ambiguous text in a specific way, so anyone reading it in the future is going to think SPRING interpreted it this way, there's IETF consensus, therefore it must mean X. For the purpose of this document we have interpreted it in this way. Martin V: The point here is that the text is not ambiguous. The text is very clear. Warren: If that is true, how come 6MAN can't say it's very clear and that's what they meant? Erik K: It's hard to re-litigate the past but it's more along the lines that people thought they got the edits they wanted because they were each holding to their own interpretations of the text. It was never really tested against other possible interpretations until now. Rob: One question is, does this sentence need to be in the document at all? Is one solution just to remove it? Eric V: Or change it. Have you seen Alissa's suggestion in the chat? Alissa: It's there for a reason, right? It came at a crucial point in this document. I'm assuming it's better to keep some version of it. Ben: I do wonder if having it in this section in the body of the document makes more sense or if it would make sense to have this topic covered by an IESG note? Eric V: The topic being what specifically? Ben: The interaction of PSP with 8200. Alvaro: I don't think we need an IESG note. This is one flavor in one sub-sub-subn section clarifying that sentence is enough. Warren: Alissa's text seems reasonable. I do still really think that it would be really useful if 6MAN could document what exactly this is supposed to mean. I don't really care which way they do it but I don't want to have this fight again next month, or ever. Erik K: There was a document that attempted to clarify this in the direction of the most vocal opinion at this time, and that has not gone anywhere. Secondly, this particular ambiguity we're talking about applies to routing headers only. The only time this ambiguity can come up is in contemplating the context of the action association with future routing headers. Warren: I fully get that. I'm just concerned. Maybe not tomorrow or next week but at some point someone is going to want to touch this again and having people point at this as precedent or something seems ... Erik K: They can point at the text of both errata and the text that was written in the appeal, as well, not just this text. Ben: If we're talking about fixing 8200 I'd rather not focus quite so narrowly and I'd prefer to have some guidelines or sense for how routing headers are supposed to work and what constraints there are on what behavior can be changed by the routing header. Right now it's an open slate so SPRING is free to consider many things that may be surprising to people. Warren: At the root of much of my disquiet is that a WG came up with a document, there are ambiguities, and a different WG is choosing to interpret the ambiguities in a specific way. The very fact that the original WG can't simply clarify feels bad. I'm abstaining on the document because I think there are a lot of other things not good with it, so maybe I should stop talking. Erik K: I don't disagree with your assessment of the state of 6MAN consensus on this point; it's certainly far from ideal. Eric V: I have a hard time seeing 6MAN agreeing on a consensus of interpretation of this section. So this is wishful thinking, removing the ambiguity, but it would be nice. Martin V: I think we are in a situation where it will likely be impossible to have one and only one reading, because we have one document in front of us who reads the words exactly as they are written and if we end up concluding in 6MAN that you shouldn't read them that way, we are impacting a deployed technology and existing standards and that would be strange. Warren: We do that with errata; that would not be uncommon for us to say. Erik K: The text Alissa proposed seemed reasonable to me. Alvaro: It works for me too. Alissa suggested we just add at the beginning of that paragraph: "In the context of this specification, the End, End.X and End.T behaviors with PSP do not contravene Section 4 of [RFC8200] because the destination address of the incoming packet is the address of the node executing the behavior." Martin V: Seems reasonable. If the Discuss holders are happy with that, and they can find agreement with the authors, I think I can live with that too. I won't go through all of the Discuss points. Thank you very much again for your reviews and this is obviously a Revised ID Needed. o draft-ietf-regext-rdap-sorting-and-paging-17 - IETF stream Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging (Proposed Standard) Token: Barry Leiba Amy: I have a couple of Discusses in the tracker for this document; do we need to discuss those today? Barry: We don't. We have to sort out what to do with the JSON path references and that's going on over email. Ben had an interesting Discuss about the sorting order and we'll sort that out by email as well. This will be Revised ID Needed. o draft-ietf-avtcore-cc-feedback-message-08 - IETF stream RTP Control Protocol (RTCP) Feedback for Congestion Control (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: No. Colin responded to Magnus's Discuss and suggested that he will put some text in. We'll see what he comes up with. Revised ID Needed. Thanks. 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 NONE 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval o Revision of core Email specifications (emailcore) Amy: I have no blocking comments, so unless there's an objection now it looks like emailcore has been approved. Barry: Sorry everyone that we don't have milestones in there. I'm continuing to push on the chairs to get milestones as soon as possible so we should see those any day now. Warren, in response to your comment, the first sentence of the charter says what the base email specifications we're talking about are. Warren: I did see that. That's where I copied and pasted from. I just wasn't sure if it was worth adding the part about these being the ones that will update. Either way. Barry: I think it's clear enough. Ben, I rephrased the bit I put in for you about the security stuff. Take a look and see if you think it reads better now. Barring Ben coming back and saying it still reads awkwardly, I think we're ready. Amy: I'm hearing no objection to approving emailcore so we'll send the WG action announcement tomorrow. 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 Alvaro: No news this week. 6. Management issues 6.1 [IANA #1177950] Designated experts for RFC 8894 (IANA) Amy: This document was an individual document shepherded by Alexey. Is this something one of the ART ADs wanted to tackle? Roman: If not the ART folks, I'm happy to try to shop for it. Murray: This is a bunch of acronyms I don't recognize so if you know what this is, by all means. I don't want to step on Barry if he wants to. Barry: It's on your side. Somewhere between you and Roman you should be able to figure it out. Murray: Okay. I'll go brush up on this RFC and sync up with Roman. Amy: Okay, I'll assign this to both of you. 6.2 [IANA #1178016] Designated experts for RFC-ietf-babel-rfc6126bis (IANA) Amy: We assigned this to Martin V at the top of the call so he's working on experts there. 6.3 Approval of an additional Designated Expert for the "OAuth Authorization Server Metadata" registry (Roman Danyliw) Amy: Roman, you want to add Dick Hardt as an additional expert? Roman: That's right. Overall I'm trying to overhaul some OAUTH registries to make sure there's sufficient backup to get timely approval. That's why I want to add Dick here. Amy: Any objections? Hearing none, so we'll send official note to IANA. 6.4 [IANA #1175036] Designated experts for content SDP Parameters, QoS Mechanism Tokens (Murray Kucherawy) Amy: It looks like we have someone who wants to be replaced and has suggested his own replacement. Murray: I just got an email back from Christer moments ago confirming that he's up for the job, so that's the proposed assignment. Amy: Any objection to naming Christer as Gonzalo's replacement? Barry: An excellent choice. Amy: I'm hearing no objection, so we'll send note to IANA. 6.5 [IANA #1178597] Designated experts for RFC 8908 (IANA) Barry has already found Tommy Pauly, Darshak Thakore, and Martin Thomson. Any objections? Hearing no objection, so we'll send official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Reminders: The IESG retreat is next week and there's a Doodle out for BoF coordination call times.