Internet Engineering Task Force 112, 11 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF112-IABOPEN-20211111-1430

Description

IABOPEN meeting session at IETF112
2021/11/11 1430

https://datatracker.ietf.org/meeting/112/proceedings/

A

You know recorded um to the in the town- that's just west of me.

B

Yes, it was if you need a second career.

B

But actually now we missed the timer right it's time to start.

B

So let's do that.

B

My name is mia clevent, I'm the iab chair and today, russ white is sharing with me, who is also on the ieb, and I think we start right away or russ. Do you want to add something.

B

Yeah, let me show um the note- well uh probably, you have seen this by by now already, even so, this is an ieb meeting. It's still a contribution to the ietf, so you should be aware of the ipr rules and all other participation rules, um especially please notice our code of conduct and the anti-harassment procedures, um which are also uh linked here on the slide.

B

um I don't think we had problems in this meeting, but it's generally important to be friendly to each other to respect each other, to provide constructive feedback to be welcoming newcomers. So in that sense, hopefully we can provide uh some good contributions in this meeting as well. So please keep that in mind also, not only when you speak up, but also everywhere and also in the chat.

B

B

Yeah, so we have always have this like what is ib open, because it's kind of still relatively new, um but it's not that new anymore more. We do it for nearly two years now. um So this is really an organized session by the iav to focus on some technical and architectural topics and discussions and for two purposes. One is to increase the visibility of what the iap is doing, also to have a forum to to to discuss with the community and get feedback from the communities. That's what we're doing here.

B

um I wanted to provide a little bit more information about how to reach the iab. um I usually have this on the slides that you can reach the iab directly with an email to ib ib.org, and what we noticed is that not everybody's aware that not only iab members are listening to this list, so we have some people from staff also on this list and hourly source and these kind of people.

B

um So we put this information now everywhere, where you, you might look for it on the web page and these kind of things, and also want to know people here about this. So everybody's aware, if you, if you have financial information, feel free to send it to me directly, for example, if you want to make sure it only goes to limited set of people, um we have the ib list to reach iab.

B

We also have some other lists. We have the architectures discuss list which is really an open list for community discussion and that's where all the discussion about architectural and technical topics happen and also related to ib documents so feel free to subscribe there and free to post there and start a discussion.

B

We have just made open mailing this for programs where the community can also subscribe and engage in a topic that into the program. You can propose topics that are related to program scope and we have this leonardo coordination coordination mailing. It's not.

C

A mailing list.

B

It's just an alias, basically, um which is relatively new, so this is a direct way if you have any questions about liaisons, to reach somebody or to reach the right person from the iab about that.

B

Okay, um so, um as I said, we're talking about the technical work the iap is doing here, so we will give you a quick update about um documents, workshops, uh programs and so on, and then we have some presentations so updates. We actually have done quite a bit of work. um We have published a new document which is rcm9120, so that was um some work about um cleanups for apple, basically not too exciting. But it's a new document.

B

um We have uh one document which is just out sent out for um no one document which is already approved by ib for publication and will come out as an rfc very soon and we have still one document that is under discussion in the ib, so it's already adopted as an document and we are working on it and you will hopefully see some progress on that soon.

B

We have a brand new workshop report out there, which was submitted just um this week uh on the last workshop that we organized and wes will tell you about that, and we are running a call for community feedback about a new document that we would like to adopt in the iab and start working on. So, that's probably the most important part if you, if you want to provide feedback on this document, um please send it directly to us or go to the architecture, discuss list, that's where most of the discussion is happening.

B

um I just got a note that my audio and video is a little bit shoppy. Is that true for everybody, because then I turn off my videos.

C

Right now we can.

D

It's not horrible, but yeah you're, definitely on the edge.

B

Okay, maybe this is because my partner is sitting in the other room, also having video calls as you have it today. So if you don't hear me, just read the slides right, it's the same, um okay, so program updates. We have an update later on on the edm program, so I will not say much. We have a second technical program running and which is a model t program. uh There was an iab review.

B

There was a little bit of silence recently and there was just a new discussion and started right now to figure out how this group could like get rescued or continue some work. So probably there will be a meeting on september, 2nd that you might want to join. You can also join the mailing list or find further information in the data tracker russ. Do you want to add something about the model t program.

C

No, no, I think that's about right. um We do need to get it moving, because it's interesting work and we just need to like figure out how to push.

B

Yeah so watch out for that meeting and subscribe to the list um and then one more program, which is you know, not the classical iab technical program. uh It's it's a special case here because it works more like working group like a community um program, but you might or might not be aware of this program. It's the ioc future editor development program and this program is working on a new model for the rfc editor and effectively.

B

It has concluded most of its work and there is one document, one draft that is really defining this new model and the working group last call the program last call ended last friday, so there are still a few issues to clear out, but nothing big anymore. The model, as it's described here in the slide kind of steps, and there is still an opportunity to provide more feedback there will be more community calls before we actually publish this. So please look at the document.

B

Not right now read it provide feedback um to the program mailing list um and you can also probably join the next end of our meeting. We had a meeting yesterday and there were not we're still a few open issues, but so we might need another interim, but it's it's nothing big left. So this is really coming to an end. Now.

B

And then um iab workshop, so another part of the technical work we're doing, and so we had a workshop on measuring internet uh internet measuring network quality for end users uh in september, and that was really uh uh quite well visited. We had a huge amount of um contributions and very a lot of people in the workshop I couldn't join, but wes will tell you more about this later and, as I said, the report is just out of first version. The first start version, um but you might be able to already find some information there.

B

That's interesting for you and then we have another workshop that we will organize end of november and that workshop isn't analyzing ietf data. So here the idea really is to look at the data that we provide the metadata provided drafts and in the data check about, for example, authorship participation and so on and figure out. If we can learn something from it, if we can see trends and what we can analyze and effectively, there's a bunch of researchers who are already looking into this.

B

So we thought it's good to have everybody in the room and talk to them and tell them what we would be interested in and see if we can learn something from it and you know how our community looks like and how it involves and how we can improve things in in the process and in the community.

B

So that's coming up uh and uh we will uh push the recordings afterward and I will probably report back at the next ietf meeting and with that um we go properly to the next presentation except so, as I said, there will be a presentation from the edm program and there will be a presentation from the last workshop and I forgot an s here, so the representation, the workshop presentation is not given by we but by width.

B

So you know, if there's no agenda bashing or any questions about what I just showed, we can move on with tommy.

B

But if anybody wants to jump in the queue it's your time now or if you want to add something.

B

So I stopped sharing and tommy is coming up. That's great.

E

All right, that's going to share slides. Thank you.

E

C

E

um I'm tommy pauly one of the leads for the edm program. My co-lead david is not here. He is the one who has the light up suits that go well with the edm theme. um I can only give you this slide. I apologize um anyway. So this is our technical program on evolvability, deployability and maintainability.

E

Everyone is free to join the mailing list. Please do it if you're interested.

E

As a quick status update, we've had two calls since the last ietf meeting and the last iab open one of those was to wrap up on draft ib, use it or lose it, which was uh mainly authored by martin thompson, and then we kind of completed it in the working group that is currently in the rfc editor queue and should be published soon, so really happy that we can get that moved along. I think that's going to be a very useful contribution, so now we're essentially moving on to starting up some new efforts.

E

There's another existing draft that we're looking at. But the thing I want to talk about today is what we had our last meeting on, which was discussing how we track protocol implementations and deployability all right. So why does this matter? Why are we talking about this in an ib program? Why, in this program I mean overall running code is how we determine deployability before we ship our protocols.

E

It's a very important part of our process here and as we're looking at the evolvability of protocols and how well they can be deployed understanding kind of the practical aspects of how our implementation's working helps us get a clearer and more practical view.

E

So tracking the implementations is also a way to help implementations do interop testing. We see a lot of uh success in working groups that are able to do a lot of interop testing and that helps them um validate that their protocol is working and will be deployable on the internet, uh dealing with middle boxes and understanding where ossification has already happened.

E

um Also, you know looking long-term towards the maintenance of protocols, it's important to understand how features have been adopted, which ones are like what extension points are actually working, which ones are successful and understanding how protocols are being used. Helps us get a feedback into that loop.

E

So uh charles eckel uh wrote a quick draft just to spark that conversation and that's what we talked about. The last meeting is the edm find code draft. It summarized some of the current tools that people have to talk about implementation status. um There's an implementation status section of drafts, that's defined that gets removed before publication.

E

So that's one way people can approach this problem and some working groups use it some, don't you have github, repos and wikis to track implementation status and, of course, there's itf hackathon events and associated wikis and those are all very successful.

E

But part of the problem is that this is not necessarily very discoverable and there's a lot of variety, and so we're wondering if there are ways to help uh working groups that want to do this type of thing have a really easy way to start doing this and get their draft authors and implementers involved.

E

So some of the ideas the draft puts forward is that you could have essentially links to your running code or implementation status or interop test matrix that you could get too easily from places like your data tracker or from your working group. Github or even through the metadata, that's associated with drafts and rfcs.

E

So in order to understand what would be useful here, the first thing we've done is send out a survey to all the working group chairs to understand, what's currently being done so here's just a little example of some of the stuff we're asking this was sent out. I think a week and a half for two weeks ago. We've had some responses.

E

If you are here- and you are a working group chair and you have not filled out the survey yet, please look at your email and fill out the survey we'd love to hear from you.

E

So we'll talk about this at our next actual meeting, but just some of the initial stats. When I looked at this earlier this week, you know most of the working groups slightly over half are tracking implementation status in some way.

E

I think we definitely see different trends in different areas of the ietf and the methods are inconsistent, but almost all of the working group chairs said that they would like to have the information about their implementation status, be more discoverable for people who are coming into their working groups, and most of them also express that they would like to be able to track this implementation status in a consistent way after rfc publication, which is something that the current guidance around an implementation status. Section of a draft does not provide.

E

So I think, there's interesting stuff to discuss here and we'll be discussing this more at our next meeting amongst other topics and we'll probably report back to iab open as well. So if there are any questions or thoughts, love to hear them, pete.

D

Am I here? Yes, I am here yay. uh First, first hooray! Yes, this is great. Thank you. This is. This is absolutely brilliant.

D

um I wonder how much the um isg has talked to you about this and whether this could be folded into the moving along the standards track stuff that we've done a lousy job with, for I can't remember how many years um this seems like it would fold in brilliantly and if it became sort of something that working groups just did, it would make that whole question much easier.

E

Yeah, I I think you know the isg is aware of this topic, but we're definitely going to be talking to them more, as especially as we get some feedback here, can you elaborate just a little bit more on how? How are you imagining that could work just so I understand for now.

D

So I I mean ideal world, my my thought would be um you know. All working groups would just sort of do this as a matter of course. It would be the thing you do when you're working on something you put it into the implementation pipeline. At that point, you know we used to have this just horrible time, convincing people to move things along the standards track, which is why we went you know, got rid of draft standard.

D

um This to me just and, and people still are not great about moving things to full standard. If this was just widespread people would, I think, sort of fall into it and say, oh sure, yeah. If we've got all the data to show that we're widely deployed and- and you know, implementations are interoperable, they would just do it and we'd have a lot more stuff, getting a standard, yep, yeah, totally and.

E

D

Yeah and it would also reduce the temptation to stay at proposed standard forever and have the entire internet run on proposed standard, um which kind of sort of reduces the utility of calling things standards in the first place. So this all seems great yeah.

E

Yeah- and you know, certainly I think we can have the view that okay, the yeah the label between proposed standard and standard. You know I've heard it expressed that yeah that's just kind of a vanity label, but exactly it.

F

E

Means something and be related to the fact that we know that this actually is being used could make it more meaningful again yeah. Thank you.

C

E

Yay team cool all right, any other questions or thoughts, and I see that charles has dropped the link to the survey in so anyone who wants to fill that out fill it out all right. Thank you.

B

Tommy uh and then we go to wii: u.

B

Do you want to join us here.

G

You got my name wrong, so you know a little bit of flock.

B

um Do you want to request sharing.

G

Yeah, I'm gonna check.

G

I naturally closed. The viewer rate is the raise again.

B

You can use this um share, preloaded slides button right next to the hint button, and that will just give you the slides from the data tracker, but you have to press it yourself. It's true.

G

We don't see mine.

B

Under your name, you have the joint button and then there's this kind of page thing.

G

B

With the other button, but you can also use that one.

G

All right, you see those.

G

See the slides I assume, okay, uh so I'm going to talk about the ib workshop for measuring network quality for end users, which we just held. We had three chairs for it, a very large program committee and as you'll, see in a minute a large quantity of participation too, which was awesome.

G

uh So a little bit of background. You know the world connectivity has gotten much much better. I think you know the the prevalence of increased bandwidth everywhere has been fantastic. We actually now can do video chats. That was not possible just a few short years ago, but you know everybody still experiences local outages and issues that uh that cause issues as myria.

C

Noted earlier she.

G

Had sort of connectivity issues earlier in this this meeting alone, and certainly we all have those at times- and you know, there's a lot of inner application resource competition too. uh There's there was video discussions. I think in map rg this week about what happens when multiple video streams are trying to compete for for competition and which one wins and examining the differences between different uh platforms. You know they're, not all equal, so the goal was you know what what? How can we identify problem spaces in this area? What what is a good user experience?

G

Users often don't know this themselves, and and if, if users don't know, how can we measure it and then how can we communicate these measurements? uh Can we do it in a standardized way and are there measurements that we can do that users can actually understand, or at least be able to report other than some things were not working?

G

The this is a graph from david reed who attended the the workshop and presented this slide and was one of many fantastic presentations that shows the fcc's longitudinal trend, for you know, load over data cable over over time, and you can see that it's getting better, so there's latency on the left-hand side and latency is just generally decreasing over time, um which is fantastic, that's kind of one of the metrics that we want to see, but still this is from lucas perdue who who had you know when you start thinking about where the problems are right.

G

There's there's a huge number of potential problems, including one of the ones that was discussed a lot during the workshop because it was humorous and because it was a good. um A good example of you know. My mom was microwaving a potato and it caused. You know the wi-fi connection to go bad um and you know you can imagine trying to get those predicted by the average end user as to what exactly is causing the problem. All they know is something's not working. They don't necessarily know why.

G

So we held a workshop on this on september. 14Th to the 16th, we hold it on webex and we had three days and it was four hours a day, and there was an hour set aside. You know, or plus there was an hour afterwards, where people just hung out afterwards and and talked for an additional hours beyond just the the four hours a day. So it was. It was neat that we had some side channel discussions and breakout rooms happen as well.

G

There was 90 different attendees total when I finally looked at the logs and counted them all. When we were taking notes, we noted that there was at least 76 at one particular time, but at least 90 different people participated over the course of of the three days, uh which is a fair amount for a workshop. That's not a that's!

G

That's a fairly large ieb workshop and certainly if we held it in a physical in a physical room that couldn't have happened so there's some benefit to virtual meetings, uh because you can actually certainly take in a lot more people every the way that we had structured. The workshop between the chairs and the program committee is, we had three to four five minute presentations with clarifying questions afterwards and then we allowed for a lot of discussion time and that format seemed to really work. Well, the discussion times were were never blank.

G

There was always you know, people wanting to talk and discuss things, so we aimed for discussion and that worked quite well.

G

We broke the workshop down into details so after reviewing a lot of the short papers that were submitted, we realized that they sort of broke into a number of categories. So we had introduction and background presentations about you know. Where are we today or you know? What's what's the current status and and how does what metrics uh you know are being used today, followed by considerations of what metrics you know?

G

We should actually be thinking about or concentrating on or what's broken with, current ones and things like that and there's a lot of discussion around cross layer. In other words, how do you know multiple things interact and there's there's multiple aspects of of cross layer, which I I think I have a little bit more detail on the later slide, but consider wireless versus wired consider you know multiple layers of of the osi stack and all of these types of things.

G

It's that's one of the things that makes it hard right is you you need to be able to measure stuff. You know not just at one place, because that's not the only place if anybody's ever studied ping or trace route, you know they're very different applications and even traceroute, which has a lot more information.

G

Does not tell you exactly where the problem is on the path and then finally, a synthesis of people that were offering sort of bigger solutions or or more global views was sort of the concluding of the four sections, and then we we did offer a a conclusion discussion at the very last hour which I'll go over next, but uh so the goal was to to go from. You know background through thinking through you know, sort of solutions as the workshop progressed.

G

So we took 30 minutes at the end to allow people, and this was sort of an experiment that I I kind of came up with to allow people to uh just make statements that they thought everybody might agree with right.

G

What were conclusions that kind of came out of all of the discussions over the course of three days uh that people thought were were statements that everybody else would stand up behind and so 24 sentences were written down and we asked clarifying questions about them only as this was going on, and then we took another 30 minutes to you know where people could actually say wait a minute. I disagree with that.

G

One that one's not under consensus after that we actually only eliminated five, is really not achieving consensus consensus out of 24, which um that ratio to me surprised me um as, as we know in the atf we like to debate uh everything right, but so you know a good percentage of them actually came out is generally accepted, and then I later grouped them and documented into the internet draft. So you can go read them. I edited them a bit for context and added more information.

G

Some of them were shorter and you know they were really well understood by people that attended the group more than anything else, so I'm going to go over them in general and I group them into a number of different sections, and I added bold words where I think you know you might find the most interesting. You know points coming around. One of the nice things that kind of came out is there's a number of short term statements that that I think describe the state of of network quality.

G

Today, right bandwidth is necessary, but not alone, sufficient um one of the things that I think has been pushed heavily. I should say the workshop really thought has been pushed heavily in the past decade has been. We just need more speed, more speed, more speed, and that's that's not sufficient, and that's not. You know alone what you need. uh I think gamers know that, well that they need better bandwidth and better latency and game. Gaming was talked about a lot because it's a low latency desired application.

G

So you really need better bandwidth right. You need you know not just more bandwidth, but you need better bandwidth. How can we make it better and in order to really figure out, if that's working, you need both active and passive measurements?

G

You need the ability to do pings and trace routes, and things like that that I just mentioned, but you also need to be able to do passive measurements and how much bandwidth is going by or um you know what sort of applications are using data across the network and and how can I use what I see in order to measure it, but even active and path measurements aren't useful if you can't compare things over time, so you need archivable and queryable metrics as well, so that you can look at trends over time like the graph that I showed previously, you know you need to be able to to see.

G

Are we trending the right direction or, what's getting worse? I think anybody studying academic papers knows that you know. Longitudinal papers are often the most interesting because they really show trends over time, but a meaningful metric for users is. Is this network going to work for me? Will my application the thing that I want to do?

G

Is it going to work, and- and this is where we get down to- how do you measure stuff for end users in a way that they will understand, and you know quite frequently it's does my application work or is my network insufficient? Do I you know, do I have the right sufficient characteristics in a network or not, and one of the other important takeaways is measurements are useless? If you don't actually make change, if you don't incentivize, goodness right so metrics that are measured should be actionable.

G

Can we make decisions based on measurements and are they you know? Are they actionable to the point where we can improve things or make changes to a network in order to to to improve things, and one other thing that came out was you know we in the ietf and and of course, in the ib workshops, the the goal should be to benefit all end users and just segmenting a a solution into something that is just for a small section of the internet is not exactly ideal right.

G

We should come up with technologies that benefit everyone everywhere, there's a bunch of more specific statements and I'm not going to read each one of these. Quite as much as I did the generals, but one metric that was thrown around a lot is round trips per minute. It's a useful and consumable metric. I think, on the server side. That's been used for a long time, but it's also useful on the on the user side as well of of how many transactions can I can.

G

I do or something like that per minute, um but it's you know you need to consider the full communication path from client to server and back- and uh you know how many times can you can you do that cycle? It's not just a one-way trip, for example,.

G

Applications, you know, are really needed that are new, that can report good measurements in order to identify insufficient points in network access. So this is this, is, I think, one of the largest things that we're missing today is. I know that my my network is broken. I know that uh my somebody on the other side has taken a measurement of my video quality and my audio quality, and uh you know and told me that it's not good right and which reminds me. I hope that it's still good, because I could just be talking to myself.

G

I have no way of knowing right. I have no way of actually understanding whether my uh my video and audio is actually getting out. Okay until somebody interrupts me to say no, no you're still good or nonsense, or something like that. Like you get in a room, um and so we you know, we need better um things that can actually identify problem points across the whole. You know network from from one point to another or more likely.

G

You know these days you're actually having network applications that are reaching out to a lot of different places and where is the exact javascript being pulled down to a web page? That's actually breaking that. I can't get to that little piece as opposed to everything else. That actually is loading properly.

G

So we need you know simple metrics and we need metrics per application which uh users are able to consume and report. You know issues about what is working and what is not. um I was noticing when I was looking at the data tracker earlier that that you know I had to click submit, and I didn't get any feedback that that my submit actually went through right. I had no notion of of yes, it is taking a bit. It is loading because it was loading in the background, and so that's to me.

G

I wasn't sure if it was my network, I wasn't sure if it was the server, I wasn't sure if it was the the application. um One of the other things that we talked about a lot is the differences between quality of service versus quality of experience.

G

uh So you know those are thrown around quite a bit, but um uh they're they're they are. They are sort of the quintessential things of how do we measure quality of service? And how do we measure quality of experience when they're not quite equal right? How do we measure what the user is actually doing or experiencing?

G

We also looked at some problem statements and concerns. So some of the the statements that were made during the conclusion section were related to things that we we had issues with latency mean and medians or distractions is one. You know. The interesting thing is, if you I think most people know that if you look at gaussian, curves or all sorts of other, you know metrics for trying to determine.

G

uh You know some statistical average about something that if you just look at the mean in the media and you're missing a whole lot of information right, a mean and a medium can be great, uh but the standard deviation is so large that you know you end up with a lot of brokenness well beyond.

C

The mean and median.

G

For just as an example um and the second bullet, there is actually kind of similar to some some things that we said before. Some of these statements actually did have a lot of overlap, but it's frustrating that you know if you can only measure stuff, but you can't simultaneously improve them right. We should be able to improve them as well and we need to figure out a way to motivate those improvements right. So we need to come up with incentives for public network access that will motivate them and again this is similar to you know.

G

If, if you just measure it, then that's not uh that's not very helpful, and there was some discussion about the ecological impact of you know. One interesting aspect of measuring network quality is not just how well it works, but how well it's damaging the environment or how? How well um everything is. In the long run, we could have great networks that you do lots of bitcoin mining. That's fantastic, but you know is that is that a long-term uh goal? Or will it actually? You know, cause later issues that will eventually erode our networks.

G

For example- um and you know, there's there's not evidence that any single metric is more important than others and one of the hard things that that I don't think that the workshop came to a complete conclusion about is how do you do prioritization across multiple metrics? How do you find the right metric for the right time for the right component of a um of a network right?

G

How do you know there's not anyone that is perfect and some are better than others, and how do you manage to put them all into one situation or one evaluation and get a concrete solution out of it?

G

So, in terms of future work, we want to document the the workshop, um the draft iab and- and that is the uh that acronym is yet horrible, but I figured we're good at horrible acronyms, so I just included, but it's measuring network.

C

G

For end users, because it was too long to fit in the draft name, so I shortened it to an acronym that I don't think had been used until I put it into the draft. It is in the um ieb, uh the internet architecture, github repository people are welcome. To do it. There is the url that takes you to the workshop itself. All of the workshop discussions were actually held in uh on recorded videos, so they're all in youtube and there's links to them as well as all of the papers. From that that link.

G

That's a it was fascinating to listen to it. In fact, I still want to go back and re-watch it all before we finish publishing the entire report um and then there's discussions about where to go next right. So we need to.

C

Bring the work forward.

G

uh There is some tasks that likely can be delegated to existing atf working groups. If there's immediate work to be done- and there was general- you know interest in- where do we take longer term stuff, and I think that the the takeout is really. We should take research tests to the irtf. uh There was a little bit of discussion of do. We need an ieb program for this. um I think the general consideration is.

G

This is probably not program worthy at this point, but um we have enough breakdown between iutf working groups and irtf research groups that were were probably okay, so that is it for slides. I think I took it almost exactly ten minutes. Is there any questions or discussion on this.

G

Is there any discussions for the microphone.

B

Yeah, maybe people want to bring it to the microphone somewhat yeah.

G

I will say you know, there's so much information in that workshop. It was hard to um there's no way to summarize it all, and there was it was a very dense working workshop, uh which was fantastic to participate in, but I was you know looking at writing the draft going. I don't even know how to summarize all that, so.

B

Yeah, I think the the discussion in the chat is is actually a little bit about metrics and there's also a draft in iqp, I'm talking about random times per minute as a different metric to use. For example, um I guess there was also a lot of discussion at the workshop about metrics right.

G

Yeah I mean to throw out the ippm. Our working group is the most likely place for for follow-on work to go, but trying to be generic and not pigeonhole it exactly there.

G

G

In that case, I will turn it back to you guys. I think.

B

Yeah I mean people can still join the queue if they want to have more discussion, because that's why we're here um we don't have any other agenda item. We have the usual mic spot, so people can also just join the queue for any other questions they have to the iep if they want to.

B

And maybe to um I mean we, we have the technical plenary which was already um last week and usually in the not in the technical. So we had the administration then already last week already so usually we try to concentrate on more of the administrative questions at that plenary. um So this this open mic is really more for technical questions um based on any kind of workshop, any kind of documents working on workshops or programs or even if you want to raise a topic that you think the ib should be aware of. That's your chance.

B

And we have martin.

H

I just want to say what I said in the chat which put in a plug for ippm next session, which is going to have a a draft about rpm.

B

Okay, I mean, if there, if there's nobody who wants to speak up, has any questions or any comments. We can actually close the session here, but I'm feeling a little bit bad if I would close the session now, while they're still discussing going in the chat.

B

um So I give you a few more minutes to take the chance and speak up in the mic.

B

I

Yeah I had a quick question for uh actually for tommy on the survey. Is there a deadline, or perhaps we should set a deadline for when responses are requested there? So people know if that's something they need to kind of quickly do this week or I think we'll get more responses if we put a deadline, everyone's deadline, training.

E

I

E

Gotten a fair amount of responses. um I've been pretty happy with that. So far, I'm hoping that you know this reminder and maybe I'll send a ping to the list uh today. Just to tell people hey here's the link again go fill it out, but I I imagine after just kind of naturally after like a week or so anyone who's going to respond will respond. um Something.

H

E

It's a deadline, but yeah, probably you know by you, know, certainly by december I'll, just say: okay, here's the results and we'll go look at it as a program.

I

Okay and then uh you know one other thing I put in the chat just kind of more of a comment. Is uh you know my personal interest with the fine code draft is also a bit broader than implementation uh status and funding yeah. The interoperability aspect, which is super important and I think, a goal as well, but I'm also very interested in just any.

C

I

Related to it, like some of the code that we've done in the hackathon and it kind of helps you with understanding a protocol or maybe implementing it or or viewing traffic on network, or you know any kind of test tools. Those types of things too are super helpful. Just to get people help people to um to implement some of the standards that we're specifying in these drafts. So I'd be interested in that as well.

I

E

B

And we have spent any queue.

A

um I I wanted to thank the uh the ieb for doing the uh public, viewing of it uh of ib meetings uh and for one specific reason, uh which was um the iab, has been doing: uh reviews of research groups uh on an ongoing basis for as long as I as long as I have known about, and they have not tended to be very public.

A

I had the opportunity to watch not participate in, but watch the pen rg review that the iab did fairly recently and having that be benefited and viewable, as you know, as it was happening, and things like that was super uh useful for me and I hope other research group participants will take advantage of that when the iab is uh reviewing reviewing their research groups.

A

Thank you all for doing that.

B

Thank you for the feedback, so um yeah you're, right that these reviews haven't been that much public, because usually we used to do them during the meeting week um in one of our breakfast meetings and those are not as public as our calls usually are and given the circumstances we now have integrated them into our frequent calls. So we can scan them anytime and those calls are actually open for observers. So you can join any any ib call and listening.

B

Rust, if you want to editing- or are you just here to say goodbye.

C

No, I think, I'm good. I would encourage people to join the ib that the calls that they can join other than executive sessions as an observer. We have a lot of good technical stuff going on right now and we actually have a lot of drafts and stuff. We could use help with.

B

Yeah I mean check out the iv webpage and try to find the agenda there. It's there's actually a direct link on the front page on the on the right side, um and you can see that we not only have those boring iab calls where we talk about administrative matters. We now have actually calls that we label as technical discussions, where we only discuss one technical topic, so this could be interesting for you as well, um if you want to check out, but also, as you just said, documents I just want to remind people.

B

Please review um the past english document which, where we have the call for feedback um out there right now and and check out the other work we are doing in the programs, and now we have more people in the queue. So robin is next.

B

Robin we, I think we heard you already if you say something.

F

Okay, uh in fact, I my this, the my some this, the one who has some of these comments on this is the drought. That's the past signal yeah, because you know that's the this time. We have this the the epm work and we propose that's the solution that uh incu, including the data plane, encapsulation and also this is the uh control plane, and this is the young model for this work.

F

So this will be helpful to understand this one yeah, but you know that's the from my point of view, so you'll notice, there's also also there's the discussion about the open internet and the limited domain, and, according to our this, the discussion about this, the apm work. So we can feel this, so we can feel this that possible difference.

F

Even for this, the past signal, and also the eating work seems uh similar. That's the application and the networking. That's this integration, but you know that's for the for the apm worker, that is the limited domain, so you can use only use available. This is the package header information to map to some of this, the uh api id. But you know that's if this is a pass signal, so this is maybe that means this. The signal information can be directly derived at the host and the application.

F

That is maybe more specific, because it's very clear about what's the user and what's the application so from my point of view, so that when for this, the for this drop from my point of view, you to you should be thinking about the possible difference between the open internet and the limited domain.

B

So um if you remember, I think, at the last iab open meeting, we actually had a presentation about this draft and we had a bit of discussion there and got a lot of input. That was really good and I think a similar comment was made um so the last revision of this draft. We actually updated it to add a little bit more text about this um you. You should probably just read it yourself, but um I think the considerations I personally think and I'm an author of that draft.

B

um I think the considerations are not that different for limited domains. You need security, also limited domains you have to protect um about. You know unknown attackers that attack your network, so I don't think, there's a huge difference um and that's what we're mentioning in the draft, but I mean please have a look and provide more feedback um and start a discussion on the architecture discuss mailing list. I think.

F

B

Thank you, wes.

G

Thanks, I just wanted to follow on a little bit about uh russ's. Great comment of the iab meetings are all open, except for executive session, and that's the part that I wanted to talk to talk about.

G

We have almost nothing in executive session and I know I talked to somebody a year or two ago that thought you know we always go straight into executive session, and that is that is we spent like maybe five minutes, and it's only when we're looking at background information for people we're going to appoint or comments that you know when we collect public feedback that is about it. uh We're we've actually had almost no executive sessions for the past three years that I've been on the.

B

Interview yeah, I can assure you that if you, if you're missing the executive station, you're only missing the boring stuff, so no worries there spencer again.

A

I don't think you're supposed to say that in front of the uh iab members and potential iab uh nominees, but but but it is true, um the uh the question I was going to ask is probably uh for something that russ was uh mentioning about uh having documents that the ib would like to have help on, and I I'm a little curious about uh two things. One is kind of uh how we would know that uh and number two is: is there a? Is there an obvious time for us to try to be helpful?

A

You know, like often the often the notices I will see are for ib call for comments on adoption, or something like that. I mean, but I'm up a little vague on how we, how the people could who could help would know that they should be helping and should be helping. Now.

B

And maybe so I mean, I think your question is really good, but maybe I also want to preamble this. So when we publish the document on the ib stream, it's also kind of an opinion piece from the iab right. So we're looking for a lot of input, because the iab has some smart people, but we don't know everything and- and we don't want to miss important stuff right, but at some point it's it's also. um You know what the ib thinks is the right advice to the community russ. You wanted to say something.

C

Yeah, I was just going to say yeah and you know if you attended some of the technical sessions. You'd see some of the stuff we were working on and maybe get involved a bit sooner than when it's published, and I don't really know of another good way of um or just look at the meeting minutes from the old meeting minutes and look at some of the stuff we're working on. You don't have to attend the meeting necessarily just say: oh yeah, I see the ib talked about blah blah blah.

C

They might be doing a document there. Let me go find out.

B

So, um just from the process point of view, for a couple of years already, we have two steps where we actually reach out to the explicitly we reach out to the community. One is before we adopt a document as an ib document. That's what what the passing document is right now.

B

So this is an early stage, and this is a really good point to provide a lot of input because that's where we can still scope and change the document and the other one is very, very late just because before we um start want to publish the document. So that's the point where the document is basically done and if you have a severe concern, we might still consider it, but we're not planning to change the document.

B

But we do have these two points in the in the process where you can easily engage and between those two points or even before that first point we try to actually bring it to this meeting here because that's where we have discussion time with the community.

A

Thank you all have a great itf.

F

uh Robin, in fact, you know I'm not sure that if you have this talk to the community uh about the point or not, in fact, I think that's the ib meeting that is open and now that's the uh every month, the uh the fourth week we will have a dedicated meeting for the technical discussion.

F

We wish that the community members can bring that's an interesting topic to the ib so that we can help to schedule this wow. We can have some the discussion in the ib. This is the meeting open meeting. So that's that's my suggestion. Okay,.

B

Yeah, definitely if you, if you have topics and that's another purpose of this meeting, if you have topic that you think the iab should consider, please bring it to us.

B

So and now I think we actually reached the end of the queue and we can just stop a few minutes early here. I don't think anybody would be too sorry about that. um So in that thanks, thank you. Everybody for the meeting. If you have any further questions, please reach out to the ib reach out to me, reach out to us or everybody else in the iab and see you next time.

B