INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2019-05-02 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 Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Roman Danyliw (CERT/SEI) / Security Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Wes Hardaker (USC/ISI) / IAB Liaison Ted Hardie (Google) / IAB Chair Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Mirja Kuehlewind (Ericsson) / Transport Area Warren Kumari (Google) / Operations and Management Area Barry Leiba (Huawei) / Applications and Real-Time Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Alvaro Retana (Huawei) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Martin Vigoureux (Nokia) / Routing Area Amy Vezza (AMS) / IETF Secretariat Eric Vyncke (Cisco) / Internet Area Magnus Westerlund (Ericsson) / Transport Area REGRETS --------------------------------- Heather Flanagan / RFC Series Editor Portia Wenze-Danley (ISOC) / Interim LLC Executive Director OBSERVERS --------------------------------- Andre Cedik Greg Wood 1.2 Bash the agenda Amy: Does anyone need to add anything new to today's agenda? I did see we had a document that was deferred a few minutes ago. Any other changes? No other changes. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from the April 11 teleconference being approved? Hearing no objection, so those are approved. I saw narrative minutes; is there any objection to those being approved for posting? Hearing no objection to that either. 1.4 List of remaining action items from last telechat o Suresh Krishnan to discuss naming experts for the registries created by draft-irtf-icnrg-ccnxsemantics with Colin Perkins. Suresh: Keep this in progress, please. o Barry Leiba and Ben Campbell to write up text on the IESG's expectations regarding conflicts of interest and the disclosure of funding sources. Barry: That is in progress. o Alissa to draft a revision to the Meeting Room Policy and communicate it to the LLC Board. Alissa: It has been communicated. Perhaps you should assign me an action to report back to the IESG after the LLC Board has its retreat and considers all of its policies, so I remember to do it. That's happening next week. Amy: Okay, we will add a new action item for Alissa to report back. o Benjamin Kaduk to identify designated experts for RFC 5580 [IANA #1139586]. Amy: This is on the agenda as a management item, so we'll mark that as provisionally done. o Barry Leiba and Roman Danyliw to summarize the discussion on common problematic behaviors. Amy: Is this done, because we discussed it at the retreat? Barry: That's done, but there should be an action item from the retreat following up on it. Roman: There is, a bit further down. o Suresh Krishnan to follow up on proposed IESG Statement on the procedure to reference material behind a paywall. Amy: I think we have a new action item that furthers this work so this item is done; is that correct? Suresh: Yes. I have the new text ready to go. I'll ship it off today so keep it in progress, but I think you can close it next telechat. Amy: Both of these action items? The new one from the retreat and this one? Suresh: The old one is done; the new one will be done soon. o Ignas Bagdonas to propose an additional question on YANG Model format validation for each of the styles of document write-ups. Ignas: This one is in progress. o Roman Danyliw to talk to the tools team to reset the counters on substate change for documents in AD Evaluation. Roman: That one is in progress. o Roman Danyliw to draft text to be posted on ietf.org about reporting protocol vulnerabilities via an email alias and possible procedures on how to assign triage resources. Roman: Likewise, in progress. o Suresh Krishnan to write a document on replacing the "updates" with new terminology (amends/amended by; extends/extended by; see also). Suresh: I would say in progress but it's not yet started. Keep it in progress please. o Warren Kumari and Ted Hardie to write a document on Implementation Target Sets (aka Living Documents). Warren: Haven't done that yet. o Roman Danyliw and Barry Leiba to draft a starting point for the discussion on setting expectations with the WG Chairs in reference to responses to inappropriate or unacceptable behaviors. Barry: That is in progress. o Martin Vigoureux to work with the IESG to create a list of possible IESG Tutorials and will prioritize them for scheduling on a series of Informal Telechats. Martin: I haven't done anything, so keep it in progress. o Alissa Cooper and Alexa Morris to put together a Doodle Poll for possible dates and cost effective places for a second IESG retreat. Alissa: This is in progress; I sent my availability to Alexa yesterday. o All IESG to coordinate with their co-ADs and send a list of specific "hot topic" items that should be checked. The list to be provided for document authors. Amy: I know a couple of the areas have done this already. Barry: You've got TSV and part of ART, but we have to consolidate ART and take care of missing items. Amy: I'm going to keep that still in progress for everyone else. o Eric Vyncke to write up draft text for the NomCom to help them understand the rules for the NomCom. Eric: I would love to say in progress, but it is yet to start. o Suresh Krishnan to write up a NomCom Chair BCP (work with past chairs). Suresh: I started something on this and reached out to Scott, who had some discussions with Peter. We want to sit down the three of us and try to put something together. That's in progress. o Eric Vyncke to draft text for a more coherent BoF Proposal for MEDIA OPS and add to the BoF Wiki. Eric: This is in progress. o Roman Danyliw to shepherd the www.ietf.org analytics discussion with the community. Roman: That's in progress. o Alissa Cooper to draft text back to the proponents of draft-moonesamy-recall-rev to talk about the outcome of the discussion at the retreat. Alissa: That's done. o Warren Kumari, Alvaro Retana, and Mirja Kuehlewind with Spencer Dawkins to continue discussion of the next Deep Dive topic for IETF 105. Alvaro: That's in progress. o Suresh Krishnan to update the text for material behind a paywall to update the reference to section 7.1; update the document shepherd writeup; and draft text for a possible IESG statement to circulate with the WG Chairs. Suresh: Still in progress. o Alexey Melnikov, Warren Kumari, and Suresh Krishnan to work with the authors of the recall draft on next steps. Alexey: In progress. o Ignas Bagdonas to find designated experts for RFC 8520 [IANA #1141661]. Amy: This is on the telechat as a management item so it's provisionally done. o Adam Roach to find designated experts for RFC-ietf-sipcore-sip-push [IANA #1141663]. Amy: This is on the telechat as a management item so it's provisionally done. o Alexey Melnikov to find designated experts for RFC-ietf-core-object- security [IANA #1141664]. Amy: This one just came in and Alexey, you know you're on the hook for that? Alexey: Yes. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-roll-useofrplinfo-25 - IETF stream Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane (Proposed Standard) Token: Alvaro Retana This document has been deferred. o draft-ietf-manet-dlep-multi-hop-extension-06 - IETF stream DLEP Multi-Hop Forwarding Extension (Proposed Standard) Token: Alvaro Retana Amy: I have a Discuss in the tracker; do we need to discuss that today? Alvaro: No, I don't think so. The authors are engaged, and because it's very similar to the other draft it should be fairly easy to resolve. So no, thanks. Amy: So it sounds like this is going to be a Revised ID? Alvaro: Yes, it will be. o draft-ietf-dots-signal-channel-31 - IETF stream Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification (Proposed Standard) Token: Benjamin Kaduk Amy: I have a number of Discusses in the tracker; do we need to discuss any or all of those today? Ben: I believe most of it is going to be on the list with the authors. Let me skim through; I forget if it was this document or the other one I had a few things to comment on. Alexey: I think we need to discuss port number. Ben: Yes, that was one. And possibly also the happy eyeballs bit. Before we do either of those, a quick thank you to everyone for all the review. Several of the points that were brought up I tried to mention in my AD review and the authors were telling me it was all good, and I'm not enough of an expert to track everything down. So I appreciate the carefulness of the review. So let's talk about port numbers. I know there was a pretty extended interaction through IANA with the experts, and I don't really have a great conclusion myself as to how necessary a dedicated port number actually is. Mirja: I saw a reply from the authors come in but I didn't read it yet. The discussion with the experts was more about usage of Coap and you don't need a separate port number for that. There was some discussion among the expert team and people disagreed. I'm happy to assign a separate port for the service; however, I'm really wondering if a fixed port is actually needed or if a fixed port might even be counterproductive, because that makes it easier to block dots traffic. Ben: Right. I think I mentioned the attack surface risk in my earlier review. I do remember the authors and general WG being pretty strong in the sense that the discovery solution for using a dynamic port number was not going to be applicable to all of the use cases. Mirja: I don't think it has to be dynamic, but there is an assumption you have to pre-configure the IP address or some kind of information about the dot server anyway. So if you have to provide this information pre-configured anyway, you can also provide port information. Ben: That's true, I guess having an assigned port number makes it easier to pick one that's not going to conflict with anything else on your network. But I don't know if we have an obligation to make things easy for deployment in that fashion. Mirja: The port numbers have been used to distinguish services in the network, but it's very much discouraged to actually use port numbers that way because it's not reliable anyway. Similarly, they allow to use other port numbers for dot services as well so you can never rely on that. Alexey: I tend to think that although this is using Coap, this is going to be quite a different service, and implement different software. Mirja: I agree to that point. Alexey: I'd rather assign a port number, to be honest. And regarding that, it's easier to block a known port number, I think the argument applies to https and everything else, so it's not really a very strong argument in my book. Mirja: No but http is quite generic, where this is a very specific service, so there might be more interest in blocking it. As I said, it doesn't seem there's actually any benefit to have a fixed number given they need to discover the service anyway. However, I need to check the reply from the authors and I'm not super blocking on this point. I think we can come to a solution but it probably would require to mention the risk of blocking somewhere in the security section. Alexey: That sounds fair. Ben: We can definitely get some discussion of the security risks, if there's nothing there already. I kind of thought there was, but it sounds like there's not. Mirja: I didn't see anything about ports in the security considerations section. Okay, I will reply to the authors. Ben: Thanks. Did anyone want to talk about happy eyeballs on the call, or leave that to email? Adam: It's probably an email thing. I raised issues related to it. I have some concerns that the responses that I got from the author on the three discuss points I raised were either dismissive or didn't understand the points I was making, so I fear this may be a relatively long conversation and I might need your assistance in mediating that. Ben: I've only skimmed the email responses thus far but I have a similar sense and I will attempt to help out and keep things productive. Adam: Thanks. Alissa: The answer I got about the MUST requirements with exceptions, which I think is a problem because MUST should be an absolute requirement; he said that he talked to you about it, Ben, so we can talk about it now or he can respond on the list. That wasn't really an explanation of why MUST with an exception is okay in this document but not typically. Ben: I think we do have a fair number of examples of things we've published that are, MUST do this in all cases except this one, and we've seen it with various ways. But the general concept that the default is to do this and there's a very specific exception we call out, has a fair amount of precedent. I'm not super happy with the precise wording in this case, so I'm happy to see you objecting to that, but I'm not sure if you're unhappy with the wording specifically or the general concept. Alissa: I think if MUST implies an exception, we should change 2119. Barry: I don't think we need to. What we've often done in this case is say SHOULD with the exception, and I think that's wrong. I'd prefer MUST, UNLESS. I think that's a perfectly good formulation and to me fits right in to 2119. Alissa: Okay, then we just disagree about that. Barry: In this particular situation, rewording might be appropriate. I'm talking generally. Ben: I'm sort of with Barry; rewording in this situation is appropriate, but I'm not sure we know what we want to re-word to. Perhaps we should take this to the email. Alissa: Okay. Suresh: Regarding my Discuss, I think there's some conversation that needs to go on, because I'm worried about the repetition of text from happy eyeballs and it's hard to see what's new. I'll write it over email. Ben: Originally they were not mentioning happy eyeballs at all, they were just having some text description of a thing that looks very similar, and I asked them to add the reference and say it's similar, but I guess I missed the part where the happy eyeballs BCP is normative and we're doing different things. Suresh: The question is, I want to know why happy eyeballs is not enough. I think it's a simple ask but we'll see how far we go. Ben: Yeah, it's a perfectly good ask. Mirja: I also had a point on this happy eyeball mechanism. What they changed is, instead of trying one after another, they try all simultaneously, and that actually has implications on congesting the network or sending uncontrolled traffic. However, they didn't respond to my message. They said it's discussed in the other thread but I don't think it is. Suresh: I told them the figure was wrong and they were doing things out of order, and they said no they were doing it at the same time. I agree with you Mirja, this doesn't address your point, but what is suggested as a response to my comment saying the figure and the text disagree, it's not one after the other, it's all at once. Mirja: In the reply they gave to my Discuss they said this was addressed in another thread, but it's not. Adam: Mirja, I want to draw your attention to their response to my Discuss, because when I pointed out happy eyeballs says not to send these simultaneously, they said we need to because we're doing this during an attack, so the notion is they want to make sure they're sending additional traffic when the network is congested, which seems to make the problem significantly worse. Mirja: I agree and I wasn't aware this was in your Discuss as well. I'll check there. Ben: So we definitely have a lot of email discussion to keep going, but it sounds like we should go on to the next one, which is more of the same. Amy: It sounds like this is going to require a Revised ID. With that we'll move on. o draft-ietf-dots-data-channel-28 - IETF stream Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (Proposed Standard) Token: Benjamin Kaduk Amy: I have a number of Discusses. Ben: Again, I think we're going to need a fair bit of discussion in email with the authors. With respect to the flags bitmask being 1 byte or 2 bytes, I do remember looking at that and I was pretty sure there was an implicit length somewhere that would let you know which encoding was used, and they have some text about if you only have the one byte encoded, it's the byte that's pretty dense in flags, and you ignore the byte that only has one or two flag bits. But I did not get a chance to double check that before the telechat. Were there any topics people wanted to discuss today or should we keep it in email? Mirja: I didn't really understand why they need this bitmask at all. I don't know if you want to explain it to me or if I should keep talking with the authors. I understand the intention but I think it's only an implementation, I don't think they need to change the Yang model. Suresh: I agree with you, Mirja. And if they have it specified they need to do a better job. I think if it needs to be there, better specification is required. I have no idea how I would set this yang model to do what I want. Ben: I don't think I can give you a quick explanation on the call, so I think we'll have to do this over email. Mirja: That's fine. Thanks. Amy: Again, it sounds like that will require a Revised ID? Ben: Yes. o draft-ietf-netconf-subscribed-notifications-25 - IETF stream Subscription to YANG Event Notifications (Proposed Standard) Token: Ignas Bagdonas Amy: It looks like I have a number of Discusses; do we need to discuss any of those today? Ignas: I think the authors are engaging quite well with this. Magnus, if you would like to talk about your congestion topic. We had quite a few discussions previously, at the retreat and before that, and I think that both the authors and I tried to explain the viewpoint of how all of the manageability system is being built. There are two parts: one that was specified in the protocol specifications, and the other that is implementation. Many of the aspects you raise in your Discuss fall more into the implementation aspects. Would you prefer to discuss this or leave it for the authors to address? Magnus: There's one aspect I would like to discuss, and that has to do with the intention to have any type of priority signaling from the receiver towards the publisher about how important the view their subscription. I think that'a a core part, if that matters or not. Ignas: If I'm talking from the actual user of this technology point of view, and that comes to a practical deployment, I don't see this as important and that's not necessarily the way things are being deployed. From a theoretical point of view, there appears to be a need to have ability to prioritize certain events. A practical way of doing this to have two signaling channels, one for one priority and the other for the other priority, and that's how that has been used for a long time. What they want to have as a functionality adds complexity quite substantially, with probably somewhat questionable gain. Magnus: My concern here is that if what you're saying now matches that perspective that there's an explicit dependency on what's called the dscp field to indicate that priority, that's not really what the dscp says. There's a coupling in here of something that's not actually coupled in that way. I think it would be good to clarify that aspect of it. I just want to have some clarity in how this thing is intended to be used. Ignas: I think that's a very fair request. Let's ask the authors to clarify the details then. Magnus: Okay. Ignas: For the rest of the Discusses, I think the authors are discussing those. Unless anyone would like to discuss something right now. If not, then that would definitely be a Revised ID Needed. o draft-ietf-netconf-yang-push-23 - IETF stream Subscription to YANG Datastores (Proposed Standard) Token: Ignas Bagdonas Amy: I have one Discuss in the tracker; do we need to discuss that today? Ignas: I'm not certain. A quick answer to Ben's comment about seven authors; this has been discussed with the authors. I have reviewed their level of involvement. Two are more involved than the other five, and the suggestion was to move those to editor and the rest to contributors. We'll see how that goes. As responsible AD I can share that all seven of the listed people have been involved in the process. I was not happy to see seven there but if they insist I would probably not be blocking that too much. Ben: That part was sort of pro forma. I'm happy to not discuss it but we do need to acknowledge it. I did have this other point about the indications of support for on-change notifications at a object granularity. It's pretty weird for me to be seeing and talk about it's the responsibility of people to ensure this is going to happen when we are not covering any ways for that to happen in the current document. It's left very open ended how that is going to happen. Ignas: That was left vague intentionally by the authors. This has been raised a couple of years ago on the sensibility side. What if we put into the Yang push mechanism everything we can imagine from a telemetry side; that is not going to happen in practical terms. I'm not certain I have a direct answer for this right now. Personally I would be objecting to this but that's for the authors to say. Ben: So you want to take it to email? Ignas: Yes. Ben: I'm happy to do that. Ignas: This one will be revised ID too. o draft-ietf-core-multipart-ct-03 - IETF stream Multipart Content-Format for CoAP (Proposed Standard) Token: Alexey Melnikov Amy: I have a couple of Discusses; do we need to discuss those today? Alexey: Yes, very briefly. Starting with Magnus. Magnus, there were responses from the WG that recursion is intentional. Are you happy to clear, or would you like some text to be added? Magnus: In some sense I'm happy to clear, it would just be good to be explicit about it. Alexey: If you clear and make it a comment, I'll make sure it's addressed. Thank you. Ben, just want to double check: did you see my followup discussion about different use cases and trying to rationalize and distinguish multipart/mixed where basically different parts equivalent in how they can be used. Ben: I did see the response but I'm not sure I have fully internalized it yet. I do appreciate the multipart/mixed vs multipart/alternative. I think I'm willing to accept your better experience about whether these are actually useable in the current form, because I don't deal with multipart/alternative or multipart/mixed much myself. Alexey: I think I would like to follow up with the WG because I think multipart alternative has different semantics and it would be important to know the difference. Ben: I'm happy to see that happen. Adam: I had some vague misgivings along that line also, and the base mime has several different things that fall under the same bucket. I had a hard time putting together a concrete objection. If you can get this clarified, Alexey, I think it would be great. Alexey: Okay. I think this will need a new revision. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items o draft-housley-hkdf-oids-01 - IETF stream Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (Proposed Standard) Token: Benjamin Kaduk Amy: I have one open position for Eric. Did you want to state a position on this document? Eric: You said Eric? Amy: I don't have a position for you in the tracker. You can decline to state a position if you didn't get to it. Eric: I had no time to do it. Amy: No problem. There are currently no Discusses, so unless there's an objection now it looks like this one is approved. Ben, there are no notes in the tracker; is this ready to go as is? Ben: It's ready to go. 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-sidrops-lta-use-cases-06 - IETF stream Use Cases for Localized Versions of the RPKI (Informational) Token: Warren Kumari Amy: I have several Discusses in the tracker; do we need to discuss those today? Warren: Yes please. I've looked through the Discusses and something I think is possibly helpful to clarify is I think this is very different from the TLS man in the middle type position. Largely because the RPKI, or the use of this, doesn't involve encryption at all. I think this is much more similar to things like DNSSEC, where an individual resolve operator can choose to accept a name which shows up as DNSSEC bogus by installing a local trust anchor or a negative trust anchor. This sort of use is specifically to take a route which is invalid for some reason, but which the network operator thinks they would like to accept anyway. So it in no way involves unencrypting stuff or exposing info, it's more that I think the results of the validation are not correct and I would like to override it using some method. I'm not sure if that helps clarify on that particular point. Roman: It doesn't help me so much primarily because the use case doesn't describe it as such. The use case seems really clear about who's shunting the traffic and what kind of traffic it's shunting, and I agree it's perhaps not exactly man in the middle, because it's the routing fabric that's doing it, and given how the use case kind of heated up I don't see any discussion relative to the security considerations on what that means for the user's traffic and all the end to end properties. Warren: Okay. I'm thinking how we address that. Currently the way it works is people just accept whatever routes come along. Moving to an internet where people use the RPKI is a definite security win, but a number of people are not doing it because it's unclear how you override when the RPKI fails or doesn't do what you currently use. Currently people have complex policies for what routes they will or will not accept and people will not move to them because they need a way to override when this doesn't work. Another example is there's no current way to do stuff like RFC 1918 in a sane manner. I guess we will need to discuss it more. Mirja: I don't really see a value of describing those use cases in that detail and picking the specific cases and having them in the document. It would be much more useful to describe the generic mechanism as you did, and leave it open. Ben: I'm not objecting to people having local overrides in general. I understand there are definitely cases, especially in the 1918 address space, and probably more as well, when you need to do this. I'm just uneasy with the way the document is presented and it seems to give a biased perspective in that it's promoting these specific handpicked use cases, when there are potentially many possible use cases, and it's not giving a clear discussion of the technical details of what are the implications of doing this and what are the risks you take on. Warren: Okay. I guess we're going to have to have more discussion with the author. Hopefully I can take some of the comments from the call and relay back to explain how the document could possibly be made something people would be okay with. Thanks. We can move on. Amy: It sounds like this might need a Revised ID? Warren: Oh yeah. 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 o conflict-review-nottingham-safe-hint-00 IETF conflict review for draft-nottingham-safe-hint draft-nottingham-safe-hint-09 The "safe" HTTP Preference (ISE: Informational) Token: Barry Leiba Amy: I have a couple of Discusses; do we need to discuss those today? Barry: We do. In response to Alissa's comment in her Abstain, Adrian already expressed willingness to work with us on text that makes it clear this is not an IETF consensus document. I think it's appropriate to work with Adrian on that. I think it pretty much covers Alvaro's Discuss if we do that; Alvaro, do you think it does? Alvaro: Yes, it does. Or, it will. Barry: There is whether we have standing to hold a Discuss on that issue, but I don't think we need to go to that bit of process at this point because Adrian has agreed. For Mirja's Discuss, I think that's more general. This is kind of exactly what the independent stream is for; the httpbis WG discussed this and ultimately decided not to take it on; we have a mechanism for publishing documents as RFCs outside the IETF stream. Unless we can argue that this harms something, I think we don't have standing to block it. Mirja: We don't have standing to block it anyway, it's the ISE's decision. I think it's the wrong conflict review. Because if this was brought to the IETF and there were concerns about publishing this document, we should mention there is a conflict. That doesn't mean that Adrian cannot decide to publish it anyway, but I think it's the wrong response to the conflict review. Barry: Which response would you use? The choices are in the agenda. Alissa: That's why I balloted Abstain, because none of the choices fit. Barry: I agree that if you don't think 2 is appropriate, the others aren't appropriate either. I'll just read the others: The IESG has concluded that publication could potentially disrupt the IETF work done in some WGs, and recommends not publishing. Mirja: I'm looking at them myself now. I guess 3 could apply, because it was discussed in the WG and the WG had concerns about it. Barry: As I read 'disrupt,' I don't think that fits, but I understand what you're saying. Alvaro: What I want to ask is, this document already came through the WG, and it came to the IESG. I found the old ballot; some discusses, some abstains, why wasn't it published at the time? Barry: We can certainly throw that at Adrian and have him chew on it. The main issues were that the definition of safe is vague and there can't be a consistent usage of safe. You don't know whether what you get back is safe or not; all you're doing is asking that the responses be safe with no verification that they are. Those were among the main concerns when it went through before. This is actually in use, and it proves to be useful, which is the reason Mark is pursuing getting this documented and having the header field put in the registry. Everyone understands it's a best effort thing and the definition of safe is very server dependent, culturally dependent, whatever, but it is doing what it's intended to do in the cases where its used. That's the argument for it. Mirja: Is it used by multiple vendors? Barry: Unfortunately I don't have the details of how many implementations there are. Alissa: There's an implementation list in the document. I didn't follow the links. Barry: The reason I agree it should not be standardized as an IETF standard is that it's not an interoperable thing, other than interoperating and sending the hint. I do think it's useful to publish the practice and reserve the header field, and that's what the document is doing. Mirja: This is not a standard, right, it's an informational document. Barry: It's not in the IETF stream and I absolutely agree with Alissa's comment that it would be good to make it extremely obvious in the header or introduction of the document because it will otherwise look like an IETF standard. Mirja: I would actually prefer to publish this in the IETF stream, because then it's under our control to make absolutely clear in the title, in the abstract, in the introduction, that this is only to document the current deployment status. Barry: We do have standing to put an IESG comment in, that Adrian would be required to include. I'd prefer to work with Adrian on text he agrees with, but if the result is not something we're happy with, we can put in an IESG comment. We've tried publishing this in the IETF stream and you know the result, we had too much pushback and it went away. Alvaro: Pointing at some issues in the last ballot would be useful beyond saying just that this is not an IETF document. Barry: I agree with that, and that's something we can try working out with Adrian. Mirja: I'm still not sure about the process as applied here because there is a possibility to publish documents on the IETF stream without IETF consensus, because it's an informational document. So there would have been another path that could have been taken. Barry: There is theoretically that, except we have not used that for years. We do Last Call all informational documents, and they're all approved by the IESG. Alissa: We almost did it with mmwg-encrypt. Barry: So we do occasionally, then. I would rather not see this published in the IETF stream because of the pushback we've had, which are legitimate concerns. Mirja: Because this document was brought to the IETF process and got so much pushback, I think saying there's no conflict is not the right reply. Barry: I don't see how I can honestly say number 3. Alexey: There is no current work on this in IETF, so there is no conflict with the current work and no planned work to address this same use case. Barry: And I don't see this as disruptive of the work happening in httpbis, and in fact I want to see it published, I don't want to recommend that it not be published. I want to recommend that we have text in there that makes its status abundantly clear. What I was going to say we should do is that I'd like to have at least one of you hold our discuss for now, and let me work with Adrian and Mark on some text that can go into the document and report back. Is that acceptable? Alvaro: That works for me. Mirja: Yes. Barry: If you want you can both hold your discusses. I'll get back with both of you after I talk to Adrian. Mirja: If everyone else agrees this is the right conflict review response, I will resolve my discuss. Barry: Okay. Does anyone other than Mirja think we should be using a conflict review response other than the one we're using? Suresh: I have not balloted on this because I kind of agree with Mirja's point. There are a couple of things I want to bring up. One of them is the preferences registry does not require an RFC be published to get this. I'm not fully convinced this needs to get published. All they need is a registration so we could leave this as a draft and that could be used to allocate the entry in the preferences. The part that worries me, I don't know how to put this in a way that's very clear, but the document looks awfully lot like a standards track document. It's got 2119 language, and I'm really worried about people getting confused by this document. If that's something you can work on, I would be okay if it said there's a thing called safe, and these people have implemented it, and it's used for parental control, is better than actually saying a proper normative way of doing things. Barry: Two things there; one is that I really don't like having long-lived drafts, at least until we get to the living documents thing. I would not like to have this live as a draft and I think it should be published somewhere, even if it's just a Mark Nottingham blog post. Second, we have a lot of independent stream documents that use 2119 language and reference 2119. I don't see that as a problem as long as the status is clear. i don't think we should put whatever we put in the boilerplate, I think I needs to go in the introduction where it's more obvious and people are going to read it. Suresh: That sounds good. If you want I can propose some text. I worked on some conflict review text for the IESG and if you want I can put that in a ballot. Barry: Sure, that would be useful. Mirja: I'll hold my discuss until we know what we want to put in there. Barry: I think that's fine. Any other discussion? Alissa: If we could just talk about the note for as second; it wasn't really clear to me from the ballots. If people want to talk about how the semantics are not agreed or understood, that would also be a useful thing to say in the note. Barry: I agree. Mirja: I'd like to see a note that said this document was discussed in the IETF process and was rejected for this reason. Barry: Let me see what we can work out with Adrian and Mark and I'll bring the results back. Amy, I think we're done. Amy: I think this is the equivalent of AD Followup because it's going to be ongoing. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Autonomic Networking Integrated Model and Approach (anima) Amy: I have a couple of Blocks on this recharter. Do we need to discuss those today? Ignas: Probably, if the block holders would like to. There is some engagement from the WG chairs and they addressed some comments, some are still open. Overall it seems the charter will need some work on codifying details. Martin: From my part, I'm in discussion with the chairs and I believe it should be resolved fairly easily. I don't think we need to discuss it here. Magnus: I would like to discuss Alissa's second point. I interpret a charter as allowing anything matching the current framework is fine, and I think that is too wide. Ignas: I would tend to agree it is quite wide. Historically, anima has been branched from nmrg and it still has quite a lot of history of being run as a RG and not necessarily a WG. Their topic is much more experimental than something tangible, so from that point, the charter is quite broad. Whether it is too broad, given the current developments in the next steps of BRSKI, so the profiles of BRSKI usage, and that will be the main work target for a couple of years. I think the WG will be busy on that topic and not necessarily look elsewhere. Magnus: But this work is still targeting proposed standards and not experimental specifications. Ignas: Some of them will be Proposed Standards, yes, although I believe the bigger part of the work will not result in documents as such. That will be either extensions to the BRSKI, or some use cases of it. Alissa: If that's what people expect to focus on, and that's where the deployment effort is going to be, wouldn't it make sense to scope the charter to what people will work on and reevaluate the charter after that? Ignas: Probably, but there is one tiny problem. The BRSKI developments happening is mostly what we are talking about right now. They wanted to have a BOF, they were not ready, and most of the proposals being drafted will be after the Montreal time frame when something more concrete is available. There's little tangible to be put into the charter at this point in time. We have two options: one is to wait until after Montreal to see if something can go in, or we leave the charter rather open to allow that work to get in right now. Alissa: I guess I don't really see the rush, if they managed to do BRSKI itself under the old charter. Ignas: BRSKI was specifically listed as one of the deliverables. Alissa: It seems like they could do their BOFing and then it would be more clear what should be in scope. Ignas: Probably. Alissa: I think that's preferable. The point of the charter is to help people focus, and all be talking about the same set of problems. I think that would be better. Ignas: Understood. From a focus perspective, anima historically has not that much focus. It's a broad group trying to cover many things and that is one of the reasons there are no specific deliverables. It's not known a few meeting cycles in advance what the next interesting topic for the WG will be. So one other comment for Deborah, you asked what about operated by professionals. This is to differentiate from the homenet. Anima will specifically not look into the topics that homenet is trying to do. Deborah: But it needs to be clarified. The original was very clear; just saying managed by professionals is not the definition in the framework. Either they should go back to the original two paragraphs, which was very clear, or they use something like what's in the framework document. Eric: On the homenet side, while it contains the word home, it's also applicable to very small enterprises with a couple of routers. So professional small business would use homenet if it exists. Ignas: That's a different interpretation of the word professional. In anima's context it means managed professionally by somebody. Whereas home net is not necessarily managed at all. Magnus: I agree. So call it managed. Deborah: It's probably just English. Professional can be interpreted many different ways and it's just not a good descriptive word here. Ignas: I get the point. So from the comments it seems the charter needs to be reworked, and I'm not certain which state that should be. Amy: I think it's just that we're waiting for instructions from you, so it will sit until you're ready. o Limited Additional Mechanisms for PKIX and SMIME (lamps) Amy: It looks like the choice is external review, is that correct? Roman: Maybe I hit the wrong button. I'm not sure what I want. It's ready to go, so external review means what? Amy: When you're rechartering a WG, there are two choices you make at the beginning: one that the changes to the charter are so small we can approve this, and the other is a more significant change so it has to go for external review before we come back and approve it. Roman: Okay, so I picked the right button. Amy: I have no blocking comments for external review so it looks like that's ready to go, and we'll get that sent tomorrow. 4.2.2 Proposed for approval o JSON Mail Access Protocol (jmap) Amy: I had a block that may have been cleared. So it looks like there are currently no blocks and unless there's an objection now, this one is approved. Hearing no objections, so this is approved and we will get that in production. 5. IAB news we can use Mirja: The workshop I announced last time, which will happen on June 4 and 5 in Finland, the deadline for submission is still open. Because there's a Backstreet Boys concert they will release hotel information soon and you'll probably need to book fast to get a room. The second item is that they are organizing another workshop called ESCAPE, which stands for Exploring Synergies Between Content Aggregation and the Publisher Ecosystem. That will be held in Virginia in the US just before the Montreal IETF meeting. The goal here is to get people into the room who usually don't come to IETF from the publishing business an talk about the web ecosystem. The call for this workshop should have gone out yesterday and there's also a blog post on the IETF website following in a couple of weeks. That's it. Alissa: The hotel info for Helsinki is on the workshop page right now. 6. Management issues 6.1 [IANA #1137877] Upcoming Parameter Expiration: Early IANA Allocation for RFC 8111 (IANA) Amy: It looks like we need IESG approval for a second renewal of this, is that correct? Michelle: That's correct. Deborah already indicated that we should get the additional year renewal, so per the instructions in the RFC we just have to get the IESG to approve that. Deborah: I recommend approval because this is already done and in the RFC Editor queue. It's just waiting for its references. Amy: Any objection to approving the renewal? Hearing no objection, so this is approved. 6.2 [IANA #1141661] Designated experts for RFC 8520 (Ignas Bagdonas/IANA) Amy: We are here to approve Eliot Lear and Dan Romascanu in these roles. Any objection to approving them? Hearing none, so they are approved. 6.3 [IANA #1141663] Designated experts for RFC-ietf-sipcore-sip-push (Adam Roach/IANA) Amy: This is to approve Christer Holmberg as a designated expert. Any objection to approving them? Hearing none, so they are approved. 6.4 [IANA #1141664] Designated experts for RFC-ietf-core-object-security (IANA) Amy: This was assigned to Alexey at the top of the call and we will move on. 6.5 [IANA #1139586] Designated experts for RFC 5580 (Ben Kaduk) Amy: This is to approve Alan DeKok and Mohit Sethi as designated experts. Any objection to approving them? Hearing none, so they are approved. 6.6 [IANA #1137011] Listing RFC 6281 as service name reference (IANA) Deborah: Mirja, you responded to Amanda saying that maybe IESG shouldn't be the assignee? Mirja: My understanding was that because it was an informational document it should not. I don't know if Magnus has had a look at this. Those are assigned on a first come first served basis so I think it's less important to have the IETF as the assignee there. Michelle: So we can go ahead and use the original assignees that were submitted, then we don't need the IESG to approve anything and we can mark this as done. 7. Any Other Business (WG News, New Proposals, etc.)