Internet Engineering Task Force 104, 29 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-CORE-20190329-0900

Description

CORE meeting session at IETF104
2019/03/29 0900

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

A

B

C

It is allowed to sit in the front seats. Even if you haven't read all the drafts, it is encouraging you to sit in the front seats. Actually it is.

D

Even if you're just doing your email, you can come sit in the front seat.

C

Okay, so it's Friday I, think by this time most people have read the note. Well, I should mention that this room has a really weird acoustics, so the the chairs will probably be wandering around the room trying to find a spot breaker.

C

They can understand anything yeah, no dwell and all that we have three scheduled blocks on the agenda: core applications, a resource directory and coral and a new idea from from Gentile if we get to it, but we also have accumulated a bit of unscheduled stuff that we will do right after this introduction anything else we need to be doing today.

C

Anything we should not be doing today.

C

Okay, so let's Marco isn't here yet I.

C

Guess you were encouraged to come to the front, not not only other district, this last year the lighting isn't up to snuff. Anyway, let me quickly introduce the topic, so we have had second proposal for a congestion control algorithm for code for an advanced foundation, control everything, and we looked at that- and we generally liked it.

C

But then we got stuck on IPR declaration, which is under data tracker, IPR, 3, 2 to 7, and people looked at that and said: there's not enough information, and so we stopped discussing it at ITA 103 and since the statement has been updated and one of us who alerted the mailing list to that fact. So the declaration has been updated by a statement about the assertion of that patent claim and the claim owner chose to make the patent available for essential parts of an ITF standard.

C

So it's not for information documents, also it's just for Senate strict documents and something that is needed to do this Senate strike document. So far. We we have considered handling congestion, control, algorithms as informational, but I think it's not particularly hard to go for stannis trick yeah and, as is customary for this kind of idea declaration, there is a reciprocity clause so that the license expires. The moment you sue Rahway on on some other patent claim.

C

So it's your classical defensive patent construction, so we like unencumbered stuff, but the ITF often has been able to work with technology that had this, this kind of strings attached to it. The procedures say that it's the job of the working group to decide whether we can continue pursuing this and I don't want to decide it today.

C

I want to get information on whether the working group now things to have sufficient information to make the decision. So is there anything missing to make the decision or do we have all information we need now? I realize congestion. Control already is a fringe issue and people who understand patterns are by definition, fringe people, so maybe a small number of people in this room who even know what what this is about.

C

But if you have an opinion on this, please stated.

C

Okay, I kind of made my opinion known, which is that this is a kind of construction that has been used in other places in the IETF and and has been deemed acceptable, so my opinion would be. We are in a position to make a decision, so we will take this to the list.

C

Michael. Do you want to make a comment.

E

Yeah, mark okay, so actually I'm I'm not intending to make a comment on IPR issues, but the but in case the working group happens to decide to take this part of this document.

E

I'm just wondering how are we able to get enough interest among the people in this working group, given that this is primary mechanism and in an essentially conscious tone, control where the expertise is basically direct, the transport area? So, in my opinion, there should have been more creation with the transport area with cocoa, for example as well, because it basically in the same area. So this is just my slight corn tremor that there is enough interest and energy in this working group to do for this particular document in case yes,.

C

So the next step would be a working reproduction call. The questions which working group should do this work I'm a bit, hesitant to say another work neutral through this work, because this is really our protocol.

C

So far, we have done work in this space paid both on the original congestion control in seven two five two and on the other proposal by trying to pull in the ICC RG and the transport area as much as possible and I think that's just the practice. We should continue all.

E

Right so I'm not proposing that that it's going to be any other variable just just exactly that, but how we kind of collaborate with the other area area. So in this case maybe the CPM or PSV so.

C

For for cocoa Aleksei, even delegated the shepherding, the suicide of the shepherding Familia children to the transport ad and I would expect he would do the same thing again when we finished this okay, so working or adoption call on the list is next normally I would ask the room whether we should do an adoption, but I think you might need some time to weigh this IPR issue. So I think this is better than on the list.

C

C

Where other slides those are gone,.

A

But you would see anything. What are you see.

C

It's acknowledged the promise that the data tracker pages require reloading in weird ways to actually get directly.

C

Made which we won't miss dashwood, yes,.

C

C

Okay, so far for some slightly.

C

The working group we have had a second dispatch discussion about the ad hoc proposal.

C

The the underlying situation is that we have adopted DTR, SS or mandatory German security scheme six years ago, and now we have another security scheme which is called Oscar, but that security scheme needs an authenticated key agreement protocol to really cover the same kind of situations that the DTLS.

C

Environment covers so we have discussed something called ad hoc as one proposal for that, and it has also been discussed in other working groups such as ace, but it never found an official home and both the security area and the art area have the idea of having dispatch working groups which dispatch work, I thought who knew working groups, responsive documents, true and so on, which means that it's not a solitary decision of an area director how to handle work, but there's actually community input on that and secure speech had an interim meeting and extra meeting just to discuss this a couple of weeks ago and the the ADEs have since taking in the results of that interim meeting and are now proposing to spin up a short-term working group to complete and authenticated Huw agreement protocol using ad hoc as the starting document links, are to tow the mailing list.

C

Messages are on on the slides.

C

This is something that that probably fits quite well true to what this workgroup is trying to achieve. But of course, it would be interesting to to hear whether the people in this room think this is a good way to to handle it this.

C

So in the best case, I would like to have something like an interim consensus from this room that I can relate to SEC dispatch. We like this or no. We want to do it in our working group, whatever we want to tell them.

D

Speaking as individual I think, this is a good way to go. I.

C

Didn't do that I think.

F

This is a good way to go.

C

Thank you any other statements and.

G

Beat the founder stock, if you have Oscar I, think I talk is something you should like to use actually, but if it should be in a narrowly scoped version group or that we should do it in ace, I have no opinion. Okay,.

C

Round 2 da I think it's very well fitted for LP one network. So it's a very interesting walk. Okay, so that would be the view of the LP one group on.

H

Akarin I without hats I think it's a good way to go. Yep.

C

So before we have 10 more plus ones, let let me just get a show of hands who thinks this is a good arrangement from the point of view of the covering group.

C

Only the right side of the room well yeah to the left of the aisle but yeah us a to the right of me and who thinks that this working group should state an opinion that another arrangement might be better.

C

Okay, so I will relay that to the SEC dispatch mailing list as the in room consensus of the car working. You understand anything else. You want to do under this item. Okay, 1300.

I

Yeah, it's a very brief update, so we are moving a bit forward on the use of github and I was just wanted to summarize what other groups are using to see where core would like to go basically so in deep, for instance, they're using github for issue tracking instead of the mailing list, but basically the alpha or the editor needs to curate the list and just choose before every idea meeting what to present or what not to present and so on. So they are not using any tagging or anything like that in core.

I

We do have some preliminary tagging, but it's not like. We have a mandatory, well a structure list of tags and then again also we don't have a lot specific discussed tags to be discussed with the working group or any kind of milestone. So there anything like that. But maybe we are a bit step ahead on that and then HTTP, for instance, a bit ahead of us in a sense they have discussed tag. They have all the tags based on topics they use milestones and essentially they work everything there. So I would like to propose.

I

Okay, that's to basically track the document life from the very beginning, individual submission to working, write them RFC, everything on github. So for those who really like email, we could also have email batches. It can be easily configured to send even much email batches every couple of weeks or every week or whenever you want. We could also if people are happy with that, we could assign issues to a specific experts. That really know a particular field, but that means that they would have to check every now and then also we also could assign we could.

I

We could also have milestones on a specific it could be either based on the draft lifetime. You know when we do working about option or working on blast call or specific features or sections and I think also the more important one would be to start using tagging. For instance, we could have the disc a stack if we want to discuss it with the working group and very other tack, so some of the stuff we wouldn't even need to discuss, because this editorial a rat, our some other way of working and then last.

I

This is not supported by the ietf at the moment, but you would make sense, maybe to consider having our own ITF gitlab servers that we can depend on get have only but yeah so, basically and I just finished. We will have some trial with some individual submissions and perhaps also with one working already working group adopted document I'm. Looking for DNA Peaks, not just looking in epics and yeah.

I

J

My comment is on the discussion using it a point, one of the things that Martin talks about in the various you know using github and your favorite working group is the working group has to decide where wants sort of active debate to occur. Whether active debate should occur on the mailing list or in the github issue itself, and either one can be done in the working groups. You decide. Often working groups choose to their sites. A number of working groups choose to say active.

J

You know, debate should happen on the mailing list and summary should happen on the github issue. That's actually the policy of teeth and read to be better at actually enforcing at that, because I just sent out emails. The teeth list this morning basically saying that on one of the issues where I started, seeing some discussion and github and so I think that's a job for this working group to specifically decide that I mean if you're gonna be using github. Where do you want arbitrary responses?

J

You if you want people to be quoting in line other people's things? Where do you want to have that? It sounds like you're proposing to have that in the github issue itself on the mailing list, but I wanted to clarify which thing you were actually proposing: I'm.

I

Proposing I mean so today the facto some of the working group items are discussing the github and there is no so much traffic on the mailing list and this really really necessary some consensus. But the authors tend to work together like that. So I was.

G

I

To maybe formalize it in some way, but of course we cannot force people to do that, so we need to Dave.

C

That's nice why this happening before.

I

C

Go away I'm going to ask people here who have experience with other stos that have picked up co-op, what their view would be which of the alternatives. We have actually would be better for getting participation from those stos.

C

The answer may be. It doesn't make a difference because there's some other obstacle preventing participation or it might be mailing. This is better github issues is better so.

J

I presume your eyes meet like for an ocf perspective. I think it probably wouldn't make a significant difference to OCF. I can say that ocf doesn't currently use github for issue discussion, there's no split ocf from I/o tivity right and I'll. Give you two different answers there. Just because I'm at the mic, ocf uses mailing lists and it uses its own document repository system, that's called copy, neither of which is github.

J

It may use github, for you know, data models or something like that, but not for the actual discussion. Io tivity uses the mailing list and github and it does issue tracking on the mailing list. It doesn't have a good issue. Tracking history, I would say, but it does have github issues and Falvey active discussion to the extent that there is active discussion as on the mailing list and I think you're on that list.

J

But that's the OCS perspective I, don't think it would make a significant difference, but the history is they don't haven't really used issue tracking for the discussion per se. If.

I

I make Anoma, we are also using github for quite some time. The transition was kind of painful at the beginning, because maybe people didn't use it. We can use both at the moment for issue tracking on the for basically even drafting the specification is done in DTaP. Some of the other discussions are on the menu list, but less and less in my opinion, that's why, with them plan.

K

Yeah bill from Tumkur University I'd, like a second. What they've just said, there's a lot of confusion.

J

K

Can actually use github could I propose that we actually come up with a best practices document on the working group, because they, the guidelines, seem to change from working to cookie group and, firstly, I have faced the same problems, getting a discussion going from the mailing list and and passing them into issues.

K

It's not necessarily a trivial thing and being an editor of some documents right now, I I have been using the tagging system and I've actually discovered that it's good idea to use github for more than just issue tracking and and it's a code repository, so we've got continuous integration going on. At the same time, github also offers different kinds of insights where you can actually see the activity on different drafts and it's difficult to know where to draw the line.

K

How far we should go into these issues as individual authors or as a working group document authors so I think, would be really good if you can get some kind of perspex was talking about all of this. So.

I

I thought the reason we would like to do. The trial I mean these are already discussed with Christian and Christian it. So they sorry we want it to be better. Try out see what is the outcome see if it is actually feasible? Maybe I can compile later on some document for it, but it's just experimentation at the moment isn't like we are going to switch everything right now. Okay, but at least to try.

F

Jim shot I have two concerns about discussing issues in github. The first is I, do not know if the IETF policy on archiving of consent of discussions on mailing lists has changed or not. The second is I.

F

Don't always know that I need to go and follow a new project whenever it starts out. So, therefore, I don't ever get find out that that discussions are occurring. If the discussions are occurring, that get up I mean if it is one big project and everything is in the same tracker, the not only have to do it once it is not that hard to follow. If, on the other hand, you have a different project for each document, that means that all sudden I don't actually see discussions, and that always worries me. However,.

I

We have every document in one project and the issue tracker will be insane. You will be a mess of comments from any drafts on any issue and also regarding their storage. So the data we had our own gate lab sorry if I came had their own deep lab. Of course you can dare apply whatever policy that's another plus for using our own ITF gate lab if it would exist.

D

Haidee interrupt the the HTTP Biss working group has handled this by having a separate mailing list set up that an ANA script on github that sends all of this to that mailing list. It's not on the HTTP biz mailing list directly, so it doesn't flood it, but you can always subscribe to this mailing list, this other mailing list or look at its archives. That takes care of the archive problem because it's all archived in IETF and it takes care of the I gotta, go fifteen different projects to go figure out. What's going on.

D

It still may not be your cup of tea, but at least it addresses those issues, and the other thing is that I presume everybody knows. There's a new working group called get to discuss these issues about how we interface with git, and you should definitely participate.

F

There yeah I will say that the SAC home working group solve this issue by subscribing the IETF mailing list as an observer to all the projects which makes things messy in a different way. I.

L

Realized I'm still new, sorry Brendan more in here, I realize I'm still a bit new here, but this does raise the question of accessibility. Github is not and has not always been available to everyone, and that seems to be one of the core things about the IETF, making it available to everyone and github isn't. Sometimes it is, but not always, and we need to be cognizant of that.

I

M

Is another reason why, having.

I

Our own get lab will make a lot of sensors.

C

Okay, we don't really want to second-guess the work that is going on in the braking group and you might as well wait until they have produced more of a result, but the the objective here of this was that maybe as well, we should start our own small, controlled experiment on this to gain some experience, so we can make make a good decision. So this is not about completely swapping the model in which we work, but setting up an experiment and I think your next slide said something about trying this with an individual submission.

C

I was actually going to propose to try this with a resource directory, because the now in the working group last fall in the work new blood scholar phase. Actually there will be a lot of technical issue management that actually is done quite well on github, so I would expect that that handing the regular scholar comments on github would be easier that way. So that would be my suggestion, but I'm certainly interested in hearing what what the main editors think about that I.

N

Can, of course, Baker follow all all all and all four Rd, but there is tagging already there and we I am already moved replicating. The discussion points on the tracker, so would be fine for me.

J

That was Christian, I'm, Dave savor, the respond, the get working group I was there and my understanding is you're, not gonna see a result of that working. If that says, you must do X right that the working group has a bunch of choices, and so I just want to clarify that you shouldn't wait for some answer to come down right, though just here's, a cookbook and your working group choose which of these options, work for you and so I.

J

Don't think, there's any reason that you have to wait for anything from the get working group if anything they're just providing for guidance for get newbies, but if you're already using it, there's no reason I think to wait right. Yeah.

D

This is Barry I, never intended to imply that I was just encouraging people that, if you care and participating.

J

Person summary yeah.

C

I was just interested in the results of the group because having that cookbook would be good and maybe having some tools slightly mahone than than they are right now would also be good, but I also think we can start doing this experiment now. Peter Hong stock.

G

I just wanted to make this down-to-earth survey. Mark I already have problems being explaining the faces to which the document goes with the normal IETF procedure. If you're going to add in the good of FM even more estates, then it becomes very difficult to explain. What's going on so I mean you should be very careful that all this taking follows what goes on in the standard ITF process and that all the others are just alternative and should be used such that it is not to be confused for other people. Yeah.

I

I mean my intention is not to change the IDF process at all, say my stages same steps, so.

C

I think it would be nice to have some some of the HTTP this tooling, that that sends summaries of the github activity to the list every Sunday. So maybe that's something. We should procure to make sure that there is no disconnect there, but I'm also hearing that people would be quite content with having a small, limited experiment on the resource directory completion process. Now, and then we can evaluate that and see whether we widen this experiment.

C

C

You actually have to run to this speaker to understand what anybody says on the microphones, useless.

C

Not my John Michael Stan Michael. Are you online.

C

C

Like do you have speaker privileges, or do we do this using the queue.

C

Okay, it's like 1:00 a.m. in California, so I'm not playing with Mike Leah. So maybe we can just quickly go to to the next option dine link. We want it within touch.

C

Okay, Mike is there, so let's go back to.

B

F

C

You are under at least five layers of wool blankets, but yes, we can you, okay,.

B

Maybe this is a little better.

B

No okay! So go ahead and advance the slide.

B

Okay, so we're.

J

Going to do, which is don't use.

B

A disco and figure out how to handle empty topics topic like time and data lifetimes in some other ways that we're working out and those are specifically the next slide. Please an empty topics that the issue is a topic has been created but not published yet so what does the broker return?

B

So what what me worked out there is that we'll have the response. Wait until there is something published, co-active and observe. That's not really a problem, you get an AK and, and then you know the response: don't have to come back there. There will be some time out possibly, but will happy a the application layer work that out the publisher can always publish an empty payload there. The problem has hubsan, only transmits payloads only representations if you will and content format, so it doesn't really know how to construct an empty payload it.

B

It means the publisher or the topic creator to do that. So that's we're going to keep it simple and write that up and depend on things like accept all and nothing to see here, sort of an aura, multi-part content formats to handle the case more gracefully, but even within ml you can just send a bracket bracket and an empty payload and the the subscriber can understand that is there's nothing there. Yet so I, don't think, there's any issue that we really need to deal with here.

B

Other than write this up this way for empty topic, right I guess we can probably take questions after I get through explaining all of these there's, no one at the queue. Now anyway, we ready okay next slide, please now the lifetime of the topic. We just want to use the thing we owe okay, so the idea is that we would create a query, parameter topic, lifetime TLT, and you can supply that on creation, if you don't supply that it's just a topic slip until you remove them.

B

Basically that when you create a topic, the counter begins to count down and every time you published for the topic or repeat the create operation like we do with our D.

B

That would refresh the counter to the to the value. Of course, with your doing the recreate operation, you can supply a different lifetime value if you want and then, when the counter reaches zero, the topics removed and that that's basically the idea that right next slide, please, okay, data lifetime, we just wanted to handle with Max age, that's already in place and the default would be to just have the Pope's a broker, not return anything in elapsed, 60 second max age on all responses. Oh that's not ideal for all situations, but it's a useful default.

B

Then we want to enable a data lifetime option as well a DLT that when you create a topic, you can have a data lifetime default and that would that would set max age unpublish. So that would basically allow.

B

Publishers to have a max age that was different from 60 seconds. So, if you wanted long live values, you could you could use this and also there's there's some talk of creating a header option that you know just can be used by push notifications. Is that the lifetime of the data they're sending, and so that would be an option also, but I think when the draft vote will well I'll show how we conclude later now. Next slide, please yeah so lifetime of topic. Contents, that's basically what I just said.

B

So the idea of there being max age value of 0, the value is still sent and the cash if it's the cash behavior of the default behavior of is that when Max.

J

B

Of zero, the cash can now use the value, but but not reuse. It I believe it's the way of the way it looks. So if we have a subscriber kind of ending like that same behavior, but that would seem to be reasonable. Like so it's a client library, the client could, for example, signal that the max age of zero and ask the application not to use the value, for example, and then a cache that subscribes to a broker could could just use max age.

B

The way it's used to okay, so here's what he concluded that next slide, so the proposed profile, so I was going to write this stuff up in the draft, but it looks like there's enough here that I didn't get around to it. I wanted to just present what what I'd want to put in. So the idea is the first option for empty topic is that the broker won't respond in topic. Creators are responsible for publishing, empty representations and then we'll give some examples. So this is what I planned it right into the draft right.

M

B

Slide for the topic lifetime and data data lifetime, we'll add the two query: options that default. If you don't supply DLT as just to respond without the max age option and that allows the default on all responses to be 60 seconds. If DLT is included, then the replications are sent with DLT and max age option, and then we read and subscribe sometime after a thing has been published with DLT you get a max age, equal to a dl t minus the the time, basically as as described in RFC 72-52 numbers. Please I'm excited sorry yeah.

B

So if the topic lifetime excluded included, the topic will remove, be removed anytime. There is no published activity or I guess or topic refreshed for a time equal to a topic life sign and when that happens, outstanding subscribers and new requesters will be sent oral force, if not resource not found.

B

So that's basically how we plan to cover it in the draft questions issues. Other ideas: okay, someone getting up yeah.

O

I have two comments. The first one is: could you go to the proposed profile? One.

O

We have been talking a lot about that up, subtopic configuration and I. Think if we have things like publishing an empty representation for a topic, it might say it might make sense to be able to update this representation at a later date. So what one idea could be to split the topic into two coop resources: one configuration resource which exists for the whole lifetime and then a data resource, which is what the publisher has published to and the subscriber subscribe to.

O

And then you could simply say you, you create the configuration resource and but if it does not have content yet the data resource does not exist yet, and it's created when a publisher publishes for the first time- and this would give you this Kurata resource for creating reading, updating and deleting topics topic configurations.

O

My other comment is I think it was on number two.

O

No number three number: two sorry the comet is on next age. When a publisher hasn't published for some time like then the broker hasn't received the publication for 24 hours. Do we really want to say that I can give you a representation now, but it's very likely that you will get an update like in zero seconds, so you shouldn't even try to catch this and I think we need to distinguish between them data life time and the mechanism of keeping the observation alive and not generate needless traffic.

O

Just to try to map the data life time into the max age.

N

Justin I'm, just I, think on the topic of of having those empty representations that could be done a lot more smoothly if at as I understand right now, when a topic is created, all the metadata is is put in there, whether it's I'm part of the link to that that's created for the topic or as as as registration of as options for the creation and I. Think that this could be a very.

N

This metadata could be a very suitable place to indicate that this topic has some kind of Testament last world tombstone whatsoever, um representation that the publisher may use to satisfy observations on that resource, which would align nicely with with metadata on topics that on resources that are not topics, because such metadata could just as well be expressed about any any other resource, and when a client gets that it could look up in the metadata that hey it's not there, but it has a default representation. I can pass on you through the application.

C

Cuz, the woman from the floor when I look at this the proposed profile, one, we seem to be extending the arc HR with long poets now, which may be a good on the thing or no, not a good thing, but I think we should do this very consciously.

C

As Klaus mentioned, there may be situations where we are having the broker not respond immediately to something maybe more efficient, so my ear to form of lung power may actually efficiency improving. But this, of course, could be a situation where a topic has to be created and two days later, the first data is published to it, and then you would finally get the response to the request you send in so I think we have to consider whether that is an evolution of the architecture that we we actually like.

C

The the other observation on the I-th I think it also has already made, but I want to repeat it, because I want to focus on the architecture right now, where it's that here it's nowhere anyway, if a publish needs to include DLT in a lifetime, a query option, then this great option, of course, as part of the UI, and by being that it's also part of the cache key, so that publish doesn't replace any cached instances that might be lying around so having a no cache key get her lifetime option actually is something that might make a lot of sense.

C

Now. Adding options also is impacting the architecture. So again, that's something that we need to think out think about, but it might be useful here and the third observation was already made that maybe having a control resource and the data resource. That might be a good thing, and if I were designing this from scratch, then of course I would make a control resource. That actually is a multi-part call that has both some control structure and potentially optionally.

C

Initial value off of the topic.

N

So, as I understand, currently the kind of control resource is implemented as just using a different content format. We've I think that doing doing something like that has given us a bit of trouble in the resource tracker as well, so having separate resources for metadata and the actual data makes sense and also frees up, have subtopics to actually transport link, link format or similar data, because right now getting the link. Data on the topic means getting the metadata and getting the, and that means you can have actual link formats. Data on the topic.

G

Become a stock now something completely different. We still in turn intend to use the broker as an epoxy for the slippy nodes. It seems to be slowly disappearing. I hope you can still look at the requirements we have ready some time ago and make sure that the power can be used as such.

H

But again on florrum, yes, Oh Peter yeah. It can still be used for that purpose too. There is the read interface exactly for that use case.

H

There's them there's a subscribing the face and reading the face and the reading the face is the classic use case you are referring to so that's still possible and in general, the theme of this update was that we're simplifying a lot of things. So you could use coop client roughly as such, to interact with a a pub/sub program and then, when you do more advanced things like five times and such then you'll have to do a bit more advanced procedures, but the basic functionality would be very simple for any bunny like or client through.

G

My concern is that it is very much concentrated on using observe and there is an action which this proxy use. This mirror server, if you like, where you just do an increment of the state latest status of a topic, is without doing an observe of it or setting the topic.

H

Yes, so we'll be most talking about that interface, which is heavily based on observer, there is also the basic 3d interface, which is essentially the same this except for one bit. You don't enable observe so, but it's it says that the observer part is slightly more complicated because of this data lifetime issues.

C

Okay, I think we have had some great discussion, but not really a conclusion yet and I think marketer can use this and all the pops up. Authors can use this for generating a next version and proposing a solution to those problems, and then the working group can decide whether we're done with us and no. We are not going to get that. We are working with sleeping notes, Time Inc. We are about ten minutes behind schedule.

C

We are behind ten minutes behind the end of the segment already. So you have to do this in minus ten minutes. Please.

K

Okay, hello, so dine link, yeah, that's not very, very much to mention. We actually managed to finish a fairly big chunk of work already and then at the end of February, we had a flurry of activity when we actually had a joint call with the OMA eleven m2m folks, and then the the current draft reflects that. So there were clarifications that were done. We restructured the draft so that we have conditional notification, attributes that can be used with general observe requests, and then that introduces the whole the whole document.

K

And then we change the data types for Eamon and pmax, so there we can support fractional. Second timing: previously they were just integer values and also there was a clarification made about when the notifications will be sent, but only for LT and GT.

K

So right now they they are notifying on all crossings, not just notice up or down. We also had some discussion with the people from the eleven m2n group about the ban attribute and I.

K

Don't really believe it was there anybody in this room from from that meeting, because we were also discussing about some alignment with the elaborate m2m documents regarding the description for the different attributes. So the consensus from that from that meeting I believe if I remember correctly, was that we'll wait for some information from Delaware em folks on if they, if they would like to contribute some text to the document. So that's that's, basically the the major part of it and then the last part was basically about the binding table.

K

So we changed the binding table description so that we have a new new attribute value instead of an interface description, so that led to a small, a small confusion on how we actually do the writing table, because we were not in favor of keeping the post operation, and this is the old. The old example in drop 7, which was about resource collection called B and D, which you can manipulate using a post, cut or delete, but we're still looking on this a little bit so I think we will get this done fairly fairly soon.

K

So right now you discover the the entry point to the running table and then we had. We just have get input we'll have to think about how we do patch and fetch quite soon on that and that's basically it so. The work on the no divisions are completed. Link bindings are completed, so that's just the partial changes that are needed for the binding table, and maybe we get something from the Levitt m2m folks and then we're ready. Oh yeah, that's that's the last light from.

K

Christian just.

N

Analysis I'd like just like to point out that there are, there, should be a made somewhere around the mailing list with some still aankhon unaddressed concerns about particular binding types that were in comprehensive I.

K

Could actually give you because they so loud, could you keep.

N

So there was a comment on which binding types there are and that this should probably not be written out as a comprehensive list and be open to be open to some scenarios that can fit easily with with what's written there, but just list that is a bit too short or maybe should just go away. But there's a comment on the mailing list, at least make sure to follow. Yeah, yeah and.

K

I forgot to add one thing that we also included into the document was basically the use of camión, because there was a confusion. What can you hear me yeah the.

N

K

Sorry source also the use of be mean to clarify which value should be sent when, when teaming expires, so that that's not been clarified in talking also yeah.

C

I have one question: when.

C

K

Think that it should have already been ready now, then, the binding table just needs a bit of work, so discussions microwave. We get this done, maybe the next two weeks three weeks and then I think it should be well. Of course, we've gotta wait with the for. Why wait and when people also, if they want to contribute some text, that's our Hanson moment and they were supposed to contribute to all github issue.

C

So the procedure is we wait for the next version. We do think two things in parallel, which is a chance review and contracting.

C

K

Yeah, that's that's fine! That way all right so.

K

Let's get this one done: I, don't anticipate much I mean it's fairly stable right now, so there's not much else in there. Okay! Next one is I'm, not sure.

A

C

Gonna, be here just.

K

C

So one of the first drafts that we actually did in in this working group like 2012, was core interfaces, and that was an early draft that actually consolidated our ideas about how this was going to work quite well, and actually it has been in an influential draft because it has been taken over by other stos who then adapted reg. They didn't just do what we wrote.

C

They did something better changed so right now, there's actually no literal adoption of this document. Just since, since there were the few recommendations, that kind of have been overtaken by events- and we looked at it and decided, hmm there is some useful text in there and actually turns out that, in particular, the text on collections a would fit into a series of small documents that the research group is about to generate.

C

So this is non normative text that just describes one way of doing things and that would fit with the rest for design document as a parent document. And actually, if you look into the Charter, the Charter mentioned this document as one place where there will be interaction with the research group. So the interaction in this case would be push it over the wall and ask the research group tour to use the good pants.

C

So I just wanted to hear the opinion of the room. I already asked on the mailing list and I think we had one response to that. Any other.

K

As the people who have been working on core interfaces, I think this is a good idea we could so there are basically two paths: I mean it's a very well-written document. It's very small and it's easy to understand. I, believe that at least some ideas would fit very well. We think two things research group, so that's that's a good thing and then the other part is probably yeah, like you say, on, the SDS has overtaken so yeah a.

G

Peter Thomas talk again. I have found this document very useful in the early days when an ad with starfish go up and see how I have the structure documents and how to structure, applications and fantastic desk text for that and with some of the additions I think it should be maintained. I.

C

Think we all agree that during in strong subject line, so it's really about throwing it over the wall and getting it published in a slightly different context.

K

Okay, clarify we and we're not gonna bury it.

C

Yes make it part of a series of fashion answers, yeah, good, so and I hope you will participate in writing those documents.

C

Next resource, like three and twenty five minutes, Dan schedule.

N

Okay, hello and then I'll. Try to make it brief, so resource directory is an is as of test twenty in working group last course, since last Wednesday, we are we've started to receive comments during the working group last call, one of which is an update to the security considerations from class um that should not posing much different difficulties. It's just to help explain basically to give the reader a better impression of of how that would actually of what would be an example of such policies.

N

Lemon noted appointed outed, an outdated reference um where, where we are describing how all this might interact with our DT and SSD, and gave an example based on probably two year old version of our DD n SSD, which doesn't fully fit with TN SSD, so that example would probably just go out, and it would, it was one way of discovering that is not fully fleshed out could still be added if T, an SSD thinks that this is a was all DD.

N

If, if our DD n SSD thinks that this is something that is needed last but not least, I managed to still leave some errors. In the examples that are confusing people and thanks for pointing them out, um I can fix them.

N

So, just to summarize, we have we've had three interrupt events by now and I. Think I've missed two implementations that are work in progress with the last interrupt, but the sequence of events shows that ambiguity have found ambiguities and problems that arise from doing it in practice, with the first interrupts and with the third we've already gone on to experimenting. What more we can do, what extensions we can use, for example, using the choral format to express the content of the resource directory which which cows will later follow up on, because it um we have.

N

We have shown in the interrupt that we can have a registrant register, was link format at resource directory and that resource directory would then expose the information in coral to someone doing a lookup and trying to find resources and find out metadata, and that did work, although of course the format of how we do it. Imprecise will still change, but yeah. That's all at work and I.

N

Think the the working group last call is in in good progress and by the 17th of our April I hope that we can go on with this um questions so far.

K

Bill thanks for the good draft, that's uh I was clarified a lot of things and also thanks for the good discussions we had or the hallway meetings that that uncovered some of the example problems. But but that's that's. Okay! That's another I sort of clarify one thing regarding um so we were discussing this also with Christine. So I just wanted to raise this issue that there is some text in resource directory. That says currently the cardinality of the cardinality of what was this.

N

Nullity of the of the registration base, registration.

K

To the donation base attribute was one and in future you might have multiple base values, and then you refer to the protocol negotiation. So I want to clarify that I, don't really mind if you keep that text in, but there's a very high chance that protocol negotiation is not going to have multiple base values. So that's that's what I wanted to say. So we, you could have base values but the semantics of what we are trying to do. It's a bit different for bass,.

N

Yeah that should drop me that's another case of one of those forward references. It would probably later be that which we should adapt to the car through the kind of state of the art and possibly move out and possibly remove from the documents.

K

Absolutely absolutely so yeah just.

O

K

Indication that we can do it.

N

That way, okay, yep. Thank you.

N

So if there are no more comments, I'd like to move to the second part of the Rd slot, that is a brief report on what I've presented to TQ TRG.

N

Don't you stay I've previously in Landrum's and the resource directory application to this group, and it was then decided that the benefits with tthe, so the the kind of a big picture here is that it is possible with the resource directory to replicate it without doing full application level replication, but rather to have the resource direct to have several resource directories meshed up with each other results from that have been incorporated into the resource directory document profile that that allows those kind of interactions, and that, in my opinion, is something that can go on without impeding work here, and this is basically mainly to notify that this is going on and tthe from now.

N

Peter Peter.

G

Snook if this document goes out, I think some text in the beginning, which tells you what the replication is supposed to serve, which purpose of this pose of hers is very important yeah, because at this moment people have different ideas about applications and they have very different consequences for the protocols you're going to use I I.

N

Think the latest version should have text in there. That lies out a few of the goals which are mainly not being distributing in order to cope with a great load of requests or registrations.

N

Read fate and tolerance to failure and I think there was a third one that I just don't remember out of my head, because it probably is a kind of overlap area, but um I'll make sure that the document will outline why it is done in precise groups.

N

Another thing that was presented over there. That leads us basically over to the to the protocol. Negotiation.

N

Part again is the is the is the kind of is what I started to call the or d-link project that is trying to integrate the whole vision of how how cryptographic identifiers can be used in order to have your eyes that work all across the internet, without necessarily being integrated with the centralized infrastructure that depends on protocol negotiation and alternative transports, and the work on especially attractive transports has been taken up again for within, within the overlap area between this working group went t to TIG, because it turns out that there are many questions that we still need to answer that are not just specify how it works and be done with it, especially when it comes to the topics of your royal icing, which we try to avoid and having a trust model that allows us to switch transfer transports without getting into all kinds of problems about being able to authenticate that this is actually the.

N

This is actually the thing to do. So there is this. There is a there's, a github repository now in which we are kind of pooling minutes. Pooling ideas. I should probably have put the link in there right if you can follow up with the remaining list. So if you're interested in political negotiation and co-op +80, please let us know please watch that repository, because this is something that will eventually become relevant to Corrigan but may in the meantime, be processed into TRG.

N

Just because there's such a wide variety of of how things could actually go, and we don't a very clear way for what yet, but have to do some experimentation as well.

C

O

I would like to talk about coral over in the t2 TRG. We have been working for some time on the constrained restful application, language, coral. There are now a bunch of internet drafts related to that and the first to the constrained resource identifiers and the constrained rest for application language now coming out of this being a research topic and are getting some interest in being used in core applications.

O

And so the idea would be to move these drafts over to Cora and series C power based encoding of your eyes in the same option style that we use in coop.

O

You can see one example here: um it's a your eye that you would normally write as co-op, codons, refresh example.org, : and so on and Siri takes the components of the URI apart and then puts it into AC bore array where each component has an option identifier in front of it, and you can see the CDL notation here and the idea is that we want to allow constraint devices to perform your eye arithmetic in a small amount of code covering all corner cases and doing that correctly.

O

So- and this has been developed as part as coral, but then extracted into a separate draft, because it's not only useful in coral but could also, for example, be used in this N and C bar format or in C of wte. Our insuit manifests, for example,.

O

Then coral itself, if you're familiar with link format, it's basically link format on steroids. It has a data and induction model for building applications. The machines can navigate between resources by following links that we already have the link format, but it can also describe operations on resources by submitting forms. So essentially, the correlate document tells you if you have a quarry representation of a resource. What is it that resource? What can you do with the resource and how does the resource relate to other resources?

O

And it also fixes a bunch of problems that we have an ink format. For example, link format has is very weird rules for generating the link anchor and it's not very extensible, ending format, attributes and coral has comes with the two serialization formats. The primary format is again based on C bar, so it's suitable for constraint devices. A typical coral document can be expressed in a small amount of bytes and can also be processed by constraint device without taking a lot of additional RAM, but because it's so compact, it's very hard to read for humans.

O

So there's a companion, lightweight, texture, serialization format that is used mostly for giving examples.

O

Overall, these two documents, series and coral are so far quite stable, at least in on the concept level. We might want to do some optimization, for example, to compress redundant items in Ybor more efficiently.

O

We had two meetings, this ITF, where we got into some details, created two coral one was the hackathon where we got to do some hacking on Coral there's a no apostle for the texture format, an encoder of the SIBO format for riot less.

O

We created a bunch of examples and look at different use cases and they have some slides on depth upcoming.

O

We looked into thing description, conversion to coral and also worked on an updated eyes and implementation, and on Wednesday we had dedicated site meeting to coral to ours and discuss topics like how could you use series outside of coral, some technical, disc discussions on comparing series?

O

We briefly looked into the conversion between coral and rdf and linked from it and discuss the concept of forms, and also I had a bit of high-level discussion. Are those real hypermedia applications, as envisioned by using coral, actually feasible and also had some discussions related possible working group? Adoption- and so you know, I have very quickly a few examples: how how the text form it looks like you have to imagine that those can be expressed in c bar, very compactly.

O

So what one thing we can do with coil is just use it as a simple replacement for link format. It looks like this and this is an example taken from our c 66 90.

O

We had the hackathon one example called Karstens coffee machine, which is essentially a collection resource of cute coffee orders. So you can create update tree, delete coffee orders, and this is how it would look like in in coral.

O

Here's an example of a thing description convert to coral. The original thing description is shown here. On the left hand side it's a bit longer and if you assume that you're using coop, then the finger scription collapses nicely in these to these very few lines of text and.

O

As one exercise, we extracted some vocabulary from the hip, so definition files and, for example, if you want, you could now use the ipso reusable resource definitions inside your kora based applications.

O

Our conclusion from hackathon and the site meeting was coral rocks and we have tried it for resource discovery and more, and there was even a bit of an interrupt a moment when Christians and gems resource directory implementations caught interoperate using coral I have created a github repository with companion material, so their drafts themselves are a bit low on the example site and these ideas and we create a github repository and there you can find this EDD R and a B and F grammars.

O

The code extracted from the draft test vectors for unit tests and the idea would be to create lots of examples and maybe tutorials and more introduction material inside this github repository. Instead of putting that into the RFC.

O

We also started collecting some open issues on the github repository. There are now ten plus open issues and those actually in a state where they would benefit from working group input and that's no longer just a decision by a single author to resolve those.

O

That was my coral and Siri pitch and hopefully less than five minutes. Thank.

C

You I need the other two minutes to ask a question so, given that we have reached the state that Klaus has reported, is it to the working group adoption here? So we have lots of documents, of course not all of them I, actually something that this group would be working on.

C

So the two documents that we seen the candidates for going into the engineering phase are the coward document itself and the Seri document, which is needed as the URI representation we use inside coral documents, so my question would be: are we ready for adopting these yeah I've seen one thumbs-up?

C

This room is useless for hums, so I will show of hands. What's the number you watch so h9 4.

C

So, who is against our group adoption of these two documents?

C

Okay? So we will report this as in room consensus and verify the consensus of the neighbors, but not do a gradual adoption. Call that just verify that you consensus we already reached here. Thank you. So the final point on the agenda is new work. That Jintao has started on speedy, block-wise strength.

G

Small question about agenda.

P

There's no concern see yes,.

G

Our ddns st has disappeared. Oh you want to resistant. We wrote it well.

C

G

Slide she might.

G

It's okay now about it. Do.

C

You want to quickly.

G

G

Yes, it's going on very nicely. We still want to do some things in to end of July. We have separated out all the automatic conversions and for the service tab. We have defined an ST parameter, which makes things much more clearly and three think we will be done by a year. July.

C

Thank you, okay and I think this is important information and apologize for dropping those slides, and we are looking forward to seeing this happen.

P

Actually, I didn't expect to have the opportunity to present this because lonely, the working groups very tightly scheduled anyway, I create a cup of slice and I always want to keep it very simple.

P

This is a speedy, speedy, co-op lock. Why transform the problem being the kind not in the current space in the corner, see the current is to send continuously requests to the server and using the block option to specify the exact segment. Then there is expected each time. That means we do. We do a lot of round trips there and such a design was a reasonable choice, since the server can be implemented to be a truly stateless and lightweight, but is there some lead and some scenarios that we we can speeding at this?

P

For example, during the firmware update? Well, a large object, a large file is going to below you to the sensor or the the device is going to conduct a critical mission conversation with some server, and the other case is there are cases that the the server is actually more capable than their original co-op assumption, which means that they can be more stateful in handling these.

P

So what we are actually proposing is speeding up blog option called s here and in the speed up option the client can specify the speedy window size there, for example, five here, then the server can send just the five segments to this to the client. Just you in one conversation as to reply in reply, and this it's a little bit more tricky. If, because we put is because the client basically know its requirement and its limitation or is constraint and requirement so, for example, here the client says that means I can receive.

P

I can call five packets in one we ten pass, but actually interface, dividing it to more than five second, so the server we are just as in five segments to a server or to descry and each five segments each speedy window. The client needs to reply with the ACK, and then the server can send more. This can you know speed up the conversation as well as keep the kinds as a constraint device.

P

There are some more details in the draft and I think they're more question to be answered, for example, how to design this. Probably this is now the best way, but I think this is one of the poster boy and that this is just very small fix here. We can have block as speedy Apple here that block s means a speedy block option here, so that you can. The client can inform the server about the speedy window. It would like to use yeah, mmm that's it, and this is anyway, a small fix.

P

Do you have us any interest or any scenarios that can be I.

N

Have two things that I want to point your it mean I, see the use. K I see the use cases I've run into them myself occasionally, but I think this is. This? Could profit from looking into two pieces of to two areas here? First, is using n start greater than one, which is something that was I, think always envisioned to be possible, but not really I'm actively worked on recently. That would allow the that would kind of simplify the model quite a bit by just sending several requests without waiting for the blocks to come in.

N

That would not give you all the efficiency that you are envisioning here, but might give sufficient speed ups without making the model any more complicated sort of negotiating that and start a greater than one is okay, and if it then turns out that this is still not enough, um you may want into what is going on with ultra with non-traditional responses, because there comes in all the topic of how will this server even know, on which time token to reply etcetera? But my gut feeling is that it wouldn't need to come to this.

N

When one looks into and start greater than one for say, eighty percent of the applications- okay.

P

So you are saying there, you have MIDI scenario band. What's the solution we just mentioned and.

N

Start greater than one which would mean that the server is at leisure to keep several to send several messages to the cloud that sorry, the client would be at leisure to send several requests at the same time. Without luck, stepping and waiting for each response to arrive.

N

That is possible that that that is not if there is no particular definition of how to arrive at those larger and start numbers.

N

But if you here that five is a number that works for you, that could just as well be a number that you could try out things with and then send resend several requests without waiting for the response and only sent more requests as the responses Strickland. So.

P

One more question is Easter a solution. You just described the document. An email I am.

N

Not aware of any document, as.

J

Lives, implementations.

N

Letter to use and start greater than one but I might easily be wrong, and someone more familiar with all the old documents may answer that: okay.

Q

Hi, did you do some analysis on on the performance improvement, you're you're getting out of this I.

P

Think we have done some very simple. Revocation of these I think it's very obvious because, for example, here the DOE regional ways you send each sent for week, four five requests for five block items, but now you have sent you just an one, because there's only one RTD happening one wrong tree. Yes,.

Q

But there's also I, don't know if you maybe you did that already sent this to the transport working group to just see where the transfer they're a working group, because there's obviously a congestion control issue. Here you, like you, pick the number five but I could say: I picked the number 1000 and so I'm I'm very fast, but I. Don't think it's that easy! Oh I'm, sure it's not that easy, but.

P

Now I think because we have the coop or what he CP defined, already specified by you right and if you are using TCP. This is obvious, because we have lot of blocks to send and that's that's llama, a case that history should hinder and TCP country console is so stable and can make an internet very stable.

Q

Say? Okay, so you ambition this to be mostly used with co-op. Over TCP can.

P

We use either for UDP also because we have cocoa a. We have to cook co-op congestion control, algorithm, define in this working group, and this can be proved also safe for the conversation over UDP.

C

Okay, so I'm seeing some interest in this and also seeing interest in exploring related approaches, for instance, with increased and start so I think we should encourage you to continue work on this and maybe also explore the alternatives work with the people. Who are the ideas in mind and we are looking forward.

C

P

Thank you. Thank you very much.

C

So we are closing 90 seconds early this time.

C

Thank you very much for making the time this time and there's a lot of actions and I probably should have mentioned it has been said before we will have interim meetings and we have large number of working groups that will be coordinating to run a weekly interim meeting in probably at late Wednesday European time, early, Wednesday, u.s. time and I think once Easter the Easter break is over.

C

We will continue this and we will have some cost lots in in this repetition of interim meetings and we will continue moving things forward, so we can get more documents off our plate. Now they do that. We have added two more which thank you ever nice trip back.