INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-10-05 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jenny Bui (AMS) / IETF Secretariat Roman Danyliw (CERT/SEI) / Security Area Dhruv Dhody (Huawei) / IAB Liaison Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Applications and Real-Time Area Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Martin Duke (Google) / Transport Area Warren Kumari (Google) / Operations and Management Area OBSERVERS --------------------------------- Brendan McMillion Greg Wood Jeffrey Zhang 1.2 Bash the agenda Liz: Does anyone have anything to add to today's agenda or any changes? 1.3 Approval of the minutes of past telechats Liz: Does anyone have any objections to the minutes of the September 21st teleconference being approved? Hearing no objections so we'll get those posted. We also have narrative minutes, does anyone have any objections to the narratives minutes being approved? Hearing no objections, we'll get those posted as well. This time we also have the minutes from the BoF coordination call for approval which you've seen a couple of versions of in email. Does anyone have any objections to the BoF minutes being approved? Hearing no objections from there either so we will get all of those posted. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Rob Wilton to find designated experts for RFC 9445 (RADIUS Extensions for DHCP-Configured Services) [IANA #1279159] Eric: Rob told us he'll be late in the call so we might want to push this back to the end. Liz: Sure, we can just leave this in progress for him. o Roman Danyliw to find designated experts for draft-yee-ssh-iana- requirements-03 (Key Exchange Method Names) [IANA #1281831]. o Roman Danyliw to find designated experts for RFC 9447, ACME Authority Token Challenge Types" [IANA #1281679]. Roman: I have some names planned, I just haven't closed the loop with a position yes so i'll get this sorted out. It's more than normal in progress. * OPEN ACTION ITEMS o Warren Kumari to follow up on a bis document for RFC 8126 regarding designated experts. Liz: Warren is not with us today so we'll leave this in progress for him. o Roman Danyliw to open a Datatracker issue suggesting a feature to better signal individual contributions. Roman: Needed to sync with the LLC, with Greg on the CAUSEPLAN? they were working on. They've given me feedback that were all clear. I'm just looking at my retreat notes because I feel like we made the right words for this but in the Datatracker, i've been unable to locate them. I just need a little more time to keep searching. o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John Scudder, and Jim Guichard to draft text regarding document authorship/editorship with regards to the number of authors listed. Andrew: I have just sent to the IESG some draft text that myself and the other guys who are working on it have done some edits. Still in progress and we'll need to have a discussion about it and what what we're doing to do about it. I proposed that i'll probably put it in the informal agenda next week. o Lars Eggert to facilitate a community discussion on priorities for IESG processes. Liz: we don't have Lars yet, so we'll leave this in progress for him. o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858, 2) draft a revised IESG Statement on Document Shepherds (original statement October 2010), and 3) update the WG Chairs wiki to point to the new IESG Statement. Liz: Neither of them are here so we'll leave in progress. o Warren Kumari to follow up with the tools team regarding removing the requirement of needing an author email for deceased authors. Liz: We'll skip that. o Martin Duke to draft an email to the community about the ART/TSV Area merger. Liz: I know this is done. Martin is not here, so we'll just mark that as done for him. o John Scudder to update the NomCom instructions from the IESG with information about the ART/TSV merger. John: That is done. o John Scudder to follow up on the RSWG Chair appointment. John: Also done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-bess-mvpn-evpn-aggregation-label-13 - IETF stream MVPN/EVPN Tunnel Aggregation with Common Labels (Proposed Standard) Token: Andrew Alston Liz: There are no discusses in the Tracker unless there is an objection it looks like this one is approved. Andrew: Yep, and all of the comments from what I can see has been resolved as well. This one can move ahead. Liz: Do you want to check it over one last time or this ready to go? Andrew: I did that this afternoon. I'm comfortable, this is ready to go. Liz: This one is approved and actually ready. We will send that announcement. o draft-ietf-ohai-svcb-config-06 - IETF stream Discovery of Oblivious Services via Service Binding Records (Proposed Standard) Token: Murray Kucherawy Liz: There's no discusses in the Tracker, so if there's no objection this one is also ready to be approved. Murray: AD follow-up please, I just want to check with them one more time to see if they have anything pending but after i'll approve it Liz: Great. This will be approved announcement to be sent, AD follow-up and you can let us know when this is ready to go. o draft-ietf-regext-rdap-openid-25 - IETF stream Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect (Proposed Standard) Token: Murray Kucherawy Liz: We do have a couple of discusses for this document, do we need to discuss it today? Murray: No, I expected one from Roman. Thank you for your detailed work; both of you. I will take it up with the working group. Unless one of you want the airtime. Liz: We'll keep this in IESG evaluation. Is this going to require a revised ID? Murray: Almost certainly, so go ahead. I'll change it if I have to. 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 o status-change-lisp-eid-block-to-historic-00 - IETF stream Move RFC7954 and RFC7955 to Historic (None) Token: Jim Guichard Liz: The consensus is unknown so we can go ahead and change this to yes for you. We have no disccues in the tracker so unless there's an objection I think this one is ready to go. Andrew: This is most yeses i've been on a document, particularly one that doesn't officially have consensus. Murray: It's not technically a document otherwise I would've made the same observation. Jim: It's a record. Liz: Jim, is this ready to go as is? Do you want check anything over first? Jim: There's a couple of text changes I need to add, very minimal. There was one comment on the last call that I wanted to add some text, if that's ok. Once I've done that, it's ready to go. Liz: Ok great. We'll put this in AD follow-up for you and you can let us know when it's ready to go. 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-irtf-icnrg-pathsteering-00 IETF conflict review for draft-irtf-icnrg-pathsteering draft-irtf-icnrg-pathsteering-07 Path Steering in CCNx and NDN (IRTF: Experimental) Token: Erik Kline Liz: We do have a discuss here, do we want to discuss it now? Erik: Zahed, I didn't notice this until not too long ago. Just by looking through the document for congestion control, I saw that they made claims that they support congestion control. That is even supports or enables something to happen for congestion control with better information. Not that it particularly participates in congestion control. Could add CCWG, if you want to jump in. Zahed: I wasn't sure what they're doing so that's why I came up this idea because it relates to CCWG. They use art multiple control algorithm, I don't know what that is. If there is some reference document published somewhere that is straight-up art then I don't know. I think this is conflicting because how transport AD sees the congestion control and multiple congestion control algorithm right now, and what it is right there. That is the one thing that I was discussing over email, I think if somehow there are multiple congestion control algorithms then definitely the need approval for their work that should some how relate to CCWG. My thing is if we write this relation and someone later picks it up. Right now i'm not sure. Andrew: I will say stating state of the art anything, particularly in documents that are going to live for a long time is kind of concerning. Erik, another thing is we obviously looking at this from a conflict perspective, but reading I do think they need to do something about a glossary or something because reading it without was sort of a headache. Erik: so those are comments for the document, but there wasn't comments for the conflict nature of the document. I agree state of the art probably shouldn't be in there, but we can say it conflicts with something. We can definitely say it has overlap with CCWG, but I didn't detect that it claims it was doing any congestion control in here. Zahed: That's what my problem is, i'm not sure what they're doing. Erik: So my read of this, with my layman's understand of this stuff and having have done a couple of view but by no means understanding it with any depths. This is kind of like recordroute, ICO and ICOP option recordroute. Recordroute gets sent in the interest message and resulting route gets returned back to the original sender. You can then use that resulting route information to basically send a packet along the same route again. Zahed: They are also saying that kind of information could be helpful for their congestion control algorithm. Two things, straight-up art and multiple congestion control, I think this is really vague. For the straight-up art, I think i'm having a discussion with Dirk on what they'll do about it. I don't think this is conflicting right now but you should add CCW to the review Erik: Yeah, I absolutely can. Sure, can say everything relate in the work done in CC and Spring WG. But the important part of this sentence this relationship does not prevent publishing. Zahed: Yeah, that's fine. If they don't change the straight-up art and the multiple congestion control, I do see that is conflicting with my view. I told them to say this is just an example, and not say this is straight-up art. Hopefully they will listen, I don't know if it's too late for them to do anything about it. Erik: Uh no, I think included some comments and nits, and they published a revised version so they're not beyond making changes or least they weren't for my small comments. I will CCWG to the list. Do we have a revised conflict as a state? Liz: No, we don't have for conflict reviews but we can just keep this in evaluation until it's ready to go and the discuss has cleared. Roman: Hold on, I want to talk to about process efficiency. Is all we need is CCWG added to the ballot and we're good to go? Is there any other changes to do, if not, can you just change it in real time now and not bring this back? Erik: That's what I doing. Updated. Roman: So if you clear then we don't need to bring it back Zahed: Let me find out and clear this up. Roman: I'm going to be honest with you, the reason i'm primarily asking because I just went through this with the next conflict review. There's this vibe that we need to include every kind of working group and I don't have the result of this is going ahead anyway, do we in fact need to list every possible working here and do we block on that? Is my philosophical kind of question. Erik: Zahed, if you click on it, you should see there's a dash 01. I've change it to say work done in CC and SPRING WGs. Zahed: Changed my ballot to no object with a comment. Liz: So I see green here which means this has now been approved. This is ready to go as is, you don't need to make any other changes? Zahed: I'll have the discussion with Dirk if there's any changes. Liz: Ok great, so this is approved and we'll send the no problem message to the RFC Editor. o conflict-review-irtf-t2trg-iot-edge-02 IETF conflict review for draft-irtf-t2trg-iot-edge draft-irtf-t2trg-iot-edge-10 IoT Edge Challenges and Functions (IRTF: Informational) Token: Roman Danyliw Liz: We don't have any active discusses. If there's no objection then is is approved. Roman: I added a bunch of working groups in real time, I updated the ballot last call. Eric: Thank you for adding IOT ops, I appreciate it. Liz: Ok, so this is approved and we'll send the standard no problem message to the RFC editor with the note that's currently in the tracker. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o vCon (vcon) Liz: We do have a block, do we need to discuss it now? Murray: No, thank you for the reviews. I will take all the comments back to the proponents and hack this together before we move it to the next step. Lliz: Ok so we'll just wait for instructions from you Murray. 4.1.2 Proposed for approval o Key Transparency (keytrans) Liz: No blocking comments, so if there's no objections now then this working group can be created. Roman: So Paul since you abstained do you want to say something in real time? Paul: Sure. The reason I abstained is that I find two things really hard to match here. One is that, the system that they want to add for the transparency of end user and identity. That it should be more automatic and invisible to the user but on the other hand, all the messages in the system could go throug the service provider. Let's say you're using WhatApp or Signal, you go through the provider and unless you somehow verify with another client that you somehow not being the man in the middle then putting your own personal group in the middle then this doesn't actually work. This does sort of work if you use third party that is independent of the service provider and you're just adding trusted parties but still not guarantee that you're having key transparency. I was on the fence for a long time, and did a bunch of talking with Eckert yesterday. I think there's some use for it, but the core goal it's set out to do is actually not achievable with the current requirements and the charter. Hence my abstained, because I still see limited use not having a trusted third party in the system that is hopefully independent enough to add some value. Roman: Thanks Paul and thanks for the iterations with the community offline and online. I'm still going to proceed primarily I think we have that consensus from the community that they want to explore this. There's a lot of energy around that. Administratively, if we're going to approve this, can we leave it in the state it currently is? I have partial commitments from a chairing team, but I need to button all that up before we do official announcements. I don't think we're going to end up with the full team that's currently in there right now. Liz: Sure thing, we can leave this where it is now and wait for further instructions. o Structured Email (sml) Liz: We do have a blocking comment, do we need to discuss it now? Murray: Yes, that's very minor. I will make that slight change and let Eric know and we can launch this. Andrew: One observation which I decided not to write a full comment on. I really hope someone is going to be looking at the security very closely because the charter mentions it in one line but reading this, we're creating a working group to create APIs to make more efficient stem. Murray: I dont think you should be shy about making a comment like that. If I can't work something like that in the charter. I'll make sure they're thinking about this. While we have a captive audience here, does anyone have any suggestions with whom we might coordinate alay this here? Roman: Well to me MOD seems which is in he charter would be the biggest and easiest thing I would point to. Not things you can put in the charter, but obviously here and other places that email is highly centralized across a limited provided providers. Murray: Yeah ok, that's satisfactory at all? Andrew: I didn't quite know how to word that comment because I had no idea what to suggest on it. That's how the document felt when I read it. Murray: I'm inclined given the handover that's coming to find someway to find something to say something a little more explicit in the charter. I don't want to do something handshakey. I rather have it written somewhere for someone who inherits this, i'll noodle on that. Thanks for the suggestion. Andrew: Ping me if you want to run anything pass me, etc. Murray: Please feel free. To answer the secretariat's question, i'll loop back with Eric and get this cleared up and we can launch this by the time I do that, i'll also have Andrew's thing dealt with. 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 Roman: We have a couple of things in flight, just a heads up. I'm going to try to do a better job at continuing to send forth those technical talks. I think the satelite tech talk was well received. I'm impressed with the talks that the IAB is doing, all of them would be of interest to the IESG so i'm going to be sending them in advance of that. The IAB is working on a technical plenary of data privacy rights and that coordination is still on flight. Under discussion is minting a new "Admin Support Work for IETF and WC3 Coordination" this is a kin to the admin support groups we already have to IEEE, for example. To do that for WC3, and that's under discussion. Eric: What is meant by administrative group? Is a person? Roman: No I had to look it up, and the secretariat can correct me here. The administrative group is akin to the thing that we have for IEEE and others, where it gets a marker in the Datatracker. There's probably a mailing list and it speaks to the counter party. Mirja: This is the tone we split up our technical programs. We also have other groups that were called programs in other times but it's more to help us with our charters which includes liaison management. Roman: Mirja, Andrew, is there a follow-up action on the client side scanning with the IESG statement? Cindy: It's listed as a management item for today. Roman: The other thing the IAB is noodling over, is the response to the US National Standards Strategy which just got published, and whether to respond to that. Mirja: Back to the coordinator group effort, this started because I was at WC3 a couple weeks ago and I figured out that there's much more overlap and we should probably do some coordination or the liaison managers should sit together and figure out if we should do more frequent coordination. We want to create this group and give them a home in the Datatracker so they can meet once every IETF cycle online. Create a mailing list and have the right people involved. The point Lars raised yesterday in the IAB, was that this means additional loads for some ADs especially the ones in SEC and ART probably because there's the most overlap with WC3. So before approving this group, we want to run it by the IESG. I am in touch with Martin Thompson who is our liaison with WC3 to get better idea what the items are, so you can provide us feedback. This is coming in the next days. Mirja: And maybe I can one more small thing, I sent an email about this yesterday. The people SVTA reached out to us because they have a meeting just a few days earlier in Prague and asked if we want to have a joint leadership meeting to figure out any overlap. I'm trying to set this up for Saturday and meet for maybe an hour. Please indicate to me if you would like to join that meeting, and if you have any time constraints. Eric: And just for information during the regular MOPS working group meeting, we typically get a couple of SVTA representatives and Glenn Deen, is both SVTA and IETF also explains what SVTA is doing. We already get some loose connections and getting a more close connection is even better. Thanks Mirja. Mirja: I think from their side they might have the attention to establish something more formal. From our side, if there's already collaboration, the right people do the right thing then I don't think we need more formality. However, this is something we discuss with them at the meeting. At this point, I just see this as a one term time opportunity. Eric: It's more social than doing something seriously. Mirja: We already have a handful of people joining for this meeting which probably good enough but it would be nice if some people show up so please consider. 6. Management issues 6.1 Designated Experts for the "Privacy Pass Parameters" registry (Paul Wouters) Paul: If I understand things correctly, there two documents in the Privacy Pass universe. One is further ahead than the other one, but one that is trailing is the one that is creating the registry. I think there's some confusion, IANA tried to contact the experts and realized that those experts haven't been requested yet. I'm sure if I can do a management item for the Privacy Pass that are coming or doing them proactively for the document that's isn't far ahead but there will be a privacy pass group where there will a registry. I've gor these three people there who are willing to be designated experts. Can this be created or do I have to wait for document to proceed? Liz: Sabrina, is on the call hopefully, this is a question that Sabrina can help us answer. Sabrina: What we were asking to unofficially ask them to review it and once the document has been approved and we can assign the experts then we can officially add them there. Just right now to unofficially ask them to review the document. Paul: Ok so that would mean that deciding would get postponed until the other document gets further in the publication queue. Sabrina: Yeah, we wouldn't be able to add them to the registry until it gets created. If you want to go ahead and approve it today and it's ok with everyone then we can definitely add it once the document is approved. We just got be able to add the names to registry until it's up. Paul: Well yeah, I think we'll wait until it's approved just so we don't have any special process in place. If it's good for you, if you can contact these people for any outstanding questions you have on the document then we'll deal with the designated experts once the document is approved. Sabrina: Ok well do. Liz: Ok, we can bring this back once the document is ready for approval. 6.3 Subdomain for IETF Store (Greg Wood) Paul: This might be a silly question, but the store is going to make money and the money is going where? Greg: This store is aiming to recover cost and small additional margin above cost, but it's mostly about recovering cost so the money would go to the IETF LLC and endowment. This isn't an issue we have yet. Mirja: Have you consider any other words than store? Because store seems super general to me, giftstore seems slightly better. Greg: Yeah, we considered some others one but this is seems the most straightforward and understandable, and what is generally used for sites where you purchase physical goods. Mirja: The only concern I have is we are not selling any other physical goods. It feels like rather gadgets and gifts is where you would sell your actual products. It's not a strong concern. Lars: Store is pretty common, and if you don't like store please make a better suggestion because otherwise it's unfair to Greg. Mirja: Yeah, that's what I asked if you considered other terms and what were the other terms. John: maybe shop or something like that, but I don't really don't care. Roman: I think it's a great idea to have a store for brand awareness. Liz: Ok, I don't think I hear any other objections or suggestions. Lars: Store it is. I also like to minute the domain that Robert picked for the dmarc, that started with the underscore. Given it started with a underscore, I don't think it conflicts with any names that we'll use for anything. I would minute that we approved that as well. Eric: Is it forwardingalgorithm? But there is no underscore before. It's enough to look at the SMPT header, right? Lars: No, this is a new thing. Erics: This is not the one that broke the email to Gmail? I just put it in the Slack. Lars: That must be it then. Liz: Does this something that needs to be officially approved> Lars: Any domain, the IESG needs to be formally approve. Cindy: Ietf.org is not a domain though, I don't think. Lars: It's being used as part of the dmarc rewriting. Robert isn't online, it was either in email or Slack, but I can't find it now. John: I just pasted it, September 26. IESG channel. Lars: It is forwardingalgorithms, there isn't an underscore. Eric: It's an email address, not really a domain name. But we approve it anyways. Lars: I think that's fine, let's approved that as well. Liz: The IESG approved using forwardingalgorthims@ietf.org for tools team use. 6.4 [IANA #1281697] renewing early allocations for draft-ietf-sidrops-aspa-profile (IANA) Liz: Warren is the AD for this and he's not on the call. Does anyone happen to know anything about this or this document? Do we need to bring this back the next telechat when Warren is here or do we want to approve it? Eric: It looks like it going to last call so it's making some progress. Lars: I would in that case we approve it. John: I don't know this particular document but aspa in general is moving forward so I would say approve. Liz: Ok, we'll officially note that we approved this and get the note to IANA. 6.5 IETF GitHub organizations for non-WGs (Secretariat) Cindy: I have sent email about this earlier this week and a number of you have replied. It looks like a pretty clear consensus not to do this. I just want to put this on the agenda so we can minute that decision in case this comes up again. Eric: I guess we all approve to disapprove. Lars: Only IETF things get IETF blessings. 6.6 IAB Statement on Encryption and Client-Side Scanning (Lars Eggert) Andrew: This document makes me a little nervous, not because I disagree. Lars: This is something IAB has worked on this for awhile, and Paul who is the person from the IESG who was involved in this as well. The main idea that Mallory as the main driver here is to make this a joint IESG and IAB statement and I suggested to her if she wants the IESG to co-sign then she should have the IESG involved in this as early as possible but that didn't quite happen. I think Mallory assumed that Paul would channel every and all feedback of the IESG which is little bit of an unreasonable expectation. Basically, we got a copy of this awhile ago and some of you have concerns and weren't willing to sign it in the form it was in and sent a bunch of comments. There was a discussion on the IAB call yesterday and because the IAB wants to finalize this, this is now just an IAB statement. The reason this is here, is in case individual area directors wanted to co-sign this, you could individually. You could just send Mallory individually comments, but she seems to be a bit hesitant on applying things because she thinks she's done. If you want to individually co-sign this, contact the IAB. Base on what I heard on email, I don't think it's possible for the entire IESG to sign this thing in it's current form. Eric: And especially since all my comments are closed without further comments. Paul: I'm also not sure if individually signing actually makes sense. It feels like we're publicly sharing that the ISB (IESG/IAB) is divided on this and i'm not sure if that's helpful to the document at all. Mirja: I think why proposed that is mainly because this is a IAB statement so there's IAB consensus but Paul, you also helped a lot with that and you have an opinion, so you actually want express that I think it makes sense. Andrew: In it's current form, I couldn't co-sign this. I certainly agree on the sentiment behind the document, I kind of think the document says there's no technical way to do this and doesn't elaborate of that at all. Further takes, what I would consider an adversarial position where the document reads like the IETF is going keep using standards to encrypt stuff and i'm not convinced taking an adversarial positon like that is necessary politically conducive to actually get change because it came across to me a adversarial take on things. Zahed: Just to understand what we're discussing right now, I think the decision was in the informal was we're not signing as IESG and I think Lars asked if some the ADs would personally like to sign it then go ahead. I think we're not revisiting those kind of things. I agree with Paul here, signing it personally. I don't know what that means, so if it's an IAB statement then let's put it in the IAB name. Lars: It's just a heads up for you guys to see if you want to individually co-sign it, and if nobody then that will be fine as well. Mirja: No, we'll need to know who is interested in co-signing so we can work with that set of people so we can we get the statement out. If you are considering co-signing, please let us know now. Roman: I provided very detailed feedback that I don't think even adjudicated. The one thing I would caution the IAB on is I think the reference to that US law, the way that sentence is written like i've said before is not entirely accurate. There's a lot of extrapolation that's happening and the implications of that proposed language versus what is actually in the language. Mirja: You mean sentence in this sub-paragraph here "this statement is a reaction to the policy proposals"? Roman: There's a wide net being cast about picking up laws relative to encryption to client-side scanning. I would urge the IAB to really read the text of the bill and cross walk that how it's going to be bind and philosophical positon relative to is it actually saying client-side scanning. Mirja: I understand your point, but in the end in the end this is not a reaction to specific proposal, it's a reaction to the whole discussion. A lot of these proposals are at a state where they are abstract and the details are not decided yet. That's a level we cannot discuss. And a reaction to your comments, I just want to make people aware that it's not about client-side scanning in general, we should revise the title of the statement. It's about the fact the government or third party is required to have accessory to private data and required in a way you do not have control of that access - thats the important part. It's not about having parental control installed in your kid's devices which is also about client-side scanning. It's really about giving access in an uncontrolled way required by government. Roman: I completely agree which is why, I don't think bad things about client-side scanning but the narrative text to me doesn't kind support that because slight of hand talking about QUIC, TLS and the rest of them because it has nothing to do with this mandatory kind of thing. It's a nonsecular from as far as I can tell. Mirja: Ok, that paragraph is to mainly show that background in the IETF about the importance encryption and privacy so that's just to give context. The IAB needs to give a little more work into that. We put a lot of work, but I feel like we're still not there given the comments from the IESG. Zahed: I think you're right on that one. I felt that I didn't really understand the motivation is educational or it's on the line where we have the technology but you will not be able to do it anyway. That's a different kind of tone than educational. I think that tone, i'm not sure. Like Lars said, we were not involved, and I was not sure what the intention is educational or a statement so it's a bit tough for me to say anything. Lars: So basically Mirja asked if anyone is interested in co-signing then let IAB know now. Andrew: I understand this is an IAB statement, but I would miss not stating my concerns that. Lars: Andrew you need to take the pen to the IAB. Andrew: Yes, but it is the IAB taking the position about the IETF. Lars: And they can do that, right. They are the architect of the Internet is task with, and you could argue that this is part of that. I would urge you to send feedback to the IAB, and cc the IESG if you would like so we can see but it's really IAB that needs to hear it. Mirja: Ok, so it sounds like nobody from the IESG is intersted in co-signing. Paul, you also think you shouldn't co-sign as a single AD? Paul: Yeah, that's right. Personally, I would like to sign it, but I don't think a single IESG member should sign it. Mirja: Ok, I think this is perfectly fine as an IAB statement only. No problem about this, I just want to confirm. Thank you. 6.2 IETF 118 Agenda Conflict Resolution (Secretariat) The agenda conflict resolution was discussed. 7. Any Other Business (WG News, New Proposals, etc.) Eric: You approved a couple of weeks all the ADD drafts, they are now in AUTH 48. I put one on hold because two implications when reading one sentence differently. They were sending DNS information in either a compressed file or a wide file. This is usually not good to have a document that is unclear and ambiguous if you have two readings of one sentence. IPSECME and Paul because they are using the same kind of thing there, transferring the same kind of information in both cases IPSECME and my case is over HTTP4 and IPV6. There are a couple of arguments in favor of one over the other. I was hoping to solve the issue and get one way tonight European time, but I think I need to read a little bit more. This is show that it's too not late to change a document even after multiple reviews if there are ambiguities. Roman: I think the document is mine because it's in IPSECME. I need to send a note just to halt it. I see a lot of healthy discussions, I haven't been able to catch up just to make sure the right things are happening across document because that's obviously what we want. Paul: I do think the consensus has been reached and that i'm in the rough. Please do carefully look over all the feedback. Lars: We should start planning the IESG and IAB agendas for Prague. There is the WIKI page that everyone always forgets about which is the upcoming meeting WIKI. Add topics on top and if you have any indications if this is for the IESG only or the joint session with the IAB, indicate. At some point, Mirja and I will do triage and bucket the things. I have one request from Elliot Lear who wants to explain to us what the ISE is about and I said i'll put it on there as tentative. Lars: We also have an ART person that accepted the nominations, now we just need another one. Rob: On the topic on what the ISE does, I think it makes more sense to do when the IESG is seated. Do we want to discuss the 6MAN document regarding zoning IP adress. Do we want to discuss that document now or not? Erik: Which document was that, Rob? Rob: The one that Murray and I are holding discusses for which I will be moving to abstained. Murray: I said on the mailing list what my concerns is, the background here is the 6MAN people want to do something the browser people feel like it's wondering in their space. People from WC3 object, the authors are persisting saying we have consensus to do this. Neither side are offering solutions that the other side is consider workable. They have both threaten to appeal. I'm holding a discuss on behalf of the WC3 people and is supported by a couple of people. I move to abstained, it wouldn't actually stop this there would still be appeals. The mess doesn't go away. The two people who are supporting my abstained, who are Francesca and Andrew, you have to decide to you also move to abstained or do you pick up the discuss or do you move to no objections. The document still needs at least one ballot before it can be approved anyways. I think there are 3-4 people who have not balloted yet, so two of us move out of the way and there are no objections then it's off to the races. On the other hand, if enough people move to abstained then it's dead. Andrew: I would almost certainly swing mine to abstained. Erik: From the author's perspective, they felt like they responded to all the feedback that were technical feedback that they could respond to. From his perspective, he feels like they're just throwing objections because they don't want to do this and they don't want to do this ever. We do have people who do want to do this, there is one toy implementation and one manufactor who wants support for this. Eric: It's not only about browser using this, right? Erik: There are command utilities that would be fixed. In discussion with the 6MAN chairs and with Eric last Friday, we agreed to update the shepherd write-up to get all the documents in a row for someone who is doing a peer review could have a clear view of everything and capture all the state and to bring it to a telechat. John: Doesn't Warren have some unrelated discuss on it also? Rob: It's me, my discuss is mainly about I don't like the fact that it changes the effectively IP address from an integer to a string. It changes the link local to device local scope and string identifier to add it on to differentiate it. I think that's a bad thing to do and that's leeched down into the YANG model. Rob: That was done a long time ago, and they tried bringing URLs and do rework and now they're trying to update it. For me, the better thing to do is kill IDs and keep local addresses and find a different local addresses. Erik: Local addresses are inherently scoped to an interface. Rob: Yes. (crosstalk) Rob: Once you start referencing outside of that interface, outside of that scope and you want to explicitly have a way to identify them outside of scope userface. That's where the scope changes. This isn't a device scope address. Erik: Because the interface is scoped to the device. Rob: Yes. Erik: There's nothing wrong with that. I don't think. Rob: The thing I think is wrong keeps changing, the IP address being the numerical identifier to a string. If you look at the YANG model at IETF, the IP address, it doesn't take a numerical identifier. Sometimes it's right, and sometimes is wrong. 90% of it in the IETF is wrong. They just add a load of complexity that doesn't really help. Erik: No, it doesn't add the complexity. The complexity is already there, it's a subtle but important distinction. Rob: I know, I have no issues with link address. I think the it's better to have a allocated device to local addresses than numerical. That solves the problem, you don't have to have any other issues because it just looks like another local IP address rather than link local. Erik: What is device local address? Rob: Device local address is where after you do your ND exchange between your peer, and you both agree how much unique on both devices and allocate an IP address base on that. Local to each device and local to that and you can use the local identifier. Erik: What procotol for this IP adresses configuration mechanism? Rob: I would suggest ND but i'm not an expert. Erik: What you're talking about inventing something new from old cloth that dosen't exist today. Rob: Yes. Correct Erik: Yeah, that doesn't seem like a workable suggestion to me. Eric: What happens if you get a separation? Partion of the link, where you have only one way link. So you can distinguish it because there's only one way. Erik: You're adding a new category of addresses as well. Rob: You sort of got that category of effectively with the identifier. Erik: They exist today. Eric: Even in IPV4 as well, but they exist. Erik: Because Stewart Cheshire work them. Rob: They exist today, but the way they've been referenced is a mistake. I have no issues with like a YANG model underneath the interface with the local address because the scoping information is carried elsewhere. The bit where I think is wrong, is where you create a new identifier and bind those two things together because it's not a numerical identifier. It's not like an IP address anymore, it's something different. Then they stopped turning up in models, they turn up elsewhere. They're used in a really small subset of cases. Eric: They ask here for representation, we don't have addresses it says. (crosstalk) Erik: There's another problem where as well, it's the scope name syntax that was created a long time and used in a lot of tools. There was never any ABNF for interface names nor can there be. Rob: And you can't up that in the URI Erik: You can put that in the URI actually. Rob: I thought what they're proposing here is does not allow percent scoping. They're plan to restrict the set of identifiers we can use to interface names They're purposing you can't use this on any large network devices. Lars: Can I suggest that we take some time on an informal and get the authors and the objectioners on call as well and see if we can make some progress on this. It looks like there's appeals on both sides. The authors can rightly appeal that the IESG isn't taking it forwarded and same happens if we take it forwarded and get the appeal from the people that don't like it. Murray: Is there such thing as abstained busting? If 6 of us decide we're not going to support this but we're not going object to it either, but we're not going to make the count. What's the appeal? Lars: The IESG has to make the decision to not progress the document. Erik: I don't about next week, it might be a bit early. Maybe the 26th, I could try to start coordinating emails. Murray: It's Mark and Martin on the WC3 side. I can see if they're available on the 26th. Erik: And Roy. Murray: I actually haven't talked to Roy about this, it's mostly the two guys i'm more familiar with. Erik: It's Roy that Brian has been dealing with. Cindy: The 26th is a formal telechat, you have two back-to-back since we get into the meeting. Murray: The 12th is our best option. We can also deal with this in Prague, if they're ok waiting for another month. Erik: We can put that in email. You can say the 12th or Prague. Lars: We can also take an half hour at a formal. It's not something we can't do, it's just we usually don't. Murray: We can also just make a meeting just for that. Lars: Why don't someone take an action item to get ahold of the individuals involved to see what they prefer if Prague is preferred or do an interim call. Erik: I can start emails and gather Doodle poll information. In progress.