Session Date/Time: 21 Jul 2026 07:00
[00:00:38] Dhruv Dhody: Good morning, everyone. This is IB open. Settle in. And could someone close the door? Thank you. Okay, still people coming in. Yes. So this is IAB open, Tuesday, early in the morning.
[00:01:08] Jánoslav Rosomakho (on behalf of Roman Danyliw): Let's start. I'm Dhruv. I'm the IAB chair. And I'm Jánoslav. I'm IAB member.
[00:01:17] Dhruv Dhody: While this is an IB open meeting, the ITF note will applies. By attending this meeting, by registering to the ITF, you have agreed to various different policies. Please be aware of them, especially the code of conduct. While we may have some heated discussions, please keep them clear of the guidelines that we have and please follow them. If you have any questions, please feel free to ask. So what is this meeting? What is IAB Open? This is a meeting in which us as an IAB members come and talk to the community. We provide updates to the various activities that the IAB has been doing. We talk about some technical and architectural topics at time, and you will see that. We focus on the liaison aspects, which IAB is responsible for on behalf of the ITF. And we want to increase the visibility of some of the IAB works and get feedback from the community as well. We also have an invited speaker today, so that would be an interesting talk towards the end of today's meeting. To engage with the IAB, iab. Dot org is our email. When you send an email to us, you will reach all our IAB members. Plus, we have IRTF chair, executive directors, liaisons, ISOC liaisons, etcetera as well. So be aware that the iab@iab.org is a much bigger mailing list than just the iab members. If we wanna have discussion about architectural topics, architecturediscussiab.org is our mailing list. Please feel free to use it. For liaison related requests, liaison coordinators have liaisoncoordinatorsiab.org. They also have an office hours on Wednesday. Please use this opportunity if you have any questions with respect to the liaisons. This is the IAB document status. As you know, IAB is one of the streams. We also publish RFCs. So in the recent past, we published three RFCs on various different workshops that we have completed in the recent past. So the workshop reports of all of them can now be seen in our RFC as well. With the active documents, currently we have four active documents. The IPGO workshop report, that's also been approved by the IB and we will be moving the status in the data tracker pretty soon and we'll be able to send this to the RFC editor as well. So this completes almost all our workshop reports that we have done in the past. We have two documents related to liaison management, which is on the agenda today. So we will get to hear updates from the authors who have been working on them. And then an output from the EDM technical program, was adopted by the IAB as well, which is the IAB protocol freezing. This document is also on the agenda, and Tommy will be giving us an update and asking for more feedback from the community on this topic. So these are all the documents which are currently in the IAB stream. Apart from coordinating the liaisons, sometimes the liaisons are directed to the IAB as well. So in the recent past, we had the liaison from ITOT TSB. This was related to e 164 country codes and e 164. ARPA. We provided a response for that for the ITOT in form of liaison statement. We also have some other pending ones mainly from ITOT to SG-seventeen that we will be discussing and responding accordingly. IAB plays an important part in the appeals chain as well. Since the last ITF, we received three appeals and we have responded to all three of them as well. And the chart that you see shows in the recent past what are the appeals that both IAB and ISG has received and processed recently. IAB also has a role in bringing new work. We help in BOF shepherding, both covering, as well as helping the community in in bringing the new work. For this, we held held a new work held desk on Monday. There is one more on Thursday. So if you have any feedback from IB members on how to bring new work, which direction to point to, what connections to make, process related questions, technical questions, we are here to help as well. So feel free
[00:05:59] János Farkas: to use this opportunity and come by our help desk, which
[00:06:03] Dhruv Dhody: will be just outside on the edge outside this room itself. Finally, this is our agenda for today. We have a liaison updates from János followed by Sureshh giving us an update on the documents that I was just mentioning about, Jánoslav giving updates on the various IV and ISG outreach activities that we have been doing, Tommy talking about the protocol coming out of the EDM technical program, and finally, a very exciting invited talk at the end of the session today and followed by open mic. So with that, let's start with our first first presentation, which is a liaison update from Janos.
[00:06:54] János Farkas: Good morning. Welcome, everyone. János Farkas, affiliated with Ericsson, and I am ITF's liaison managers towards IEEE 802 dot one. But before going any further, I would like to point out that whatever you hear here is my personal opinions, not official opinion of either of the IETF or IEEE 802 dot one. First, I thought to talk about a little bit the the coordination itself, like the process, and I have some technical slides depending on the interest and how much time we have. Could not resist adding some technical parts. So I'm talking about coordination with 802 dot one working group, which is part of a bigger coordination. So there is a coordination team between IETF and IEEE 802. I thought to give you a bigger picture as well. The coordination team has all the facilities like an ITF working group, a page, actually, Wiki, email list, and everything. The effort is led by Russ Housley. You know him very well on eight ITF side and Robert Sherry from IEEE 802 side. He he is the 802 dot 11 working group chair. This came up yesterday in 6MAN. We can have further discussions on dot 11 aspects. And the way of working is that the team meets prior to every ITF. There's a virtual meeting. Pre pandemic, we used to have in person meetings at the ITF as well. What we have now in person is time to time workshops, especially when the two groups are collocated, like last July in Madrid. The coordination team had a workshop. And during the meetings, we start typically taking a look at new work items in both organizations, and then we go to our running items. These are numbered it's a number list, and we keep the numbers, and this is why you see high numbers. They are increasing. So the I listed the active items. Item 25 is the one I will be talking a bit more. This is coordination between the 802 dot one time sensitive networking task group and the ITF deterministic networking working group. And the way of working is, I think the best way is common participation. So there are common participants in both groups, and that's the way we have been working from the very beginning. There are further coordination items. This is focus to 802.1, the development of young modules in I triple 802. This is ongoing effort. Each new standard has its own own young modules. So this is, I think, really good that is ongoing. Scott Mansfield is a is a champion of it, and this is really beneficial for overall for the industry. There is a one item capability discovery. This belongs to the LSVR working group. This might be going away. These things are happening at this meeting. I kept it for now and for reference for the upcoming slides. And security is an important topic, so post quantum cryptography is one of the key items. Both groups work on the topic. So we also leveraged the collocation last July for the two groups, the TSN and the DAT Networking Group. We had a half day joint workshop, and first half was about updates on standardization efforts. And given that both work is going on for a while, we got some updates and presentations on implementations, experiments, and so on. And actually, we had a very good discussion. We we were running over time leveraging the possibility of being in the same meeting room on on, like, the way forward with both groups, coordination, and so on. You can find the materials. And, unfortunately, this is not happening that often. We are not so often collocated. Last time was 2018 in Bangkok. And, of course, the takeaway was we should do it more. We should do it more frequently. But it depends actually on on the waiting locations quite a lot. And I thought to I have a few slides on what it is. I'm talking about what these groups are doing. So the TSN task group is the one that is responsible for time sensitive networking at layer layer two, and the the ITF deterministic networking working group is the one responsible for it at layer three. And, ultimately, I think this is spelled very well in the DETNET charter. That's why I copied the the two groups work to go towards together towards a common architecture to provide this end to end deterministic connectivity leveraging both layer two and layer three. So from that perspective, TSN is the primary subnet technology, but not the only one, of course. So that's how
[00:12:45] Brian Haberman: we
[00:12:45] János Farkas: envision the work from the very beginning. And this common architecture is actually along common components. This is illustrated in this figure. There is time synchronization. And along the lines of minimizing the duplication of the work and maximum alignment, DETNET doesn't work on time synchronization explicitly set from the very beginning, but leverage leverages time synchronization from lower layers. The 802 dot one group works on time synchronization. And on the other three aspects, the reliability and congestion protection that has two components, latency and resource management, both groups do their own part, and that's where actually the coordination happens at the technical level. And ultimately, both technologies are the colloquial way to say it is traffic engineering on steroids. So it's a generic networking with some add ons. It's not replacement of existing networking, but putting some ads on to existing technologies. And a few slides on the summaries for each just to give you a quick summary. I know it's all all eye charts, so this is the full landscape for TSN. There are the green ones, the the standards for the components. And in TSN, actually, we have so called profile specifications addressing a certain vertical how to use the the technology and being compliant to provide profile specification. Actually, one can expect that buying a box, you can use the box at a certain deployment. For example, the industrial automation was a joint project between IEC and IEEE. And as the way we work on DetNet as well, bring the experts of the different areas like industrial automation and networking to same meeting room, same project, and this was just published last month. There are two red boxes. That is the 802.1DC QoS exposure, I would say, which was done mainly for DETNET so that the QoS techniques that are in the 802 dot one q standard are available for non bridges like routers, firewalls. And the other one is we call it LLDP version two. The multi frame LLDP was triggered by the link state vector routing group. So this is was triggered from here. This is the DETNET RFC summary. The the red ones are related to TSN, like TSN underlay, TSN overlay. And just to list on what's going on in DetNet, actually, there is an activity for OEM that was started in the row working group, reliable available wireless, which has folded into DetNet. Quite some effort on queuing techniques addressing scalability requirements and two recently adopted items on multi domain framework for DetNet and SRV six data plane for DetNet. And in TSN, we have stand alone projects like resource allocation protocol and the cut through forwarding. These are the capital letter IDs, and the amendments are the small letter IDs with what they amend, some queuing techniques, traffic engineering for wireless. And there is some new work more more new work coming like telemetry tagging, backward notification. They are targeting new use cases coming from the ultra Ethernet consortium. And this is in a nutshell.
[00:16:35] Dhruv Dhody: Any questions for János? Thank you. János, one thing like maybe we always try to say is the liaisons works best when there are folks who are participating in both communities. And I think I want to commend you for helping making sure that the relationship that we have between these organizations is working so well. So thanks for all your effort.
[00:17:03] János Farkas: Thank you.
[00:17:07] Dhruv Dhody: Next we have Sureshh who will give us some updates on some documents. Oh, and media as well. Thank you.
[00:17:20] Sureshh Krishnan: Thank you. So this is like a set of documents. So RFC forty, fifty two, and 53 got published in 2005, from the Closer.
[00:17:31] Dhruv Dhody: Little closer, I guess.
[00:17:33] Jánoslav Rosomakho (on behalf of Roman Danyliw): Be shorter.
[00:17:39] Sureshh Krishnan: Now it's, can you hear me better, now? Okay. Thanks. Was it you, Brian? Okay. So 405253 got published in 2005, and we've changed a lot of things since then. And the documents don't accurately reflect what we do right now. And part of the issue was that there's a lot of low level guidance inside the document. So as part of this retrofit, we decided we'll just talk about the high level things and take out all the low level things and put them elsewhere. So whether it's in the tools or, like, some wiki somewhere, not to keep it in the documents. And, one of the things that kind of kept coming up as, like, role, of the IAB liaison coordinators is that people say, hey. We wanna set up a liaison relationship. And we always say, like, why? Right? And why do you wanna set up a liaison relationship? So people thought that the having a liaison relationship kind of gives some kind of additional privileges into the ITF process. So we say, like, hey. It doesn't. Right? Like, something coming in as a liaison statement is, like, you sending an email from a random email address. Right? So there's no difference, really. So we kind of try to clarify why a formal liaison relationship is needed and why, in most of the cases, it's the other organization that requires it, not us, because they they may not be able to share the documents without a liaison relationship, without membership and stuff and so on. So we try to put a lot of high level guidance and think of it as like a checklist on why somebody would want to formally listen relationship. And, also, one thing we kind of clarified was that, like, to send us a liaison statement, you don't need a liaison relationship. So this is also, like, something that is not obvious to people. So that's also something we kind of started putting in there. And these documents, for reasons, like, unclear to us and forgotten to a lot of people, these are BCP documents produced by the IAB. And the IAB, if you look at the RFC data model, it doesn't publish anything other than informational documents. So the process we are trying to follow is the IAB goes through the process, which is kind of almost done now. And after it's done, it moves on to the IESG. So the Roman would, like, take up this thing as a a d sponsored submission and take it through the IETF process. So we kind of, like, brought on the feedback thing to the agenda's patch right now so people can come and comment to us on the documents and see how they feel. So but most of the comment we received is from very experienced ITF participants, so we would like to hear more from people, and maybe I'll talk more about it. Okay. So I think we kind of talked through this. It's really about clarifications on why liaison relationships are needed. So there's, two documents. One of them is about setting up the relationship, how we do the liaison managers and stuff and so on. That's 4052bis. And we kind of subsumed stuff from another document which we're gonna obsolete, which is the forty six ninety one, which talks about the low role of a liaison manager. So we do have, like, lot of awesome liaison managers here, like, János, like, being one. And, like so we kind of subsume all these things into this document. Again, because we're not doing the low level guidance, it becomes, like, much simpler to pull in the like, how you bring the stuff in. And one thing that kind of always tripped up people is when you send a liaison statement, who are we speaking for? Right? And if a working group sends something or a area sends something or the ITF sends something, it requires, like, different levels of consensus, which we never documented properly. So I think that's something we also spend a bit of time to say, like, how do we document the level of consensus that this LS has? So that's it's in 52.
[00:21:11] János Farkas: So so maybe I'll talk more about it. Thanks.
[00:21:14] Robert Sparks: Thank you. Yes, so 52 is the document that describes the process to establish a formal liaison relationship, and 53 is the document that talks about how to send and receive liaison statements. 53 actually was written to define all the tooling details we have in our liaison tool, but that shouldn't go into an RFC, so we moved all the tooling details from it. So that means removing whole sections, parts of the introduction, all the appendix, and even the security considerations, because the considered security considerations talked about how to attack the tool that shouldn't be in our seat. So what the document is focused on is really more on high level requirements, and we added a lot of guidance to make things more clear, as Suresh said, that that we got questions about all the time. What's still in the document, which is kind of close to tooling, is really kind of the formatting. But instead of phrasing it on, like, requirements as a tool, it's really requirements on the liaison. You need some front matter. It has a certain structure. You need content. You need a subject line. So that's all still in there. What we we moved the approval requirements for liaison statements from 52 to 53, is because that's about liaison statements and not about liaison relationships. It was there because usually we have a liaison manager caring about this, but we also have liaison statements without a liaison relationship, without a liaison manager. Especially, we talk a lot about what kind of consensus is needed and try to clarify that. That's a case for confusion and also the approval strain. And, again, this clarification, liaison statements don't have a special standing. They get recorded publicly. That's a value in itself because you can see another organization said something. You can look it up. You can point to it. You can say, I told you so, also in the other direction. But then, you know and, like, you should take it seriously. Of course, you want to have a good relationship with the other organizations. But otherwise, you treat it like the same input from anybody else. It's not like any special. So this is the overview of the two documents. And we think, actually, they are done. We got a lot of good input from the on the architecture discuss list. That was the list we are using for many of the IAB things, and especially those people who have been involved in liaisons you can go to the next slide, I think who have been involved in liaisons have provided good feedback. So we don't have any open issues anymore, and we are kind of ready to go for IAB approval. But before we do that and then it goes into the ISG, and there will be an IETF last call. So there is time for commenting. But we would like to get the broader community feedback right now, so we can actually approve a document or the IAB can approve a document that we think is in good shape and will not change too much anymore. We're holding right after this session, we are holding a feedback session in the IAB room. So we will go in that session slightly more in detail through the documents and the changes, but you can also take your the next break and read the documents because they are not very long. And then you can provide any feedback in oral form, or you can, of course, also send written feedback later.
[00:24:17] Sureshh Krishnan: Thank you. And if you're a working group chair who had, like, issues, like, doing stuff, so we are trying to simplify the process, so please come and tell us. We did a working group chairs training couple of meetings ago. And so we do understand this is pretty complex. And I think, like, Jen is laughing at me because maybe 6MAN needs to send something soon, for FMS maybe. But, I I think, like, the idea is really to simplify the things because we understand, like, the the the liaison statement fields are, like, very complex and confusingly named, but we couldn't do any better. So we made it much better than before, but it's still pretty hard left. So yeah.
[00:24:53] Robert Sparks: Yeah. I mean, we are still also based on the changes in document, we are working on updating the tooling. So that's coming.
[00:24:59] János Farkas: Yeah.
[00:25:00] Sureshh Krishnan: Thanks, Robert. And and there's, like, this amazing flowchart for a workflow that, like, Robert came up with. We can share with you at some point, like, how this thing goes on. So it is fairly complex. A lot of the other orgs have, like, a separate set of people who do this, but it's us, like, who do the technical work and do this too. So, yeah, come help us make it better. Thanks.
[00:25:19] Robert Sparks: Are
[00:25:23] Dhruv Dhody: there any questions? Elliot?
[00:25:27] Sureshh Krishnan: Elliot? Just
[00:25:28] Eliot Lear: a comment. Thanks for tuning in to my comments. I think Sureshh and your guys have done good job on these documents and.
[00:25:38] Sureshh Krishnan: Thank you. Thanks, Elliot.
[00:25:40] Dhruv Dhody: Next time, use Meetecho on queue, please. Any other comments? Thank you.
[00:25:48] Lucas Pardew: Thanks.
[00:25:52] Dhruv Dhody: And next, have Jánoslav giving us an outreach update.
[00:26:03] Phillip Hallam-Baker: Hello,
[00:26:03] Jánoslav Rosomakho (on behalf of Roman Danyliw): everybody. Jánoslav, member of IAB with outreach update. So IB and ISG participate in outreach. So the outreach is, well, reaching out to other organizations presenting information about IETF on the conferences, talking to various stakeholders about what IETF is doing, about updates that are happening in IETF. Basically, there are a few types of outreach. First, that we typically deal in coordination with ISOC, that is outreach to policymakers, to Internet governance, to civil society. In certain cases, these organizations do care about technical details. They sometimes do care about some of the things that IETF is doing or, well, IETF, in certain cases, is relevant organization to educate them about what is happening in in terms of Internet specifications. The second group of targets for outreach are operator groups. Operator groups, they have they typically have various regional meetings such as RIPE, NANOG, APNIC, and others. So we do outreach to them, explain what is happening in IETF and also gathering their feedback. Another type of outreach is technology specific. So attending various industry conferences such as, most recently, RSA, for example, to share information about what IETF is doing that is relevant to particular topic of a given conference. And then we have various other SDOs, industry consortiums, Internet treaty organizations with some of which we have liaison relationships. And, again, in certain cases, we do outreach to them to share information about what IETF is doing. Last but not least, education institutions and open source community. So the key goals of outreach there to recruit new participants to IETF to, again, share information about what IETF is doing and with open source community, in particular, to get some people to start implementing some of the specifications that IETF is working on. There are four main outreach topics that are recurring. Introduction to IETF, so we maintain a deck of what is IETF, how IETF works, what is the process behind it, how IETF is structured, why IETF operates in the way it operates, which can be confusing to many outside of IETF. IETF is very different to most other standards bodies. It takes some time for some people to wrap their head around it how open standards organization can even exist in this day and age. So it yep. It's it's a it's a recurring theme to explain what is IETF, how it's working. We also maintain what's new at IETF deck and set of set of presentations. It's reasonably generic, so we coordinate with area with relevant area directors to keep this fresh and to keep it relevant. So highlighting the most important things that are happening in various areas. But also for each and every event, we try to customize it a little bit to make it relevant for a given audience. Third topic that we started, I think, relatively recently is specific to working group technology outreach, especially when we have a chance to attend an industry conference sharing about some new and exciting development in certain areas that audience might not be familiar with. And then last but not least, IB workshop and program reports. So we try to be as impartial as possible not to express our opinion on a certain topic that could be sometimes complicated, sometimes could be politically loaded, such as, for example, age verification workshop that we that we recently had, but sharing what was on the workshop, sharing as impartial as possible the outcomes of given workshop or progress in a given program. So most recently in this year, the events that we have attended included operators, various operators conferences, so Apricot, RIPE, LACNIC, and Nanook. One personal observation, it's interesting to see how different those conferences are. Different operators in different parts of the world operate differently. Some of them have very broad interest in wide range of topics. Others are much more laser focused on things such as Internet routing and don't really care about many other things. So we will be looking forwards in the future when we reach out to operators. We will be doing more customization of contents that we present to them. ICANN. So we had a session with government and end user stakeholders group to explain what is IETF and multistakeholder model. Had a chance to present at RSA conference, which is a security annual security conference attended with by a large number of cybersecurity practitioners to deep dive into MASQUE and WISH. Those technologies or groups of technologies that people at IITF are somewhat familiar with, but for people outside of IITF, they are relatively new and can be confusing. So had a had a chance to present there. Connections twenty twenty six is pre IETF forum in Bangalore. Dhruv had a chance to do a session there to introduce IETF and what is new, what is what is upcoming in this meeting. NICSY was an event for where where we had a chance to do knowledge sharing for Internet chip cohorts and net missions 2026 for knowledge sharing of next generation of Internet Internet governance governance enthusiasts. We have somebody in the queue.
[00:32:57] Dhruv Dhody: Let's finish this slide, I
[00:33:00] Jánoslav Rosomakho (on behalf of Roman Danyliw): Right. So for the rest of this year, we are planning to attend, thanks to thanks to collaboration with ISOC Global Digital Conference in Europe. There are operator conferences that are coming, OSNOC, APNIC, RIPE ninety three, and NANOG ninety eight. IGF twenty twenty six in December in Nairobi, Internet Governance Forum. Right now, we're actively working on our proposals for presentations at IGF. So this is very much a work in progress. ITU Forum in, I believe it's in Middle East, in 2020 in in late twenty twenty six, and ICANN eighty six '87, sorry, eighty seven conference. Those are the events that we're planning to attend and perform some form of outreach later this year. So we have few people in the queue, but I also have questions for our audience. What are events that you believe that we should try and participate in that we currently do not cover that should be relevant? What are other topics that you believe we should be covering that we do not cover today? And any other questions, suggestions, or feedback.
[00:34:24] Dhruv Dhody: Thank you. And we have Ted.
[00:34:27] Ted Hardie: Ted Hardy. This really should be Sally Wentworth, but since I didn't see her on the attendee list for this, I will I can't hear you. This is Ted Hardy. I'm oddly enough speaking on behalf of the ISOC board of trustees here. As you noted in the early part of the slides, one of the coordinations that the Internet architecture board does is work on policy topics with ISOC. And on slide four, you had a list of things that you had done. And I wanted to call out one of the things that we really appreciated your help on, which was working with ISOC on C-11 and C-27, in particular, the statements to the Canadian government on lawful access. Those were very, very helpful, we very much appreciated it. And I just wanted to call it out since it hadn't been listed. Thank you.
[00:35:12] Dhruv Dhody: Thank you, Ted.
[00:35:13] Jánoslav Rosomakho (on behalf of Roman Danyliw): Thank you very much. Jen?
[00:35:15] Jen Linkova: Jen Lincova, network operator and former chair of one of the RIPE working groups. Thanks. Thank you very much for going to the operator community. Don't know how we're doing time wise, but I'm just curious if you have any thoughts on what you would like to do differently in that outreach. I did share some of my observations earlier, and I'm just curious how like, is it applicable for other conferences? Basically, what you learned. So we are not doing the same thing over and over again expecting different results.
[00:35:50] Jánoslav Rosomakho (on behalf of Roman Danyliw): Right. Yes. So, I mean, I I I could share my perspective. So we do need to do more customization of contents, specific for the audience that we are outreaching to.
[00:36:03] Jen Linkova: So yeah. I just forgot to say, and if you need any help.
[00:36:07] Robert Sparks: I I am I am actually around here. Okay. Got it.
[00:36:10] Dhruv Dhody: Thanks, Jen. Georges.
[00:36:13] Georgios Karagiannis: I'm Georgios Karagiannis from Ahoy. Thanks very much for the outreach activities that IB is doing, but I would like also to mention some other kind of outreach activities that are actually also discussed in the education and outreach directorate. So one of them is, for example, what the IETF Foundation is doing, you know, to attract students. But as well, some activity that several companies did also who I was involved in the ITF one to five where we try to attract, stimulate students to also come to ITF. And, actually, we also have students that came then and are also now here. So that's think it's good to mention that as well.
[00:37:02] Jánoslav Rosomakho (on behalf of Roman Danyliw): Thank
[00:37:02] Georgios Karagiannis: you. And that was called the Chinese Youth Talent Program.
[00:37:07] Dhruv Dhody: Thank you so much, Georges. As we say, outreach is something not just for the leadership. I think we take part in various different communities. So when you are outside and attending some events, if you have topics about ITF, there is lots of materials that we maintained on our EODR Wiki. I'll point the link in the chat as well. Use those material. Come to EODR. Come to our leadership. We would like to do outreach more together. Yeah. Elliot.
[00:37:36] Eliot Lear: Thanks for this effort. Sorry. Thanks for this effort. This is Elliot. There are two groups that I'd like to see a little bit more focus on. The first is industry itself. So whether that's industrial IoT or IoT in terms of how they use the standards. And the reason that the outreach is important is because when they don't hear from this organization, they tend to go off and do things themselves and do them poorly. The second group is academia, where it would be great to see the IETF show up at or IAB leadership show up at various academic conferences, ACM, IEEE, Infocom comes to mind, SIGCOMM, HotNets, and to to try and at least explain what's going on and maybe where we need help.
[00:38:38] Jánoslav Rosomakho (on behalf of Roman Danyliw): Point taken. Thank you. And if you have specific suggestions for relevant industry conferences, that would be very appreciated.
[00:38:45] Dhruv Dhody: And this is where I think IRTF and Doug does a lot of good work as well. Yeah. Andrew?
[00:38:51] Andrew Campling: Yeah. Hi. Andrew Campling. Echoing other comments, thanks for doing the outreach. I think we're gradually changing the perception of the community as being introspective and uninterested in other people's opinions. So the more we do that, the better that that will be. Feedback, I think it was at Ripe. The enthusiastic presentations from a range of ISG and others were fantastic. Unfortunately, it sort of crowded out the time for feedback from the community, so I think a learning for future would be to maybe be a bit tighter in in on the delivery. But, yeah, the enthusiasm, I think, was really welcome. A conversation for later, I think, just because we assert we're multistakeholder, I continue to believe that's an that that's an incorrect assertion, but that's maybe a discussion for another day. But, yeah, thank you for doing it. It's a great thing to see.
[00:39:50] Jánoslav Rosomakho (on behalf of Roman Danyliw): Thank you. Warren?
[00:39:55] Dhruv Dhody: No? Go ahead.
[00:39:59] Speaker 13: Hi, Thanks for the update. I would really recommend again this comment about the academia. Mhmm. So I would like to see more collaborations happening with academic conferences rather than the other the governments and so on. I think that that you are doing a quite a good job. And specifically for academia, I think the need is not only to just educate what IETF is doing, and not only to develop, for instance, like the implementations of the drafts, which are or the work which is going on in the IETF, but on a parallel stream, which is like actually verifying that the properties that the drafts are supposed to achieve are actually being verified. So I work with my team on the formal analysis of the different drafts, which are being done in the different working groups. For instance, TLS has a proper analysis. We have that in that domain. And I know few researchers who actually would be willing to contribute if they are given more information, like how to come to IETF and how to contribute, and so on. And I would really like to emphasize a specific point, which is to say that it's not only development, but also finding the vulnerabilities is very, very important, because if you give out a standard out there in the middle, which is vulnerable to the extent of the critical severities, like 9.1 CVSS score vulnerabilities in IDF drafts, that's really bad. And I have actually, myself with my team, found these vulnerabilities. We have reported it out to the relevant working groups, like WIMSE, is Jánoslav is also chairing that. So 7.5 high critical vulnerabilities, up to 9.1, which are critical severity vulnerabilities. That's really something that we need to collaborate a lot with academia, and this is something that IT IAB, sorry, is needs to, like, find something more collaborative that we can academia can actually contribute more? Thanks.
[00:41:52] Dhruv Dhody: Thanks for the feedback. The one message that we give is there are various ways in which to participate at ITF and to contribute to ITF. It's not always with respect to writing drafts, but measuring things, formal analysis is one thing. So yes, there's many, many pathways to contribute, and thanks for highlighting that. Though we close the queue, but Brian, maybe a very quick one.
[00:42:14] Brian Haberman: Yeah. I just wanted to point out that it's great to say we should have more academics involved. But from experience, I can tell you that the fact that RFCs are generally not recognized as academic publications is a almost a showstopper for a lot of academics because academics still need publications and they need ones that are treated as first class by the academic community. So you might find that academics have to publish but not publish RFCs even if they want to work with the IDF.
[00:42:51] Dhruv Dhody: That's a known problem that we have been dealing for a while. But, yeah, thanks for highlighting it. Thank you. Thanks, Jánoslav. Next, we have Tommy.
[00:43:13] Tommy Pauly: Alright. Hello, everyone. I'm Tommy Polly, and I'm gonna be presenting one of the documents that the IB has adopted from one of its technical programs. This is from the EDM program that previously brought documents that are similar to this about how to maintain protocols and maintain their evolvability. This is the one kinda active thing that we've been working on for a while, which was more recently adopted onto the IOP stream. The goal here today is to let you know what's in this document, to maybe encourage you to read it, and also to get feedback of what could be missing on this before we finalize the document. So this is all about protocol greasing, which is a trend we are seeing generally that could could have some useful overall architectural comments on it. So you you may have heard about this before. This is not necessarily a new technique. We've had several different existing protocols define greasing. It was originally done for TLS in RFC eighty seven zero one. QUIC has greasing in it
[00:44:27] János Farkas: from the very
[00:44:28] Tommy Pauly: beginning. And these are all cases where there are specific protocol fields that have values that are reserved that don't mean anything, but they're used to make sure that unknown values are handled and accepted by peers or things that are intercepting the traffic to ensure that we don't have too much ossification. We also have previous IAB RFCs that cover aspects of this. There are certain things in the successful protocols RFC fifty two eighteen. That was before we had formal greasing that allude to these types of things. And the previous EDM document, RFC ninety one seventy, on the viability protocol extensions does talk about greasing. So why are we doing this now? What more needs to be said for greasing? So overall, greasing is an emerging pattern, and we're seeing that it is useful and can be applied to more protocols that are either being newly developed or where cases where we need to make sure we still can maintain extensibility. And it's a pattern that we're seeing, but it's not always obvious how to define it correctly within a protocol specification, and it's not always obvious how to implement it and deploy it correctly. So the goal for this document is to be a bit more practical than the previous documents and actually give very much on the ground guidance for how to actually define this, how to implement it, and how to deploy it, and also talk about the things that are very similar to greasing but are not strictly greasing that's our all around protocol variability. So it's a brief overview of what the document says. We try to give concrete guidance on how you define greasing within a protocol. So this starts with saying that you have, let's say, you know, some iana registry of a bunch of different values, and you should reserve grease values ahead of time. And we talk about how you can scale the range of those values and the number of those values to fit based on the size of the field. You're gonna have fewer grease values in an eight bit field, and you're gonna have a lot of them in a 64 bit field. And we talk about the common techniques of using an algorithm to define them so you don't have to list out every single greased value. Talk about how once you've assigned something to be a greased value, that can no longer be reused. That's kind of a burned value. And we give examples of how to define this with IANA. For implementations, there are a number of gotchas that we thought were important to call out. First, it's important to be unpredictable when you are sending grease. And and there's multiple dimensions here. You need to make sure that you are picking which grease values to send unpredictably. You don't wanna just keep sending the same grease values because then you could essentially ossify around that. And you also need to be careful about when you send the grease values and make sure it's not always being sent or never being sent, but have a good balance of how often you send it. There are also important cases on the receivers to make sure that when you're writing the code to handle unknown values that you do it correctly. There have actually been bugs that have been seen in implementations that will end up potentially accidentally special casing receiving the grease values, and so you still end up with implementations that are intolerant of new extensions being used. They just correctly handle grease. And so we provide some pseudocode on how to do that correctly. For deployment, there's a lot of interesting kinda game theory here about how do you actually get this out. When you are designing grease, you you're trying to fight ossification. You're trying to fight cases where networks or endpoints don't know how to correctly handle new values. And if things have already been deployed and have already ossified, deploying grease may lead to breakages. And if an implementation is starting to grease things, they may lead to these breakages and can get essentially blamed for that. So we talk about different ways that you can avoid these failures. It's a lot easier if you define grease very early on in the protocol definition. This is what QUIC did of just having it be there from pretty much the beginning so you don't have a problem of adding it later. We can talk about adding it with protocol version changes such that you have to really redo an implementation and switch over lots of things anyway, and so that you can start adding more grease at that point, or you can have heuristics to disable and retry after failure. We also talk about greasing the wire image. There are cases where the target of what you're trying to grease and what you're trying to make sure you're not ossifying is not the peer endpoints. So in the case of TLS or QUIC, you're often thinking about the actual peer between client and server and making sure that they're tolerant to changes. But there are a lot of cases where you also may be interested in ossification along the network path. And the considerations there can be a little bit different. You can actually have cases where you negotiate the fact that you grease this at all. This is the case that we saw with greasing the quick bit. And then we also talk about how to make the ossification visible, like when you detect a problem that you detect due to greasing, how do you report that? How do you have that lead to some sort of change or bug fixes? We also discussed protocol variability. Overall, trying to avoid ossification and trying to avoid intolerance to new protocol changes isn't just about greasing. Greasing is just one of the tools in the toolbox. And there's a broader set of things that are just about making your protocol behavior more variable. And we list many different examples, and we try to cover different layers of places where protocols can add variability to make sure that peers are more tolerant. QUIC has a number of cases that have done this about stream frames, crypto frames, and other things that you can split up between packets or reorder. TLS has interesting examples, particularly around when we added the post quantum handshakes and we had larger handshake sizes, and that's a case that exposed some cases of that where variability would have helped identify the problems earlier. I p v six header extensions have these same properties. And in general, we note that pretty much anything that can affect the wire image of how you split up your packets can be something DetNetworks can ossify around, and adding variability will help fight that ossification. But, of course, doing variability of splitting up your data across more packets or changing the timing isn't free. This can come with a cost. And so we discussed some of the downsides to variability around implementation complexity for senders, processing overhead for both senders and receivers, as well as impacts on network efficiency. So overall, both greasing and variability are about finding the right balance of doing enough work to get the benefits of avoiding ossification while not adding too much overhead and too much cost. So that's the scope of this document. Generally, we hope it is useful, and I know there have been cases we've been reached out to about where people are trying to be adding greasing into their protocols and are are using this as a guide. So if you're doing that, if you're interested in that, please give us feedback on how useful this is. We'd like to know, is there anything missing from the advice in here as well as are there more examples of protocols that either do use greasing already or variability or could use it and we could use as more illustrations of these principles? There's also been some discussion that it would be useful to have more discussion about the applicability of various approaches to different layers. A lot of this came from the world of TLS protocols, QUIC like protocols, but they do apply to other protocol layers potentially slightly differently. So if there are protocols that you are particularly interested in that you think should be highlighted as fitting to this model or maybe being exclusions from it, we'd like to hear that as well. And that's it for me.
[00:53:49] Dhruv Dhody: Thank you. First, have Jan Sloth.
[00:53:53] Jánoslav Rosomakho (on behalf of Roman Danyliw): Speaking as individual, I think this is very important work. Thank you very much for doing it. I'm really tired in my day job explaining to people, no, that's not TLS one dot zero. It's TLS one dot three because that, well, you shouldn't be looked at. And, if we would have greasing back then, probably, we didn't end up with this mess. One, I think, really successful example that might worth calling out in this document is ECH greasing. So without that, we probably wouldn't have ECH at all for all sorts of reasons. Yeah. So it's Maybe maybe maybe you want to include that.
[00:54:32] Tommy Pauly: Thank you. Thanks. PHP? PHP?
[00:54:35] Phillip Hallam-Baker: Yeah. It's really important work. One caveat that I think you you need to add in Mhmm. Is what happens when you try and use the points that are being greased and you have applications that are sending in random stuff to grease that point and making sure that you're not foreclosing the use of the extension points. I'm not saying that we've done it today, but potentially, this is a way that you can make it impossible to use extension points.
[00:55:20] Tommy Pauly: Right. So are you talking about, like, if you if people are using them for randomness, that means that those are essentially burned and you can no longer use that
[00:55:29] Phillip Hallam-Baker: Yes.
[00:55:29] Tommy Pauly: Particular value. Yes.
[00:55:30] Phillip Hallam-Baker: Yeah. Like, I think with the I p v four address space where we
[00:55:34] Rohan May: burned a quarter of it
[00:55:35] Phillip Hallam-Baker: for extensibility and couldn't ever use it.
[00:55:39] Tommy Pauly: Right. I I think, yeah, there's some allusion to that in the beginning about how do you reserve them, but I think increasing the warning flags around that and maybe pointing out things like the v four case would be useful because it's full of dragons.
[00:55:54] Phillip Hallam-Baker: Yes. You asked for people to tell you about the dragons? Yes.
[00:55:57] Daniel Kahn Gillmor: I'm talking That's great.
[00:55:58] Dhruv Dhody: Thank you. The dragons. Lucas?
[00:56:08] Tommy Pauly: These are the co authors.
[00:56:11] Lucas Pardew: Sorry. I thought I was further back in the queue. Lucas Pardew. Thanks, Tommy, for presenting this work so clearly. We've been working on it a little while. We're having you and Dave come on as as authors. That's helped a lot. We've been able to kind of make the the spirit of the guidance we're trying to give clearer, I think. And and we don't want it to be like super exhaustive. Like, there's a lot of nuance in the different protocols that we would like to see adopt this approach. I think there's a difference between designing people who are designing a new protocol from like whole cloth to those who are trying to say add extension points that are greasing to something that is already done or is kind of deployed in some environment. So we we do need the input to make sure that the guidance here is broad enough without boiling the ocean on it. It's been great to see various attempts at applying some of this. We had somebody reach out about a protocol I know nothing about and was very illuminating to me in in how they read and maybe there's some more text we can just iterate on. It's not that the text we have is not right, but in terms of the messaging and and communication there. So there's some other examples that have been posted in the chat. I think it would be a good exercise for us to review those too. I'm not committing to reviewing them for all time, but at least in this phase while the kind of the books open on what we're we're trying to communicate. So if people have other examples, I think it would be really great to get in touch with the authors.
[00:57:52] Tommy Pauly: Yes, please.
[00:57:54] Dhruv Dhody: Thanks. Dave?
[00:57:59] Dave Thaler: Yeah. I just wanted to add one thing to Tommy's point, to Lucas's point about adding more protocol examples. At we've had a number of different IAB documents that have examples from many different protocols, including the the documents that Tommy mentioned at the beginning. And, usually, we stop adding examples when a new example wouldn't add some new guidance. Right? And so, gosh, we sure hope that there's plenty of new drafts and stuff coming along that add greasing to it, And the intent is not to enumerate all of them here. It's to enumerate enough of them to make new guidance around each one, to say each category of of greasing is actually covered here. And so what's, anybody else that says, well, we think you should add the following example. What would be really helpful to hear from the community is, and here is the particular type of greasing that's doing that's different enough from the other examples that it's worth providing some guidance. That is super useful. So rather than just saying, here's some drafts or whatever, if you can say, and this is different enough from the other ones that it needs some guidance specific following thing, that's what I think the authors would really love to hear. So, thanks.
[00:59:07] Tommy Pauly: Thank you.
[00:59:08] Dhruv Dhody: Thank you. Very good advice. And thanks for all the authors to keep working on this. And with that, we have the last, item on our agenda, which is the IB Open invited talk. We are glad to have Louise, Biltsing join us from Austrian Chamber of Labor. She will talk about one of the most timely topics that we have been dealing, which is how do we protect minors in the social media itself. Just wanted to put a disclaimer out that this is an invited talk. These are not the thoughts of the IB or the ITF in any way. But we want to have an opportunity when we go to a new location to also hear from folks in the local community on what they are dealing with, how are they interpreting the regulations as they are coming their way. So this is our opportunity to have a good conversation on this timely topic. With that, off to you, Luis.
[01:00:06] Luise Biltsing: Hi. My name is Luis. I'm working at the Austrian Chamber of Labor and Consumer Protection. To explain a little bit, like, the chamber of labor and consumer protection, where's the link, we are a statutory legal representative body of employees, which gives us, like, a great big mandate because we present, well, consumers in in Austria in well, most of the consumers in Austria, I'd say. And as such, we are involved very tightly in legislative processes. So we get to command. We get to suggest changes. And in the last, I'd say, one and a half years on the national level, but it has been, like, since 2018 that the protection of miners has been more and more on the agenda on the European level, now on the national levels. And there are a lot of open questions. We have worries on on how how how the situation will evolve and waiting for the next speech in September to know what what will be announced. So I'm very happy to to have you as an audience because I'm mostly dealing with people working on legislation, with stakeholders, with varied consumers, varied parents, and happy to see, like, different perspectives perhaps on the same questions. So what I have done here now was to have a look at, do I find for for countries already certain ages that have been have been already decided on as a possible limit, as a possible age that could be enough to be to to go to go on social media or not. And and what what you you see here is, like, there is, a fragmented approach. So you you will see that in various countries, it's 13. In in Austria, so far, we are, like, 14. It's it seems to me that we're still, like, unique in this, but you will have 13, 15, 16, a lot of mixed approaches and and all this in in, let's say, in a political societal atmosphere that shows, like this Eurobarometer, a very strong support for all whatever measure will be taken to protect minors better online. And and then you you see that the whole discourse is on minors, but then it's a very different age groups. So sometimes you see children. Is it like children in in in the legal perspective is not a 16 year old? And so we have, like, the the this idea of, like, there is seems to be, a consensus on we need to protect minors. But then on the details, and be it on on the age, but also on the how to protect them or where to protect them or what to protect them from, We have a lot of, fragmented, approaches. And this is the situation that, the European Union now has to deal with because, somehow this contradicts, the idea of one approach to regulate, social media platform. So going back, what was before the bans, the the idea on how to protect minors online on platform, it was with the Digital Services Act, and it's, I think, 2020. Thierry Breton, if if you remember, you you might remember him because he was in the media again and again now, but declared that it's it will be now the end of the Wild West online and everything, you know, that what it will be you know, everything will be solved. So I I remember this speech. It was a kind of a bold statement. And then now you see that, you know, six years later, it seems as if there has been, like, a kind of frustration, collective frustration saying, okay. Doesn't work for the platform regulation. Just keep the children out. So the Digital Services Act had it had, like, a or has a still has, you know, a risk based approach to say, okay. We need, like, an EU wide rule book. We we cannot work with national approaches on this and to regulate risk, but not the content. So fully applicable since February 2024. The focus now or most of the, you know, most of the provisions also within the DSA concern online platforms and very large online platforms. There are now, like, numerous very large online platforms. Very large online platforms are platforms that have, like, more than 45,000,000 monthly average users. You will have heard perhaps yesterday that Alibaba with Aliexpress received, like, the record fine of the DSA. It was a €550,000,000 that they have as a fine if they do not react properly to the satisfaction of the commission, whatever. But it's it's the record fine imposed by the DSA. The DSA imposes gives, like, the option to impose very, very high fines, so up to 6% of the worldwide turnover, which can be huge for this very large online platforms. And you have on the very large online platforms, you have social media platforms, but not only. So you have marketplaces. You have pornographic platforms. You have all kinds of platforms. And one of the very key articles on the protection of minors in the DSA is article 28. And the article 28, basically says that, if a service is accessible by minors, well, they they should have, like, privacy, safety, and security. And when this appeared already, we we knew, you know, that any kind of age assessment will happen. And a lot of this it opens a lot of discussion. What what what are the measures that should be taken by platforms? How how should they know? Should they protect everyone as if they were minors, or should should we find, will there be assessments everywhere? And so the long awaited, guidelines, came to article 28. And guidelines are not legally binding, but they they give an indication on what does the commission understand or considers possible appropriate interpretation of of certain articles. And so for the article 28, it was quite an open question. What what will be within these guidelines? It's and it's interesting to to read them and happy if you if you, you know, to take this piece of paper because age assurance was a very important topic within the article 28 guidelines. So the the guidelines, first, they they explained. So they explained, okay. This is a spectrum. There is not one method. There are a lot of methods explained the difference between age assessment, age verification. But they clearly stated that for content that is meant to be for above above 18 year olds, self declaration is out as a a method to to to say well, to assure that someone is not minor, which was a very important statement because, as I said before, pornographic platforms are like those with the the most self declarations you you you'd see. So it's always, I'm 18. Yes. I'm 18. I'm 18. I'm 18. So this guideline said, okay. Well, the commission doesn't consider this appropriate kind of age assurance. The like, wordings, like restrictions have to be proportionate. They can be complementary. Important sayings here saying that you do not need to have, like, age assessment before, like, the whole service, but it's on the content. So for instance, let's say if you consider your live streaming within a platform to be non non something that contains content that is not suited for minors. You can have only the live streaming being HSS, etcetera. And then there was this any method must be accurate, reliable, robust, but also being nonintrusive, non discriminatory without any kind of explanation what would be robust enough, accurate enough, any kind of measurement. So it's it's really just explained in in a in a very general term. There is robustness. This is robustness. This is accurateness, etcetera. So the guidelines helped a little bit, but not not really. But they are very interesting to to look at because you see you see that you find, like, poor practices, and they they they list, like, good practices and poor practices on what they consider a good and a bad age assessment. And already within the guidelines, they announced that their a u h verification solution will be the benchmark. So we knew they will present something that will serve as a benchmark. So now with all the national, know, all the national partly also very populist movements coming in, deciding seeming like a bit like a frustration of your platform regulation doesn't work from the European Union. We will just make bans on the national level, and we don't really care if it's, like, legally okay or not because you cannot impose fine on the national level if there are fines already on the European level. It was a little bit like, okay. We are just doing it like this. So last September in the State of Union speech, we we heard there will be, like, a special panel. A special panel on child safety will be given, like, the the task of the commission to decide on on the appropriate age, on the appropriate measures based on discussion with experts. And this special panel has had a few sessions, and then we have now a very good date because on the July 13, the special panel presented its report. And it's to to be known that the special panel has, like, two chairs. The two chairs are a well known psychiatrist and a well known psychologist, if I I get it right. So to just to say, it's not it's not the data data protection expert, and it's not it's not it's coming from, you know, the the question of well-being of minus protection is coming from this this point of view. And they have issued now their report. The report is from the chairs with and it's the chairs that have listened to experts, but the chairs have issued their opinion on their analysis on what the commission should take as a measure. So the there are, like, a few interesting points in these reports. The first one was that they have broadened up broadened up the the topic. So it was social media. Now it's social media plus. Social media plus is within the report social media and other relevant digital services such as and then you find examples throughout the report. So app stores, games, online games, also chatbots, AI companions. They they have not really, you know, closed the closed the topic down on social media and on the question, what is social media, but have opened it up to, let's say, the digital, which is not surprising coming you know, seeing from where it's coming, but we have now social media plus. So interestingly for social media plus, what they have said as a as a as a result, and I see very different interpretations online on on have they now said there will be age assessment or not. So some have been celebrating that they have not said that. That's now not how I'm reading it because what they are saying is that, well, no use between zero and two years old. Like, only supervised use between three and 13 years old. And from then on, it's it's like the problem of you you have, like, most risks. You have a high vulnerability, but you have young people that are evolving to an autonomous use of not only, but also digital media. And what they say is not that there is a need for age assessment, but there is a need for age assessment if it's not safe by design. And I I I'm open to to being challenged, but I don't see social media being what kind how social media if users can upload content and users can have live streams, and I don't see how you have a safe by design. I I I see how you have safer by design, but I I don't see safe by design. So I my conclusion would be they're they they are advising for an age limit of 13. And then throughout the report, you you see certain requirements for age assessment. And here it's interesting because they're different to what the commission so far had as their interpretation of article 28 because they say, well, okay, proportionate, upholding fundamental rights, but no ID documents, no biometric data. They mentioned zero knowledge proof. And then it should be accurate, easy, and reliable, robust against circumvention, inclusive, I don't know, nondiscriminatory, and available to all. And one new point that came into the discussion from within the the the report that I find interesting is that they also talk about age assessment being important to prevent cyberblooming, so providers should keep out adults impersonating minors. So based on this on this report, the commission has announced that in September, they will present their solution. Their solution is meant to, well, reconcile all the fragmented approaches there, and it's a very open question how this solution will look like. How much autonomous autonomy will they grant nation nations to decide on appropriate age assessments. I see differences in in in the approaches and in the, you know, also the data protection sensitivity in in in countries, so I don't I don't really know. So what what is an open question is, they will they say will they say, okay, will they give, like, a room for 27 kind of implementations, or will there be, like, one common approach? Will be this beyond social media is something that has not been taken over by the commission even on on talking on the results of the special panel. So it was like the plus went away, and it was like social media. And they have issued recommendations on social media. But within this report, it's very clearly stated that it's not only social media. It's social media plus all other digital services that could be accessed by minors, which is very wide. So here, like, the the question of scope is still there. And what has to be to be known already is that in parallel, there is work on something called the Digital Fairness Act. The Digital Fairness Act is has a very nice name, but it's basically something like an update of consumer law that is planned to be proposed to proposed changes to introduce proposed changes to, for instance, competition law, but not only, could be all kinds of consumer laws in October, November. And one possible thing that could happen and has been discussed already, for instance, would be, could there be, like, an article 28 asking for protection of miners in a very broad sense that is not only restricted to platforms, but that is put up like a horizontal approach, so all services. So this could be an option. We don't know. What we know is that the infrastructure that the commission is proposing is not yet ready. So the the European wallets should be rolled out until end of this year. I don't know for each country. I know at least that for most countries, talk is about will it be finished until end of the year. There is also a lot of talk and worries about will be really implemented in the way that it should be, such as will it be really controlled to the user, or will it be opening up a way that of you have to identify yourself at every at every platform? So a lot of discussions on this. We have also looked at what are like the current age assessment methods on the relevant platforms. We see a lot of different approaches from scan your face and hold your ID to the camera to only scan your face to etcetera to the nonworking but privacy sensitive. Yes. I'm I have this age where you have to correct your age until you have the age you you need to have. We see all kinds of age assessment methods out there, but so far, I'd say most of them are not compliant with with with how they should be. So the I see, like, a lot of implementation challenges. I see even more implementation challenges if this debate shifts from social media to social media plus. And it's it won't be only social media, as I said, because the DSA is has never been only social media regulation. It's social media and other platforms. So for me, like, the discussion, I'm I'm very curious to to see is a little bit like to see do you see same challenges? Do you see other challenges? Do you see I I have the the questions regarding, like, who who gets to be the verifier, how how much yes. So on this, I have written this is like Freud. Does unlikability hold? No. I I meant, like, unlinkability. But this is something that we see in at least legal drafts that on the on the on the paper. Sometimes we see double blind, and we see as requested, we see we see, you know, good intentions or intentions that from from our perspective seem to be, like, the very good intentions. But we are still very done on the implementation. And, also, one question that, that I have, and happy to discuss is we we have seen already in the guidelines that circumvention is not considered something that should be possible. If circumvention is not meant to be possible, this has, like, far wider implications on VPN, for instance. And I'm I'm a little bit, like, thinking, like, curious on on your opinions on is it very important to to somehow be very careful in asking for highly real reliable and non circum you know, like, tools that allow no circumventions. Yes. So thank you.
[01:21:09] Dhruv Dhody: You so much for an excellent talk, and we have the first question from Ted.
[01:21:15] Ted Hardie: Ted Hardy. Actually, Edward Thomas. Because today, I'm speaking as a member of the Defense of the Direitos Digitais from Portugal as opposed to my usual set of affiliations. I want to thank you very much to the AIB for hosting this talk, and I want to thank the speaker both for the diligence in putting together and for managing to get through it without screaming. Because every time I approach this topic, if I can keep it down to a rant, I figure I have done well. The overall situation is we have two or three people who are out, poisoning the well, and instead of actually dealing with the fact that there's poison in the well, the governments are saying, you have to prove to us you're 16 or 13, to come to the poisoned well. And by the way, this affects every other source of water or liquid you might possibly ever consume. I have put into the chat the absolutely well mannered, but strident comments from my colleague Eduardo Santos from d three in response to the Portuguese version of this. And let me just say, if you are in Europe, please pay attention to your local process because they can be so much worse than what you see here. The first effort to do this in Portugal, the actual identity required was the, which is the digital mobile key, which is directly tied to your citizens card and reveals an extraordinary amount of information and, incidentally, made it impossible for any of the 400,000 immigrants living in Portugal to access any of these services. It is it it is so much worse in some of these local implementations than the European standard that we really encourage anybody based in Europe to get involved in your local organization and to look at the local implementation of it, because it it is really, really bad. From the point of view of where do we go from here, I I think my my my general perspective is that this is going to be something that that has to be fought street by street. Even though the the European Union might be eventually persuaded to understand that requiring the the level of of revelation that they're currently contemplating amounts to authoritarianism, some of the organizations within Europe are are basically willing to do that in order to handle, the the public outcry against the the harms which are coming from some of these, poisoned wells. And I think the result of that is extraordinarily dangerous. We have seen authoritarian regimes in in in Europe not that long ago. And in Portugal, the dittadura is within the memory of many living people. And having this be the thin edge of a wedge that leads us down into into that world again is just not protecting our children. It is throwing them into the maw of the beast.
[01:24:19] Luise Biltsing: Mhmm. Yeah. Thanks. I I just to to say something, I'm very worried we we see that I I don't see that there will be, like, a step back. This is a bit what I see. So I I'd see, you know, my optimistic thing would be it's chief that it's only social media, but I'm not optimistic on this either. And it's a very how you say in in Germany, say the train has has has has started or is gone. And it's it's very difficult to argue because a lot of the arguments are on harms, on very small children, on on yes. And we are here in, like, a very tight tight situation.
[01:25:00] János Farkas: Thank
[01:25:01] Dhruv Dhody: you. We have around six minutes, so let's keep the question short or comment short. PHP?
[01:25:08] Phillip Hallam-Baker: Yeah. Philip Palm Baker. One of the problems here is that the companies that have an incentive to engage with government by and large tends to be the proprietors of the poisoned well that Ted was talking about. And the slogan that is heard, Enrangement drives engagement explains how the poisoned well got poisoned. And folk who are selling technological snake oil. If you remember, two years ago, we were talking about automatic scanning of images for CSAM. And that talk has almost entirely disappeared because the government started to look at those solutions and realized they're snake oil. And what I'm seeing now with is that age verification is the same problem. It's very difficult to do age verification. And what I fear as the proprietor of a very, very small social media company, what I see is the proprietors of the poisoned well engaging with government to create a monopoly and lock alternatives out. So when you come to these, you know, dealing with the poisoned well approaches, Please don't shut the door to do things differently. There are different approaches possible, and I'm hoping to be able to show them.
[01:26:38] Dhruv Dhody: Thanks. Vittorio?
[01:26:42] Vittorio Bertola: Thank you. No. I I just wanted to say that I I still see people in this community, I think, that maybe we can go and convince the governments not to do this. And this is not what is going to happen. There is, in Europe, a very strong societal demand for this and all. So this is going to happen anyway. I think that what what we have to choose is whether as a community, as an industry, we want to be cooperative. So cooperating making this the least worst way and finding, I mean, least least better ways of doing this or whether you want to stay out and say, no, you're doing everything. This is where the we don't want to have anything to do with this, and this is just affecting the openness of the Internet. And I I think encourage everyone to think of this question because I think that there are ways to make this better that they are better than others. And especially, I mean, the the question maybe for you is, how do you see the fact that the the this verification stems from the official ID documents, maybe not privacy protected way through zero knowledge proofs and so. Because they I mean, traditionally, there's people that think it's better to keep the governments completely out of this. But maybe the the European way of seeing this is that it's met it's better made by the public than by third party private company that want to sell as they call solutions.
[01:27:50] Dhruv Dhody: Thanks. Tom?
[01:27:58] Tom Newton: Hi. Tom Newton, Corio. I just want to first thank you for your bravery in what really is coming into the lion's den here because the tools are, you know, available to government for this are largely very unpopular with this with this crowd as I'm I'm sure you've seen. And the aggravating thing is many of them have some very, very good points about why those things should be unpopular. I think one of the challenges and something I see in in safeguarding young people is that proving you're over an age doesn't solve a great deal of problems. However, it seems to be a very popular thing to talk about simply because I think everyone could kind of grasp what it is. And and so it's a it's a stick that we see used to used to beat beat tech firms. It's a conversation topic around the place. Have you got something that's your own personal desire to see discussed more that isn't just around age verification? It didn't isn't just around a bar for preventing young people from getting into services? What would what would if you had a magic wand, then you could have one thing. What would it be?
[01:29:09] Luise Biltsing: Well, my I had, like, a very optimistic, naive thought that I thought that perhaps the whole age verification process could lead to platforms being realizing that being compliant with the DSA wouldn't be that bad and to a change in how social media platforms to an end of this culture of noncompliance, as I call it. But I guess well, let's see.
[01:29:40] Dhruv Dhody: Andrew?
[01:29:41] Andrew Campling: Hi. Andrew Campling. Again, thank you for coming. I agree with Vittorio's point. We can either deny this or we can make it better. I think we should try the latter rather than be a denial. I think also we need to recognize that one of the unintended consequences of a lot of the actions of this community around privacy is that governments aren't gonna give up because of the scale of the harms. And some of the measures that we've implemented leave them with a lot less tools to to use and the the harms of those tools or the the side effects of those tools become worse. But that's partly on us for for closing out other options. A final point, I think I hope that we don't lose sight of the fact that all age verification bans does is stop maybe minors from accessing these products. What it doesn't do is to make the product safe. So, yeah, I think we still need the DSA activity to actually fix the underlying problem, you know, take the poison out of the world, to use Ted's term. But as I say, think there's a responsibility on this community of understanding the consequences of some of our actions where we can't then say to governments that they're doing bad things because we've left them with very Yeah. Tool.
[01:31:10] Dhruv Dhody: Thanks thanks, Andrew. We are open to time, so we'll just take very quick. Rohan?
[01:31:14] Rohan May: Hi. Rohan May. Thanks. I I enjoyed your presentation. However, I disagreed with the first slide. Safe, you know, safe, to whom? To no one, really. Right? Poison to everyone? Private? I've I haven't seen any any, social media platform at scale that is indeed private. And free? Well, at what cost? Free at the cost of your attention. So I think we should be thinking about how to how to think about social media as actually as as being the negative of all three of these and not just the protection of minors on social media, but the protection of everyone
[01:32:03] Dhruv Dhody: Yeah. Thanks. From the dangerous social media. DKG, you have the last word.
[01:32:08] Daniel Kahn Gillmor: Thanks. I appreciate the the speaker. This is Daniel Khan Gilmore from the ACLU. So I I there's a lot that's been said that I agree with and appreciate in terms of raising the concerns around this. And I just wanted to flag that even if we do manage the most private and secure age verification process, the second step of all of this is that is is presumably that the platforms need to know what to suppress for minors. And, you know, I don't think we can figure out a non circumventable age verification approach. I think that's actually really challenging. There will be circumventions that happen all the time. But even if you figured it out, understanding what needs to be suppressed is itself a serious political contention. There are people in The US, where I come from, who want to restrict content to minors that I think minors need to have content available. And they probably, you know and I probably think there's some things that would be better to not have kids looking at that they would think would be fine. And so setting these systems up does provide a locus of political control, And we really need to acknowledge that that's a real thing. We can't we you know, it's tempting for us to nerd out about, oh, well, how could you do the age verification in the most private possible way? But we also need to be thinking about the impact that has on our ability to express and communicate for minors and for everyone else who's gonna be subject to these systems, which is everyone.
[01:33:33] Dhruv Dhody: Thank you so much. And sorry for going a few minutes over, but first of all, you so much for coming and speaking to us. Thanks, everyone.