 This is hot off the press, so hot that the paint is still dripping. The reason for that is the IETF leadership is actually meeting right now, and so over lunch, I was getting the updates and updating the slides over lunch as to what would happen this morning, okay? So yeah, that's how hot it is. All right. BPF's documentation standardization process. So we first provide some history as to where we were before I get up to this week here, and so the discussion of standardizing BPF, like the ISA and so on in the IETF, there was two main issues that had been brought up at some point in the past, right? Joel Halpern from Ericsson is one of the IETF trustees, right? The trustees is those who the IETF trust is what owns the intellectual property or the copyright, if you will, on IETF documents, okay? And so the trustees is the one that's their job to look out for what the legal requirements are around IETF standards, okay? So he is one of the IETF trustees, and he personally raised two issues about trying to standardize BPF things in the IETF. One of those was basically that he believed that it was out of scope for IETF, right? Because it's not networking stuff that goes across the wire, right? The second one was that he believed that there were legal issues in bringing BPF work to the IETF because the Linux kernel used GPL, okay? And so that was all prior to IETF 116, IETF 116 was March 25th through 31st. There was a link in the slides, you can get to the proceedings, you know, there's the video, there's the slides and everything else. So if you're interested in what happened in detail, you can go back there. But I'm gonna give you the summary here. So there's a couple of events that happened at IETF. There was a hackathon that a bunch of us were at where we had a table hacking on BPF stuff, including the documents. There were various other groups at the hackathon working on other networking technologies. Several of them were actually using BPF, and one of them we actually had a meeting together between the BPF table and the other table to educate them as to how to best use BPF for their scenario. So that was pretty good. That was pretty good. We then on the Sunday morning, we had a meeting between the IETF leadership and the various BOP proponents, which is a couple of the people in this room, right? Alexi and David and myself were there. We explained the legal state and the IETF's lawyer was like remote on the screen or whatever, where we explained here is what the various licensing around the actual documents and the code and answered questions and so on. And we came away from that saying that the lawyer was confident that there was a way forward. The lawyer provided a statement that the BOP chairs could use in the BOP, and I'll talk about the BOP on the next slide, or at least one of the next couple of slides. So they provided a statement saying, okay, there's going to be some way forward. We'll work it out, don't worry about it type of thing. Don't worry about it for purposes of the BOP, right? BOP being birds of a feather stands for we're gonna try to propose work in the IETF, right? BOP was the formal process, if you're not familiar, to say to propose a working group. So then we had the actual BOP, which was the actual meeting to propose, here's what the charter for doing the work in the IETF would be if it gets approved. That BOP was chaired by two people, one of whom is Suresh Krishnan, who is the past area director over all the internet area working groups, and Lorenzo Collidi, who does the Google Android implementation and could talk about BPF there. So the two of those were the ones who chaired the BOP. Both of them are very familiar with the IETF process, and we're seen as sort of neutral moderators and did a great job, I thought. And so I'll talk about the outcome of that in a minute here. We then had a hack demo, which is the hackathon, anything that gets done in the hackathon, you can have this table or presentation about this cool demo you guys did, or whatever else happened there. And so we did that and we handed out things like these stickers and flyers you saw up here and answered questions about BPF, just advertised stuff in general, so that was great. It's also worth noting the IETF plenary, the entire, big, across the entire IETF, there's like a thousand more people in the room, but whatever, BPF actually got a special mention by the IETF chair. It was used as a positive joke, just highlighting the importance of BPF, not a technical discussion, but hey, any mention is a good mention if it's not negative, so. And then later in the week, we had a side meeting, meaning not an official IETF meeting, but it was there at the IETF venue with all the IETF people in it, where we actually worked on some charter text. So that was what happened during that week of March 25 to 31, busy week. So how did the actual BOF meeting itself go, okay? Well, there was over 100 attendees in person, and it was hybrids, it was more remote, and I didn't count how many people were there remote. Out of those, I think at least half of the BPF String Committee was part of the meeting, as well as a significant number of the actual IETF leadership came to the BOF to weigh in on the topic. And the purpose was to propose we standardized cross-platform BPF specifications, okay? There was presentations, right? Alexi gave a presentation, I gave a presentation, Lorenzo gave a presentation, all great stuff, and then we opened it up for discussion, or I should say the chairs opened it up to it for discussion. The chairs showed that statement from the lawyer that had been prepared on Sunday that said any discussion of legal stuff is out of scope for this BOF. We'd like to have a technical discussion here because the lawyers are gonna work out the legal stuff when the lawyers aren't in the room, and so any legal stuff was out of scope. And so nobody could bring that up. Any of that would happen out of the actual room. And so the rest was on the technical discussion and whether it was actually in scope for the IETF, okay? Which was that other maybe issue that had been brought up before. Oh, and by the way, after the BOF, I ended up talking to Joel and who had also reached out to his lawyer, and apparently he got a similar answer from his lawyer too, so. Everybody went forward during the week under the assumption that the legal stuff would get worked out eventually. And so during the BOF, there was a discussion about, should it be in the IETF, right? Is the IETF the right place for it? Is it in scope? Can it actually work as far as the process goes and so on? And it turned out that there was actually overwhelming support for doing it in the IETF. In fact, out of the hundreds of people, there was a whole bunch of people that came to the mic. Two people, Joel and one other person are against it, and everybody else were strongly in favor of it, including people that are usually detractors and beat up by just about everything, right? They came up and said, let's do this, right? And so it was actually surprisingly positive for those of us that have been in an IETF and lots of these BOFs and stuff. This was almost as positive as you can get in a BOF, and so that was actually really nice to see. So it was overwhelming support. The IETF chair, Lara, has even got up on the mic to talk about how the IETF's mission is to remain relevant as more and more protocols are implemented in sort of dynamic code things, and so if it's not in scope, we need to change the IETF scope to remain relevant was basically as argument, right? That says, and BPF is actually central to that mission, right? And so arguments like this sort of carried the way in terms of the consensus. So when the chair is called for consensus at the end, there was, I would say, strong consensus that it should be done in the IETF, right? Because we said, well, we could go somewhere else or whatever, but no, no, no, the IETF wants it there, we want it there, and so there was very strong support, and so the de facto assumption was gonna be, yes, it would happen, it was just a matter of when and when would the legal stuff get worked out and so on. So that's where we ended the week with that kind of on a positive note. Just step back for a second, what is the actual process that the IETF uses to create working groups, okay? So the decision owner for whether a working group is created is technically a particular sponsoring area director, right? IETF has area directors over different areas, right? So there's two area directors for security and two for routing and two for applications and so on, and so different technologies fall under different areas naturally, and one of the two area directors over that area becomes a sponsoring AD and is the proponent for, yes, I'm going to approve this thing or I'm going to not approve this thing. In this case, Eric Klein is the sponsoring area director and he's the other one that has, that overlaunched, he's reviewed all these slides and approved these slides here, including the stuff that I'm quoting him on later. And so the process for working group creation, it requires a couple of things, right? The area director is supposed to have community consensus that this is the right thing, okay? We actually got that at the BOF, so big check mark. He needs a set of chairs that are willing to do it and IETF precedent or normal approach for chairs is there's at least one senior chair that's familiar with IETF process for years and years and maybe one chair being trained that's familiar with the technology, okay? And so that was done here, Suresh Krishnan being the senior chair IETF expert and David from this community will be the chairs once it's approved and so that all happened during the week in fact, was the recruiting of chairs and discussions among them. So thank you, David. And so we ended the week with that part checked off. Then a charter to vote on because in order to approve something there has to be an official charter it's like the contract between the IETF and the proponents and you do this and we'll actually publish it as a standard kind of thing. So there was a draft that was done prior to IETF and in the side meeting we did some editing on it and I'll show you that in later slides here. And so that's what we'll actually get voted on which is the point five here. In many cases the legal part is irrelevant but in this case it was decided that we needed a legal okay that we needed the lawyer to actually say yeah, I don't see any issues here, right? And so some of the process was stalled based on number four in between IETF and now and then after one through four is done then the area directors actually vote at a formal meeting just minutes it and it requires something like, I didn't look it up here, it's something like two yeses and at most one no, right? And most of the area directors are saying looks fine to me, no objection, I'm not the expert in this area, right? And so that's why two yeses, something like at most one no and we don't think anybody's gonna vote no, right? And in fact they met this week and even Eric doesn't think anybody's gonna vote no, it'll be yeses and no objections, it's the expectation anyway. Okay, so that's the process and we're kind of in the middle of that process. So now we're gonna get to the hot off the press part, you ready for it? Okay, progress on legal. Last night at about 10 o'clock at night the lawyer sent his legal written analysis to Eric, the IETF chair, the IETF executive director and me and since it's AC privileged I can't forward it because that if you know those of you that know AC privileged you're not allowed to do that but I can tell you the impact on us and again this slide has been okayed by both Eric and the lawyer and so everything on this slide I'm confident or perfectly fine to relate to all of us. So basically between Eric, the IETF chair, the executive director and me who are all on the thread between 10 p.m. last night and about half an hour ago all of it everybody's confident that it looks good that there are in fact no legal issues here. I will make one wording tweak to the internet drafts so I took two documents, the ISA and ELF specification and created internet draft versions which are formatting as an IETF input and I had done that before last IETF and I had an acknowledgement section about who was actually authored by, where it was copied from in the Lynx repo and that kind of stuff and he suggested this wording tweak and I said, yeah great, I'm happy to make wording tweaks, right? Pretty trivial. And so I'm gonna make that wording tweak into the acknowledgement section in the draft format and I'll talk about the derivation part on another slide here. So the IETF note well, which I'll show you what that is in a minute here, but that's basically the IETF rules that are on the legal aspects of contributions, okay? And so we actually talked about this at IETF. This is one of the discussions we had in the side meeting and so on. It says, how do we make sure that those contributing document changes in through say the Lynx Kernel Repository patch to contributions are somehow aware of this IETF note well that their text is gonna be used in an IETF document, okay? So the idea that was floated among people that attended IETF was, well actually I'll get to that in a later slide, I think I got summarized there. And so the BSD license is of course okay, but if you read the BSD license it talks about code and software as opposed to document text and so you have to kind of squint a bit but the intent is clear, right? And so the belief is it's perfectly compatible with what the IETF note well shows, which I'll show you later. And so all of this that I'm reporting out here was also discussed like two hours ago at the IETF leadership. They're out there at treat in Seattle right now all in a room sort of like we are, right? And the same stuff was talked about in there this morning, right? And so I then got to update this one that says it has been discussed and they were okay with it, right? So that means all the people that are actually gonna be voters have already seen everything that's basically in these slides, right? And they're okay with it, right? So that's why we expect it'll be yeses and no objections and there's no no's because that would have come up this morning anyway, so. And it would have come up probably in the meeting that a lot of us were in there on the Sunday at IETF and so that's why we're pretty positive that there is in fact already a now a, so that point about go ahead from legal we can now see a big check mark on that point three done that happened today. Okay. Then Eric who's the person who actually gets to make the decision, right? And send out and put out the vote into the IESG gave his thumbs up and here's quotes from him and he helped approve this slide like an hour ago. And he says we've received a thumbs up from council that's what I reported on the previous slide. He said that the proponents, that's us I should review the proposed charter, see next slide to see if it's ready for broader review and some steps that Eric will take and from the trust of our intent to proceed that's basically responding to Joel saying yeah, we're going to do it and not just Joel but he's one of the set of trustees he was just the one that was speaking up so and form the IESG of council's review I think that's what he was doing this morning like an hour ago or two hours ago now and then the goal is to vote on the charter at the next telechat which wasn't in the quote from him the next one is May 25th they meet every other Thursday morning and since they're at the retreat like this week so it won't be tomorrow but it'll be two weeks from tomorrow and for some reason if we want to delay then the next one after that would be June 8th but assuming we're ready then the last check mark that 0.5 on that list here will happen on May 25th if we ask them to delay for some reason then it'll be June 8th but that's up to us not up to them they're happy to do it on the vote on May 25th and at this point it should be a formality so yeah so this is I'm excited to see what else you have fresh off the press but I just want to say that if we probably don't want to delay so we should probably come up with some some policy where essentially if you know you don't say anything by May 24th whatever is in there is going to be what we propose to the area director so if anybody's interested we should send it to BPF at also and you know expose it to the community but I don't think we should assume that like we need official sign off from anybody like what's there is there so just up with that and to be clear the charter proposal so there's the link if you open up the slides and you click on proposed charter you'll get to the stuff that I put on the slides later that I just copy cut and paste it there that proposed charter the only person that can edit that proposed charter is Eric okay anybody else can send Eric suggestions but technically he's authoritative for what goes in there he can just decide and then other people get to vote and either accept or eject that but technically everything else is input to Eric he would do an edit if he agrees with it and then they'll vote on that okay and so by the way he was there in the editing meeting and editing live and so he's very amenable to changes if we want to change stuff he's happy to do stuff so is there sorry I might have to sneeze in a second is there like a way that like what's the workflow like for proposing changes to Eric is there like a PR that you can make in a repo or something or? I think that there is but this probably the fastest way to do it is just post a piece of email to the BPF at itf.org list okay with like the diff and so that's probably the fastest way to do it okay and especially if you're changed at asking for addition of like one line or you know reword this to this or whatever that's the fastest way to do it we should yeah I mean not to be repetitive if you're we should probably send an email to BPF at vigor explaining all of that pointing them at the repo with the thing well I would say we should send an email to BPF at itf.org of which BPF at vigor is a member and so it'll automatically go there right the point is all the discussion on this goes to vigor and wider and so don't send it to vigor send it to BPF at itf so it gets the wider so it gets both the itf proponents and basically itf leadership people who are on that list plus the BPF community okay so I'm going to show you that what that proposed charter says okay so in other words unless we send them feedback this is what's going to be voted on here and keep in mind that we would prefer to not delay it we'd like the vote to be there and so if you have some gosh it would be better if then it's better to just say yes could I live with it is a better way to phrase it could I live with this or is it something that I couldn't live with because if you if you want some tweak or whatever if it's going to be arguing about it we don't want to delay the vote right so if you can live with it then it's good enough okay so there's three slides so that would actually fit here the first one is just background on what IEBPF is the most important part is the parts that I personally bolded on the bottom that is what is the working group going to do it's going to document existing state it's not going to invent new stuff right it's trying to document existing state okay and a process not the technology but a process for extensions let's say you wanted to add a new instruction what is the process for doing that so IEBPF is not going to come and add new instructions or something like that say here's the process for doing so okay and it's going to document what's already out there okay that's what the initial scope is could it do other stuff beyond that in the future yes but right now a scope to document what already exists so yeah yeah just one one comment like that you told us it wasn't a sandbox on Monday and the Trider has the word sandboxed right there so don't know can you live with it feel free to suggest a text change if you think it's not trivia a little bit accepted just make sure it's it's in there by the 24th right universal assembly language doesn't work either because it's not just the the ISA so we'll brainstorm so the point is get some review you don't have to review it during this during this meeting but if you got thoughts right now you want discussion right we could get fast resolution right now if you got something okay so that's point one can I go on to the next one or anybody else want to stare at that longer okay I'm gonna go on okay going once going twice okay point two is what are the specific work items out of the working group okay and the point in the italics on the bottom is my own my own text because that's where I have a comment okay these are the things so I had a list that I presented at previous ones like an LPC and so on I think Alexi had a list that I think was presented at ITF if I remember right and so this is a derivative of that because this is what we edited during that side meeting and here's the current list right and so like the other day somebody asked about would we standardize the API and you can see right there in the middle the platform support API is right there on the list okay so it's the ISA, Verifier Expectations, BTF, ELF, Profile, PSABI, cross-platform app types, cross-platform program types and some architecture that's just how did how the other documents fit together okay Dave do you not want to discuss what the community thinks about whether any of this is in scope here because it might be a good time for folks no the word if you want sure since I'm filling in I think we have time but I guess that's up to Daniel I guess my only point that I would want to make is that I think it would be very difficult to talk about map types without talking about how you could actually create maps and read and write from maps and so that's why I argue that you got to have something that some type of helper functions to do map look up an update and maybe you put that into the same bullet as the cross-platform map types itself or maybe it's a separate bullet that's the only gap I know of in the entire text that's my only comment is somehow feel that or at least have a gentleman's agreement that the interpretation of that is map types and ways to interact with maps right yeah I mean everybody should just think about what they consider like core BPF and what you would or would not want standardized and speak up for the 25th ideally and we've said that this list that this list of bullets is intentionally in order probably by order in which they have to be done because lower ones depend on higher ones and so you start at the top and work your way down okay and so the charter actually will have milestones which are like you know back of the envelope which not held to dates and the expectations these bullets are in chronological order okay not necessarily that you have to finish the first one before going to the second one you have to finish the second one before going on because you could have overlapping dates but the deadline for them is usually in this order approximately that's the expectation and that's what a number of us talked about at the side meeting right not me this is a test this is actually an emergency okay this is actually emergency we have a working group already alright bottom of the text this is the last part of the text okay the working group shall actively engage the BPF foundation and all major users of the BPF that just means work with communities like this one and you know if you have summits and etc to ensure inclusion the ITF consensus driven process and the working group was had intended to only work on cross-platform aspects of BPF that are useful to the wider internet community and not operating or otherwise platform specific okay so if there's something that's going to be inherently Linux specific it doesn't have to be part of the standard that ITF goes into but if you wanted to apply to say you know Linux and Windows both then yes it should go into and be discussed in the ITF or at least be part of the documents that are in there right so you can imagine splitting stuff into a core document and extension document which I kind of already started doing in the upstream into instruction set that RST and Linux notes that RST we already started doing that split for exactly this reason okay suggestion for wording thing for the all major users of eBPF I mean I guess it's fine but I feel like we the BPF community yeah yeah sure I'm not a lawyer okay if you have a specific wording suggestion you'd like post it to the list if you think it's not worth arguing about that it's close enough then don't care yeah just one question on this the cross-platform I think we're trying to express that it's explicitly out of scope to standardize things that are platform or operating system specific but does that also exclude a mechanism to define a platform specific no it doesn't and so that that was exactly what going back here when it says a process for extensions that's partly what that includes process for extensions in say subsequent standards it says okay and here's the extension for networking or for storage or for memory or what I know scheduling you know whatever but there's also the plot of the process for like vendor extensions is it okay for say you know red hat to have a red hat specific extension is it okay for Microsoft to have a windows specific extension so on and whether the answer is yes or no this is the place that gets to say whether the answer is yes you know and if the answer is yes here's the process for doing it to make sure you're not colliding with somebody else's right you can't just take an opcode and just use it because somebody else does the same thing and now you have collisions we don't want that so what's the process you either can't do that or here's the process for doing that that prevents collisions right and so that the working group would be chartered to actually decide the answer that and write it down and then the last part that's not in there right now is that those things that are back here there would be rough dates for and just culture the dates people always overflow the dates and stuff and they update the dates later so at least you need the first set of dates it's in some order whatever but they don't hold you to them but having dates is better than not having dates because at least people have a goal and people can give other people a hard time if they're not keeping the document up to date or whatever so right so that's what's in the charter and so this is what would be voted on or a derivative of this on the 25th okay so this is the call for anybody else that has this please read if you have anything that you need fixed before the vote post it to the list long enough before so they can have so that Eric and update the proposed charter text so that when it goes up for vote on the 25th then hopefully we'll just say yes and we'll have a working group on the 25th. I have like an IETF process question I suppose so like once this is all done and you have the current state I mean VPF is going to keep moving are the documents going to be in the kernel and like will we be expected to keep them up to date or if they're not in the kernel where are they coming from because like funny you should ask I don't really want to have to update an IETF draft just to submit a patch right okay great segue I have a plant in the audience thanks John okay so today the status is the RST files are under documentation slash BPF okay there is a mirror which is currently a manual mirror meaning I sink from one and then I post the other one and under eBPF foundation slash eBPF docs there is an internet draft skeleton meaning the thing that puts it into the IETF boilerplate at the top and there's visual references section at the bottom thing that does the transform okay is sitting in eBPF docs right and so it imports stuff from the from the mirrored portion does the generation and outputs an internet draft formatted version with the appropriate boilerplate and acknowledgments at the bottom that says where it came from and their references section and that kind of stuff right and so I was the one that wrote this tool that's RST to RSTXML that does the automated conversion from RST sorry from RST into this XML format that then used to generate HTML so in internet drafts right XML is the canonical format and because it automatically derives you know HTML and PDF and text all from XML right and so this generate this causes RST to be converted to XML preserving all the different types of markup thing in the appropriate way of doing that so that you get pretty printed you know PDFs and pretty printed HTML pages and stuff as a result okay and then I manually submit the resulting ID snap as a snapshot says on a bigger date right I snapshot whatever the outputted version is there and submit that the ITF okay so that's how that's what happens right now okay and that's what I did before last ITF some discussion is yeah well yes yes I have a question but it's not related to this last I think you wanted to follow up right I'll get to that okay I'll get to it okay but short version is yes to what you said John is yes what you wanted is the case so both now and in the future in the list of domains that will fall into this ITF standardization I saw that I saw elf there for example I don't know what you mean exactly with bindings elf bindings there but I assume that you mean like the BPF a specific elf artifacts like I don't know section time profile yes it's the things that are not in there's the core elf spec okay and there's the way that you use elf in BPF which is like you know what there's such a thing as a dot map section which has yeah so that's what's in that that's what the profile yeah I understand what's the magic numbers that go in the header right yeah but the thing is that as far as I know well you know the elf specification itself itself is sort of part of the CS5 ABI and as far as I know this will be the first elf derivative being a standardized which is not in a PSABI which is part of CS5 now I don't think it makes much sense for BPF to be in the CS5 ABI because clearly it's not a CS5 system and it cannot be but have you considered that I mean because I'm thinking in terms of who is implementing elf like Binutil implement self elf utils implements it I think in the kernel for sure you have like elf dot H right somewhere your own version of it right so as far as I can tell I mean this will be I think the first time that someone out of the CS5 environment will actually extend elf so was it considered yes but not for very long I think there's a problem to clarify so this is not elf extension this is how elf used yes so we don't think that there's any problem with it but by we I mean the different people that were at the IDF discussions so if you do let us know but as Lexi said this is just a use of elf there's no change to elf per se what if you need to add in the future I mean let's say like for example a BPF a specific elf relocation will that fall in the in this IETF effort or not that's what if you require a change to the base elf spec then you got to go to the other committee if you can do it without a change to the other elf spec you're saying here's how you use it then no but that's my assumption though you tell me if you have a different one okay and do you use elf in windows to yeah yeah yep yep absolutely okay so I'm gonna go back and finish answering John's question here okay the discussion that came up is okay so right now the mirror is in the EBPF foundation it is common practice not required but common practice in itf that there's an ITF repository per working group or sorry an ITF organization per working group using the github language right get it you know github.com slash you know ITF working group name that you have repositories for drafts you're not required to do it that way but probably at least half of the working groups do not all them but at least half of them do that okay and so the suggestion is rather than sticking it under EBPF foundation can we just move that repository under the ITF working group okay so that's actually the the proposal there is just move it over there because that doesn't touch the kernel tree right that's just the mirror right you move the mirror over the ITF that's fine right and right now I mentioned that the mirroring process was manual and gosh it would be great to automate that so the automate the mirroring is still a manual snapshot to actually do the draft generation so it's not like every patch set generates a new internet draft no no it's it's every you know milestone like before an ITF meeting or before an intra meeting if there is one that stuff so before some major conference it's relevant right then you snapshot it put it in a draft format I mean yeah we're not standardizing through the EBPF foundation which let's just move it to the ITF repo I don't see any reason not to right right so before there was some proposal that came up but maybe it was at LSFMM BPF a year ago or something said should we standardize it in the EBPF foundation which was an option on the table and we said it's really better if we can use ITF which has a whole distribution mechanism and you know marketing and you know wide broad audience and so on rather than the foundation doing it and the foundation can just deal with marketing and pointing and coordination and things like that so all right so now I mentioned I was gonna come back and tell you what the note well says right so if you're interested right there's the links to it okay now we said it's gonna be most compatible if we don't actually put any code into the docs right but we don't do that now right we put the docs in the docs not the code in the docs right and so this is the actual answer your question John to say in the kernel tree the discussion around the ITF note well which is like how do you tag stuff is having the appropriate legal stuff there the thought was I mean I've got a better idea but the thought among a couple of us that talked about it is we create another sub directory underneath BPF document or documentation BPF like documentation BPF slash you know ITF or something like that right we move anything that gets derived into an ITF document down a level into that directory and then you slap some read me like file in and parallel to it that has the idea of note well in it right so it officially tags which documents are the ones that show up in ITF drafts and which ones that don't is it problematic that the UAPI header files don't have a BSD license at the top of them because if you want to pull the helper the helper content notes right none of them have a document label at the top that's why we relied on I should say the legal review relied on two things it relied on the BPF dash license that file that's actually in there a kernel repository right now that gives the history of the licensing around BPF which was awesome document according to the lawyer that's just what you needed and separately Alexi's clarifications during the meeting in an email right so between those two he had everything needed so the fact that they didn't explicitly label stuff at the top was not a blocker in any sense right the intent and the history document that actually covered all the stuff for the purpose was close enough yeah I was just wondering like for the helpers were you going to try to pull the descriptions that directly from the header files but it looks like they they have an explicit GPL at the top so I was just curious how that works you're asking about the helpers and right now if you go back here that's currently my comment here helpers and on the list now I argue that the least helpers for things like map manipulation need to be on the list right and the ones that are the help the map manipulation ones of things that are not GPL I think right you can verify that but but the point is if they are that we might have to rewrite them right but that's not a big deal yeah I mean like I think the proposals to have a separate entire namespace for whatever is going to be standardized right and I don't we wouldn't be pulling from you API headers correct we want to be copyright infringing anything so we would rewrite it if we had that's the don't allow copying any existing code into such docs so something is explicitly able GPL does not get copied in it could be rewritten if necessary by a different person or something that's fine I just don't know of a case we would actually need to do that if you do then that would be our out there okay we could improve our documentation in general so we don't need to copy copy paste it yeah Daniel is giving me a little time signal but you know I'm I've got another half an hour later on and so I'm not done yet and so I don't know how you want to do that so if you're trying to end early because I think I'm happy to stop now if you want we just move on I like we got to a logical stopping point say and we got to a logical stopping point I saw it here's a logical stop and see that's what I've got left I've got those two slides that's it okay I mean if it's a logical stopping point because now also file system people are here so fair enough this cross track then we can move this to the end because like there's like one session where the presenter didn't show up so we still have some buffer at the end as well I got maybe five minutes left but I'm fine just either skipping the last five minutes because it's you've gotten through the main part you've got everybody's asking what's the status I've told you the status is hot off the press you got that okay that's perfect yeah review the charter all right then we continue at the end thank you so much all right so the ITF note well if you haven't seen it before if you wanted I if you're an ITF you should have seen it lots of times okay but if you haven't seen it before this is it and so anything that is a contribution to the ITF that includes things like post to the BPF at itf.org mailing list and includes things like comments made during official ITF meetings of which the side meeting was not one but the buff was as well as contributions in the form of documents okay I'll fall under note well okay and so note well says you have your basic you know code of conduct type of stuff that's in there but the second bullet is unique and so I just want to highlight that one says if you are aware that any ITF contribution is covered by patents or patent applications that are owned or controlled by you or your sponsor you must disclose that fact or not participate in the discussion okay but that's the one that's kind of in addition to what might be and BSD or whatever which is not an obligation to go and actually look for anything right this is on personal knowledge not on behalf of your corporation that says okay if you propose a change to the to the documentation that gets accepted then you're basically saying that according to your personal knowledge okay you are not aware of any patents okay we hope that there actually aren't any that this isn't a big deal okay but if you ever are aware of one that it just means that you're obligated to say so that's all and may I say that if if a lawyer at your company asks you if a patent is okay and you can still go basically tell them don't tell me about it that's the problem yeah the problem is when your company tells you about patents you have and you have to disclose them yeah yeah and so often legal departments will say don't go and look right for those reasons right because it's a personal knowledge obligation not a corporate obligation okay so it's not like you had a check with your legal department oh do we have any patents no don't do that in fact the legal departments if you have one that have actually looked at this note well they'll usually say don't do that okay just do it as your personal knowledge that's all that's required here keep the process lightweight okay so when we say we wanted to put the note well into the repo that's the main thing that's set that's maybe in addition to what's already there and like the or BSD clause or whatever okay and so when people are saying is this covered by the note well or whatever that's usually what they're talking about is that clause okay we hope the patents are a non-issue that there aren't anything in this space that would be in any documents or whatever but when people get into legal discussions about what's the legal process and stuff that's usually the clause that they're referring to but again don't go and look the ITF does not ask you to go and look and probably your legal department would not want you to go and look either this is are you already aware of something and most of us say as far as we know there's no patents there's nothing patentable here it's open it's been in open for forever so okay so that's what note well is and this is the text and text format that we'd be proposing be copied in a file it's in parallel to the other files in the kernel tree in that ITF directory okay so that's what the proposal is okay separately whenever issues get raised okay different working groups follow different processes this is just my personal input I'm done with all the rest of the stuff so if I didn't get to this one that's fine okay it is common practice but not required that working groups keep track of some sort of issue tracking so that the chair is going to side whether there's open issues that the chair is going to side whether there's a consensus achieved and so on many working groups the chairs choose to use github issue tracker to do so technically the chairs are will be Suresh and david so they get to decide since this is not a technical issue the chairs can just decide okay but they like to decide usually based on suggestions from authors or people that actually track things and so my personal suggestion is if we're going to use the ITF github repo as the mirror right for generating internet draft let's just use that for tracking issues and if we want to do it there then that's fine so if you want to file an issue and just say I've got a complaint this needs to be addressed I don't have a suggestion yet this would be a potential way to track it and the chairs can just decide when they want to close issues do they say that's closed when you merge the patch do we wait until the internet draft gets submitted or when the chairs look at it and say yeah you did the right thing that's up to the chairs to decide okay but the point is the first proposal was to move the mirror over from maybe foundation ITF and the second one is maybe use the issue tracker that github provides on that repository okay not for tracking pull request but for tracking actual issues right you know need to be addressed okay and so with that we expect by you know knock on wood that on May 25th or so unless we ask for a delay based on charter stuff we should have a working group that means that future ITF meetings there will be a BPF meeting slot on the agenda and so the next meetings that are in person but there's also remote attendance possible are those dates San Francisco in July and Prague in November and so would encourage you all registration is currently open for the San Francisco one the early bird rate is there so if you book it between now and a month from now you get a cheaper rate there's still a charge for the remote attendance but it's much smaller if you're going to do remote and that's to cover the cost of like the AV people that are doing that the streaming okay which I appreciate and so there actually is a charge to get a remote attendance but it's no limit there's no cap or anything so would encourage folks to go and register there so you can participate in the ITF meetings and that's the last thing like in between them and I sat down when I stood up here again this is what though we're in the other side basically the Eric and folks asked me to invite you all to do this so this one is even hotter off the press than I got it before so Joe and I guess in terms of what maybe discussed at any of those given meetings I presume that in advance well presumably when we get a slot assuming we get a slot of course lining up there would be an agenda ahead of time so we can be aware and that will be posted on the BPF at ITF yes yes the BPF at ITF dot org mailing list which will then be mirrored to the feature mailing list right because it's member of it and in fact the way that the agenda process works is the chairs meaning Suresh and David gets control what's on the agenda that would be their job as chairs anybody can request an agenda slot so if you want to discuss something then you send their request to them usually on the list itself so it's public information and then they may prioritize them for example they could prioritize them by if you're on this list right here right then you're prioritized over anything that's not on this list and if you're on this list then anything higher up on the list is prioritized over things that are lower on the list that would be a fair level of prioritization and they can assign time slots and speakers and things and so it's basically a request for them sort of like when you submitted your slot proposals for this beating right here so that's very similar that's it any other questions about logistics otherwise again two invitations review the charter text by going to the slide right yeah go ahead yeah when the itf session is over typically people take notes of what happened so you also get recording of the chats of the session itself and also of the minutes of what happened so you can access that later and back way back at the beginning when I talked about itf 116 this proceedings link here take you to what a manual is talking about for itf 116 except I just looked in the recording is there the video is there and all the slides and stuff were there but the minutes have been posted for the PPF buff yet right and so there were actually there's how you can actually get to them if you know where to look because they were live live tracked in like ether pad and so on but not linked into the proceedings page right now and we'd have to like wait for them to create the link or whatever so like said this part is new they just publish the proceedings in a couple of minutes links are lagging so the minutes are there but they're not on that page right there if you want to find them like tomorrow send me mail and I'll give you the link because that you can find it on the agenda page but not on the proceedings page go figure all right that's what I had all right thank you very much hope to see some of you in San Francisco I also just double-checked itf 118 is not overlapping with linus plumbers conference so it's it is not it is not linus plumbers is coming after that so yeah it overlaps the cube gun yeah but linus plumbers yeah people were asking me earlier whether it overlaps I said I gotta check the dates and stuff so thanks for putting November 4th through 10th is not the week of LPC all right so we have 20 minutes is there anything anyone still wants to discuss ad hoc otherwise if not we can close it here and at 4 p.m. there will be like in the lightning talk slot there will be a summary of of all the sessions for from the session leads for everyone to attend if you want to if not then you're free to go as well but yeah that's otherwise it thank you for organizing this to those put this together thank you Daniel for moderating and for a few folks and stuff great job and also Martin I think it was really fun and useful so I love to do it yeah cool yeah thank you then that's it all right if anyone haven't grabbed the stickers for ebpf or the bpf do so now because we'll probably take them back yeah if anybody's heading to another location or place that you could advertise bpf take some and hand them out people like swag we did that at IETF take them to any other venue you're going to be