Internet Engineering Task Force Interim Meetings, 26 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-DNSOP-20211026-1400

Description

DNSOP meeting session at IETF
2021/10/26 1400

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

A

All right good morning, so it's a minute after.

A

And we'll we'll keep this short in focus hi, betto beno's here this is I'm tim and welcome to a little interim adidas hop a very specialized one, um we'll start off um suzanne's here as well she's in the middle of some icann week. So um I'm not sure if a warren is here. Okay, so good morning, all um we got the jabber. We got the minute paul's here I was going to take minutes if paul couldn't. um But thank you. If you can um here's our note well about what you say is open.

A

Please pay attention and read this. I'm sure you all have read this reading the list of folks here. I believe they have um so we'll continue. Our agenda is one item we've got today is roy's day um we're calling it. So um it's all about the error reporting- and I know people were questioning this, but it's um he's got some very specific topics he wants to talk about.

A

He wanted to talk about it with implementers um and we thought this is a good way to get all the influencers in the room and just sort of chat about implementations and stuff, like that. So he's got some slides and we're not going to sort of get in his way and we're going to let him run this so um sorry. So there we go it's very straightforward and.

A

That's basically it, but we can um I'm going to stop sharing slides. I think.

B

Thank you, yeah. Let.

A

Benno take over.

B

um Thank you roy. You can run your own slides if you you request, like no.

A

Nope he shares that.

B

Roy you can run your own slides.

A

All right, you've got the you've got the wheel right, please, you know, have.

B

Fun there you go all right, um you can switch on your video. I will switch off my video.

C

I I I believe I can do this without video. I just tried to do that and not consume any bandwidth and not having to have a haircut all right, um hi. Everyone thanks for joining um and- and I really thank you to um to the dns, op chairs and isg- to allow me to do this. um This is about the extended dns error reporting.

C

um The draft is currently in zero zero status. It's about to expire. um I have some updates, but I need to discuss a few points with you.

C

In order to implement the extended dns error reporting, I think it relies heavily on extended dns error to begin with, which is the standard which is rc891.

C

um I saw a discussion recently on matter most in the in the town square, where peter van dyke asked who has implemented what already from extended dns errors and- and he was quite pleasantly surprised- I am quite pleasantly surprised, so I've made a list. I did some additional research and I asked to ask a few implementers where they are with these things, um and I've put them on this slide.

C

So most implementations have it or are coming. Meanwhile, some large deployments also support extended dns errors, so that's on both the authoritative side, for instance, for godaddy, but also the resolver side, for instance, for cloudflare, quad9 and opendns.

C

I'm not sure to what extent they support extended dns errors, but at least they have the capabilities to support it, and what I mean by that is, I don't know if all the errors that are listed in rfc8914 are are supported, but that's not the purpose of this. The purpose of this is to discuss the extended dns error reporting, which is independent from rfc 8914.

C

It's basically reporting the error um to a place that can potentially fix the error all right next slide, so um I've got two main issues. I would like to discuss um peter van dyke of of power. Dns um um explained to me that they're they're, when you have an interaction with a resolver that does q name minimization.

C

It really basically reports a few times the same error for a minimized domain um to a reporting agent, which is an issue um right. I mean because the moment you receive this this this error as as a reporting agent, you don't know which one is actually the broken domain. You could guess, but that's that's a little bit too heuristic, not deterministic.

C

So I have a suggestion to fix that is remember. We have an underscore er label to separate the queue name, the erroneous q name with the agent domain, which is underscore er, and we could actually start with it as well. So now the q name is completely encapsulated and basically everything that comes in that doesn't start with an underscore er.

C

You can just ignore we're open to better suggestions, not just for encapsulation. um If you, if you don't like the underscore er, that's fine. Let's take it to the list. Let's not use precious time here, um but I'd like I'd like to fix the problem of of dealing with qd minimization.

C

What I do not want to do is ask the result for implementation to switch qn minimization off when reporting the error. I think that's too intrusive so and I don't think it's necessary if you can just solve it this way. So that's one and the other thing is signaling extended, dns errors and reporting support.

C

So in the current version of the draft, that's version zero, zero. The resolver must indicate support via an edna zero option and if the resolver has indicated support, then the authoritative server can actually return the edna zero option with the reporting agent domain in its in its option space.

C

Now um I thought that was the nice thing to do right. No unsolicited.

C

C

However, it turns out that some authoritative servers will be turned forward or surveilled if they see an unknown edna zero option and yes, that's a buck, and yes, that's annoying, and yes, that should be fixed if they actually support the indiana zero.

C

But the fact remains that some do, since resolvers cannot yet discriminate between those that support and do not support. They probably need to retry without the edna zero option, which is which is cumbersome, which cost extra delays, etc, etc. So a suggestion is to allow the authoritative server to basically return reporting agent domain unsolicited and, um while that seems a bit spammy, um actually the extended dns errors. Rc8914 already does something like this: when there's an error um it it, it sends this option the ede option. I think that's option 15.

C

it sends it back unsolicited. Basically, it doesn't need the resolver to indicate that it supports extended dns errors. So we we kind of the idea- is to mimic that that kind of thing, um because I understand that results are far more resilient against uh unknown idiozier options.

C

um So I like to go ahead and do this um the idea being that an authoritative server can always send this option and without relying on a resolver indicating support for them.

C

So that's the two main things I wanted to discuss. Then I have one more slide.

C

Basically, not all errors in rxc8914 are equal. Some errors are returned by authoritative servers and I don't think it's needed to actually report this back to the authoritative servers. If a resolver receives one of these errors, so, for instance, you have 14 not ready 15 blocked 20, another authority of 21 not supported those are, um I think, implemented by some authority of servers already um so well. I leave it to the working group without me deciding what to do. What to put in the draft.

C

Should the resolver report these back to the reporting agent, if a reporting agent string is present in a response, so those are typical.

C

Error codes, basically, the authority server can can be brought back.

C

Then you have some errors in the rc-81914 that can only be completed after uh only being concluded after completely resolved after a complete resolving session. So basically what you would normally send back to the client right and that's just basically, there's no reachable authority.

C

So if there's no reasonable authority that actually implies that no authority can be reached. um Are we going to send it back and are we going to send it back to whom? um So that's one of these one of these oddities, where um ede extended, dns errors and excellent dns error reporting are not aligned, um then you have, for instance, when you have multiple hours. Let's say you have a single zone, um that's still where all the signatures are expired and does the resolver need to send a report to each individual authority.

C

To each reporting agent and there's some room for optimization here we put that in the draft and then there are some errors that reveal resolver policies such as 16 censored, 17 filtered 18 prohibited. um The reason I mentioned this it's already in extended dns errors that it reveals. We've also resolved a policy um when you basically report that elsewhere um should they be, should they be reported back to a reporting agent? Yes or no, that's a question to the group and um that's actually yeah my last slide.

C

So these three things I would like to discuss. I don't know um um I don't know how to um I'm. Sorry, I'm going to address the first two already in the in version one, and so there will be text in version one which will be out today or tomorrow, um which, which contains the the question that I posted here now in version two which I'll shall submit in a couple of weeks time.

C

We will have the results of the discussion from this dnso working group session and the reason um that I don't do that in one already is that the draft is about to expire, and I don't want to let it let it leap all right. That's it back to the back back back to battle.

B

All right, thank you. Thank you. Roy um well, first uh paul is in the queue and then we can go over the the different issues you brought in. uh You brought up in your presentation, but first I'd like to give the floor to people who have questions immediately after your presentation, paul.

D

Please go in uh hi. This is paul hoffman. So this is not a question on any of the technical stuff, but roy the um the draft submission deadline was yesterday, so you won't be able to do a zero one or a zero two until the meeting week.

D

I'm not sure how you wanna deal with that and that might cause you to want to combine them or such but you're not able to turn in anything. Now.

A

D

A

He can um we can get warren to sort of approve it um or something of that nature. I believe so, but um he can send something to the list. Also.

C

All right, thank you thanks for that paul, and thanks for that tim I will um I will. I will make sure that, whatever I said to the list is also sent to uh warren or to yeah to warn um so that people are aware thanks.

B

Okay, thank you um any other questions after the presentation. Otherwise I suggest we go. We go to the uh to the three issues you want to discuss and ask maybe the implementers about status, what they think yeah so.

B

D

B

E

Okay, um so can you go to the other slide because.

E

Yeah this one so on which errors to report back I mean everything that goes wrong can go wrong, will go wrong and I can totally see an authoritative server kind of not real. I mean and management of an authority so not realizing some of their services and that data so asking if there is anything uh it has to be sent back even if it comes from the authoritative server- and I mean that's what's on on that issue.

C

Yeah, that's a good point.

E

And then on the.

E

C

No sorry what what I I I agree um um if, if anything, the authoritative server reports back to the resolve for the resolver should be brought back to the um agent's domain.

E

And on the last one I mean it is really part of the resolver policy if he wants to report back that your domain is blocked because I'm filtering it. If I mean I don't think that the rfc should kind of uh I mean um have a kind of say there.

C

All right, that's a good point. Shall I just mimic what says over the these few um errors, um because you need to say something in the security section um which is which is which is basically that some of these some of these errors might reveal something.

F

Hi, uh I'm thinking along the lines of ralph's, because basically the option is not anyway, so the authoritative server can decide for every single response, whether whatever the alternative server is sending back to the resolver should be potentially reported to the reporting agent or not. So I think that, basically what ralph said there is no reason for the rfc to prescribe whatever list of options which should be ignored, because the implementation of the authenticative server can decide specifically for their case.

F

There is no need to prescribe it in rfc, because everyone can do their own decision and if someone you know wants to get reports about zones, they are not authentic, for there is, I think, no reason to prevent the authentic server from sending back the the option with the reporting domain.

F

So I think that we can have a text which actually makes it explicit that the authoritative server is allowed to send or not send the option on a pair answer basis, and then all the rest follows from that. I think.

C

Okay, basically, that means um I can avoid uh discussing individual errors completely, and um but there is a there is a small thing: there there's a fundamental difference between um a resolver not being able to resolve something because it's our response or a resolver not able to send something back, because the entire resolver session is over and sorry for the lack of the right terminology, but basically a resolver determines at one point, um there's an error, and at that point it needs to send something back.

C

So there's a small, a small disjoint that an error happens because of an authoritative server that sends something back or an error. That's happened because all options are depleted. If that makes any sense so do I do I specify something around that in this in this document. Or is it basically, if you notice an error with the authoritative server and something that you normally log about or something that you would normally form an ede about report it back to the um to the reporting agent.

F

Yeah, I can see your point. The problem, basically, is that if we have, if the error is caused by the single message from a single, authoritative server, it's all clear, because the server can decide on the per message basis, whether it should be reported or not.

F

But if we have to retry the query multiple times to multiple alternative servers, then the problem is basically what um reporting agent value we take, because potentially the every single alternative server and every single message can have different value. And then we have to pick one out of n or zero from zero two to one. uh So I think that when, in any case we need a general text not necessarily specific about like policy decisions, whether it's blocked or anything, but we probably need a paragraph or two discussing.

F

How do you pick the reporting domain when you have like n options? And how do you pick one when the resolution fails? Yeah so sorry answer, but I think that we need to consider it and it should be mentioned in the text. Somehow.

C

All right thanks peter I've, noted.

B

uh Paul, please go ahead.

D

Thank you, so uh I think that's an uh an interesting discussion that needs actually more in the text, including possibly a new error. That is it would. I think it would be valued valuable to whoever's, looking through this log on the authoritative side, to know that the client actually tried all of the uh authoritative servers before generating an error. That, to me would be a valuable thing to know and that's not something. I believe that we have in ede.

D

So I think this will take more discussion, but um a fact like that, I think is, uh will um be super useful to somebody who just goes like oh yeah, like if I'm looking in the log, I might say- oh yeah yeah. I know I had a problem then and ignore it. I would be less likely to ignore it. If I saw that the resolver said, but I tried all of your authoritative servers, so just a thought.

C

All right, thanks paul.

G

Hello, I'm mostly responding to better here, so a resolving session might generate 10 or 20 errors, plus a 21st error. That is none of the outer reachable and you may not want to send 20 error reports.

G

You also may sometimes even not want to send the one report you have because you're already busy enough. So perhaps some sampling is in order where error 22, no reachable authority would have some preference over the others and then, if a domain is popular enough and all of the outs are broken in various ways, then over multiple queries to resolvers those various errors will still end up at the agents.

G

Even though a resolver might be randomizing dropping a fuel.

C

Petrol, do you want to respond to that or shall I try to give a response to that.

F

I think it certainly makes sense to have some sampling and also the amount of you know, messages we send out, but I think that it's mostly implementation, specific, very much depends on particular conditions on the reservoir, so I wouldn't be like prescribing everything in the draft. I I lean more to like text, which has says well, don't forget to consider business and this and make you know, decisions appropriate for your use case and implementation, then like prescribing how the sampling should work and stuff like that yeah. I do agree which.

G

Should never be too prescriptive.

C

So peter and peter, um can I um I'll I'll send you some um some some some text um and um it's because you you both of you um actually implement this stuff and- and I don't um so if and and ben, are you as well?

C

um So if I, if I can, send you text and see if you like it and if not just just just mess it up and hammer it down and burn it and then then I'll I'll put whatever we agree on in the document for the rest of the group to to discuss all right. Yeah me perfect.

C

um I I still have the other two, I'm not sure if we're done with this, this with the um extended error reporting itself, sorry with the individual errors itself, but I would like to have some feedback about the um avoiding messing with qna minimization and just and just dump a label in front of it that says underscore er or whatever that needs and the other one is to have unsolicited.

C

Agent domains in authoritative servers.

C

And if, if, if there are silence all the way, which I completely understand, I'm gonna go with the suggestions that are currently on the screen, um so that why the working group has a chance to discuss that on the list. If that's okay with, if no one has any comments.

B

Yeah, so I see that page has suggested it as an implementer. I don't know about other implementers haven't thought about it.

B

All right, no okay, so maybe later on the mailing list. So I understand that um kind of related. So so there are already some proof of concept. Implementations of uh extended error reporting. Is that correct.

C

um Well, I understand from.

C

Yeah, I know you.

B

C

Work there, but I don't want to. I don't want to point it out from william thought. In a in a hackathon, he actually implemented the authoritative side in an nsd implementation as a proof of concept. So it's not part of any any release, but there is a proof of concept and at the time he had that running, so you can actually send it. um You actually can query it and you get back a an agent domain where you can consequently report stuff- um I don't have I I.

C

There is no proof of concept on the resolver side.

B

Okay yeah, so that was indeed why? Okay, thanks should I go ahead? No! No. That was indeed also uh so uh I I I talked with villain indeed, so uh I understand that there was. There is an implementation in nsg. It's still running on the on the chat, but I'm also very curious about indeed the resolver part, but there also you're dependent on the ede implementations.

B

I see on your first slide that there are power. Dns recurser is there already and inbound is in the feature tree, so so the the thing is when implementers will start implementing part of parts of your draft for clarity and uh all these decisions. Is that already clear to them? That's that's kind of the question here to the to the room.

B

C

Well, there's there's something additional. I want to point out the um I. What I would love to do is um is um have a session at maybe not this um hackathon, because that's that's that's too close, basically and and the implementations are too fresh, but maybe the next hackathon and the next itf um to to basically already start working with resolver implementations and authoritative servers to have a test session or a hackathon session around this, and I understand from the list- um and so this this.

C

This is nothing new that quad 9 um um they they um um woody basically already bill. Woodcock um has, as I said, we are going to support this when um when when this is a standard, etcetera, etcetera, so it would be good to who to those who support this, to help me out get a session during a hackathon.

B

Excellent thanks villain, please.

H

Yes, I'm wondering about the returning the reporting agent unsolicited.

H

So what's your intention to do that on every response, or should the authoritative keep state and remember to which these offers returned? The reporting agent name.

C

um That's a very good question: um the idea was every every response. If space allows right, the uh I think yeah go ahead.

H

So uh so you say on your slide that resolvers are more resilient uh against unknown edna zero options, but maybe you could measure that.

H

Perhaps that would be a good hackathon project for the upcoming hackathon.

C

That's a good point. Actually we can. um I I.

H

Measurement or something to send queries to authoritative that returns edns option and solicited.

F

H

So it's not a question, but the suggestion.

C

Yeah yeah, I I I that's a very good suggestion uh and- and I'm sure there's also um you know the um the the the google ad guys that could do that could do this as well I'll I'll I'll talk to matt matt larson he's the co-author of this and she and happens also to be the um head of research um at ican.

C

um So I I'll I'll talk to him. Maybe we can get, and maybe we can get both right and um and joao in in involved in this. I know that joao was on the list on the yes, joe, is participating in the room so I'll reach out to you all separately. If, if, if they're interested in helping me measure this thanks for the suggestion, that's really good.

H

Welcome, that's it.

B

Okay, better, please go ahead.

F

I will react to what willam said because he triggered an alarm in my head and- and the key word was state, because I think that we should try to keep this draft as stateless as possible because as soon as we introduce some sort of caching on any level, I'm I have very bad feeling that we will open a can of worms and introduce some security vulnerabilities, because right now it's kind of easy to reason about the possible like ways to misuse the option, because there is no state.

F

So you can see what happens for that particular query. But as soon as we start tracking um keeping state, it will be much harder because then one forged answer with the agent option. Might you know change the state of the system for a longer period of time? So I think that we should try to avoid state in the protocol as much as possible because nightmare to reason about, and I think it's not needed for the protocol itself- I mean I don't see why it wouldn't work. This way.

C

I I agree um to be fair to willam. um He wasn't suggesting it what he was saying, if you, if you, if you don't do this on all responses, then you need to, then you need to keep some kind of state um and- and I think we all agree that that that it's better to do this and all these sponsors are not doing this. So I'll not do this at all. Instead of keeping state.

B

Okay, thanks just relaying the jammer room, so jau is happy to help you, okay,.

C

uh Fantastic joao thanks I'll I'll talk to you absolutely after that, after the session I'll, send you a meal after the session yeah.

B

Okay, uh paul: please go ahead.

D

So there is a third option, which is that the authoritative server sends out the.

D

Announce the unsolicited announcement randomly that is just as a way of seeding it. I don't think that's a good idea at all, because I think that it is that it is safe to assume if a resolver isn't going to be able to do anything with that information that they will have put it in in the eating zero request.

D

But um it would I mean, as part of the the eventual uh implementation there should be no prohibition on a authoritative server to choose when it uh does unsolicited announcements, it can do them whenever it feels like it doesn't have to do them on all announcements I think ran. You know, like a very interesting experiment, would be two years into this start start doing it randomly and see.

D

If you get more responses, that is, if there are resolvers out there that are somehow behind a broken middle box that is preventing their outgoing request coming, but they can see the incoming going. Okay, great, I can give answers now so again, just let's leave it. Let's leave it optional and not say it must be all or none yes, good point.

C

H

B

H

B

Are we um yeah, um so any other things you want to discuss roy that hasn't been covered yet.

C

um No, no, there isn't the.

C

If anyone knows of any implementation that I haven't yet listed on the first slide, I would love to know about this, because then I can keep track. If I, if I have implementations that support ede, I can actually ask them. Maybe they can support the ede r as well. I'm really sorry about the bad technology. Here I think it's going to be called extended, dns error, reporting or either or something.

B

C

Yeah, I'm I'm not at all into the silly um ietf um acronym game and I'm sure if anyone has a better creativity than I have please go for it.

C

So I have not yet heard any pushback on starting with the underscore er label and if there's no pushback, I'm just going to go ahead with it and then the wider group can discuss it, and this is the third time I'm mentioning it. So this whole should be the last.

B

C

You had an opportunity.

B

I

B

C

I

B

Asking for now.

I

Hello, um there's no pushback, but I do wonder we have to think about uh underscore er labels that may exist in the domain name itself.

I

It is not a prohibited label, so you can have a broken test domain, which is broken, underscore er, open and score er test. Whatever.

C

um That is correct, but I I understand, there's a registry of underscore labels. Maybe we can make use of that registry, I'm not sure if we then be abusing it, but um we could have a look there that wouldn't.

I

Prevent me to create underscore er labels in my name, but.

C

No, but to to be to be fair, I mean what what whatever we choose. um There might be an issue with that um um I mean I I know I know about x and dash dash and and all the other hacks that exist yeah. It needs to be something so I'm happy to discuss this on the list, but what I'm?

C

What I'm trying to get feedback on is the idea of encapsulation right, starting and ending the cue name um with within with with a label, in order to avoid uh the problem introduced by q, name minimizers.

I

Yeah, I think you can do that, but um I'm just pointing out that whenever you encounter the second uh underscore er going from top to bottom, uh you can't be sure yet that you have the full q name and probably there should be some text about that.

C

Yeah yeah good point I'll um I'll put that in.

A

C

A

I was going to just point out to rory. Yes, there is a registry, stefan just put the link in the in the in the chat and we could define something and it's mostly the starting labels right. So um while somebody could have something.fu dot underscore er, it won't start with that. So we could use that. You know that would still just sort of slide through the without a problem. I believe, but yes, so um you should consider that it's not that's.

A

Actually, I was thinking about that and then that's a that's, a very good idea to sort of to sort of lock that name down right, yeah, the application people are all over this registry right. So that was it. Thank you. Roy all right thanks.

C

And thanks stefan for putting it on the on the jabber, sorry putting it on the chat.

C

um I understand um vladimir um had his hand up, but it's now down um and when you announced vladimir, we got my thanks.

C

D

C

I

If I was still in the queue that was an accident.

B

No, um both you and vladimir, were in the queue, so maybe vladimir uh also wants to say something or proposing there. Vladimir please go ahead.

B

D

Have technical problems.

B

B

You can grab, you can grab the microphone if you like.

C

Okay, or maybe put it in the chats.

B

Yeah, of course, yeah: okay yeah, yes, a technical problem, yeah, okay, sorry, sorry, vlad vladimir um tim! You still have raised. Do you want to mention something you have raised your hand?

B

Forgot, put it down.

E

B

B

Okay, uh I'm I'm reading out uh vladimir's comments on on jabber. He said anyway, the null q type might differentiate it enough. That's an argument, but he also will post it to the list and it's minor. Okay.

B

Thanks. um Thank you. If there are no other questions or this points for discussion.

B

I want to wrap up actually I like this a lot it was focused made some progress, starting some discussion.

B

And um well, we I think there are some ideas for the hackathon and also well, if implementations become available with ede, we can also work with implementing extended error reporting, that's good, to hear um yeah. I please continue the discussion on the mailing list, so we can make progress and the the draft was accepted with a great enthusiasm by the working group. So I also expect that we continue to work with great enthusiasm.

B

I think there are no other things to discuss right now: um kind of start, plugging uh the itf 1112.

B

um We are still we have two slots of two hour and one hour and we're open for uh agenda requests. So, after submitting your updated draft, ask for a gender spot or otherwise tim suzanne, or I will ask you to fill an agenda slot um tim suzanne, some other things to share. We will yeah.

A

No, I was going to say: yes, we will actually come find authors and yeah tell them to do stuff. So exactly yeah yeah see really ahead of us. Yeah yeah.

B

Yeah yeah, I think we made good progress in the past uh months with the interims and making progress on the drafts, and we want to continue this well. We want to keep the the.

B

uh I recall that, in the in english, keep things on speed that we make progress and and finish uh especially tim- is really uh the bully here. He really wants to have people uh finish their uh the drafts and.

J

Tim is not a bully, but we would like to keep the momentum going and we have found these to be. You know, from our point of view, really useful, but we also don't want to overload people or have too many meetings. So if you have thoughts on what's the right kind of uh kind of cadence for these things, um you know we like being able to focus on one or two drafts for just an hour rather than the sort of the the schedule we have to maintain during a regular atf meeting.

J

So if you have thoughts on how to keep that how to make that effective, how to make that more effective, you know we'd love to hear from you. Yes,.

A

We like this idea of especially getting implementers in a room, and just letting them kind of you know, talk things out um for an hour that this has been this. This was a great idea, so we're.

D

A

Rory had some plans on this, um so thank you royce or for org you know and organizing the implementers as well. I know there are a bunch.

C

Thanks just like the implementers, not me they did all the work. Thank you.

B

Okay, thank you all and see you in uh oh warren. Please, please speak warren.

K

Yeah, I hope the audio is working yeah.

B

K

Mean I just wanted to say thank you, everyone, for you know we're making really good progress now. um I think these interims have worked really well, um but you know it'd be great if we can keep up this sort of like getting all the documents done, moved out of the way, um keep up, keep up the progress and stuff, and that's it.

A

Yep, because we have people who want more documents to be brought forward, so we're trying to juggle all that and warren's been helping us with that. So thank you.

B

Yeah yeah indeed so people don't stop thinking about problems and proposing new ideas so yeah. We have to keep well this this train going and finish existing work and accepting new work. Thank you.

B

Warren. Sorry, uh of course, I don't mean tim is a bully, he's the nicest person I know so warren volunteered to be the bully. So thank you warren.

B

um Thank you all see you in two weeks and um well send feedback on the mailing list on this session uh contact the chairs, if you want to have a gender time time slot for presenting your draft and and see you. Thank you. Thank you for your time and thanks for all your input, bye.

B