Internet Engineering Task Force 105, 22 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-TAPS-20190722-1330

Description

TAPS meeting session at IETF105
2019/07/22 1330

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

A

Keep fussing with this, maybe why you beat or.

B

A

The fresh batteries.

C

A

Thank you. Are we be at time? Oh yeah, we're time yeah.

A

Okay, we're having a little problem with the remote clicker here, so why don't we? What if you've got one that just plugs in sure I mean I, can do the chair sides from here, but I think it's easier for other folks to be able to advanced on slides?

A

Oh, yes, I did test it and it worked I'm, not sure I trust it. Okay, let's try. Oh.

A

That's interesting: the ears works. Well, if this looks like an Apple thingy, it's just excited it. It looks like a trademark infringement.

A

Okay, let's, let's get started I think the agenda is a well even though we have had short agendas in this meeting so far, I don't think. We've ever actually ended early, so I'm, assuming that we're going to be pressed for time by the time we get to 3:30, so blue sheets are going around. This is the transport services working group. If you don't know what transport services or taps are, then you stay and watch and learn.

A

Teresa is going to jabber scribe for us. That's helpful for the for the minute taker to get your name. So if she's, looking at you, funnily, it's probably she's trying to reach your badge, we have a minute taker in the back. I see you.

A

Okay, so we need a minute taker, so Sarah banks and her son we're going to tag team, doing the minutes as a kind of a learning exercise, but it looks like Sarah's been delayed, so could somebody get started in the ether pad and then, when Sarah gets here, I have I'm using Mary's clicker?

A

Why don't you take leave that one you take this one and I'll try it at the end of the session. You will be no worse off than we are now. If it doesn't work, oh yeah! Well, you should take those with the old one you're giving me that and you're taking. Oh.

B

You just have matters no okay. Well, okay, I'll! Try the battery there we go. Thank you all.

A

Right preciate.

D

A

Okay, so a minute taker, somebody please well. What we really need is for somebody to capture the action items right. You don't need to record everything that said. Thank you. Cory.

E

Cory first we'll take notes because he hasn't worked on the drafts this time.

A

Okay, as your as your penance awesome, all right, so no well anything that is said in this room is considered an IDF contribution. If you don't know what that is, you should meet some of that stuff.

A

Yes, today's agenda, you may not be surprised if this agenda looks familiar, because this is almost exactly the agenda from the interim meeting which, where we made some progress on the issues, but there are still some open-open elements, and so today we're going to try to push some of those along, so young published in the RFC since, before the min set draft is sitting the RC editor q.

A

It's got a Miss Ref, it's waiting for the security document to be submitted and then they'll be published together, we did complete a working group last call for the survey of transport security protocols. So thanks for the folks who read and commented on that for the document to proceed, it needs a shepherd. A shepherd is ideally, somebody is not an author, but is willing to be a intermediary. I, think I, see a volunteer. I haven't even told you what you're going to be doing, but Philip. Thank you.

A

Consider yourself signed up for those of you who don't know what a shepherd is. A shepherd is a person who makes sure that the authors respond to feedback that comes in the review cycle. The ietf has called the area, directors, reviews and and tries to make sure that the right discussion happens, so the document progresses. So thank you very much Philip. So that means that is my area director here, Agnes, so Magnus. You should expect this within the next day or so once I can fill this form yeah.

A

We had an interim many of you were there virtually. It was a virtual into him interim and we talked about framing. What is it the implementation draft, which continues to evolve and mature as we learn more and then about how how default parameters are represented? You know, should applications be able to ask for things without giving the parameters and have something happen.

A

The yang model, which we talked about here a couple of times, was discussed and people continue to think it's a good idea and then there's a bunch of open issues with the architecture in the API draft.

A

So our schedule- it's unchanged since the last ITF, so the goal here is to submit the architecture, implementation and API drafts for publication by November I suspect that the implementation draft won't be done, but it sure would be nice if we could all agree that the architecture in the API drafts have done. I, don't know four there. But if those of you during the conversation today be interesting to hear people's input on that, just so that we can kind of set expectations.

A

That either the computers frozen or that's my last slide so I think we should move on. The computer appears not to be frozen. Okay,.

F

Hello, all right, hi, I'm, Tommy, poly and I'm gonna give a quick update on the state of framers and we have renamed them in the document to message framers. So we can put all of our messages and frames all right.

F

Do you can you make it fullscreen? Is it okay, other clickers, no breaking them tiny or no? It's okay!.

A

Snap fullscreen ooh, that's interesting! Why.

C

G

A

Clicking for a moment we're going to try to get it into it. That looks right, okay, see if it works.

H

So you want the.

A

Up arrow all right: well, that's ask Marian. How about you just tell me. I will just tell you great all.

F

Right so as a status update, we did have a pull request to rewrite how we do framers, and this was based on our discussion that we had last time and I f-104 as well as in the interim. So we did merge that in there were still some open questions or thoughts that people had. So we said we kind of come back to those potentially revise the text in accordance with that, once we've landed it so I want to cover those today and then I also want to share that.

F

We did release a version of the framing API in our network framework within Appl systems for swift and c, and so we have that in our iOS and Mac OS beta currently. So this is a way to implement framers and you can play with it. You can test it out and see how it feels to hold. You can see also how some of the practicalities of like putting this into a concrete language turnout.

F

Okay, so I want to first cover, essentially what the API surface looks like currently for framing based on this latest PR. So if you are an application- and you have your connection and you would like to add some sort of message framing into it, so let's say you have a TLV format over a TCP stream. You can create a message.

F

Framer object like this new message, framer and that's the thing that you can register all your events on to handle framing and D framing data, and then you can add this framer on to your pre connection. Now the way the text currently describes it is that you add them on and each one you add kind of goes on to the stack closer to the application.

F

So you could add a lower level one and then maybe hand your connection to someone else and they could add on more framers I'm. One of the issues that was raised I think my max was it wasn't super clear what happens to the order of all the events when you have multiple framers going on, so we will want to clarify that the intention I have here is you essentially will get any start events to start framing from the bottom from the transport up in that order? I have a question.

I

Do you ever any model famous, because you could also just like create one frame of it? It's even more complex, and especially you.

F

Certainly could I think the reason to have multiple is for more code. Reuse. Let's say you have like a basic like let's say, I'm doing something for a DNS framing that can work over TCP and UDP. I could have one that just does like the length value framing over TCP and then one that strips out some of the and does more interpretation that can work over both TCP and UDP, and so I would want to compose them separately.

I

F

Could certainly do it that way, but since the it's not necessarily the taps implementers, but it's more like third-party apps or third-party libraries that would want to be implementing framers II. You should at least define what is possible for them to do.

F

But that's a good point so once you've added your frame where you can add specific things that you want to communicate to your frame or when you're sending and receiving so there's a message, context that we already have as part of our send and receive calls, and so right now it specifies that you can add kind of special values specific to your frame or onto that send to receive to say you know when you're, sending your header and the specific value.

F

So if you had an HTTP framer, you could put your header values in there, so they could lay it out.

F

Similarly, when you are receiving, you are able to look at the message context and see the properties of how it was D framed. So there is a open issue kind of around this I'll get to in a second.

F

Then there are some events around kind of the frame where lifetime of saying hey, this misses. Framer is now actually active on a connection. The connection got far enough in setting up the transport that you are ready to start framing, or the connection has closed. You should stop framing now. This just allows you to prepare and cleanup.

F

Similarly, when you are, if you are writing a framer, you can send it events to say: okay, I'm ready for more application data. The connection is now ready for my perspective or you can say, I hit some error. There's some invalid message that came in just fail. This connection.

F

One of the points brought up in the issue is that sometimes you need to be able to close a connection without having an error on it. So I'm one way to solve this is to just rename fail connection to like close connection, you can have an optional error, have two different methods to do that.

I

So why do you need actually to add your framer to the pre connection.

F

So you, what's the other option that you're thinking of at it just a connection.

I

F

At least the way we have things right now you get your connection. The moment you call initiate, um and so, if that action of initiate is asynchronous, you know you mean the connection could become fully ready before you've added your framer, which is okay.

F

If you haven't sent a received anything, but if you let's say you had already started receiving bites or you had already started, sending somehow then you're adding your frame, we're at an unknown point in the stream of data, and you don't know if it's actually valid to start parsing, where you are it's just a little bit less safe.

I

F

Right because it may need to send a prefix before it begins, framing saying like this is the type of framing I'm doing to the other side. So that's why it's currently in the pre connection, I think if we wanted it to not be in the pre connection, you'd need to split out the create connection from the initiate.

I

This kind of preheat phase, where you think your framer and then activated data right, you don't really need it. I guess well,.

F

There's an so this is not, which are you talking about the start, color the make it ready. No, let's start this is the start. Event can generally be ignored. It's mainly if you need to send some like prefix to do like a little extra thing before you begin framing messages, it's your opportunity to do that or allocate memory or whatever you need to do it's. You should be very simple or short yeah.

C

J

C

And so these I'm a slightly pleaser, then it's given to the framer, not something you have to.

C

F

So, yes, if you are yes, these are for people who build the code that is framing and D framing it's not for the application. Sending/Receiving t.

C

The model I I heard of this was the framers would be implicit based on the Transperth premises. Add them explicitly seem seems like the reasonable thing.

C

C

C

F

And so this PR didn't go as far as to do that. But I agree that that should be done implicitly for a lot of protocols that are framed.

K

L

As the framer currently has to be added to the pre connection, ah can we use it still to influence things like starchiness at the moment? Yes,.

F

So I don't think I have it on these slides. There is a method for a framer or a protocol to prepend another protocol or framer. On top of it, I think it's called prepend framework, and so what you do is you would do your start TLS and then you would add, on this other frame. Around top.

L

First reconnection, but this thing.

F

Yes, right, and essentially this all has to happen before the connection becomes fully ready, because otherwise you don't know whether or not the application has sent and received data and you're in some weird intermediate state between boundaries.

A

So I think I'm asking a variant of this topic. Yes, do you still believe that if I am using taps with a Kramer on one.

M

Half of the connection.

A

K

M

K

A

That I think I only need to do it on one side, but it'll still work fine end to end that there's no additional semantics in here right, yeah.

G

A

Knowledge that the application can convey it to the stack and either on the sender, the receivers mm-hm.

F

So you could have a taps or non tap some alimentation just doing a TCP stream on one end, that does its own HTTP, oh yeah, and another side that does a framer with HTTP. But nobody.

A

You start stacking yeah.

F

Things are listening.

A

F

It's still the same on the wire and protocol. This is about how we signal to the application.

A

There's nothing on the wire.

F

A

N

You want to be up.

E

Signal we go, that's it that is, it I. Think cently.

A

It's an EMT requirement for taps right. We can't we can't require and both ends right.

F

All right so then, on the data path um we have, you can get in there's a new sent message that the application is trying to send. You can look at that and you can send your own data to frame it and when you're receiving you say if there is new, receive data on this connection, and then you can parse it. You can say alright I'm done looking at this, and you can deliver data up. That's kind of the basics that you need to do.

F

I, don't include all of the parameters here, but they are in the document. So some of the questions that came up in the course of the PR. These are just kind of like side things that you want to get our opinions on. One I think my phone got up of like I had originally been discussing. These framers as like protocols in the stack I have backed off. Of that mainly questions like. Are they should we be calling them? Currently, we don't I think that's fine.

F

There was also a question about like how much are we referring to things as objects? I kept it as objects lab, because most of the API document really does refer to objects and stuff like that. It does raise a broader question of. Is this the way that we want to be referring to kind of the operational functions that we have within the document? I think it's clean, but if people are allergic to that, that's fine.

O

So where are you.

F

Pre connection equals parameters for us. Okay,.

O

I mean because we're favored the object that is a framer is corresponds to a single connection. I mean you might have a constructor or factory to these things, but there's a single instance of this per connection. Yes, so where has your object right.

F

So that's an interesting question, so this has probably brought up in some of the discussion on the PR. The way that the current PR describes. It is that you have a message frame or object that you create to represent kind of the abstract of your framer and all of the functions here. Take the connection, that's specific. So essentially, when you get a start, it means this instance of the framer curves, corresponding to that connection is being created in the way that we did it in network framework.

F

We actually have it be that you define your own class that conforms to a protocol and we instantiate your object new for every connection. They boil down to the same thing, but they do look semantically a little different.

B

P

Isn't about the questions? What a framework is already? They are protocols, I think they are one possible way to implement parts of protocols, not the only way to implement them, but I think I find them really useful. When I explain them to people I usually say they are as sort of a set of functions that can transform a message into a byte stream or vice versa, and then maybe do other things on top. So in a de traffic right now says it's a piece of piece of code, I think that's to implementation of functioning.

F

P

Even simple transformations between message, data and draw transport by transport, bytes I, wonder what simple transformation is right, so maybe we should specify this also. Doesn't the frame on that you're specifying does a lot of buffer management, and maybe we can separate the functionality for the transformation from the actual a for management right. So maybe we have like multiple things that the frame others. Maybe we want to separate them, or also? Maybe we don't want to be so specific in the API- try to standardize what no the frame was implemented right if.

F

You could open issue for what you're discussing that'd be great, so.

A

Before we launch into this discussion, I just want to point out that we're at the end a time for this slide. So if this- but this is I- think you know- we've been wrestling the framers for a while, and so it's worth talking about this did you have a lot more in your door.

F

So the only other thing in this- this is just for reference. If you look at the slide, deck I have a link to some of our sample code for what a framers look like in Swift and I include some of it here, so you can just see how it looks. We don't need to go through that now, it's too hard to read it's a reference for you. Okay,.

A

So let's have some discussion.

D

So Eric's near apple, just to what Reese was saying, I think I, like that view of the problem in the a framer at its most basic, is kind of serializing and deserializing, a byte stream into something that's messages. And then, if you want to go further with that and have it do something semantically, with those messages like maybe a framer, would do a handshake for you at the beginning of some protocol, like that's kind of up to you.

D

If you want to define that, but you also have the thing that the client application could read out that to the needed message and do the logic for engine, but I think that's the next way to communicate it to people, because it's pretty easy to grasp like I've got this logical message. I would like it to be a live stream and from.

G

There, the rest of it.

D

Kind of falls out, it's.

L

Good, so towards the second question: I have a hard time understanding the PR at the first place for me much easier when I've sort of the framer object as a frame of buffer manager and then having different object, communicating with the buffer manager. But this brings me to the question whether the actual API, but it's exposed at the moment, is too much focused on the buffer management and a little bit less focused on how to compose multiple framers and how to really spec these concepts or how to build out these concepts.

L

This is this is my problem with this API, so by the way, I like what I've seen flickering smooth ER from there and the connections fragment, unlike this much better than you.

F

Like, which was better.

L

Connections was found having a protocol class that implements the framer itself. Okay,.

F

But that's good! That was a little bit more. What my initial PR was trying to get at, so just to clarify what you mean.

F

So the data path does, you know, involve some buffer management and to be clear, the part that the taps and lunation needs to provide is the ability to you know, interact with the data path, so there will be this buffer management, so I mean do we agree that these kind of functions just like sending and receiving will exist kind of in this form, I'll.

L

Show you whether they really have to exist in this form, if you're going for a much more actual language earth. Think about that you might want to push trainers, for example, down into a haka offloading or something like the little supplementation which have something framing like that's implemented, EPP F! If you want to enable this kind of stuff, the buffer management might look quite differently, then that's the reason why I have a little bit of a problem that I think it's a nice way.

L

It's one nice way of implementing the finger, but I'm not sure whether it's the only.

F

Way of implementing.

L

F

I see right until to to that end we had define is this is a way to do it? You must have at least these capabilities if you want to express it differently in your implementation. That is fine.

F

Partially gets down to the reusability of code, though like if you know, we would ideally want someone who wrote a basic implementation of how to do HTTP framing on top of something to be able to be somewhat portable and so having something that is. Common is useful in that regard.

L

Okay, this is the way how you add, friend, to a connection or through a free connection and then have okay. This is how you implement the framer, and if you want to have an implementation, specific other way to implement framers, you still have some kind of frame representation you can have and whether this comes from a library or is compiled from EBP effort, something.

G

Else, that's not.

L

Portable, that's fine! Still! You have common way to at this. Yes,.

F

I think that we should leave that open trim. They just do if they want okay.

A

Let's try to move through the queue quickly and then cause at this discussion.

P

What maybe this is what you just said, but I suggest moving parts of just a frame implementation to the implementation drop and heap the way that the application adds the framer to the pre connection and the set of functionality that the framer should implement in the put cutter stuff in the implementation draft, or maybe a separate draft. If this really grows out of proportion, yam.

Q

Extrication, the same way, having tried to implement framers or partially implemented this newer model of remiz a lot of the way the API works is like, for example, it's really painful to do it like that wait. It would be much easier to do and I think that's like an implementation specific, like the communication between the framer and the connection. I, don't think that has to be standardized in the API I.

Q

Think part of it should be moved to implementation, asturias, head on set a draft, and we talked about the brigde x1 right, there's a lot of implications from the way this works. So if we want to standardize the different way, we hoped would have read like a lot of comments to the implementation bar like a special amount, because there's so many implications on how the rest of the connection works.

Q

We talked about received at the next length is basically somewhat becoming irrelevant, with frame as active, because the frame is going to frame how much they tied once and how much the connection and application set rigid frame.

C

High configures economic agreeing with syriza the what we have it's possibly.

C

F

So one thing before you just so I can comment, so you can respond.

F

Great yeah I'm agreeing as well what what that means is that you, essentially what we are left with in the API just to clarify, is we have to have a way to add it, and we have to have a way to send information to it. So this is the part I'd like a little bit more input in scrutiny on, because.

C

F

Oh yeah yeah, we should we'll describe what it does and then the implementation can say this is one way to do it.

F

One of the issues that was raised for adding information to the context is like it's a little bit vague and I. Think in general we could have better text around like how do we when we were sending something? How do we tell IP or UDP what options to send? How you tell a framer to send it's, not super, rigorous and I. Think that's the part that is going to be most important. If this is the only thing that gets exposed.

R

So you have these questions up here. It's all hands in the pipe right: internal, uh no, not anymore, not necessary, not really not necessary cool. We can move on um so yeah message. Traders are not protocols, they're a special kind of thing. um You know that we we have this idea that we want to kind of like generalize these things to the objects that we can on. I. Think that's dangerous, because if we do that we're gonna use it you shouldn't we should. We should give.

G

Ourselves, like a foot gun, cuz.

R

It gets really tempting and yeah, so so you're asking question: if you go back to the Eco back to yeah, Here I am about whether there is a better way to represent how to give metadata to the frame. uh I. Think if you want to do a better way to give metadata in the framework, then you have to go and have this whole object model for what those metadata.

G

H

Look like and then the metadata.

R

Objects and the frame objects are I. Think that's. This is the point at which we can say like is an abstract API, but, like too much abstractions is leads to something that's sort of like unimplemented lis, abstract and key value. Pairs are kind of. We understand them, we know how they work yeah. This is this is just this is a little bit ugly, but it's a completely acceptable, not prejudiced. You go.

S

To the next slide,.

R

Yeah this is, this seems like it can go in the implementation draft. If you go to the next slide, dance.

G

R

Cursor I just I I've done too much with like that.

R

Database libraries, if the board cursor just makes me.

G

R

Yeah, it's like so it's a fill point here is that yeah there's a lot of languages in which you know a single.

G

Threaded cursor.

R

G

R

Not even put this in the I would maybe put. This is an example and.

G

R

Comment a draft but but make it very clear, there's a bunch of different ways to do this and I think that it's absolutely correct to say and.

C

F

If we get another one for like the Python implementation.

F

Q

For exam that thing with the TLB, this completely unnecessary in right, because the date object is typeless and that you hand over to the send anyway. So it can already include its own make the data.

A

Query here in minutes comments about refactoring this into the implementation and okay, great.

B

Awesome: okay, Thank You, Tommy.

C

A

T

U

John tongue, yeah sort of somehow it's not rolled halfway.

U

Training yeah all right, I'm, I'm, I'm, quite glad you know how this frame our discussion has turned out. I would have said you know this kind of stuff that we're doing now is way less important, so I mean this should be a quick and easy one. Actually, let's see.

U

It's much smaller question in the frame.

R

U

Okay, see I'm starting off easy first question is: is anybody that really really hates the idea of us allowing that we can specify that somebody can specify a specific protocol.

R

Brian Trammell with a philosophical question: can you define and allow?

R

Well sorry, can you define the word allowed? There are two ways to allow this rate. You can essentially say either in the abstract API. We have a way to do this and in order to be compliant with taps whatever that means you must have a way to do this. Yes,.

G

R

Say: hey if you're implementing a taps tag, but you might want to do this and the only really good reason I can see for doing. This is if you're, essentially doing recursive house raid, so you're building an L 4 plus protocol like you're gonna, build web.

G

R

A protocol that you're going to make available in taps built on top of its own taps implementation, where you absolutely must then specify that this new style has to live on top of this over stack. Does that make any sense I? We need white boards for this I. Think, um like your, there are two reasons to basically say: I want to explicitly specify your protocol right.

G

Okay, you're a lazy application.

R

Developer and you just went one way you want, and you know me you wanna in you, rights get on stack, stack, overflow. That says just flip. The TCP switch on and everything will work. Fine. These are the people that I think we should.

U

R

U

I mean I because they exist right.

R

There are two ways to roll on this: one is you put in the abstract API? Yes,.

G

R

Other thing, is, you say: hey if you want to do this, then do some implementation specific way of doing it. There's the point at which you're going a tap to application that you want to force a protocol on you're kind of getting into the internals of the system anyway, and we just kind of say yeah you can you can do that.

G

But do it on the side.

U

I'm still struggling to understand the second version. The second version sounds like you're trying to make it harder for be able to do it. Yeah I mean okay, discouraged, yes, but discouraged by making it hard to use.

H

A

E

E

You tell us often we you, you say on walk and a point with this protocol and then your API has to let you do this.

E

U

E

Don't make impossibly hard yeah.

U

I mean I agree with that. I mean I, think discouraged in the sense of writing that you know this is not a encouraged way to do it and it shouldn't be like the obvious default way to do it, but making it hard on purpose seems weird. Okay, yes,.

C

G

C

Need to be able to specify.

U

U

Yeah I'm trying to see if there are people that have an issue with that like if we, if we all, simply agree with this, which I hoped.

U

Yes, exactly that's the proposal.

L

F

Is so yes, I think we should say that it should I should allow you to specify protocol, but we should not. So we should say your implementation should allow you to do this. I must. But you should specifically say that it is up to the implementation, how it wants to express this and that it is not standardizing, because I think if we do try to standardize how it is then we need a registry of all protocol is that you can enumerate explicitly.

F

We don't want to get into that right exactly so, we should allow you to specify it somehow. It's up to you and I think one of the reasons in favor of a lot of people to do it. Some way into this specific way is: if we do not, then there is I think more lenient. Someone who really needs to specify something specifically we'll kind of like ossify around using certain transport selection options to always get tcp, and we change that they'll be upset yeah.

L

F

Let's encourage and have the standard way he always protocol agnostic, yeah.

U

Regarding the point of not standardizing it, I mean there are you know the next slides talk about these concrete proposals of profiles, so this is a bit it's not in that direction, right or whether you take them as it. Okay, yes, sir.

J

And to me, and for the typical use case of this would be that you want to write your application in a tax compliant way. But you know that at this point other and your support protocol, so you can make it more efficient. By also saying that you know even.

V

Just for testing.

U

J

A

So a quick chairs interrupt here so michael- has eight minutes left in his slot. I clearly got something to say he said it was short. We should let him get through it. So the question is so near yet you're. The next in line. Ask yourself shouldn't wait.

I

Because otherwise, it's just too easy to, like you, have an existing application and then you just think the easiest way to move.

G

It over it's just saying.

I

Pcbs TTP's appear a so it should be the prepare denied. It did agree to this approach where we say it should be possible, but you don't specify the next wave hard well.

U

I mean it's gonna be hard and dad you have to change it to ride two again, you have to ride against a new API anyway right. So it's it's not it's not like. You have an application written on sockets. You just bought it and it runs because it's not sockets anymore. So that's already hard.

I

U

I

Where your selective protocol then pointing it to a generic solution, yeah.

P

There is a you know: I think. The easiest way to discourage it efficiently is to make profile easy to use, so everyone will use profiles and most people who yeah we just.

G

Disagree with that.

U

Yeah can I see the next slide. Please yeah yeah, exactly I saw that maybe maybe yeah I'm getting the feeling that I should have see.

G

This is, this is let.

U

Me try and help all what is because that is the actual proposal on the table. I think and yeah. It's probably more more useful to discuss this so who has Red Bull requested. Okay, one two couple of people: three yeah.

U

Okay, so this is a polyp or requested that describe that, describes, profiles and describes. You know you would choose a protocol by way of choosing a profile that matches on so, for instance, TCP.

R

Yeah yeah so discuss actually I originally got in line to say that I had almost completely changed my mind on what I did before, even though nobody understood it. That's.

G

Probably the cold medicine talking.

R

I so I continue to really dislike the forest transport I, like the fact that it's called force because it fine it kind of feels like you know, that makes it feel a little bit discouraged. I think we should make it feel a little bit more discouraged than that I, like maybe putting like it's gonna, be in the document that in shaft, like you know, we should use the blink tag. You say: don't do this, that's a different! A are yeah I.

H

Guess we're so probably.

R

H

R

And I was really confused by it because they seemed like alternate proposals to do the same thing except I. Think that's what yeah, but they were, but yeah.

U

I'm, a baby Phillips should go ahead and.

L

L

Corey wanted for the second one for before half, but if I don't make it I think they're both puzzles are not alternatives but apps to each other. So the profiles is like. Oh, we have this kind of news cases, don't make it so hard. Then you have to set a bunch of properties, so we have a shortcut to say and I want to reliable stream in order speed protocol. Thank you and whether it's TCP Oh, quick I, don't mind and we have the other one to say.

L

I'm implementing this specific protocol that uses in some of its internal state machine fields from TCP I know it's shitty protocol analogy, but I really need TC deal because of this reason, so please force TCP or for TCP or UDP, because we have badness for those and therefore I think this are not alternatives. But these are two ways: one is saying catch the common case have a profit, then I don't need to add, does lock properties and the other one is.

L

The Elm is the reason I really have to force the protocol, and this is a rare case, and this is discourage you. Please don't use it and we get the technical compilers. Thank you so.

U

What about maybe that's stupid? What about a profile that just has one property in it and it's grant? The property name is protocol and the value is TCP if I want to pick TCP so I'm using the same machinery and it.

U

Shouldn't be protocol like you're terrible guy, want to pick a protocol should be the name yeah.

R

R

U

I mean that could be just a profile right, I I,.

R

Don't dislike that as much as I thought I was going to when you first started saying it. That's that's actually a pretty good idea, because I think I do.

L

R

To think that the main reason that you would end up like forcing a protocol is because you're doing some low-level stuff right, which is why I like to turn on the state for this, because that's what like both Rosten, go uses there you're you're mucking about underneath.

J

R

Compiler and bad things are going to happen to you.

G

A

H

A

Think there's a community people who don't think that's unsafe. They think that's absolutely required. Don't remember the woman who came here in the.

P

Early days.

A

Of taps, who was talking about like these highly optimized TCPS, and how can I make? How can I, how can tap support this I, think that's what this is allowing her to do? Why are you calling it unsafe, I think that that's unnecessarily, but.

R

A

You're you're disabling taps.

R

I'm using the taps, API, but I'm gonna, disable the entire engine right.

A

I assume that if you want to do that, you would just use TCP where you just call.

L

Correctly, this first protocol property. You can send it multiple times. For example, you can say I can accept the following state combination. Sorry I can accept TCP or a city or eep, because I wanted to to talk, sit, sit for example, and then taps can still race these three against each other.

U

But if you want to do I mean if you're going down that path, then you could just as well not specify these three protocols but the service that you want right.

L

Because your bindings, it explicitly require explicitly have some weird knowledge that they use some fields of TCP yeah.

S

L

The case for it.

U

Okay: okay, I, can't imagine that yes, hey.

A

We're running out of time in this slide, so let's try to activity Q. This is a remote I. Think.

U

Actually, I monitoring people I'm I'm, I'm I- should feel me moderating this. That's not even my proposal yeah, so you go ahead. Your people.

P

More emo, it is absolutely essential for apps to be able to specify transport protocols. My experience is that there's too many subtle differences from Braun transport protocol to another to expect apps to run successfully over arbitrary protocols. Second, that permitting arbitrary transport protocols. You make testing of apps and support into nightmares. It's one thing: if an app can support and assess it on any protocols for small N and that's potentially useful, but arbitrary number of protocols is unworkable.

P

Using profiles is inviting more variability between endpoint situations and more ways for an application to fail in mysterious ways.

U

A

If you can say must always, he said must be able to.

W

Discuss more on this full requests, so I mean one question that was biting me about it was like well: when do we need to need any specific put Isis fire protocol? If Jeff's is doing is show up say like okay, you have property to conceal and how hard it is.

W

Okay, these are the properties, give you tips dissipate. These are the properties between UDP. So when you do, I need to specify what is the reason I can hand it here. One reason like well, one very specific application is only working with TCP because they have shame layer and stuff like that. Yeah.

U

The server's listening on that protocol only on that.

W

Test those are not like those; they should not really try to do steps at all because they have the DEF specific requirement. So I mean to me the application developer. I would say like okay, if I can specify all protocol that I like be good, but then I will use some other and for me, if I can't.

O

W

U

Trying to replace them or.

W

Make a decision here that makes the application developer to get what they need and that's the use case of a test for me. Otherwise, I am NOT good. These tests, I'm going to use like something something that that gives me in specific product, because I am using tabs because I would like to try. I would like to get the best of human transport services. That's my requirement when I am thinking of these, they were as clear.

C

Q

What it's all about.

C

We, what we're building should be capable independently.

C

It's a complete replacement future, so you can't say: don't use taps because it's the one being alternative in the eventual Nirvana work essentially and I, say nothing. They cannot believe. What's on the slide is the right way to specify DCT, because there are many protocols that could satisfy those behaviors I think we do need a way of explicitly saying: I want TCP I, don't want a reliable order to congestion control, preserving message boundaries, Prescott, I, wanna, see CP yeah.

C

C

U

Like to get a feel for for my proposal of just saying, a property is a protocol and the name is TCP as one of these profiles. So would that be something that you like, because I think you know I said yeah I said I think that comes.

W

Out so Michael one question for me: I mean when you said, like I, have profile and TCP. Do you expect that they only provide that one or do you expect that they also put some fund of really prepared forever here, because I can make a mistake that I want to see, but the record where it gives me something else.

W

If you, if you specify a profile, I want TCP, you don't need all these things right.

U

Just just a very simple profile that has only death, yeah,.

F

Apple, so one comment just to Colin's point right now on the watch: we actually only allow taps or things based on top of it. You can't do sockets directly, so.

F

K

F

Don't like the profiles proposal, if we have also expose what we currently have in the document, because it's essentially.

G

F

Way of saying the same thing: it's a convenience I completely believe that every implementation will have conveniences for how to easily set up the common sets of things. However, I don't think we should be defining what those sets are because they will vary based on different use. Cases today and use cases in the future, like our EPA, has kind of default sets of like here's, how to set up the profiles, but that is not required to be.

F

You know, cross implementation compatible if we're looking at kind of forest like the yang model, having or being able to describe everything that could be because it's not really a developer typing it out. If you wanted, like a big yang model, here's my pre connection, you can go through every property and set it the way it needs to, and you could reuse that. That's just that essentially a profile. That's.

D

Very interesting, but we don't need to in.

F

The API itself and I think it's similar for the protocol specific stuff. We should say the implementation should have a way to do it, but that's not interesting to make part of API think we need to be smaller in what we're adding the value that we add. As a group music, we have the stuff that we've gone over of the different transport services. We analyze the transport protocols, so we've distilled the set of things and properties that are useful to put in there.

F

So that is the value that we are adding to the API doing these other things are not really what the taps group is the expert in it's going to be what the implementations do in the future with it. So.

A

B

A lot of sense to me, but I'm going alright I agree.

A

With you but I think Keith made a very good point, which is that there is a requirement here. Applications must be able to specify a legacy protocol if that's what they need. There.

U

Was a front, then we don't.

A

Have to say how how it's done but I think it's an architectural requirement for the abstract API is you have to be able to do that? Otherwise, your manat? If you're not requiring it to be supported, then you know: there's a there's: a full applications: users who.

F

A

F

So I guess, like the two options I see there are either something in the document says. Your implementation should must expose some way of sending it to you a protocol and may have profiles, but don't say what they are or we say. Well, we can even want give a specific property name of choose a protocol, but I think that's maybe further than we really need to go. Yeah.

B

L

Awesome as I wrote, those PR so I think we still need those mechanisms, so we need a mechanism for explicitly choose. One protocol I think this one should be part of the core API, because otherwise it makes stuff much less portable for this and as a second one I think we might need each product profiles that allow to set up comments of properties, and that's we see these profiles as set the following properties. By the way.

L

This enables second thing we had a lot of discussion about which should be the defaults for all these properties by including the profiles we get rid of a lot of these discussion and say not. The default has to be somehow physically comfortable, but ok, we have a bunch of default profiles and.

U

What your settings, what you call this: a bundle which is a profile, and it includes all the defaults or what you discuss each to each default and have it listed across the document is the same thing right technically.

L

For these prophets we have default values and you can still overwrite.

G

L

You know your pre connection with the profile, then you get something tcd comfortable and you can add further restrictions of further requirements like zero RTT or you can relax some.

X

L

These bells, but you get rid of the problem F as having to completely agree on one set of defaults for the properties. I can say: ok, we move this to the profiles. This is one way to do this, I'm, not sure that that's the right way, but this was one reason for of this proposal. Let's cut.

U

The line after Anna.

I

My discussion so I'm selecting a specific protocol I, would like to step back over then really understand the use case behind that, because there were a couple people who brought up some kind of use cases for it, but those are really not convincing. For me, for example, if you have a very specified spec, which usually means you have a user space in the invitation of something which is whatever minimized, because we use it undecided advice or whatever, then you probably don't want tip.

I

So you don't want all the flexibility to get it, because we wouldn't make sure that you really really have that one. That piece work that you want so I'm, not sure, if that's a convincing use case for me also, if your server only supports TCP and you to try to open a Greek connection to the server, it will not reply so anyway have to for vectors as long but then like. If what we want.

X

I

Everything and anything you wanted in DNA, because it's the wooden Ephrata system, so I would understand why this is reading inquired because I didn't see a good case for it and that's protocol specifically profiles. I.

G

I

Agree with Tommy that I think this is very implementations. There's a figure, especially I, think we shouldn't specify a set of pop a profiles because that's exactly the flexibility one here so I would recommend to make. We put it in the implementation draft, but not put it in the API, and this is also another general comment. I have I think we should actually try to like not extend the IPA IP API too much because the more complex we make it the best incentives people.

G

Have Germany we.

I

Should stop at some point.

V

Hi, my name is Michael shorten speaking as TC venture I just want to give a heads up that there are legacy applications that you not only know what protocol they need. They also want to specify individual TCP curvatures. If you're interested in that please contact et bien session. You will learn about one of the use cases there. The specific parameters vacations interested in that case other keepalive parameters, and if you want to be generic, you will have to think about that level of training for Nora T I can access the parameters possible, yeah.

V

No, no! No! But there's a time because just a heads up in case we come to a PC PMF. You interested in this specific use. It's a relevant.

O

So I'm going to argue that I actually think that having do not have letting applications have strict control over the protocols, they usually actually get terrible thing for the ecosystem. So the example I'm going to give is, let's say: I have an app that runs. You know, Apple watch end. You know talking to an apple to a Mac, OS server, so I'm using Tommy stack and living it's a smtp over TCP and I recommend it.

O

Today everything works great and next year, Tommy deploys quick and it's tactic limitation and my app suddenly starts doing SMTP over quick in an entirely done way, just treating it as over TCP and the IETF says. No, that's not.

G

O

Seem to be over quick, you should use old grief, it's a quick, but sorry we have deployed stuff. The only way to do it, you know in our existing running code is to treat the so some PCP, because that's the legacy we got accidentally I think I'd be a terrible outcome. You don't want that to happen. We don't want protocol should definitely come online. Just because the stack upgraded.

O

We that's gonna have that's going to be bad. Then you go system. It's.

P

A treasonous Travis cry again info Keith Moore as an app developer. I would love to be able to find out what options exist. To connect to appear.

P

That doesn't mean I, want a lower layer to choose an arbitrary stack and not just legacy protocols and then, and then I also want to say something Harris myself, so I'm, really in favor of profiles, because our target audience for the API drove our application developers in my mind, who want something, nice and shiny and like some new features and who maybe don't want all the details of the transport protocol I want to make it easy for them to use right like we have tossed you such examples or we want to show all this API is really nice and easy to use.

P

You don't have to care about all the transport protocol. Details for that. I really want profiles, I want to mention they exist and I would like to have profiles in the egg and a draft that they exist and the specific profiles can be appendix or somewhere on.

J

The restaurant so I think we will need profiles in implementations, but I agree with Romania that I don't think we should have them in day. Guy draft.

L

X

L

Collection conferences.

J

L

J

Not want them as a parameter, maybe you can mention that it's possible to when we describe our transport parameters. We may say it's also for implementation as possible to guru in various ways.

J

A

Let's, let's maybe try to close this out by taking a couple of hums, so let's say have a hum as to whether people think that it is that profiles should be an element of taps. Setting aside where it's documented I'll put. Do we want profiles, yes or no I'm free, yes, I'm trying to be vague, I'm, gonna, drill down? Okay, we don't want profiles, okay, so buddy there seems to be consensus. That profiles are useful. Should the existence of profiles be part of the API specification Humphrey?

A

Yes, okay, the profile should not be part of the API specification. The existence of profiles, not the specifics. Okay, so there's a few humps, but it was it's stronger for yes, then no, so you guys look very confused. This all supports what I thought I heard in the line.

I

Pieces of the draft, but it's already mentioned really well.

A

You can it know whether you you that now you've got something, that's general, it can be extensible right. We don't have to specify all the profiles that should exist so.

R

I think you're. There are three options and the poll 328 is almost so.

A

Option number one.

R

Is profiles or normative, first-order citizens again the API, you must implement them. You should use them. Here's what.

G

They are and we're going to even specify.

R

A and, if you're going to do that, you also need to specify.

A

R

Right, the second one, which is what the poll request is almost now, is it's in the appendix we're saying you could do this and there is a normative reference down to there by saying here is an optional profile thing right: where.

G

If you're going to do this, here's how, if.

R

You're gonna do this I think those are that's and then the other one is. You could do its own document and then say hey this. Is it maybe that document to standards track and then it's like? Basically a tax extension, it's like we have files, and then there is maybe a non normative reference in the API drafts. Saying hey you can have. If you want profiles.

G

Go read this other.

M

R

Too great or you could put any implementation.

A

So there's yeah there's a bunch of different. So do you think you heard a consensus on one of those I.

R

I didn't know if you're convinced on any of those I heard a consensus on. We want them. Okay,.

A

So I think we're out of time we're not gonna we're not going to resolve this here beyond that point Tommy, unless you think you can state what you think is the unifying solution here that everybody is going to agree on. I. Think that we're gonna have two.

F

Options because I think there was confusion so when I was going to propose three options, were one do essentially what the PR is today. How do you have profiles and they modify the existing symbols in the API abstract API requires that it takes a profile symbol that is part of the API.

F

Maybe I mentions that profile conveniences exist is that it does not modify the existing. Take a parameter. You just say you can build this on top. Maybe you should and three you don't mention the middle guys. I think that might be a clearer hum. Yeah.

F

As mentioned right, essentially saying like you, the API can also add a way to create a set of a pre connection. That's pre-configured in a way, that's good for this, but it doesn't modify any calls on the pre connections. It just set stuff for you, but I think those are the degrees that.

A

So without trying to muddy the waters further option, what can we do a home on that? Do people understand what the three options are enough, that they can express a preference okay option, one all right, I heard the vaguest essence of hum, but I was trying not to because then we're gonna, then I won't do it perfectly, and then we will argue about that.

I

Do it hum now, if you want a parameter.

S

A

Entered we've entered a nonterminating process, I know.

I

If you don't want to change the.

B

We're gonna move on.

A

I think I think.

A

Let me here's here's, how I'd like to do. What I would like somebody to propose the options to the list and we can do an online hum or.

G

A

Equivalents right people try not to get too much into editing the questions who would like to do that I. Think good candidates are Brian, Tommy, Michael or Maria. Okay, yeah told.

W

Me, oh honey, you're, gonna, close the questions to the list. Try.

A

To while it's still fresh in folks minds, and so when people can just do a plus one for the thing that they like and maybe try to move on today, did you have anything more on this run? Yeah.

O

What spread a surprise, hominid.

U

From your the coffee.

A

U

Just made the mistake of transience everything as if this was my proposal: I'm not gonna. Do this this time, I'm just going to read to you what this is and see what happens because it isn't my proposal I'm just trying to moderate this okay parameters and defaults. Should we specify, rather than recommend default values. The proposal is the red line here right that was Cory's proposal.

U

If I remember correctly, essentially replacing all the text about the default value could be or is recommended with well requirements language should we do that or not and that and enter the policy discussion, which is why I'm not going to answer comments I'm, just gonna watch you.

E

What we were doing is somehow disagree with what the I chatted in the other RFC's, when we did.

E

U

I want to see if, if this per request should be approved or not so this is.

U

Yeah. Okay, sorry, it's a it's! Not a pro request. It's a it's an issue, yeah right, okay, but I mean if we should do this.

W

So what one comment I have like I, really don't see the policy matters for this must here I mean the policy can override the different thing. But here is more about the sentence like saying like before, mostly this and the ePub some policy, whereas before that's the different factor for me,.

E

Policy could be overridden. I was unhappy by kind of saying. The default is recommended to be something. Let's just be bold it we know.

D

You're exactly saying we must yeah thought before it must be now yeah all right, yes, allowed Erica near Apple, so if you say that a fault must be, this is that the default for an implementation must be this or they default in, like basically a rescind into the default when I implement. This I need to specify this unless the client overrides it. That's plural. So at that point, we've already seen that for transport properties of a large number of protocols, different platforms have different defaults.

D

Are we trying to say that the entire world should not have done that and is? Do we somehow believe that they will do this? If we say it must be? That, like, is this going to be any more effective, if we say must, because we haven't seen different platforms, make their own choices, I think.

U

The center question is about requirement language or not, so we could have shipped for these cases for for cases where you think that this should be different. Different platforms.

R

Gouri so as.

Q

I understand it, your.

G

R

The issue your reason for following the issue is that the language was kind of like if you feel like.

Q

It maybe you could save you.

V

Like how this is the.

R

Default, you know, let me let me make an alternate suggestion here. The default is because, when you stick a must.

A

In there, yes,.

A

Can we just say the default is so I'm afraid I'm a little confused by this discussion, because I thought the question was: should we have defaults.

R

Yeah we're agreement reopening okay, so that's settled all right. Good.

R

But that's not requirements, language, okay,.

G

No, it's not. The coin is like this. It's.

R

It is less, it is less kind of the area. Then then, what we have is.

E

Okay, so we avoid the lower chance to.

R

Recommend, which is.

R

Okay, what's there is bad, let's go, it is, and if we want to reopen this in IETF last call on your life is, it should be. Must then we can have that argument among your ETFs Twitch's be more fun.

B

You have a table comment on this, I mean.

I

Even though not you can even specify whole protocols without normative language, yeah.

B

And we're not doing a protocol.

I

And the other point to use a must is because you might have some interoperability issues, so you.

K

I

If you think that, like it's important, that all platforms use the same default because it's the assumption of the user and otherwise things will break then that something you should make clear and that would be reason to use math but I think still think you shouldn't use no magic language anyway,.

E

The reason I wanted normativity language in was because the things we were society cup normative language. That said, you must do this, so we eat when we say the default is well. You recommend this because.

M

The RSC already said: do.

E

You thought, I think just say is I'm still very happy yeah. If.

U

E

I say you just click on.

A

U

If you say we were commended, but when the RFC says must and done what yeah.

J

Two dimensions here also override could be not just a client, but will all be the existent policy or something and I think the other part is that it's the default here is how we use it for for the protocol, selection and racing. So if you say ignore it doesn't mean that you can ignore the feature necessary. It just means that it's not used for selecting the problem, so that's also different things that I think we have to be confused in this discussion agreed.

A

And I think Gauri that the point that you're making about how you know a taps implementation should not use protocols in a way contrary to how they are specified. There should be some text somewhere in the implementation or in the API document. That says that if you're billing a taps API, this isn't an excuse to put in a permanent hack that violates how we think that protocol should be used.

P

Teresa again, it's trouble scribe for Keith Moore. Please define things in such a way that applications behave predictably, predictably, across different locations and different hosts. If defaults, are implementation, dependent, I, don't think this happens. I.

B

Can't go three.

S

With that yeah.

B

So Joe anything else: cool, no okay,.

G

B

Thank you. We gained some time and we it's in Paris.

A

Sir, the next is arch and API open topics.

L

All right so still the next part of someone moderating just stuff that has to be done so.

L

For for your information, I compiled a list of issues from github that we might want to discuss today if the time permits, so we go as far as we can get and I sorted them a little bit across that we might make progress here and they are not completely editorials. So if you don't find things that are look at eternal yield, this is my invention. So if the first engineer I think we could discuss is the question of Tommy, whether listen filtering bruh, hey behavior for TLS should be somehow exposed.

L

I put the T for T less brackets, because I think it's generally useful feature. The business option delivers the connection but doesn't provide a particular wait to reject connection. So the text suggests that receive connection delivers. The connection once the Tila's server handshake is complete, but some implementations may want to rate limit or modify this behavior so I.

L

Think there are three possible resolutions that I'm reading them aloud, but I think we should have a short discussion. What makes most sense for this improbably just read all for the result. Us today.

R

Of these three I, like resolution, a naturally not received event in your connection, events with listen calls um primarily it's a little bit weird. It means we might actually want to rename listen because listen has it's like listen and except they have meetings and sockets. We don't have it slightly different. um We have slightly different semantics for these now in taps, but I really like the symmetry between sort of like to receive connection back pressure and the receive back rusher.

R

It makes sense to have like one way to be miss Eric.

A

As our security one of our security representatives here, you have an opinion. What do you want to generate an opinion on this? Well Tommy's talking.

F

So this is something that we've discussed a lot specifically.

F

We chosen our recommendation not to do this, but instead to actually model be listening more on what the existing listen call has, which is kind of like a window of how many connections you want to receive I think, unlike the connection with general receiving data in which the application has some expectation of how much is going to receive a server, that's receiving connections out of the blue really has no idea how many there could be and adding these calls could either add latency where I essentially have to call receive new connection a thousand times if I want to be able to receive a thousand connections at once and have that be the window.

F

So having a convenience to just say, here's the window of how many more connections I were willing to receive. It is useful, I think that's slightly different from the what the issue is trying to get at, because even if I allow a connection to be received, I may want to do something before all of the application for a custom, so before TLS occurs, we'll just to do some filtering, so they're related.

R

F

F

Not an additional.

R

Then, essentially get an.

G

Initial knob to say how.

F

Many in connections and we're going to accept- that's not TLS specific, but we may also need something business. What the issue was that allows us to reject certain connections from certain places or like say, oh, my.

O

Server doesn't like, under.

F

Their dolls I want to reject everything for this supplement.

O

Yeah Dominic's just that point one of the things when I was first learning, sockets I always thought was really strange. Is that there's no way to respond to a sin with a reset, so something good we know like for you know stacks that are doing. You know Carl implementation, but actually doing their own PCB.

R

So I'm gonna get back in line after listening to tell me I want to withdraw my statement on a it's beautiful, but it's not practical, um I'm, not sure I agree that that's that he is the right way to do. This I think we should probably continue to discussion somewhere else. I will know that I forget where it was, but I think it was in an early version of post sockets.

R

There was essentially a three listening like event, which is essentially an event that came back the application and said: would you like a connection that looks like this before I? Go to the whole effort of setting up all of the context and stuff here is an incoming connection. That here is the remote address of it. There's any information about the remote that we have do you care and then at that point it could essentially return.

R

No right, like so in post I think it was a call back and it was like it would return to boolean. You know. Do.

G

You want this and.

R

It could be like no Freddy, it would just drop out of those a way to to short-circuit the early processing. There are two different.

G

R

We need to address here. One of them is back pressure like the fundamental rate limiting problem, and one of them is, is sort of like early rejection and I think we should probably what you put something in this issue, who are splitting into two different issues that it points out that these are two different things that we need to control, but I. Don't how many more of these do you have to go through these kind of questions of these questions of these issues?

R

Are we gonna go through today, I think, six or seven we should probably make a note me issue and move on would be my I. Don't think we're gonna resolve on this: okay, cool, yeah, okay, okay,.

L

So but I think the general, so just just the feeling is adding an additional event for let's say: pre acceptance, a solution we might want to go with I'd, be so so yep anyone I'm speaking against it. Fine I think we have a solution for.

O

The TCP layer with my new look, my map, reconnect.

L

Any volunteers to write text for this.

T

L

I think we go for the next issue that.

L

Yeah so there's a issue: 158 unidirectional streams for multicast source and sink support. We have a selection property that allows to create intellectual streams, the main document, but no way to credit curry very web. The connection is unidirectional, so the question is: is the mechanism sufficient for multicast.

L

A

Think we want Jake's input on that.

Q

Just make sure that if the local.

G

Address isn't it's.

Q

A group address and it isn't specified any transfer property that it has to be unidirectional receive stream. Then it should just say: oh the connection, because then ditch yeah, that's what he did.

E

Gouri Fairhurst, and I think we should do- we could do more multicast I think we should do the least that say about what was already done so I like what was done. Okay,.

F

L

I think the question is most probably yes and the other extensions might come in with another PR from some of you, okay, the next question is already answered, I think in the last discussion, so I think framers are enough. First start here less, so is there anyone against closing this.

L

Now closing the issue with yeah: okay, okay, so we need text and we need text for this and the implementation. But the issue itself is: we have a sufficient mechanism for it.

L

So there's the question between differentially bad selection configurations from connection issues. So currently we want just have one initiate error event that could be everything from racing failed to.

L

Use just specified in unsatisfiable configuration with the transfer properties. There are three ways or two ways which I could imagine to solve. This one is at another event that tells you that this is unsatisfiable or the other one is to extent the initialization error to contain a reason which could be configurations answered as far away or we don't have any candidates that certifies satisfy your properties.

P

In what I'm in favor of I would like the initiation error to contain some kind of reason could be an implementation, specific enumeration or something I think there's multiple like failure modes, and we want to initiate an arrow to contain some information about why it failed I. Don't think that we right now can foresee all the different reasons why something might fail, and so I would say it should be information included in the error, but we can probably not specify all of them.

R

Hi Brennan Trammell I'm a little confused because I thought- and maybe this text came out of the draft or maybe I'm just thinking about post sockets, and it never went into this draft um that if you try to initiate on unsatisfiable constraints, that should be throw an event. It should give you an error on the call itself for eight, like the point of an initiation error. The reason that that's an event is that the initiation happens asynchronously, whereas everything you know about an unsatisfiable selection configuration happens at calls line.

R

You have enough information to resolve the failure at the time that you make the call, so you don't have to queue an event. It is it's not asynchronous and I. Don't recall whether that means in two taps her. If I'm, just remembering post sockets Tommy, you have.

R

Hasn't returned value, oh yeah, so.

S

When go, you have.

G

A multiple thing right.

R

Yeah, but um that having been said, I still think that we want to add additional information initiation error event, because.

G

There are other asynchronous.

R

Things that can that, can that can happen right, so yeah I would suggest resolutions beyond this. One.

U

Mike Alyssa I think max has opened two or three issues that relate to communicating specific arrows.

G

U

Adding information to arrows what about just adding a listed in the appendix to you know a list of error codes say these are initiation error. Is these kinds of errors and explanation.

Q

Yeah max franca and first of all, it's somewhat.

G

Q

Also, the nature about initiation ever being very specific right now, when it should occur and I think it should just be more generic, because the thing I just said about motorcars, then it should fail out. It should also initiation aright, the local versus the group addressed, but it isn't a unicast receive stream. So that's the thing and I think the error. Events like descriptions of errors or, however, you want to call it shouldn't, just be on initiation errors, but maybe should be on all error. Events in general.

G

Q

Might be useful, like you probably always want as much information as you can get from the events.

F

Tommy I'm Colin. Yes, so definitely on these in favor of be and generally in favor, of having fewer events with more descriptive errors being returned.

F

I think this is actually a rather EPI design thing and we would look similar to some of the conversations we have around send sending gating the various completions you can have to send like I was able to set this or I got an error or maybe even whose act having one event that you expect he's a lot easier for the application to handle right, because if the application, depending on the language, has memory or state of actions that they need to be able to take, knowing that there will be one event that they need to handle in completion of an action as opposed to any number of things.

F

They just gets a lot more complex with them and less practical to hold API. So I think when we're looking at things like this, unless we have a really good reason, we shouldn't be adding extra events that can just be communicated in single events.

L

So is there anyone who wants to give it make a PR and may do a make over of the error. Events to add reasons make a proposal for our text. For that there's some volunteer.

L

Mucks your warranty.

B

G

B

You can quit boring.

L

So there's an issue race by Colin.

L

Consider API that takes panning policy as an input, so padding is increasingly supported by Transport. So, for example, you could do a lot. A lot of padding stuff in TCM. Sorry um now was UDP light, but you can also do this with quick and we have some use cases, especially for implication, if occasion, prevention in quake that need some kind of control of padding. The question is whether we want to expose this functionality within tabs I'm, not asking whether how we want to expose them. Just ask me whether we want to expose it at all.

L

The reason why you might want to expose it in the transport is that you don't know the MTU. You don't know, for example, if this is petting before interruption, how much encryption or overhead this there will be so petting, just if you buy AB and too much bytes can just make a packet to bake, so it makes sense to give this as an input through the transport. So the question is whether we want to include that.

D

Eric, can your Apple I think, aside from the fact that, like yay, padding in good things to consider padding is one of the things like you said with the overhead and especially on more expensive interfaces, and things like that there may be a cost, and so that's something where I think we have to expose it. If we want to be able to do it in because, like you just said, the application doesn't know how to do it and the the the protocol. That knows how to do it.

D

Doesn't it's allowed to do it and that's kind of definition.

E

So Cory, if we have a 30 year information, then maybe we can do something smarter here. Otherwise we just do something stupid.

O

Dominic's I mean while I agree. This is a useful thing. I'm not I mean I also feel like. We do want to finish and I feel, like you know, just because we published the first document says he was never going to be extensions, so 100 fish should be. You know something that we start thinking about. Okay, what do we want as exceptions to the.

I

Basically minute so I think there should be away in the API to support some kind of use of petting, but there might be different ways to implement it. Another way is to you know, tell the application what the maximum size is. The message can happen, the application again with the petting or the other way around 2000 transport. What the message sizes you want, and then the transport in do something on.

L

This this can be problematic. If you want to have read the patent or, for example, heck happy within quick, then you can't easily do it wasn't the application is the transporter.

I

G

I

Can you can in the interface, could talk about the message message size instead of using petting as a function? Okay,.

L

A

So somebody's going to start a API, miss.

A

T

Show a bucket to put it in okay.

L

So suppose we just add a label on get up for the extensions and put this is the first one under the label that says it's not the first one.

A

E

You know I know in a bit time here, but um everyone have a sign the beginning. We said we just like to finish these things. Yes, so what did we do with this list? When we finish, we will.

A

Decide that when we decide whether what happens with the working group, I mean what I want to do is publish these three documents right. If there are other documents that might happen in this group, it might happen somewhere else. Yeah.

E

Super stress are quite happy unhappy, Independence someone that says under other things, rather than trying to decide no yeah.

A

No, that's what I'm saying I'm actually I'm saying I'm, making a stronger statement that we should just. We should note it somewhere, where we are keeping track of things that we could do in the future. I'm not saying I'm, trying to push it out. I.

R

Would suggest that the github issues list is the perfect pose to do that? Stick a tax ID stick a tag on it that says no. We create a new tag. That's like hey things that are gonna happen in extensions like we have decided as a working group. Please don't go in the core Docs, but we've also said just working group that we want to.

G

R

G

This is why, if this is a this.

A

Is a pretty easy thing.

R

To add right like so it's it's a message, context, sorry, property right, Sam yeah. It.

A

Do you think that there is other future work? Besides extensions? Is there a different tag that is future work? We.

R

Just got a few worker yeah, we don't even need it. I mean, like extension, you don't wanna use it yeah you're right. We know we use the word extension because extension might mean something exactly.

A

I thought you were using anyway. That means something you know: yeah.

R

A

B

R

Do that right now.

L

Yeah should send return message contract. This one are is some kind of issue that started as more as a semantic one, but turned out to be ever actually be two questions. The first one is there are concerns that and often unused convenience return value could be harmful in some languages, which is the easy one. So just drop it. If you don't like it. The second one is more interesting because sent hours are currently want, one matched with send code.

L

So, if he's issue a San call, you get one sent error if this data wasn't sound so for the first one, the question is.

L

For the first sponsor of the question, the original question whether said San should return a message: contact as a convenience or not. We have the resolution to either remove the message, content of return value or have it option one as a convenience and make it optional for languages that have problems with unused return. Louis is there any.

F

Time so my initial confusion here was: what is this return value? So if I call send and I give you a message context that here's the message I want to say: will the return value ever be anything other than what I passed as the message context now.

L

What will always speed the message? Context to your past.

F

Which is a little confusing then so the only case it is a relevant value is when I pass like a default or nil or something I didn't.

G

Specify anything.

F

And then, for some reason, I want, but then I realized that I want to care about what the value was, how they didn't want to create something. So.

L

If you don't want to create a message context, but afterwards would like to introspect on which was the source of rs.10 for this telegram or some other values that the transport system shows. That's the only reason or if you want to later on use it for use it for reply matching. What would you which we edit? This is the only reason. These are the only reasons where you want to use this return value.

F

You just always pass a value if you care about using it, and that should be very cheap. It should be easy to do, but it's you should pass the handle that you want, because we already take that.

U

Yeah and and if there's something you want to learn about what they want, the transfer system chosen tit and that should be a queryable parameter or something like that, and not not a result of sin which is just okay.

R

Plus two, this seems like it's very, very, very C, C API, driven and it seems like, is leaking sort of like specific.

G

R

Semantics I, like I like Tommy's revolution here: okay, so.

G

L

Go ahead and close this.

R

L

Close the first half on the second tab is the more interesting one. I guess the question is: centers are cruelly one-to-one match with send calls. So if you have an application, that's stupid, and that writes by twice and at some later point that's filling up some send buffer at at some later point in time this connection dies and there's still stuff sitting in the send buffer and there's a few kilobytes. Then you get a few thousands send arrows back.

L

So the question is: is this the behavior we want or do we want to have another way by saying either you could just get one cent error and some reason or some message context object telling you which sense failed or have some property how to control the aggregation of these events.

L

Document currently says that, especially for each cent call you did you get the sent error event potentially.

L

As I read the document currently, it would be.

A

We are out of time for this session so now you're eating into a discussion of yang models.

O

Your assumptions that every send will eventually either get an error or a set right.

O

Okay, so it's not it's not going to make it a sender. It's a will definitely get either successes go so that so they know that there's something there's a thing is like a a final error on the connection after which everything after that gets neither success or failure. I.

L

Think we should take this discussion to the list. I.

L

Have more but I think we should discuss the yang model.

L

Yeah, so the next questions are basically how to handle protocol stacks that are not equivalent draft appointed existing implementations and implementation should separate our protocol specific bits so.

A

Perhaps, as a way to move forward, you could just take the text with links to the issues and send those it's individual messages to the taps list, and we could try to get a little bit of discussion on there and see if we can make some progress. Okay, but it does seem if we don't. If we unable do that seems like this is a good material for an interim yep.

A

I thought he said: you're closing the first half.

P

Hello, so I'm not going to talk a lot about Yang, actually, but mostly about testing tabs, because that's what we were using the yang model for in the hackathon, so max, Jake and I were basically participating in the hackathon the entire week and and doing various things like implementing multicast.

P

But what I focused on wasn't testing, so um what we are using yang for right now is so you have we're creating a pre connection and you have to specify a remote endpoint, a local endpoint, transfer properties and security parameters, as you can see above and of course, all of these have to be filled first, with like some content and now what the yang file gives us is that we essentially substitute all those four parameters and the initial like filling those parameters with data.

P

We substitute all that with a yang file which contains like some remote and point address, or hostname, and port and transport properties and security parameters and all the stuff it's in a single file. It's easy to refer to, for example, in a test case, I can say: ok, I have my UDP client to Jason and then I throw it into my tests and they send something I get something else.

P

I get something back, I check, whether us, what I expected and the advantage of having it in a model is that it's easier to port across implementation, so I I'm going to go back to this later on.

P

So this is sort of their benefits of Yang that I got and the pain points is actually or it's not actually that much of a pain point anymore once you have it, but getting it to work is first a little bit weird because it is a different implementations of yang, but pi yang was too painful for validating instances of models for some reason. So what we are using for pi, EPSA, kaliya, c++ library, you'll, have to install this library and you have to build it and we got it to work. So there's a shell script.

P

So if you check out our repo- and you just run this script, it works on linux and mac OS on our machine. So actually it's not that bad to get it to work, but it's sort of a little bit ugly but yeah. So what we did with this model was I, wrote some tests, basically sending data and then I'm running an echo server and getting back data so I test whether TCP works.

P

What are you DP works without gos works, and next steps could be to also test like, for example, failure modes and while testing these. Of course, we found some issues too in the code sandbox to fix, but also I looked a little bit more at the model and, for example, the security parameters right now in the model have the identity and the algorithm as required. So you always have to specify a algorithm and I think it's not always necessary.

P

For example, if I give you a certificate and in a certificate, the algorithm is already in there right.

G

P

Like my application doesn't necessarily have to give me an aggravatin just because it gives me a certificate and also maybe I'm a client, maybe I don't have my own certificate and then I don't have to give my certificate to like the API right. So they could both be optional depending on whether I'm a server or a client and TLS for example.

P

So this should probably be optional and then another suggestion was to sort of do more sanity check for this pre connection and endpoint configuration that we are getting so, for example, we could check if at least one endpoint has been specified in this JSON file right because either it's a client or a server either needs a local or a remote endpoint, and we could check that and we could also check if there's transport properties and there that exclude each other.

P

But if we don't do that, then our implementation should throw an error that those properties exclude each other or something like that. So again, what the yang mother gives us is that we have the pre connection at the endpoint sort of all in the same file specified, and we can do sanity checks on them first and then we can throw those files into the implementation and see what the implementation does with it. And hopefully my tips does a similar thing.

P

With the with the young file, then, for example, Apple implementation does so that's the basic idea. Also we could add profiles to the yang model, but I guess we would have to agree on profiles first right. So two really interesting points that came up in the hackathon was first, the yang model includes an interface type and I. Remember the discussion we had on interface type so days in a yenna, AF type yang module, which contains lots and lots of different link types.

P

So this 802 11 is in there I found it I'm, not sure I actually found a different cellular like links, but I, guess they probably also in there and then there's like hundreds of different link types that I don't really know, but right now, the yang model that Jake wrote import sort of those link types. So you can like say: I require Wi-Fi and then you're using this and in our API draft.

P

We are not pointing to any specific registry of different link types or different interface types, but we leave it up as implementation specific, so it could just be a string saying Wi-Fi or like an enum or something so I was just wondering like do we still want this or I, don't know just found it interesting, because Jake just used the module right so and the other thing which we maybe really want is that we could also model our output or essentially what we get from the taps implementation.

P

So, for example, we get a TCP connection with a specific remote and local endpoint and over an interface, and maybe, if we model this this connection stage that we get as an output, then we have a portable input, which is a pre connection and endpoint configuration and we might have also in portable output.

P

That is the connection that we got maybe or just the protocol that we got, and then we could test whether we given a certain input, whether our implementation produces the expected output, and if both of these are portable, then we could run essentially a similar tests on different implementations and portability and, like checking that this is actually valid or invalid input might be something that becomes easier with yang, because otherwise we would probably have to check it in some other way, but also maybe not, and so this is what I was wondering, whether there's any kind of like interoperability, portability tests that we can define and then also, of course, for testing.

P

We might want some tests whether or implementation satisfies the API contract. So we've been talking a lot about them different different issues that came up when implementing, and maybe, if I do this and with my application return me one sent event or multiple or something like that, and we could put those into test cases and then it would be easier for, for example, two different implementations to make sure they are all doing the same thing and the correct thing. So those are the ideas that I had that I mean.

F

V

Is actually where the profiles.

F

Idea could go should go right is this is really big part of that very sorry, but then the other point regarding testing. This is something that we discussed at the hackathon them.

F

So maybe, if other people have thoughts on this too, if we want to check the output of what the tap system ends up doing basically, but we give it so we can either have you know essentially a standard way in which all the systems export what they chose to do, but that may be a little tricky, because when we have more heuristics we'll do different orderings will be hard to validate.

F

The other alternative is to essentially have another big molar, whatever configuration for a server and go through in pairing or turning off parts of the server, so you know make the server only listen on one address or address family, or only one protocol, or something like that and validate that the client is always able to do some racing that ends up connecting you, don't necessarily care about the order as much as we do. The end result that we are still resilient to. However, it works. So that's another approach: okay, yeah.

P

So that would already be possible with the current yang model. I think we have one yang for the server one thing for the client we sort of let them do their thing, and then we see what the output is.

I

Listening to you that I don't want for us because there's a new gang one is that just a different way to implement profile.

X

P

So did another idea that we had to model not sure why it's not on the slides, but we could also model that a given transport protocol implements reliability check implements order check like this kind of thing right, so we could add that to the model as well. I'm, not sure. If that's what you mean by profiles.

I

A

Believe you're just describing a way of describing profiles, not that we don't need profiles, you're, just saying that you could describe.

I

Them using a I actually because you can just do it if it's a configuration fight right, that's what we're kind of talking, but it doesn't have to be a configuration fight. It's a configure set of parameters for configuration, I thought.

A

The point of the chart, the point of profiles, was to help applications request useful sets of behaviors, so what she is coming up with descriptions of useful sets of behaviors in doing her testing, writing that stuff down and making it available to applications developers make makes it so they don't have to do that same figuring out that she's doing right, I thought! That's the point of profiles.

I

A

Absolutely I do.

I

A

A minion in a trap, so people know and.

P

Sorry, but no I do not think it is a reasonable expectation for like an arbitrary iOS developer, to learn how to write a yang or how to use a yang model. So I see those as completely separate points. So this is for me for testing and like me and Knox, and she can use it. Perhaps other people can also use it, but like an arbitrary like application developer, we won't ask them to use yang right.

Q

Fine, like model models more than just the profile from transfer properties right. You move the endpoints and things like that, so you would have to have assistant if you just want the angle for the endpoint and right now would have to change, and you would have to have separate models for the endpoints and model for the transfer properties and so on.

Q

G

You would have.

Q

P

Could model the profile and using the yang model.

P

A

W

A

Zero minutes left also you're now on.

N

Your own carry on.

N

M

So I I guess I haven't clarified question like are you suggesting that we have profiles in the yang model, but also define the profiles in terms of the features that they implement? Or are you suggesting that we do not have profiles and instead only have the features, and you define all of those in a second I- think that that would make the yang models less useful.

M

In my opinion, just because part of the point is that they're relatively simple to edit that looking at them in a way that's similar to looking at the source code, at least in my mind, part of what I have to to do is that you, edit it encounter the way you edit the source code, but it's easy right, but it's, but it would working in several different locations and so like the same reasons that it's easier for the user to to use a profile, instead of using all of the individual emanate an application developer.

M

The same reason that it's easier for an application developer to use a profile instead of using all the values, I, think it's easier to define a profile for the application to specify a profile for the application developer. There is to the foreknowledge, or maybe there's an editor, the egg model that would make it reasonable to do that, um but I. It's not immediately apparent to me what that would. Okay.

P

I suggest we figure out whether we want profiles and the API draft or appendix or whatever before we discuss further like where it goes.

A

Are you, can you say.

B

A

Are missing goodness? Oh you're done! Okay! Well! Thank you. Thank you. Everybody Oh before people leave the room I'm sorry I would just like to propose that we do a virtual interim in September. The anybody have a real problem with that we can work out the dates online. Okay, I see some heads nodding and thumbs up. I, don't see anybody saying that's a really bad idea: okay, thanks everybody thanks to Cory for taking notes and for Theresa for Jabbar scribing and we'll see you online.