Internet Engineering Task Force 101, 23 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-MMUSIC-20180323-0930

Description

MMUSIC meeting session at IETF101
2018/03/23 0930

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

A

So good morning, everyone welcome.

B

To the EM music session here at 101, I am beau Berman, and this is my co-chair Fleming and resin on the screen. You have the ietf note. Well, should you not have seen it before or not ready? We strongly suggest you do so.

B

Did anyone not sign the blue sheets.

B

We have one note taker, Ronny Evan: do we have anyone able to join the general.

B

Jonathan is coming in the room, Jonathan.

C

Would you mind getting.

B

In the jabber room for us, thank you.

B

When you speak, please use the microphone and state your name and for the percentage we have a nice pink square up here.

B

Itf is dependent on good document review review and we ask you to please review documents in your own working group and also at least one other document from another working group.

B

This is today's agenda. It's reasonably short: we have two documents being discussed today. It's the session description protocol. There 4566 miss a few open issues and the short presentation on status for the SDP offer answer procedures for ice. Anyone wishing to bash that at Ajanta.

B

So for the working group status, we have no published RFC's since last meeting, but we have quite a few in the RFC editor queue. I believe many of them are have interdependencies, so expect many to be applied republished, as once at once. We have one draft in ITF last call until lost of March, and we have two drafts. The bundled negotiation and the trickle I sip in is G review. Currently, the SDP simulcast is publication requested.

B

We have no drafts waiting for write-up, but we have two drafts in working group consensus. That's the RTC web data channel STP negotiation, where we have a few comments and that's the same for the 4566 base. A few comments, that's still to be addressed.

B

The ICP document is and working group last call and there we have some Shepherd and review comments. Just as the previous two documents.

C

Only Evan I didn't see any any message on the data channel is the PNG did I miss something because I'm don't understand.

B

The status of that the data channel is deepening yeah.

B

D

Believe the author posted a new version.

C

B

Had a few comments based on the Shepards review and other than that, I was.

D

Not aware anything, was it Yamazaki, one that.

B

Was just posted.

E

There was us rpm MSRP, one.

B

Was just posted yeah.

C

Okay, I'll check it. I'm, not I thought I didn't have any work on that. That's why I'm confused to see that you mentioned that there's something I have to do if I remember.

B

Your your comment correctly, you answered that those comments would be addressed, but we'll fix that.

B

We have no new work items, we have three drafts that are not on the agenda or already covered. We have a new author for the MSRP usage for the data channel that was recently updated.

B

We have the previous milestone for the opportunistic negotiation draft, which was extensively discussed among the 80s, and the decision was there that they're related draft insipid brandy would be continued and this one will no longer be needed, so we have also dropped the milestone for that one, and the last draft is the P UK s that needs review.

D

Yeah and actually I know a Martin who was one of the authors of this draft. He was actively soliciting feedback. So could we get some volunteers to review the draft.

D

Don't all speak at once: no, no.

D

F

D

So Martin who's, one of the co-authors of this draft, had asked unknown key share. He has asked for feedback on the draft, he's not aware of any open issues, but he would like more review, so he was asking if we could find somebody to help review with the draft. So that is the request. Here. Is anybody volunteering to review this draft.

G

D

Thank You Jonathan. Anybody else take your mark.

D

All right, thank you guys.

B

And finally, we had one as the P Directorate and the science desolated expert, your review in the negotiating human language in the sim working group.

B

A follow-up on this slide that we had presented before this is the table with the RTC web dependencies that we have hearing and music it's starting to look pretty good. We have number of drafts that are in RFC editors q. Already, as you saw previously, we have the bundle in 9sd review. We have simulcast publication requested.

B

The rid is in ITF last call, and there is the trickle I season is G review and the only one that is not submitted for publication has working group last call and it's with a few comments ice if STP- and that is also here on the agenda today-.

D

Anybody have any comments on anything if not Ally Europe next.

H

Okay, we have been working on this SDP revision for some time, just a few minor issues are remaining. Hopefully this went through the Cherry weave and we got some comments from Flemming I already addressed most of them by the help of some people in the list and then some some of my quarters.

H

But there are a couple of still remaining ones and then we would like to go over them today, hopefully close them, and then you know, I can push another division and then maybe we can go for publication quest so number three I'm using the issue numbers that I posted in the list just to be in sync. So the comment says we have a say text in section five point: nine about the time zone stuff.

H

You know the text wasn't really clear which time zone it was referring to. It turns out that it is the UTC, but I mean there is another field called the Z equals field, which is the time zone adjustment? So if it is, if it's always UTC there may be, do we need an adjustment field in the first place? That was a comment, and maybe someone who has been familiar with STP for a much longer time than I am might be able to answer this question.

I

The time zone adjustments there for daylight savings time, they're there for announced sap sessions way where the there's a specified time for the session, and it spends daylight savings time- is to show you when the daylight savings time adjustments happen.

G

John Donne, together time zone adjustments are specifically for repeating sessions, so this is these. These are the initial session in UTC, repeating sessions which repeat like once a day you have to do the daylight savings time. It's a primitive and semi broken version of what the vcalendar did in much greater detail later, because it's actually a harder problem on this, but yeah that the idea is that this is especially cuz. This is for repeating conferences in this bag. Right.

I

Yes, the way it was implemented was this seminar repeats once a week at one o'clock and well daylight savings. Her tiny changes in the middle there for calendar a different time. Okay,.

H

Looks like it's gonna stay there.

H

Okay, next white, that was easy. Okay issue number: four: we have the P time, IMAX, P time values. We decided in one of the earlier meetings to make these non integers floating numbers and their fractional values.

H

So that was a great in a meeting some time ago, but now I don't see Magnus in the room, but he made a recommendation on the list saying that we should leave the PT I'm a max beta, alias in that equals, if I, if I, if the MP lines and duplicate to use on media stream level- and you know nobody really got back to Magnus on that recommendation on the list and I wanted to bring this up here in case anybody who's. A comment on this.

B

Have a comment from hope.

J

I'm fine with deprecating it, but we still need to put something in this index because if we're gonna deprecated it so I think we still have to answer the question one way or another.

D

Fleming and rayna's individual I'm not sure exactly understand what it is that Magnus recommends, but if you're talking about deprecating, these I'm not sure that's a good idea, because there are other people that are using them today. I know that much I think.

H

Mac knows his motivation was you know there could be multiple? You know P time or max P time values for for the for the media. That is using the same specific payload type number, and then you know it would really indicate anything significant. So there could be multiple media types under that different P time values under that payload type number.

D

Yeah I mean I, think the limitations of Keaton and max Pete hammer well understood, but that doesn't mean that it's safe to deprecated them because, like I said there are people that are using them. For you know all the perhaps wrong reasons, but that's all that there was.

I

Colin Perkins, you mean different P type numbers for an EM line, even for a payload type. Number yeah, I. Think I agree. Why me I, don't think it makes sense to deprecated this. It works perfectly well for a large number of use cases through and it has limitations, and we should probably document the limitations but and possibly recommend the new deployments would do something else, but yeah it solves the problem for many cases and I think I think we have to keep it.

I

H

Thank you pit and we just came out the shortcomings. All right.

J

You know we still haven't answered yeah, we're still I mean the original question was you know somebody raised the question of whether this ought to allow fractional values or not, hopefully,.

H

We make this decision sometime, you know, ATF, 92, I, agree.

J

H

J

Just say: yeah, it's okay, the way it is but I mean I, think somebody raised the issue, so I think we need to respond to them.

J

H

I think the initial comment came from Fleming saying that he always thought these numbers were integers, but.

D

Yeah, this is really a question for implement this more than anything right, yeah that that was my assumption and they used to be integers. If, if that's not a universally shared assumption, then you know I find if it is then again, I think we have to be careful with changing things in a non backwards compatible matter, especially if we're recommending not really to use this right, except for backwards compatibility and legacy issues.

J

My memory might not be exactly right that my recollection is that in 4566 this just said it should be a number. You know in text, and there was no syntax and it didn't say whether I'm just gives news yeah, whether it'll of fractions or not so I was.

K

J

The practice was in the process of trying to put some syntax in for it that the question came up and at the time which is like a couple of years ago, you know I think we I couldn't find a full history, but but we discussed it and decided that we thought maybe you ought to have fractions in it, and so we ended up with syntax and fractions right.

D

So let me just ask the question: I mean more generally in the room. You know what a people's opinion you know, experience, implementation, etcetera.

I

Okay, :, so I have a hazy recollection. We added it because there was a codec that needed it, but then I went and looked and couldn't find one, but there are lots of payload formats and maybe I missed it.

H

He said if the number will be an integer, we will just leave it as an integer in the P time or max P time le. But if there's a need for fractional values, we will support it. That's what we said at the time and.

G

Jonathan I mean Opus can do two-and-a-half millisecond decisions which is needed for very hard real-time encoding. So.

J

Okay, so we got a use case, yeah.

D

Flowing and so I mean Olli I think what you just said: I mean that text I think makes perfect sense right, because that gives you the best of both worlds, shouldn't break anything that doesn't need it and if something does well, obviously it would support it. Okay, all right.

H

H

Issue number seven, and this is section eight, so you know Fleming at this comment. Why is the existing registration to 37:11 not used to? Why don't we just remove it from here I.

H

Honestly didn't understand this comment very well, but I mean why? Why does it hurt to have it here.

D

So as an individual I can I don't know if it hurts, it was more question of. Is this what it should be referencing in the Ayana registry, or should it be referencing 37:11? I.

I

Mean the number is that the reference is in here, because someone complained about it. Last time we were. If this document- okay, okay I, mean we, we need to list the protocol, the the protocols and whether they're I on a registry references. This document or 37:11 I mean it. The I on a registry should probably reference 57:11 I, don't think it does any harm. If this says this is a legal value, I mean. If we're going to list the values we should list all of them right.

I

They say as a PPF and a p PF and all of those well, which is trivial to do great.

D

But if I recall correctly, of course, I don't remember the section numbers offhand was this in the ini, ini registration section is right, so I think there is an existing registration, 237 11 and use you're, suggesting changing that now: 245 66 bills, no I'm, not.

I

Paying a registry all.

D

The text is the.

I

D

I

Just lists the values which are in the registry, I think and references the documents. So we are saying it is.

H

It's not really saying register this under this registry right, that's I,.

I

Know this document is fully in the registry in the registry, as reference for defining some names that refer to some existing profiles.

D

I

This document should probably list all of the things which go in there in that registry and say you know. The values in this registry are at EPA VP at EPA, VP, FSA, VPSA, vpf, UDP, whatever it is and lists the references for all of those, and the registry should be made to match these listing that the legal values for the prototype field, okay,.

H

And then I suppose so we should put did not die in a editor saying that you know you should really make sure that the table the registry is up to date with all these lipsticks.

I

I mean, if you put put it in here, then the registry will be made up to date when I know this.

J

B

Holding the key yeah.

J

I think I, disagree, I mean what needs to be here. Is instructions Diana to register things that aren't already in the registry from something else and I mean so like. If the registry currently refers to 4566, then we probably ought to have something in here that I mean we need to have something in here that refer yeah.

J

You know that re-register is it since we don't want the registry to continue to reference 4566, but things that are already in the registry, because they've been registered by some other RFC I, don't see, I mean why putting them in here is helpful.

J

This makes it more complicated, for instance, if this, if, if someone were to to Rev 37:11 and and therefore its replacement changed their ego had a new ini registered in consideration section the change the registry to point it to it.

J

Then then we just have a conflict with this document.

I

So Colin Perkins I actually went to read the registry, so the registry, the only thing that the registry has pointing to four five six six RTP AVP in and UDP, which seems like the right thing to do the rest, all reference- and there are actually very many of them. Yeah.

D

I

They all reference over the appropriate other documents. So, having read that I think the right thing to do that they'd likely agree with Paul and take back what I said before this should just mention RTP, AVP and UDP and say there are other values: go see the registry? Okay, what this should? Probably what I think this is probably doing is saying what goes in the registry, so we should make sure it's clear about. You know what what value you need and which I think it is. It just says you need the name and the reference.

I

Okay. Okay, there are many more of these than I realized we'd registered.

C

So, just for my note, I understand that to keep like this and to head that way, the reference to the registry for the others I mean that's just just list this RTP AVP and the European, and and is everything.

H

To do we remove the security P from here, and then we say there are out of the area that into the registry, and this is what goes into okay, thanks, like at the same section, okay, a similar comment for transport protocols. We have an existing registration for a UDP TL, which references t-38 and the Fleming says it should refer to a 73, 45 and I just checked this yesterday. I think that's a correct statement comment and then should I just put it not for editor to.

I

Fix this is that reference to UT PTL made the registration fee TTL made by this document, or is it just no.

L

I

Just talk to the the INR getting to fix it, so the chairs should talk to I, honor and say. Look, look was a mistake here. Please fix it. Okay, okay,.

H

So that's an action item for you, I.

J

Don't have the answer in front of me: I yeah. Is this saying that RFC 73 45 has a I an a consideration section? The hedgers registers is the definition for 40 38.

H

No, no, the existing registration has UDP TL, which seems and Fleming says this court in correct. It should rather referred to as chapter 345 and the the action item here is, for you know, Fleming to contact ima and say you know you shall fix the Australia reference, so this really has nothing to do with our pissed raft. I.

J

Agree, it has done to do with our draft.

J

I guess my question is: does if the references but yeah.

D

Paul surrender.

J

It it does. 73 45 have anionic consideration section that the register is itself. If the register is UT PTL pointing to itself it.

D

G

No I just looked at it only it's only Jonathan, since 73 45 is only UDP. Gl / DTLS, not Roy, UT PTL. As far as I can tell okay.

H

Then, who does the UDP tale in the first place? I don't know. Okay, maybe.

G

G

H

Anyway, people they will probably get this fixed one way or another. There's a nerve well,.

D

But III think I mean the comment from Jonathan right is: is correct, right, seventy three, forty five, those actually did not register UDP TL. It registers it over TLS, which is a different thing.

D

So the initial reason for the comment was that there is a requirement here saying that you must reference an RFC, and here we have a registration that does not. You know, maybe we'll just ignore that and say you know whatever. That would be the easiest way of dealing with that. We.

F

Can follow up and run that down, but it doesn't seem to impact this document. No.

J

Wouldn't what I mean? Maybe it's the right answer, but wouldn't wouldn't I mean if this document remains like this, then the only way to really fix the thing it sounds like if, if currently, the only definition for UT BTL isn't is, is BFT 38, then wouldn't it require someone to submit an RC the references to 38 that that there, the registry could reference.

G

J

G

You know we need to choose. One is it affects us document is because of the this Ayane registry requirement and basically just edit this report. This registry doesn't allow registrations by IT new documents, but we've done it anyway. So maybe we should change the and I'm not exactly sure how we should word this, because we don't want this to be just specification required or something like that, but we don't or maybe we should just say we're: okay, we're grandfather, a t-38 and just tell I Anna but I mean I. Don't know that docking.

G

You needs to say that or just Ellie and I guess we're grandfathering that whatever.

I

Comp against that there's an RFC somewhere that gives guidelines for writing. Ionic considerations, and it has some suggested wordings for this sort of thing and I believe one of them is a standard. A standard produced by recognized standards, body and they've got some suggested words for how to describe that. If we want to generalize it so.

H

Don't use so far as either specification.

I

Required or RFC to quark I'm sure that our others ask I honor and they will suggest appropriate wording. Okay, they've done this. If you want to generalize it that way and.

H

I relocate you, you know, reduce the requirement from an RFC requirement to like a specification required by an in recognized organization. Are we okay with this.

D

Microphone please.

G

Jonathan I was saying: I'd be more inclined to grandfather. T-38 then give the IDU blanket permission to register these things going forward. I I will decorate.

H

D

Mean as an individual I agree with that as well.

C

D

I think there is.

H

D

I think the suggestion right now is that we will grandfather in c38 and that's it and we will keep the requirement as it is arrives.

H

D

It's already in there so.

H

All right next slide, please, okay, issue number 8! This is the media format section. So this was a comment from Flemming and Paul.

H

Where are these registrations to be done by any instructions and actual location of the corresponding registries are unclear, so I mean there's a registry, but nobody really seems to have big clear instructions for this registry. So what do we do with that? Now? Our RFC.

I

3 5 5 5 describes had to do this right, but this is only for RTP for the media formats.

I

So that's the okay, so I mean for the RTP case. It says you use the media type registration, which is the mine that are my media type registry work. An RFC, 3550 5, describes the registration processes and should possibly be cite it ok and for the rest, it specifies how to do it, for UDP should be registered of a protocols cutting the rules of the proto spec.

I

So it depends on the proto that's being described so for RTP, it's RFC, 3550, five, the UDP it's what's written in here, for anything else depends what that proton Pro is okay. Okay, we should probably make that clear.

D

In the silicon Colin coming question, for you do we need do we need additional specification around I mean how are those registrations for those other protocols done? Do we need to require that somebody has to write procedures for it or I mean right now it seems very open right. That was the issue. Not only not clear I mean.

I

It is very open, but that's because it depends on what the other protocol is. Okay,.

D

I

It basically says if you're, using something other than RTP or UDP here, I mean if you use flute, for example, then the flute spec should specify how you do the registration I've types for for it, and if that isn't clear, we should clarify that the wording, but it is, it is intentionally very open because the the namespace depends on the protocol. I.

D

Think I think it's fine that it's open but I think a little bit more guidance than around. How do you restrict that openness once you actually have a particular specification? Would.

I

Be helpful, yeah I mean it may make sense to put in something that says you know the proto value defines the namespace or whatever protocol is defined. You need to need to specify how that namespace is managed. I.

J

Almost changed my mind bagger, so it's come in anyway. So it is clear, then, that that the namespace is definitely governed by the proto and there's no need for uniqueness. The cross proto's, yes, yeah, I'm good.

G

Yeah and I think basically, this is a requirement. Jonathan acquirement on the RFC is we. The previous slide was talking about. Basically, when you, when you register a proto, one of the things that has to specify is what the media formats me and how they're registered good.

I

Yep confidence I mean I, think historically, the only one of these for which we had any sort of well-defined policy was RTP and it's basically the hailer historical reasons and I mean if it's Harold walked in. Just as we started this discussion, and we had a very, very long argument about media types and ITP many years ago, I'm sure he recalls it took a long time to get there. And at least some of the ambiguity is due to the the nature of the discussion of the time.

D

So for the note taker the we agree that we are leaving it more or less the way it is right now, but we will tighten up the specification to say if you have new prototypes, then I think Jonathan had some good text. Suggestion basically saying that that new proto needs to come up with procedures for how you manage the media format namespace under that proton.

D

I

I mean I think if we wanted to tighten it up, we could say for anything other than RTP and UDP you might you know the new proto must describe the registration policy.

D

Okay, so for the note taker you got it.

C

Must specify Alistair.

C

Must define the registration for media formats names.

H

All right is it the last light: okay, one more okay, the CT and a s so.

H

My of your comments.

H

Should be max, attributes is going to be in RFC sooner than our draft, so it should be rather just let it go with that draft, or should we should we ask I need to refer to that RFC actually, or should we should we ask you to refer to our draft.

D

Clapping and raise, and so I mean I- think it should point to forty five sixty six bits, because you are changing the definitions, right, you're, updating those right. So that's why I think the registration should be updated accordingly,.

H

New objections to that.

H

Paul, are you okay with this as well, I think near the comment earlier, if I remember correctly,.

J

What am I all right, I, actually don't remember if I, if I had a comment, I, don't remember it so yeah, I I, don't have a position in this one. Okay,.

H

J

Today, too,.

G

Early in the morning, something.

J

G

I, don't remember really year.

J

G

Was a MUX attributes so um all right we have, we added MUX, attribute stuff to this document or not I. Don't.

H

Think so right! No actually you know we are updating a couple of registries and then we added a column for that right. So so.

G

The Kerner so I had so I Anna updated these currently to add, the monks have to be its reference, because.

G

That's active: it's extended the definitions right.

G

Right well, why did the registration change.

C

G

Yeah so I mean so my question is: do we still need the reference to monk's attributes to refer to what the MUX advocates draft did, so that the IANA graph should refer to Perdition six, miss and amongst that MUX attributes or just refer to fundraising, C's expense, isn't in question and clearly the fort of I think you think you have to get up into the best. The question has read: the MUX attributes part still be there as well and I. Don't remember exactly what the MUX attributes registration did enough to know.

C

C

Don't remember this stuff. Did the max attribute document already strange? The registration did you do. A neurologist I should just put the text that what you should doing this, what type it is order, just I I, don't recall it and I'll have to go check on that. Okay, so I didn't think they did registration either just lunch, and what is the policy for for it?.

D

Well, they rework the registry format, but I don't recall if they also changed any other registrations.

H

Mac said to be strapped, it's a column for each attribute that says median accession only bought.

C

Meat, yes, yeah.

H

C

That but the question was: did they just go and update every registry that isn't it that's specified in the Dakin, because they have a lot at least of all these attributes that they provide input about I, don't know if they change the register for that for neutral registration? You must have this new definition in the registry, but I, don't know I don't know so. The question is: if now, that you're doing a registry, should you update the registry accordingly tools to specify the max attribute, also as part of the registration?

C

If you are changing the registration of this of this value,.

C

H

Does that mean there are, any changes should have been already implemented.

D

Believe so yeah sure.

H

We can just go to the Aria and see what changes they did place today.

H

K

H

The action item is checked. The current register a given that the max attribute is in the RFC editor queue and say you know how they actually changed or replaced registries, and then you know, based on that, we can. We can refine the text over here.

H

Because, by the time we go through the process, those tables are gonna, be refreshed in a way so.

E

K

F

K

You Ronnie.

F

Had been Campbell before you sit down on this one, the open issue: seven got Adam and I looking at the text for the proto registry and if weird it should be, registered and then further down it's well, it can be experimental or informational, but should be standards track, and these are all kind of unenforceable. The way they are or if it makes it over, might make it tough on the expert so just to let you know we're talking about that and we may bring that back up yeah.

F

Obviously, it's been the way it's been for a long time. That's legacy text, but but it's weird.

K

I

That there were a lot of legacy uses of that field at the time 45066 was being done, which is why this text is so weird we may want to clean it up. I, don't know, I suspect. Most of those are gone by now, I.

F

I

The math stuff has disappeared by now. It was a long time ago.

F

In that case, I think the area Adam and I are probably an agreement that the working group should look at fixing that and picking one of the currently defined policies, and if we need some text to grandfather stuff, it's already there. That's fine.

D

All right so for the note taker Ronnie, you got that.

D

All right, Thank, You, Ali mark next.

M

All right, so my guitar I see past EP on this draft.

M

We are not able to make it this morning early and, and so us we met on I met with Zubaz on on Monday, and we had at the time five open issue that we were going to present, but I think on Tuesday sue us met with Krista, who is working on the ice visa and apparently the as I serve or the remaining so many issues, so they are supposed to source, were supposed to publish a new version of ice sdp, and so I asked us to send me a slider which you have here.

M

There is only one once right, so hopefully we will have the new version and and the response on on Krista and flaming reviews soon in meaningless. So I am reading, like like users, loss right, so the next step will be to remove that receive nominations. References remove the generic, isolated residue and simplify clarify the other officer section and at the cheetah. If you have any question of command I will the exam to sue us, but.

M

Any question comment: I can help with I can maybe.

D

This is a clarifying question. Generator PDR versus submitting an updated draft. Is that one of the same or not? No, it's not a PR is a proposition to.

M

Modify the document and publication after that, so.

D

When should we expect an updated document.

M

So, let's go yeah I think you will not see a new version of the document before me and again it's not in my okay.

F

This is a Ben I. Just wanted to remind the room that this is a cluster 238 lynchpin, so I understand people can get work done when they get it done. May seems like a long time. I don't know if I can make any specific recommendation other than I'm a little sad but I guess we do what we can do. Yeah.

M

I I would certainly a volunteer to work with us on this, but I am NOT back in in the US and he'll meet up for so I could not even help on this honor. You know I.

D

Mean I I think I'm. In the chairs point of view, I mean we'll try to contact the authors and see if we can get this expedited.

F

Also, give you a sense of competition, I think this draft and flex back payload flex back or in in a race to see who can be the final linchpin. What's the winning criteria.

L

F

Having the RFC editor frown at you when, at all, when it all comes out at 1finity, your draft fault.

N

C

When they at RFC.

M

All right, I will I will try. I will contact us who has not next week. I am both, but do we have after and see if we can accelerate and at least have a new version need poor appreciate.

F

M

F

Welcome a one one other comment and it's I'm not going to tell people how to do the work, but draft revisions are cheap and often these things are easier to review in the form of a graph. Then in the SPR for some people.

M

Okay, as I said, I reload contacts to us to eat from.

M

Yeah I am a core, so I don't want to be the last in the crystallizer. So, let's see if I can.

M

Well, something you can do that yeah.

N

L

Thank you much.

D

That is it unless anybody else has anything they want to bring up.

D

Alright, thank you, everyone and enjoy the rest of you day.

E