Internet Engineering Task Force 101, 22 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-DNSSD-20180322-0930

Description

DNSSD meeting session at IETF101
2018/03/22 0930

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

A

B

C

Starting a couple of minutes.

A

After slights have a chance to pick up, people.

A

If you want to drive.

D

Okay, so welcome this is some DNS SD, hopefully everyone's in the in the right room, I'm Tim, Chang co-chair with David Shaughnessy here and skin as oh sorry, so we've got two and a half hours and a fairly full agenda.

D

We'll show you that in a moment, first of all, please take note of the note. Well, it has updated recently. So if you at the back it's the fighter, pilots will be able to read that. But the note world is also linked from the the meeting pages as well. So you should always read it to make sure nothing's changed between meetings.

D

We have a minute taker. Thank you very much. Barbara I would encourage others in the room to help Barbara. You can go to the etherpad there and make any additions or tweaks the things you said, maybe to clarify any points or to get the or name spelt correctly. That's always a tricky when the minute taker can't see your name match, and we also have the professional job ascribe aquel southland doing the jabber function. First. Thank you very much Mikael.

D

So just the basic working group info. This is the same as it's always been. If you want to find out more information about the the group, those are the places to go to and how to join the mailing list if you're not on it. Already in terms of the document statuses, we have two RFC's that have been published. Now we have the one on the consistency of labels between conventional DNS and DNS base SD, and we have the original requirements.

D

The working group items that we have that we're progressing. There's the DNS hybrid Genesis, T hybrid proxy since been renamed the discovery proxy. That's been updated after reviewed by the ISD, so she will tell us a little bit more about that shortly. We have a couple of privet. We have in fact three privacy related drafts that have been authored. Those are currently parked while we review the scope of the privacy work we want to do so.

D

You've got a reasonable amount of time today to discuss that, and Christian and Stuart have a few slides to stimulate some discussion on that later in the agenda.

D

The NSS d.push again, that's been updated very recently and Stuart will include that in his talk there is also the DNS stateful operations draft, which is required by push which, in turn, feeds into the discovery proxy. That's, though, being progressed in DNS op, some of you may have been in DNS help earlier in the week Stuart presented on that, and there were no objections raised in the room, which was good, but Stuart again will update us on that here.

D

So expect we're hopeful that that will progress and push in the discovery proxy with it, whether we advanced them at this time or not, is a question for the group to discuss that discuss later. So the goals for this session is, first of all, just to understand any remaining issues. With that little triple of draft I think we're in a good position.

D

We want to progress work on the discovery, DNS SD discovery relay which table talk about anyone to get an update on progress on the work that's going on over in core in terms of the mapping between the core resource directory and in SSD.

D

So Kari is going to present remotely on that we have a small number of essentially part documents and that they haven't been updated for a meeting or two, so we'll just run through those and check where we are with them and what's happening, and then we've got I think about an hour in the agenda to discuss the scope of the privacy work, increase some requirements and agree as a group.

D

What going to progress so, as I said, we have Daniel and Christian have produced those other three privacy-related rafts, they're, quite well advanced I, think the group generally thinks it's good work. The question is: is that the right work I think we just wanted to step back for a moment and just look at the bigger picture. Briefly before we look at the bigger picture before you progress?

D

Okay, that's what we'll be doing today and in more detail is the agenda again. So if it's, if you reduce to quite a small font, so we'll start with Stuart, giving an update on the DNS stateful operations and on the update on push and the discovery proxy we've then got Ted talking about both the discovery relay and the simple home net naming and SD architecture. You think.

E

D

Kari coming in to talk about karate, DNS, SD mapping and then we'll end up with the privacy discussion, so I will attempt to cut over to Stuart's lights. There's a remote continue. There.

D

F

G

Okay, thanks Tim.

G

So we'll start by talking about the DNS stateful operations. Quick recap for those who don't remember the history. We started off with DNS push notifications to support the discovery. Proxy and Rob Ellis wisely pointed out that we're really conflating session management with the specific behavior of push and that did slow things down a little bit. But that was a good observation and we've been working together on what stars doff being called session signaling late last year, I think a lot of people finally understood that.

G

It was, it was not just about managing session timeouts for TCP connections for DNS and they caught a new name, stateful operations, so just to cover the recent history in draft Oh for last September. That was when the name changed. We also had a lot of debate about whether every request must have a corresponding response, and we decided that that was not a requirement, and that was good because that simplified the push notification as documents and that's one of the things that was holding up the push document.

G

Is we needed to wait to see what the consensus was on DSO before we could really move forwards? We had a bunch of feedback at IETF 100. We addressed that updated at this January. The DNS off working group chairs started the last call in February that completed. We got lots of good feedback.

G

If you look at RFC death you'll see that we changed quite a lot in the draft, but nothing material about the protocol over-the-air that was submitted before this ITF meeting so DNS, or could review it and confirm that all their issues have been addressed. We had some more feedback from Paul and that was addressed this week because we wanted to stay on top of this and not to learn any more. So we we believe it's now ready for IETF last call. We.

G

Presented the same information at the DNS or working group and didn't get any objection to that so I'm hoping the chairs will decide that this is now ready to move along, which is important because you can see there are these three other documents right now that are depending on it. So diving into these documents now push notifications was critically depending on DSO, because that was what it was based on.

G

In the new DSO draft that doesn't require replies that actually simplified a bunch of text in the push notifications documents, there were some very awkward texts about some replies that really didn't carry any information, and the text was saying that the our code had to be zero, and if the our code wasn't zero, then what you had to do about it and and all of this was describing stuff. That should never happen. So it was much simpler.

G

Now that we can just delete those pages, the draft actually shrank by six pages, which almost never happens when I work on the raft and.

G

Tom and I also updated the Alka iterative algorithm for discovering which server to talk to so that will need some review. I see Andrew sitting at the back there. So hopefully, we've got some text now that satisfies Andrew and if there's still more to change, maybe Andrew you I and Tom can get together to bash that and make sure we're all happy with it.

G

Discovery relay was also updated this week at ed, we'll be talking more about that and the discovery proxy draft was also updated to address the feedback we got from the isg.

G

We actually got lots of really good feedback from the iesg, and it gave me a lot of faith in the ITF process that we have. We have smart people in the leadership who had some really thoughtful comments and there was not a lot of duplication. Actually, all the different ihe members had different areas that they suggested so text. There's quite a lot of change to the document to address that I added a diagram, because somebody wanted a picture showing what the network layer looks like.

G

There was a request for an example of how this actually works in practice, rather than put that in this document, I added that as an appendix to the roadmap document and put a reference here to the road map. So if people want a bit of a real-world example to make it tangible, they can look for it there and, as always happens in IFC review, we had some more more wording for the security consideration section.

G

The road map is not currently a working group document. That is something that the working group can decide. What I added this week is the walkthrough. This is some text I previously sent in email when people have asked me. So how does this work in practice? How does the device know what domain names to query?

G

How does it discover what server to send those queries to so I like to use the example at the terminal room here at the IETF meetings, because you can actually follow along in a terminal window, doing the same commands yourself and see for yourself exactly how it works.

G

So that is the document update.

D

Okay, thanks Joe, so just running through the the three things with three main things there are, the the DSO does any other any comments on the DNS stateful operations options, the dns hoc item. There are no comments raised there, I think as a working group I believe we're well, we can't influence anything, but we can certainly support the DNS. What working DNS, what we've been saying it? We believe it should go up. No I think that's what we're going to do.

D

No objections here, we'll hear a little bit more from tent about the discovery relay sums of the DNS push. Are there any further comments on that think again, we're generally in a happy place. I saw love at the back from Andrew. They let.

G

Them go. Let the minutes record. We had a thumbs up from Andrew just.

D

Clarify what type of thumb it was? It was a thumbs up and then the discovery proxy, formerly the hybrid proxy- any comments on that otherwise I believe we're we're ready to push up on that.

D

Okay I mean there I. Think I, remember, I! Think the interesting question is once those three documents are all at the point where they're advancing towards publication. Is there any other reason why we'd hold them up? How are we, for example, in terms of implementation? Experiences, that's something where we might want to just hold off a little bit until we get more of that, or are we happy to let the ITF process happen?

D

G

And I are actually working full-time now on getting that implementation experience. So I think it is important that we do that, so that we don't find some silly mistake and then end up with errata listed on the document. I'm not expecting that to take very long, certainly in the next couple of months before the next ITF meeting.

G

In fact, I think we should plan on having code running at the hackathon to show people and.

D

I think the the way the ITF process works. I can't see any of them actually going to publication before the next meeting. So by the time we do the last calls and the ICT reviews, etcetera, so I think that's going to sit quite nicely now. The other question I've got. Is there anyone else in the room, that's implementing other than Stewart and Ted okay good on John? Oh, yes, on Tom anyone else, anyone know of anyone else to implementing.

D

Okay, that's interesting! So I think it's going to be good that we.

G

Get oh well, I should answer your question. Sure there is a team at Cisco that I've been working with who have an implementation. Okay, Oh and yes, Marcus Steinberg had an implementation of an earlier version of the draft. It would need to be updated, but that's in open, wrt.

D

Okay, good and then I think the final thing coming from thanks very much the final thing coming out: there was Stuart's, updated. The roadmap document, I think it's so. Firstly, I think it's a really useful document for the working group. It's showing essentially all the components of the things that were working on how they relate to each other and the sort of direction forward for the working group and I think adding an appendix shown how things actually work with a practical example.

D

Maybe a overtime one or two more appendices may be added with other examples like that. That would be good, so I think it'd be a good thing for the working group to adopt whether we actually ever aim to publish it in the end or not. Is another question but I think we should have a decision now as to whether we adopt it as a working group item.

D

So could we take a farm? All those in favor of adopting the roadmap document is a the necessity. We actually ask a question Fergal how many people have read the roadmap document? Okay, that's good! So yet then minutes there show that about 8 to 10 hands went up, I, think so all those in favor of adopting the I've so you've got a question. First from Tom.

H

D

H

If we reference it in the hybrid and the discovery proxy, doesn't it have to be published? No, no.

D

I mean ideally yes, but in practice.

G

If it's, if it's a normative Rohan's.

D

G

Would help be as an informative reference? We can either leave it as a reference to the draft or we could remove it when it's time to publish, but that doesn't hold anything up. Yeah good question, though,.

D

Okay, so all those in favor of adopting this the roadmap is a welcome goodbye, jun-hyung, very musical. Anyone object hum so noted that there was a healthy, humming, favor and I couldn't hear a single hum against so obviously take that to the list as usual. Good subject to that, we can be published as a as a working group item.

D

Okay, well thanks very much.

D

So discovery relay first I think.

I

So don't do that I thought I hit cool you! Well, oh I, see yeah, sorry, alright, okay, so here to talk about discovery relay what is it so it's a simple lightweight relay that can be added to any router. It's basically it's! The idea is that it's like a DHCP relay, very small lightweight, doesn't need to be changed when features are added to the protocol. It acts as a virtual interface for discovery proxies off link. So if you have a discovery proxy on a fairly, you know, smart machine, that's got plenty of CPU.

I

It can be using this. This discovery relay that's sitting in your. Perhaps you know much less capable router somewhere else, and so it's doing all the work and the discovery relay is just relaying. It's not there's no intelligence to it.

I

So this idea I'm kind of going starting from the beginning, because I'm not sure how many people have actually have actually got this on their radar. But this idea came out when I was working on the home like the home, that naming architecture, because we needed a way to separate out the sort of simple home net use case from the more general home net use case and so, but but actually the home. That use case isn't really the main use case for this.

I

It actually kind of makes sense to have this in pretty much any any router that you'd have a DHCP relay agent in, and so it kind of makes sense actually on on larger networks, corporate networks and that kind of an so anywhere, essentially where a real agent would make sense.

I

So the benefits of this, it's really simple to configure you do need to configure it with some authentication information so that you're, not just letting any old person connect and start snooping on your mdns traffic.

I

But you don't need to tell it like you know what the domain names of the link are or any you know anything that might be changing a lot so once you've got it set up, it should be pretty easy to to just leave it there and have it work, it's pretty lightweight it does. It does require TLS, but at that, at this point, I think requiring TLS has pretty much table stakes and so I'm, not counting that as making it heavyweight. There are some pretty lightweight TLS implementations that could be used.

I

If you have a very small router and as I said earlier, you don't need to update it when you add features to to the mdns to the discovery relay.

I

So it essentially allows you to really centralized your network. You can have leaf networks that don't have a lot of intelligence on them and then centralize everything and it provides a way also to monitor mdns traffic on a link. If you, for you know, for network management purposes, you might want to see what devices are out there. Advertising services and you can just connect to the relay using proper authentication and get that information status. So the document actually is pretty complete.

I

I think that if you wanted to implement a discovery relay right now, you could just use the document as written in a work. I had actually originally a pretty elaborate management section, which was more than half of the document, and I decided that that was a little too elaborate. So I took it out. I think there were some interesting stuff in there, but it wasn't really about the discovery relay.

I

It was more about the home net use case, so I might take that and put it in a different document later, but it doesn't really belong in a dns SD document.

I

The document relies on DNS stateful operations that Stuart said, and the Stuart mentioned. I actually did an implementation of the relay for the Singapore hackathon when I was still working for nominal, that's nominal codes, that's that's been abandoned, but but we're working on a new implementation now and.

I

It's not done yet, but it'll be done relatively soon. I think and Stuart's got a discovery proxy that can talk to it, which is of course the other half. So it would be nice to get some some. Some working group working group review on this I, don't think I've gotten a ton of feedback on it ya know so so be great.

I

If some people could read the document, and so that brings us to the next step which that which is that we'd like to request adoption for this document, we'd like to get some review and comments and if somebody is interested in implementing it, that would be awesome.

I

Mr., it said we're planning on being in Montreal at the hackathon, with working code to test. So if you've got code, we'll be able to test with you and I'm also planning on stuffing some of this stuff into open wrt, so that people can just download it and try it out and it'd, be nice to get more router vendors who are interested in this. So that's pretty much it any questions.

D

So hands up who has read the draft, not necessarily that the latest one? Okay? So that's a small number, so, yes, we certainly could do with more people, reading it and giving feedback other a couple of people that were is none of them. It's not a huge document or a couple of people that might volunteer to have a read and send some feedback to the list. Anyone prepared to do that.

D

Yep thanks Barbara one other, maybe don't be shy, so I'm gonna.

G

It's a pretty short document, yeah.

D

G

It's not a big request and I think. The other reason we haven't got a lot of feedback on. It is because it's pretty straight forward and I want to give Ted credit for this idea. He listed me as co-author, but I think we Ted's background in DHCP. He was very natural and obvious thing to Ted that you have this very simple code like a blooper reel, which is very stable.

G

It doesn't change you implement it once and bootp has pretty much not changed for 30 years and you can still innovate on the DHCP server and once Ted pointed that out to me, I thought that was obviously a good idea. I mentioned earlier, we've been working with a group at Cisco.

G

That's the group that works on a Cisco product called the Cisco network registrar, which is an appliance that runs in the datacenter and I, was always happy that they were spending their time, reviewing the documents for us and doing implementations, but it never felt like a perfect fit, because the discovery proxy, in my mind, was something that lives in the routers and the Wi-Fi access points yeah, but still it I was appreciative of their time and their input in their assistance in developing this, and then the the irony is that it all paid off in the end, because with Ted's idea of having the relays suddenly, the Cisco network registrar product becomes a perfect place to implement an intelligent discovery proxy that is using these relays as its tentacles out on every little link in the enterprise or university campus network.

G

So it's funny sometimes how these things come full circle and when you read the draft it just what? When I read what Ted proposed I was just sort of nodding going. Oh yeah, that makes sense. There's nothing really controversial there. So that may be why we've not got a lot of feedback, because it just seems obviously the right thing to do. Yeah.

D

And as Ted said, though, you did have to tweak the spec a little bit as a result of doing the hackathon. So it's it's not completely trivial. But yes, any little.

B

Bit of review would be.

E

B

E

Libram so I had to press the editor here for to say I'm, the one speaking it's more diverse,.

J

E

And be at the mic at the same time. So do you know what version have opened up here to you're going to be doing the work against the.

I

Head of the tree, I mean I, don't see any reason why I couldn't be back ported to a to an actual release, but rest is just in getting or getting an open wrt that builds, but yeah I mean this. There's there's nothing in this. That is in any way, I mean most of the. When you see open wrt, advancing most of the advances are actually Hardware, stuff and sort of integration stuff, and so integrating this into a into like chaos coma or something like that would be quite easy right, but because it.

E

Is a lot easier if you take something that is stable from an operating point of view and then just create a new feed and see it. So people can install it yes from there, because otherwise getting people to try and whatever's trunk of all the time that then the hair might have other breakage, and so.

J

I would like.

E

You to do take that the latest stable and do the work against that. So you don't have a moving target for the rest of the distribution if possible. Okay,.

I

That's great feedback. I didn't occur to me to do that, but you're right.

D

Yeah, okay, thank you. So we should take a view as a working because of whether we want to adopt this item. I mean from everything we've heard. It seems a very natural idea and it fits with the model that we have so all those there any further questions before we take that decision, as anyone need to know any further information to help them with it, No, okay. So all those in favor of adopting the discovery really as a working group item please come now and any opposition or anyone think it's not a good idea.

D

So again, no, that is a healthy, come in favor and none against and we'll take that one to the list. Thank you.

I

Red button on the desk that.

D

F

K

D

Big red button, bigger than the other big red buttons where I can I, have to bring them, carry and remotely latest. It's probably to do with that. Okay,.

D

I

The next topic is simple: home net naming and I just wanted to present. I. Think I presented this to the group, maybe once before, but just trying to raise some awareness about. What's going on there so home, that is using DNS, SD Discovery proxy is the basis for the simple naming architecture, and you know, there's some there's some push in the in the home. Networking group largely for me to to use the registration protocol as well, but that's not in simple naming so so I'm I'm.

I

Actually, my goal is actually to do the simple naming document and also an additional advanced naming document. The layers on top of the simple name naming document, and so the goal is to is to actually implement that unicast solution that that we get out of the registration protocol.

I

So why does anybody in this room care well, I? Think the so the advanced home that naming architecture really kind of hits a lot of use cases that we care about I, think or at least, is relevant to them. It's possible that what we have in the simple naming architecture would not be just a drop in thing that you could use in a corporate environment.

I

A small small organization might not be a drop in thing that you could use in a number of the use cases that we've talked about like the the EDUCAUSE use case, but we don't actually really have a management story for dns SDU right now and so I think that even if the home, that naming architecture itself is not what we wind up using to address that usability issue in other environments, it's probably going to be very relevant to that work. So I think it's worth looking at for folks in this group.

I

So what's going on with that I actually I looked over the I hadn't worked on the simple home that naming architecture document in about six or seven months and I. Guess I did a small haircut for it on for Singapore, but but I looked at it about. You know a week or two before the deadline and realized that the organization was just terrible, so I don't know it was kind of ad hoc. When I wrote it down I just it was a stream of consciousness.

I

So having that that break really helped and I reorganized the document, it still needs a lot of work. Basically, I've got a nice skeleton for it now, but but it needs more detail, and so it's not ready to publish yet but I'm really hoping to have something that looks like a final version of the document by the next ITF des spent. It currently des spent depends on the discovery relay advanced home. That naming will depend on the on the registration protocol.

I

I haven't actually done a ton of work on Vanstone net naming, but there was a home net name mark naming architecture document that preceded the simple home that naming architecture document that has a fair amount of that stuff in it. In fact, you know the the some of the ideas that that turned into the registration protocol were mentioned in there.

I

So, let's see so the ask for the DNA SSD working group. Well, we already talked about several of these documents. Basically I'd like to get all these documents adopted, because I need them for home net. So.

I

We already talked about a dot. We already. We already had a hum firt for discovery relay, so we don't need to go over that again be nice to do. We didn't talk about the registration for.

D

I

Could be nice to get that adopted as well, because I think that that's the nice thing about the registration protocol is that it basically lets us have a migration path to a network or not using multicast for everything every service discovery. You know we still have multicast as a fallback, so we still have compatibility with old devices, but this allows us to do things like you know.

I

Some devices like IOT devices that are running on on lossy low power networks may not actually have access to multicast and so right now you either have to have some kind of shim in place to make them look like they're doing multicast, in which case what does that shim look like or you could have them do a unicast registration, but we need a protocol for that, and so this this is a port of for that.

I

So, let's see so I would say that right now, it's not the right time to read the simple hum that naming architecture but I'm gonna send out a new version of it hopefully fairly soon, and when that comes out, I'm gonna announce it on the DNS SD mailing list and I'd really appreciate it.

I

If folks, here could take a look at it and send any comments that they have- and you know so in particular like what's missing and does this seem like it has relevance to the DNS SD management problem that you know that makes it relevant to this working group as well.

I

Questions comments, tomatoes, okay,.

D

Thanks so just a reminder, this draft is a home networking group item already all these, the simple naming, simple home net naming architecture document is so I think there's a couple of in perhaps what we go back, get back to the slide, with all the draft names on that's what's one yeah, so we've obviously already taken a decision on the relay I think there's a broader question with the service registration and what's implied there in terms on the groups feeling of a move towards supporting unicast here and moving as far away as we can from using multi casting new work, so I think it'd be useful.

D

Maybe we've got plenty of time today just to hear some thoughts on that this there's kind of two implicit things here with the social situation. One is the unicast and multicast position. The other is essentially returning to the DNS update type of model, and you know yeah.

I

It's a little different yeah.

D

I know, but it's it's it's having the working group understand what's different this time and why it will be likely to be more widely adopted, so got it at a time if people want to talk to those two topics.

G

Stuart Rashtra from Apple for the notes I wanted to expand a little bit on something Ted mentioned. I talked about Internet of Things, home automation, and devices like that are increasingly becoming very popular. Apple has the homekit line. Nest has the thermostats. Now there are a bunch of these things. Ocf is working on standards there. The ZigBee organization is doing it.

G

The thread group, which is an organization out I, started by nest and Google, is working on low power, low speed, short-range wireless networks, where you need a mesh to cover the whole house, and when you have a mesh, it gets really hard to do multicast and when you've got battery-powered devices that want to save power running the battery down and forwarding multicast for other devices is also not good. So for me personally, this is an area that I think is important and something that I'm going to be working on.

G

If there's energy in this working group to help design that future non multicast discovery protocol, then that would be great because the more input we have the better but regardless it is something that we're going to need for the new technologies that are coming out. Yeah.

D

And I think there is another draft elsewhere with Charlie Perkins and some other people involved in terms of describing the issues with multicast I've forgotten the specific name of it. But I think that's that's the rationale for push here towards remaining compatible with the existing multicast things that are out there, but in new work, trying to lean towards more use of multi-card yeah.

G

I think Charlie I think the draft from Charlie Perkins is about Wi-Fi. It's.

D

In yeah, I guess.

G

I finsihed- maybe that's us yes, but which is also true I, mean I- would talk about the mesh yeah.

D

G

Even Wi-Fi now we're up to gigabit speeds for unicast and multicast is 100 times slower. So we don't even need to look at things as esoteric as mesh networks to see that multicast is running out of steam. Yeah.

I

Another another thing to say about the the registration protocol by the way is that it also adds some not huge amount, but some security, which is not present an MD, an acid mdns. Basically, anybody can blab on the network. My name is Phu and what happens if somebody else had already claimed Phu is that whoever was that already claimed.

I

Foo is like oh I'm, so sorry and gives up Phu, and so it's very easy to attack services on the network by just you know, claiming a name and one of the neat things about the registration protocols that actually uses public key cryptography to to assert ownership over over a name that hasn't yet been claimed, and that makes it impossible for somebody who doesn't have the private key to then claim that they own that name. So you.

D

Just got that in the service registration project, yeah.

I

Now you could in principle, do that with multicast too, but it seems, like you know, there's no reason to do both so yeah. That's a nice! That's a nice feature and I. Think probably you know equally as valid a motivating feature as as the the multicast issue.

E

Michael Abramson again, yeah I was an MD. The other day were Perkins were he was presenting that and I brought up this issue in 2015 or something of it that this is something that should be worked on and I still think. I still think that today, the I, chiefly, for instance, and the ITF has not decided like okay. This is how we're going to solve it.

E

It's going to be a little bit of both, but but I think that if that Draft at least describes some of the physics limitations and so on what you want to do on on radios generally, so it's not only Wi-Fi, even though it's focused on what yeah well.

D

There's also, obviously, lots of shenanigans in mapping multicast to actually unicast at the lower layer and all sorts of other things that were great. But.

E

Yeah I think the takeaway from that is that, yes, we should move away from multicast because it has downsides on.

D

Those kind of media's which yeah and the implicit question then, is the coexistence of what we have today with nd and SD + SSD, alongside whatever new thing is, and to make sure that those aren't going to interfere with each other in some way or another yeah Stewart.

I

Might be able to speak to that more authoritative, Lee than I can but.

G

You making a good point: we'll have some cases where the old to the new coexist. We may have other scenarios like the thread mesh network, where the old multicast stuff is just never present from the start and I think that's another reason. We want to push ahead with developing this, because there are other things going on the Indus in the industry that could really use this, and if we don't have a solution, ready, they're gonna have to invent something different and then use.

E

G

Will not be as awesome as a stuff. That's right, Ted.

L

D

I mean maybe this is maybe there's a opportunity for an ad to make a comment here we haven't I was just saying today: we'd be having a recharge it for a long time. If at all, they we've tweaked our milestones a bit. So it may be appropriate to look at our Charter, which does mention things like mesh networking and maybe review the Charter and include that more explicitly in our future work plan. Does that make sense.

M

Tara mandersohn snoozing ad yeah, look I'm I'm happy to have a chat, a discussion at any time. I think this working group is one of the working groups in the IT. If there's insanely, responsible and I'm very keen to to listen to the members within this working group as two steps going forward.

A

One thing I like to add is I think we're doing one more work in the privacy field and that's not reflected at all in the Charter. So I think you might be useful to change it to reflect that Michael.

E

Abramson ain't, yeah and I think when I brought up the the multicast issues on radios, there were a lot of people from there was three or four different working groups to deal with radios, 6lowpan and money, and something else. So we need to make sure that we're not stepping on someone else in that were using whatever experience and protocols they might already have just did in this case we're not reinventing the wheel because they had a lot of I mean they came out. I said it of course.

E

Of course it's like this, why didn't you know, and most people in the IDF didn't know so, but there is a lot of knowledge that might be untapped as well. Yeah.

D

Well, we've also seen in the last couple of meetings and we're gonna hear today that the Corps and anime are doing their own service discovery things in different contexts as well. Michael.

G

Can if you could send a link to Charlie Perkins document to the list, I think that would be an educational for all of us. Yeah.

H

Tom Brewster Terry speaking about milestone in the Charter that dates need tweaked again. Yes,.

D

We didn't look at that. No no was there a slide on that.

A

D

Yes, that will be something to discuss when we do a chart, so I think I. Think again, just speaking David I, don't think we want to hold up this work that it's holistic there, the service registration in particular and the the essentially unicast work. So we don't do anything to preclude that progressing quickly, but it does sound like refreshing. Our Charter would be a good idea, so that's probably something we can take the lists discuss. What sort of things should be added?

D

What maybe can come out now that we've either done the work or it's we don't believe it's any relevant anymore and I think maybe even looking back to the original, for example, the original EDUCAUSE request that led to us doing, you're partly led to us doing this work and see whether we think we've met what they were asking for. The interesting thing when we were looking at the Charter, so I think we'll take the the Charter to the list in terms of adopting the service registration thing.

D

I haven't asked David about that at the moment. I think we would like the work to continue I. How many people have read that I suspect we don't have many people that have read it yet, which is a an issue I? What do you think? Oh I,.

I

Thought it was great.

I

D

Worried about adopting is it bit early to adopt service registration from what we know so far, I think if you push ahead with the Charter, where we clearly say we want to do the work, then that's implicitly going to lead to an adoption for it.

D

I

D

Think more review would be required. I was.

G

About to say the same thing, I think when not enough people have read it is too early. Isn't it not useful to ask for adoption I think as part of the discussion about changes to the Charter? That's a good opportunity for us to figure out what are the things we want to work on. What current drafts cover those areas and then we can actually give people a reading list of things to look at and then we could. Then we can have a meaningful discussion about it. Yeah.

D

I

Sounds good so on the topic of educause. I didn't really want to get too deeply into that in the SSD presentation, because it's sort of tangential but yeah the engine I, actually I I, had heard the term the EDUCAUSE petition passed around a lot and I thought. Oh wow, that must have been like you know, ed Rousseau. It must be like really detailed and I know it.

E

Was it was like.

I

A half a paragraph of we want AppleTV to work on all of our networks. That was pretty much split, both Angie yeah. That's what well! No that's what they said as literally what they said.

I

But if you, if you actually turn that into like what are the requirements, then obviously one of the requirements is an enabling technology to allow the the service, the the the announcement of service availability to be reachable from the net from around the network, and the other is some way to operate that machinery so that it either is automatic or, if not automatic, then at least pretty easy to operate and I think that DNS SD has has addressed the the machinery that you need to do this part of the problem pretty well at this point, I think, there's more stuff.

I

We could do, and you know as I said, but but you know the the the discovery proxy pretty much solves the the transport aspect of the the EDUCAUSE request. What it doesn't solve is how do we deploy this, and so, and you know how do we deploy? This is well you just put it on all of your things and it just sort of works right except know.

I

If you, if you look at if you look at you know how you would have to I mean this is something that we had to think about in the home map, because we have to automate the deployment right. There's no, there's no way to to to have the end-user set it up, whereas in an educational environment, maybe we could have the IT people do it.

I

So it's not that hard to set up, but but it might be worth actually having a document about that, and it might make sense to have a DM SSD document about that I'm not proposing that at the present. But it's something we should probably be thinking about and if we're Charter and make sure that I.

D

Think it's something we have discussed in the past. I know: Tom had, for example, sort of a draft that never got published about the actually deploying what we're doing in an enterprise and I Ralph spoke to that topic two or three meetings ago, so I think putting that stuff together. I think what you're doing with the HomeNet stuff is kind of addressing that question in the home that area, but for a campus or enterprise having some equivalent view, point that were documenting yangmi.

E

D

Thinking, thank you.

D

E

D

Agreement there was two.

D

So the simple home so yeah, the agreement was to work up a an updated Charter, and out of that, we will better understand the work that needs to be done in that area and I think the same will apply to the privacy which they would make as well. The privacy isn't really mentioned much in the charge from the moment and out of that, then we'll understand which documents we need to adopt on which gaps we have for work. We need to do okay, so I think that covers that off.

D

So the I think the next thing on the agenda is is Carrie Carrie. Can you hear us.

D

The chairs, of course, can't see the Oh, though there we can see. Are you there Carrie I.

D

Don't know if we have to press the red button.

A

D

Right yeah, so Carrie join the queue and just pretend you're answering a question but actually present.

D

So we don't get to press the red button.

A

D

You've done this before, if you used to give me your first red button.

F

D

Think there's just a sort of an arm raised button. Isn't there icon you press just to basically ask your question in.

D

Me, tech, oh, there should be I'm. Assuming you can hear us, there should be little I, think it's a raised hand, icon or something you pressed to say you want to ask a question: I think it's there. Alright.

I

D

Your me, okay, we see the Kari pad man, it's moving.

D

We got a parry all the slides, though, hang on probably best if I bring the slides up here locally, and then you just are here.

N

Yep so I'm Kerry linen presenting on the.

O

Camera phone with the slide one so just tell us when the.

N

Problem space that we're discussing is machined a machine or thing to thing discovery. This is apropos of the earlier conversation about reach our Turing and DNS SD, there's nothing specifically in our Charter. That says we need to cover this domain, but there is a charter item in the core Charter that says that their resource directory must interoperate with DNS SD. So that's why we're here hopefully to to get some help from folks who are in DNS SD and may have use cases to contribute. The history of this draft was that it was.

N

It started life as an individual draft. I did this was ax Shelby several years ago it was incorporated into the resource directory draft, but then it was split out to basically eliminate dependencies that the art you might have on other work that was still immature resource directory draft as being teed up now for working group last call I. Think one thing we want to do is to gain some more implementation and operational experience before we go to work. A group last call, but this work.

N

No, no oh yeah right so.

D

You're just so just smoke am we.

N

E

Slides yeah just.

D

Just just as fun sure whether.

E

You might be.

N

The first and locally.

D

In thinking we're not so yeah, can you actually see which that I just.

N

Wanted to meet you when you see the slide with Wizards of the history playing which.

D

N

The source directory drafts working group item in core and so we're.

J

Basically, socializing.

N

The topic both in core and here so now you can go to the next slide, so the use cases that we envision, basically there's a there's, an obvious use case at the edge of heterogeneous networks where we might have cross proxies that translate. Http client requests into co-op server requests and vice versa.

N

There may be other cases where we've got resourceful.

N

Clients that are talking to constrained servers and resourceful clients are quite happy operating with DNS, also I think we're talking about supporting hierarchical discovery and very, very large deployments large buildings with building automation, for example, where you might have tens, or even hundreds of thousands of points where one could use DNS, sd4, coarse grain discovery and and then drill down into resource discovery for even finer grained discovery, and also we expect that it probably covers some chicken and egg cases like how do you discover the resource directory in the first place?

N

Alright, I guess we go to the next slide.

N

So for those who don't have background with with core it's the kind of the main application protocol developed by ITF for IOT, the main deliverable of core was co-op, which is the constrained application protocol. It's basically in its initial state was rest on top of UDP. The implication there is that request can be multicast, so it supports something a little bit like mdns.

N

However, multicast is even more problematic and mesh networks than it is in Wi-Fi, as we've discussed, but for the purposes of examples that all that will bring up here, we could just imagine that we could multicast for four resources on the on the constraint networks. Other bindings are being worked on right now, specifically co-op as being bound to TLS and/or WebSockets for transport over the Internet.

N

If there's anybody who still isn't at rest is it's essentially a set of architectural constraints, the world consists of clients and servers, and this thing can be either is called a Serbian. That's a term that's been coined.

N

The methods that are available to operate on resources are rather limited to the crud, create, read, update and delete patterns, but also Co app supports and an observed pattern. I think there's a rough equivalence between resources and objects. They both have behavior state and identity, albeit resources have a more constrained set of methods that can work on them, as I said finally, rest supports or a very mature rest design for an API should support something called hypertext is the engine of application state.

N

What that means in practice is that hypertext controls the things that control or or change resources are actually links and the methods that act on those links next slide.

N

So originally core was not chartered to do their own discovery protocol, but ultimately it became very compelling to use Co app to do discovery, as well as everything else that it does so Zack shall be developed. This thing called quarreling format based on web, linking essentially it's a it's a way of describing links between a between a target, sorry between a source link and other target links.

N

So, for example, if you're processing a list you might have a link that tells you how to get to other members or the front or the back of that list. If it's a device, you might have a link that tells you how to turn it on and off. You can access the behavior or the links of any device. By doing a get to slash well-known that slash core, you can optionally include a query. String and you'll receive back a collection of type links that basically tell you how to control that device.

N

So the web, linking draft is defined a set of target attributes for these links, such as a resource type, the interface description and the size that you get back. If you were to do requests on that now, resource directory is essentially a way of capturing all of the state for a given constraint network into a directory so that you don't have to do multi casting you can still unicast individual devices, but it's a bit like you know, capturing all this into a DNS directory next slide.

N

So in our draft we've defined a couple of new link target attributes, so this exp attribute is essentially a hint that information about this resource should be exported to the to the DNS or perhaps other sorts of directories right now, DNS is the only thing that that we're considering the granularity is fairly coarse in comparison to resources.

N

So, for example, if you had a device that was a clock radio, you might export the the API entry point for the clock, behavior and the API entry point for the radio behavior, but you wouldn't have you wouldn't export to DNS all of the individual controls like the on/off switch and all that stuff.

N

The I NS target attribute is essentially an instance. It's like it works like an instance name, so it basically uniquely identifies this resource from all over the resources of this oven. From this given type.

N

Rt is not a new on a new thing; I, don't know what's listed here, but anyway, one thing we're we're thinking about is perhaps a federated namespace, so that all of the resources, all the resource types that can be exported, don't necessarily need to be listed in detail. But potentially you could list in the registry just the name of the SDO that standardizes the types of resources below it and I'll get into that in a minute.

N

If' is again a semantic tag or a link to an interface description, something like a waddle or or perhaps a schema to describe this resource and how it works next slide.

N

So here's a very rough summary of what we're talking about doing and, as I said, you know a given resource that wants to be exported to DNS SD would start by having the exp attribute, and so then these other, these other things would be required. Oh I see that's why they previously. The previous slide said new and or required link attributes, so the instance attribute would be required. If you wish to export this, it becomes the instance part of the service instance name. The resource type becomes the service type.

N

The URI of given API entry point becomes a part of the text record. Similarly, with the interface description, any other, any other attributes would also go into the text record. So the idea here- that's maybe a little bit different from previous DNS SD patterns- is that what we would like to do, I believe, is to export multiple text records per SRV. So we're basically talking about multiple api's that live at port 443, let's say- and there actually is support for that in the DNS SD draft, but I don't think it's he very often next slide.

N

So here's a an example: I don't have a pointer I can wave around so I've color-coded these a little bit. You might start off with a with a query. There might be a mapping agent that does this mapping from resource directory entries into VN SSD entries, and so it starts by basically doing a discovery of all the resources that have the exp attribute. It gets back, for example, something from this node at you know: FD FD, 1, 2, 3 4. It says I've got a sensor. Here's the URI to it and read the content.

N

Type is FIFO which basically is Jason. The resource type is OIC dot, r dot temperature, in this case, oh I, see, would be used as the main type of this resource and our temperature might be the sub type. The instance is indoor temperature, the interface in this case, oh I, see dot I, F dot.

N

S refers to a schema that you can use to basically look up and see how this thing is operated and the resulting resource records are below TVD is how to generate a quad, a record if it doesn't exist and what domain we should map this thing into, but essentially we would create a pointer record listing a new OIC type that have the instance name of indoor temp, which came from the original record and and then we'd have a sub type. That lists this thing as a as a temperature sensor.

N

O

D

A question in the room: Kari I.

O

Carry this is Taylor, I have a question on the slide here in the label before underscore utpd, you have underscore oh I see, and the question is: how do you derive that from the information in the core query, or is this something you'd expect to be some hard coded table or whatever, because I can't tell whether you're, assuming that there's actually some structure inside the RT value which you're not supposed to assume, even though there is a convention or how you would question.

E

N

It this is not a well-formed idea, but but the idea I think, is to try to come up with some sort of technique where we could have a federated, namespace and I. Don't know if there's you know broad support for this again. We're sort of resocialized I think. If, if we were to go with some sort of federated name scheme, it would relieve us from having to specify every single resource type that could be exported in an eye on a directory somewhere.

N

Maybe again, that's not very onerous I, don't know how people feel about that, but I'm. Assuming that there is structure in the resource type string and the OIC is the first. You know label and then everything under that is essentially the domain of of that SDL. Again I just sort of picked OIC out of the air I, don't I'm not trying to imply that.

O

Okay, so I, don't know why you don't know why you need that so I don't think we should assume that there's any structure and the RT value, but it occurs to me that I don't know why you'd need that if, for example, if you just put in some label that means that it was derived from a cork worried, why do you care what Jessie? Oh it was? Alright, oh you're, RT values are unique. Isn't that simpler? What's the what's the use case, you don't want that all right and why can't they just be a constant.

P

D

So a couple more questions, or if the queue is a forming here for you Carrie.

I

Obviously this is a popular idea. This is Ted lemon, so I'm not saying that what I'm about to suggest is correct, I'm, just curious as to whether or not you considered this as a possibility and already discarded it.

I

If I were just naively thinking about how to how to get Corrin, DNS SD together the way that I would think about doing it would be to say: oh core is a service, and so Deanna says you just offer a core as a service in DNS SD, and then all of this complexity goes away because you just you're just saying you can do core with this device and then what you do with the device using core is up to the core implementation. I.

N

Had thought, oh, that makes sense, or is that I think the key takeaway here is that we would like more interaction between the DNS SD working group and the core working group. So those of you who sort of have a foot in each camp it'd be great. If we could come forward with more use cases and and more specifically, operational and implementation experience, I should say that there is an RD Interop plan for mid-april, and so that's maybe the first opportunity to try out some of these ideas.

N

N

Think it's going to be virtual I think it's going to be an online and Rob Kerry.

G

Where is that in drop happening?

G

Q

Just YUM I'm says I think I can answer answer that custom, because I will be holding that interrupts. Yes, it will be work virtual and there right now it sir. It is not planned in a very precise way. So we are still waiting for potential participants to to input us with basically what they would be, what they have implemented, what they would be willing to try starting.

D

Catch and name I.

N

D

N

Q

N

Is that when this work was originally conceived, it was in the context of a protocol that was being developed. That was heterogeneous where we potentially had HTTP clients operating through cross proxy because of the rough equivalence between rest and HTTP and resting core or in Co app. This cross proxy is potentially easier to implement than a application layer gateway, so just to advertise something as being core capable or co-op capable might not actually help out an HTTP client, so they might actually want to get to. You know to the links and manipulate them through HTTP.

N

If that makes sense.

R

G

I'm hearing several comments around a common theme here, I think you're right that we could help with more communication between this group and the core group.

G

Dave made a good comment about how you do this translation, whether it's a mechanical translation or whether there's a big table somewhere that lists the translations. I think that is one that that's, maybe the key challenge and the introduction to the roadmap document talks about that, because I've realized that, regardless of multicast, DNS or DNS service discovery.

G

What protocol you use, if you don't have a common vocabulary for describing services, then you end up with this big translation table that this mechanism is using one namespace for listing services and then another mechanism is using a completely different namespace to describe the same things. I, don't know how we solve that easily, but I think that's the issue. I, like Dave suggestion that maybe you lump all core protocol or co-op I should say I think is not the right time.

G

All co-op implementations are under underscore co-opted underscore UDP, but then you can use subtypes that are mechanically derived from the RT to let you do more selective discovery, so you not discovering every co op device there is, but just the ones you're interested in I had one little NIT on this slide. At the bottom, you have three separate text.

E

G

I think what you probably meant there was one text record with three strings in it. So, okay, just a minor detail.

Q

Just anomalous I'd like to add the one one point to the discussion of whether we should have some part of what is derived from the the RT in in this in the in the type one applicant used that we were we're considering is that there might be there might be a group of resource types for which it makes sense to use an HTTP proxy that is actually advertised through the resource directory or that is known to to the rest environment to be an equivalent resource advertise that via DNS st, so that so that a client, so that a client that only knows HTTP knows dns SD and knows how, for example, say a no score.

Q

Oh I see services. Work could use that reference without even knowing that there is current, moved.

N

By bar what I know.

S

I'm not wearing my badge, but you know me: I'm Barbara stark, hi Carrie. You know me too so and you know the work that's been going on in broadband forum on USP and we've got a protocol, that's running over co-op and it does DNS Sdn. It does nothing like this. How would you expect something like that? That has a completely.

P

Differently scheme to work in touch later, or is this more of what we need to understand so if.

N

You can bring me up to speed on that or send me a link that great thank you.

P

S

N

Nope, that's it. Thank you.

D

Okay, there's nobody else at the mic. Is there more slides here or is that was at last? Okay, so there's clearly interest in this topic and I think we did mention earlier coming up with a reach, our Turing, so maybe factoring in this type of interval and interactivity. Whatever the word is, it would be a good thing to put into the Charter I think if we good is Christian, are you on the DNS SD list Christian?

D

Could you send a list info about the inter up to the list if you're not on the list, feel free to send it to the chairs and we'll advertise it I think this is something we need to pick up and have some people involved with and something like that in trop of nth sounds like a good way of getting some communication going. So thanks very much Kari. Oh that's right! That's very useful.

D

I think we need to progress that so that then takes us on to the will be the largest item we put time aside for which is discussion of.

D

Dns SD privacy, so we have a couple of people that is going to speak briefly. To that to prime the discussion is Krish. Jin yeah is I an Stewart. So basically, what we would like to do is to discuss the scope and requirements, obviously within the working group, so that we can agree what work we want to do, and it may be that we continue to progress with the work that Daniel and Christian have done so far, which I think we all seems to be the working group consensus that it's it's good work.

D

The question is: is it the right work? Is it the complete thing we want to do? How does it fit in with the broader view of privacy that we have? So you have a couple of people we're going to just talk to this topic first and then, we've got essentially the rest of the session to discuss the topic, so I think Christians going first, if I remember rightly, oh, it's just Christian talking. Is it so, but I've got two slide decks. I've got the scaling, talk and I've got the scenarios scenarios first, cool.

D

You gotta stand in the blocks.

R

Good morning and I am Christian, Redeemer I've been working on the NSSE privacy for some time and I'm very happy that, after two years of working on that, we start getting some feedback.

R

So the first feedback was that we need to have consensus on what scenarios we are addressing, and so we added a couple of hallways discussions and I'm trying to summarize this with the scenario that we are saying so the first scenario minute the kind of threat we are looking at. All those threat are linked to warming users. I mean it's, it's pretty clear that if you do as a discovery scenario in your own house between devices that stay within the house- and nobody listened to them, the privacy consideration are pretty minimal.

R

But what happens is if you move to a public place, then you have an issue. Is that if you use DNS SD today, or in fact any discovery, protocols or specific to the NSS, did we place mats at the same issue?

R

You will send metadata with your queries and that metadata can be used by advanced service at the Guyana Hut in this slide to correct information. For example, if we take the NSS, if we use the NSS in a coffee shop to discover the printer in the coffee shop, well, obviously that there is a printer in the coffee shop is not something that is secret and discovering.

R

It is not a big privacy issue, it's meant to be Schelotto, but having someone register who is using that printer when and specifically, was in the coffee shop when, because of metadata leaked by the discovery? That would be bad. So, in that scenario, Wilson are you in which a service public, the client is not add alcohol. There is to not disclose the client identity to make sure it can be not be linked.

R

You have a second scenario, suppose that David and Scott are in a coffee, shop and they're deciding to do some application, so they use DNS SD to synchronize the application. One of them becomes a server, the other one becomes the client they discover each other. They do some fancy application and life is good, except that the guy in the Hat has looked at all the metadata, and now he knows that David is speaking to Stewart.

R

So he knows that both of them are here and also may well know what kind of service they are using and infer what kind of job they are doing. So in that kind of scenario, our requirement is clear men. We would like to make sure that nothing is public, that we don't disclose the client identity and, if possible, that we don't disclose when we don't use either the client or the server identity, and we don't disclose the type of service that they are doing.

R

So that's I think is the the classic scenario in the preparation for this meeting. We discussed these two scenarios. I added and also one I- think it David is a pretty modern guy. So, yes, he has a fancy. Watch has a fancy phone and and a fancy watch is trying to discover the fancy phone using DNS SD to see hey, should I update my screen or something and that's pretty much the same scenario as the one we have seen before.

R

Okay, because I mean these DNS SD scenario will leak information and it was or not a bit disclosed.

R

G

I'm glad you're, including all these norwich, you said this is pretty much the same. It mostly is. There is one difference, though, which is that in this scenario, David's watch and David's phone are both owned by David. Yes, so there's Ennis in a sense, a bobble that those devices talk to each other, but they don't talk to other things in Scenario to David could be exchanging copies of the slides for this meeting with me with you with Tim, so you can't assume that those devices were set up by the same owner at home.

G

In preparation for this meeting in the coffee shop, yeah you're correct. It's the same requirement.

R

But it is not the same scenario and and that's pretty much a scenario that we are concerned with. Okay at the 8th. The next in the next point that I wanted to say is that if you look at the general class of solutions for those problem, they all involve having some kind of secret shared by the client and the server and used to protect the discovery mechanism. I mean how you do that exactly will vary, of course greatly.

R

Depending on the specific protocol. You shoes, but I mean this requirement that they be some kind of secret. Shared is pretty much in event to the scenario now the point there is that we have two ways to think about those secrets and in many implementations like when you are doing your pairing of your Bluetooth device with your car, something like that, we are using one single secret exchange to do both the authorization of the service and the protection of the discovery and as the classic pairing scenario, that's not necessarily the only scenario I mean.

R

In fact. If you look at the discover your climate, it may well be adequate to have a lightweight discovery, filter off, which is just meant to ensure that the message that we are changing don't leak metadata and to have a distinct authorization for CTO, which is meant to ensure that the client is authorized to access the resource that the server wants to make available.

R

So that's just to say that we don't necessarily have to tie together those two authorization models and in particular it may well be that in a number of implementation, the authorization model is dictated by the application and may or may not be the same. That used for the discovery and.

R

That's it for the introduction in any question about this introduction.

A

D

Excuse me, a bit of Fox's questions also got a little back on the the scaling issues. So wishing you just run through that, then you can sit down while we start the more fuller discussion.

R

Okay, so I suppose that you are all in Singapore when Stewart presented his misgivings about some of the current developments.

R

I was not I could not travel there, but basically, if, if we see we, we got feedback event we at ITF 100 and there's a lot of feedback. But I've tried to put that in the big bullet points. Okay, there is a first ever of feedback, which is relevance and where events in the sense that we have discussed that in the DNS SD working group discuss privacy, but we got actually very little feedback in the working group as if there was only minimal interest.

R

People were polite food, but one of the reason for that may well be that most of the discovery is not done with the spec of the working group, but is done by integrated spec in a big as a IOT stacks or whatever I.

R

Don't know about that, I mean if the suit Truman had actually the second specific piece of feedback on the solution that we proposed focused on three points. One was that in our solution, we proposed a pair device model which is in line with many would say. Historic. Implementation of the NSS D, but which may not be in line with the emerging usage and the emerging usage, is that people install applications and that the device are controlled by the application.

R

I mean lucky if I installed and short was giving the extreme example of a medical device that is embedded in your body. Well, you want that to be accessible by the medical application on your phone, not necessarily by the form simulation.

R

So it's clearly something where you have to have application, and, yes, you can achieve that by having in the operating system a centralized service which is then specialized with a lot of access, control procedures and things at that is clearly one way. But a very simple way is to imagine that you are doing the discovery from within the application itself so that, basically, things are well compartmented and intervals.

R

If you are doing the discovery from the application itself, it does lead to simplifications in the model compared to what we have, because the the per device model forces us to event leads us to have the two phase, implementation in which you first discover a privacy service on the device and then use that privacy service to discover the actual private services.

R

The second class of feedback were details on the pairing process, which basically was we are.

R

That was the work of the near Kaiser, who really took the state of the art in pairing protocol and and focused on the solution based on short authentication strings, which is which has some very good theoretical properties, but which has one weakness is that it has by asking the user to compare the pin on the device and the pin on their control phone, and there is a psychology whole there is that if the user is tired and really wanted an seem to complete they'll, just click OK without looking at the numbers, there was around.

R

That I mean it may be that the UI of the pairing that we keep the short authentications thing and in the UI doctoring we just ask people to actually copy the number which would have good properties or, if you have to copy the number when other ways to go to a pin best, auto call in which you specify the pin at the beginning and then don't ask question after that, I've ever seen automated, we could have a long discussion there.

R

I will result table that discussion for now, because it's it's really specializes details of cryptography and I will go to the next one. The next one, which was pretty much the biggest objection, is that at a high level, what we specify looks complicated.

R

It was complicated in terms of scaling. In particular, some of the exchange require the large number of application or a large number of messages. So I went back to with to the drawing board and say: okay, do we have a fundamental tension between privacy and scaling and what are the trade-offs? And that's what I would like to present here and in order to examine those trade-offs? I looked at three options: the first option is what we are now, which is require a pairing process which leads to pairwise secrets.

R

The second option will be I mean the stupidest it's there for reference, it's not something that actually want to implement, but to say what, if we just add a secret shared by all the authorized clients, but you know the password of the printer, then you can use it, but that's not that stupid.

R

That's actually what most coffee-shop do to let you access their Wi-Fi switch, but that's one possible thing and clearly, because you have something shipped by every client, your your scanning, for what you are going to be different and the third design is to have something based on public key and effectively treat that shared secret use for the chat secret, the public key of the server. So let me justify that for a moment, a public key is a unique identifier.

R

So in any public key solution you are tempted to say: oh, it's, a public key can be public, but in fact, given the way workers are done. If you know the public key of a server, you pretty much can track that server.

R

So for public key solution in a privacy environment, you have to assume that the public key of the server has to be kept under some kind of control, and you can do a basic design in which you do a first I'll. Do that as a theoretical designer, but try to integrate that Indian SSD in any way.

R

But you have a first message, the query message, which is say: hey I'm, looking for this server and you do that by adding sending a hash of the key and the nonce or if you want to spend more cycles like an encryption of the nonce with the public key of the server, but only the server can decode it. And then the reply comes from the server and the replies includes an encryption of the norms with the private key of the server that the client can verify to check that yeah.

R

That's really the server I want to have that gives you a fairly secure protocol and I. Don't know whether people have actually design protocols activities. It's a fairly obvious designer and I will now look at the scaling properties of those three options that we can make informed decisions later.

R

So if I look at that, there are many dimensions of scaling. Okay, the the first dimension is the number of clients that you have for each server.

R

The also dimension is the number of servers that you have forged, client or not. Let's say the same, because there's some kind of a fan-out happening there and a third interesting dimension in terms of network traffic. It's the number of servers that are present in the scope. So, for example, my phone can be paired to 50 other phones for some game application or whatever, but of those 50 game partners. Maybe only five I knew room at a given time, so these are the difference between a M and P in that scaling property.

R

First, the first operation in discovery is publication. I mean there. The server wants to become available is going to publish something like in the DNS mode of DN SSD. The seller will push a set of records that says hey I'm here.

R

Well, if you want to have pairwise keys, you will have one record their third device, so a B n, if you arm to have something which is common to all clients, beat of shared password or public key. You would have just one. So that's so far. Okay, the number of response to a query. If you do dns SD- and you say hey how many server out there that implements service number X and I'm saying that was the ocean design that we have in which the service is specify as to privacy service.

R

Well, in the case, are further the pairing solution. You will receive n times P responses, because, while you have any response per server and your pizza was present and the client will sort out which of those are good in the shared secret, you'll receive one response of every seller, and so in the public.

R

The there is a variation of that that we have not implemented in our draft, but could be done suppose that, instead of making the instance name a function of the norms, you make the service name a function of the notes. So basically servers at the theis random service is randomized service and clients can predict which randomization scheme the server is using.

R

Well, in that case, the clients will receive exactly one end store, and that may be something we want to consider and as well and so in every scenario.

R

We could have client mode in which the client, just not the wide search with one query per server, and that cares basically the no of course goal. Is they the number of servers?

R

Another dimension of scaling there is weather. Caching is possible, so in mdns in particular, we do caching by listening, to responds to auto of clients and caching them, and if you have a pairing, a pairwise secret. You cannot do caching, because each response is manufactured for exactly one client in the shared secret kind of stuff. Then you can do caching, because it will Sam responds to every client.

R

So clearly that gives us some skiing property, which show that are being pairwise. Secret is more expensive, even with optimizations.

R

The next dimension of scaling is not about the day-to-day discovery, but about what happens when things go wrong.

R

Clearly, if you have a sharp a squad with firefight people as long as nobody leaks, it you're, good and in fact, you're good with pretty much every of those design.

R

If you make the hypothesis that all your clients are good, that they will never be compromised and that nothing bad will happen now, if you assume that one client is compromised, you have to do some remediation and the cost of remediation will vary depending on the scheme.

R

If you have a pairwise secret, you will just need to repair one secret. You will need to say all Stewart York is compromised, let's get a new one, but if you have a shared secret, you are going to obviously need to go contact all the clients you had that have that just secret and tell them hey. You know what of our global key is compromised. We have to pick a new one. Everybody has to change so that gives you this cause for radiation them.

R

I say the cost of a radiation on pairing is on the order of the novel of servers that are paid to the client. The cost of a mediation on shelf secrets is that times the number of client per to each of those circles.

R

The consequences of a compromise also differ.

R

Obviously, if you can impersonate the client, you will be able to discover all the servers that the client can discover and that's true for every solution now. The next thing is, can you not just discover the servers but also the clients that are connected to the server and if you have a shared secret like a shot password? The answer is yes, absolutely.

R

If you have pairwise secret or public key, you can do. It depends on your design, but you can do design in which that property is not to in which basically get some good isolation.

R

The next thing is, can I impersonate the paired servers in the case of the pairing? The answer is a flat. No, you cannot investment the server because you only know the key for one client, so you won't be able to invest in the server for the other clients.

R

In the case of the shared secret yeah and in the secret public key. Ok, you can say you can pretend that the server is present and if you pretend that the server is present, you are going to discover the other guys now, in the case of the public. Key I may be a bit pessimistic, because if you pay the cost of having your query encrypt a secret with the public key of the server, then basically you need to have the private key of the server to decrease of secret.

R

So you have a protection tool so effectively. You can say that the pairing and the secret public keys have some seminal property there after the cost of remediation, is higher in the case of the shared public key, because you have to tell everybody that this public has changed.

R

So if I summarize, in the case of the pairing, we have more messages in the case of the public key, but we can repeat that if we make the secret dependent on the device on the service, ID meant. Basically, if we have to do cell excuse me, if you have the service ID depend on the secret of risk. It is by the secret, in which case we are back to order of one.

R

The pairing is good in compromise resistance. The shared secret is definitely something you should not do because I mean it fails catastrophically in the case of the secret public key. It depends if you are ready to pay the cost of more public cooperation. You might be protected.

R

The remediation is easier in the case of the pairwise secret and harder. When you have shared secrets. That's that's pretty much two simile. So if you ask me now not yesterday, I'll go.

O

Into a theater, I think there's another row that you said verbally and I want to confirm that I have the other contents right is the other row is cost of CPU, then pairing and shared secret are basically symmetric and therefore fast by comparison and shared secret. Public key is asymmetric and therefore a slow by comparison is that correct. That is.

R

O

There will be another useful road to say if you're talking about stealing in terms.

R

O

R

Time and power gap that is correct and- and in fact that's one of the weakness of the secret key- is that if you have mechanism in which random people can ask a server to perform a public key operation, then it becomes possible to does that saga.

R

So yeah, that's that's true. So, if you ask me, for my preferences, without constraints, I'll be tempted to go to something like this secret public key class of solution, because it has, it has some pretty good properties in terms of effectively in terms of provisioning. Many pavia, if you want to publish on a client in the case of with a public key, you just have to give them a copy. If you want to polish on a client with a pairwise secret, you have to do something complicated.

R

So that's that's one thing.

R

The one thing which is not clear with any public key solution is whether it fits in the DNS formats like, for example, take the service ID. It's a DNS name, part it's 64 cocktails at most, and and there are not that many public key operations that can fit in 64 characters.

R

Now there may be where around that, like you use an additional text record or something like that, but it's it will require some engineering, okay.

R

So my preference, if we must keep the DNS SD protocol in format, is to keep pretty much the graph that we have and consider 2 simplifications: one go for an application based discovery because it's simpler to implement on ship than the device based solution.

R

You don't have to change the operating system in particular, and the second one is to consider using a secret dependent service type like make the service type of hash of the secret and the nonce, so that you get exactly one and soft work when query which goes for fewer messages and that's better, but that's just my opinion having a I'm waiting for feedback.

A

So, thank you very much. Christian I think this did a really good job of showing the various possibilities we have, and so I'd like to kind of kick off a discussion in a working room where our goal for today would mainly be to figure out requirements as in the use cases that Christian described earlier are those the ones we want to solve. Are there other ones we want to solve other ones that we'll just basically don't want to solve, because at the end of the day, there are quite a few compromises here.

A

There are quite a few options, for example, if you want to do a symmetric or asymmetric crypto and based on what security properties we want our system to have some of these will work and some of these won't. So if people have questions or topics they want to bring up, please come ahead now. Otherwise, I'll start with a few questions, get people's opinion.

A

T

Chris, we'll just a quick query: vine question Chris: what are what kind of constraints are we setting for the type of cryptography using so I Christian, discuss this basic symmetric, key stuff and then standard public key stuff, but there's more there's newer, flavors of cryptography. They could be applicable here particular some work at the endpoint, a and others did from Stanford on this exact problem, private service discovery and they use. You know fancy identity or pairing based cryptography, and maybe we should or should not look at that. There's.

T

It's not at all been discussed in the ITF, but the properties that provides are quite nice. In particular, it gives you stronger identity, hiding when you're advertising or placing service records somewhere and when a sender who our client wants to contact the service when it sends its initial, like whatever request right terminology, would be that's completely hidden and they have Fulton eye ability of actually doing so so I would like to like lobby for including these newer types of primitives and, of course, maybe consulting with the security area or the CFR G to see.

T

If that's something we can start looking at, because there's a certainly room for improvement, so please.

D

Do send a pointer to that the list I don't think they would arrive familiar with that works. Probably the group isn't so yeah.

T

Certainly I have to pour requests, then Stuart's draft, in which there's a pointer to the documents so but I can also circulate a list as well.

D

All right thanks, yes,.

A

I, like Tim, said I'm not personally familiar with these, but I think it's definitely something we should consider. So if you couldn't send us some background and have a few people here, kind of look at it and see that could definitely be of interest thanks.

G

Chris, you asked a question generally of the room. My opinion is, we should not be ruling anything out in principle. We should look at it. We may decide later about what's appropriate or not appropriate or or easy to implement, but but definitely we should not rule anything out before we've looked at I will, as David said, I was not aware of dampeners work. I will add that reference you sent me and I can update the draft. I think this is a relatively new area a few years ago.

G

Nobody rethought about privacy in these cases and I think that's why this is a new field and people are still coming up with ideas and I certainly don't know all the crypto, but that's partly why I wrote that requirements document which asks a bunch of questions without really giving answers, because I don't claim to know what the answers are yet, but I'm hoping we'll find them being developed actually.

A

Yeah, unless you're a jerk you're applying to Stewart, carries in virtual line so Chris is this a reply destroido to something slightly.

N

A

R

For this work June, you were trying.

P

N

At the end of the day, exactly what sort of metadata is being exposed by the roaming client? It seems to me that we cannot cloak the IP of the of the client or the IP of the responder or the fact that the client is doing discovery in the first place. Based on you know, perhaps the port that it's accessing so I, guess at the end of the day, is this work really about cloaking? What the client is trying to discover and what it's getting back? In response? That's number one number two.

N

It seems to me that you know. Obviously one problem: privacy problem with clients is that they should not be advertising any services without the knowledge of the user in the clear. So those are maybe two separate problems that have to be addressed in this work.

R

Thanks Gary! Yes, if you look at the original draft that we do the DNS SD privacy, we listed the set of metadata that are in the DNS SD headers, and you have things like a service name in the clear service instance name in the clear and host name in the clear, and these are independent of the IP addresses. In the case of the coffee-shop scenario, you don't care that much about your IP address. You just got it from the coffee shop, so it doesn't matter. It's not something new.

R

You may have also information back to your MAC address and things like that. Better I assume that somebody else is taking care of that. So really what I'm trying to protect there is the metadata that is specification awaited by the DNS SD protocol.

T

Kind of clarifying the process related question, I, guess, sort of related with. What's your saying is there or what are the plans for collaborating with the security area on this particular problem, because they will of course have very strong opinions about which type of crypto we use or which type of security sign? We have and better to start that earlier, rather than later, yes,.

D

I believe we have had a security review of Christians airing draft, but that was just looking at the specific thing we put before them. It wasn't a it wasn't a broad question of what would you recommend here? It was an evaluation of the approach the Christian and Daniel had taken I. Think we.

R

Had an evolution both of the of the privacy of the discovery and the padding and they say well: yeah, okay, you're. Basically, the high level thing of the the privacy discoveries that we are using a few sketti discovery to find a service, a pirate service and then doing a terrace connections that servicing so basically were using non components. And if you're, using known components, you're pretty much in the clear sure sure.

T

I was mainly asking if we're gonna, not rule anything out, there will be new things that have not gone through the security review process. So certainly like. Can you want to get that pipeline well-defined? So we can start working with them.

A

No absolutely and we definitely plan on asking for their feedback and especially if the new crypto pixie dust that you mentioned, if it hasn't been reviewed by CFR G, yet will need that. Of course,.

O

So follow up on a couple of the comments. Let me start by following up on the comment about: what's old and what's new there's a related field, that's old, because this is only solving half of the problem. Okay, so what's old is if I've already discovered you and I want to open up an authentication channel with you. How do you do that in a way that preserves privacy right and so on? Christians first use case where one side is publicly inside is private. That's the typical case.

O

It everybody does an authentication today and one side is private. Okay, the other cases where both sides want to be private from intermediaries and not reveal their identity. It a case that is a field that has been around for at least 15 years. It originally started as being called the secret handshake protocols and now the new term, as of maybe eight years ago or whatever has renamed as authentication, sorry affiliation, hiding authentication, so eh-eh-eh search for affiliation, hiding, authentication, you'll find stuff.

O

I actually gave a talk at the core working group a couple times ago, where I had a whole slide of a bunch of one bullet references of things in that area. Okay and so I also sent emails to the C FRG saying this is well known in the literature to have affiliation, hiding authentication, but there's nothing any standard or any widely available implementation, but in the research it's been around, for you know eight to ten years, can we do something in the center suite that actually uses with protocols like TLS? So far, nothing's happened yet.

O

Okay and the point is what's new- is to say well this problem that says: I only want to discover things for which authentication would have succeeded. That's the new part of the problem and what Christian and people are trying to address now is how do I discover things for which the authentication using one of those mechanisms or that style of scenario, would have succeeded and I want to discover things that would not have it succeeded right and I want to do that without reviewing the other metadata that Christian mentioned right.

O

That's the part that is relatively new okay, but the discovery is only half of the problem. I have to be able to open up an authenticated session with you know, TLS or whatever else it is, and if the same scenarios are just going to reveal your identity. Anyway, that's only half the problem, okay, and so we actually need work from CFR, G and other people for the other parts of the problem, and so how do we relate to the rest of sag and so on?

O

Yeah we need some work and standards and so on to make sure that say, typical TLS libraries and protocols have affiliation hiding authentication schemes that preserves the identity of both sides right today, usually one side reveals it's at dinner to the other one. Then they establish a session right.

O

That's that's what standardized and widely used today so I don't know if you have a follow up on that, but that was what I talked about and I have a whole slide of different links in a survey in the field if you're, interested and I can point that to the to the list. So yes,.

A

Definitely interested the pointer Tillis will be great.

T

Thanks Chris but yeah just going back to the work of Bonet, they do in fact their solution does provide mutual privacy for both this and their in the for the client and the server by exploiting the fact that there is a dis, private discovery step beforehand, so that these two kind of problems are very tightly coupled. If you do just you know, try to connect to a server and then authenticate.

T

Of course, any active adversary can learn the identity of at least one of the peers, but because you're doing this discovery beforehand, that's not their able to work around it. So it's interesting that you work together like that and I'll just point to the paper soon so yeah.

D

We are somewhat in approaches discussion there, rather than the scope and requirements I think still so maybes, try and step. These are all good points, but maybe just step back a bit to answer some of the questions in Christians deck and we've just David and I are just throwing some.

R

More questions.

D

On the screen so.

R

D

Additional question was.

R

Is and it's pretty much what they've Terrell said is: should we be concerned with the policy property of the actual connection between client and server, and and and that's it, that's a piece of work. My tech is that that piece of work is probably something which is more on the TRS working group than the DNS SD working group, and that's why I did not want to take it here.

R

A

Way, I would rephrase that is as a requirement do we have a requirement that private discovery allows us to bootstrap and authenticate it encrypted channel. So one example that does it lead to assured secret or public keys that we can use for TLS. That would be might be a reasonable requirement. Yeah.

R

If, if you look at the 1213 SSD privacy to have the two fails, do have the second faceted here is a TLS connection, and when we specify that we are very concerned precisely with this kind of TLS leakage, specifically the replay attack I mean if some once we place the your clients, connection, attempt and the server does a handshake. The interior servers handshake reveals the server's identity.

R

So that's why we add basically a shot secret mineral PSK in the original grant, hello that will protect the handshake and allows the server to not do that. Now, whether we want to have that class of solution generalize to also application, that's indeed something we can debate Pertamina yeah. We may want to respond to those four four questions. First,.

A

Okay, so on the first one I think kind of the thematic question is we're building a lot of new infrastructure, Indian SSD, but it's gonna work over unicast and many things, and should we constrain ourselves to have any private discovery need to work with that?

A

Does anyone in the room have an opinion on this topic.

G

The way I read your points and not questions, we're necessarily gonna answer right now, or maybe not even soon, but things to keep in mind on the first one. My my hope is.

G

The answer is probably yes, that wherever privacy mechanisms we develop can also be exercised remotely via proxy, the second one the answer may be: no, because if the, if the privacy solutions that we come up with, involve the responding device doing some crypto operations to decide whether to respond, it can't do that when it's asleep and it may not be willing to hand off its credentials to a potentially questionable sleep proxy that could then masquerade as the sleeping device.

G

That I think it may be question. We can't answer it's a question that we should document that we say the tradeoff. If you're building a super low power battery device, then you don't get these privacy benefits or if you want the privacy benefits. You probably can't do that with something running on the lithium coin cell, because you can't go to sleep so my suspicion is. We won't solve problem number two, but we need to lay out the trade-offs that you get to pick one or the other, but not both.

H

Tompa so teri seems like, in the first case that you are going to limit what you can do if you require that Christian stuff seems to be. You know working independently of that and once you, you have to reveal something to go through a proxy and so you're, obviously going to reveal more than you would have to do it. If you don't so I think, there's two cases here and we might be okay to have a subset that works for the proxy, but it won't be the same as what Christian came up with thanks.

A

Know I think that's definitely a possibility where we have a subset of the privacy work that works across and some of that doesn't I think that's reasonable.

E

And my killer favors, so the last point there: what granularity of trust ie? What kind of trust or we're talking about here, who both what trusts? What.

B

A

Trust I mean if I trust you I, allow you to discover me and then the question is who's. You is it us person? Is it this chat application? Is it your entire device and that's that's. What kind of what I meant by trust is right? Who gets to just get this privacy sensitive information right.

E

That's a tough question because of sandboxing you, some applications I might not want the entire device. Oh yeah, that's an excellent question.

K

This is Dave Robbin. That leads me to my burning question and I've, been sitting here waiting for somebody to discuss um when you talk about granularity, going sort of to an application granularity instead of a device granularity to me and then trying to hide that application. The problem with that is that that application, that's trying to hide the application doing the discovery itself. It's doing it with my MAC address, which I had another application. That did this completely plain text thing over here. That completely identifies me.

K

So what's the point it had this super application. That's trying to secretly find something, but my traffic is originating from a device that has been clearly identified by other leaky things. So in the case of the blood-gas monitor or a printer or a specific function device that has one function and one application. It's easy, because that that random MAC address that he got that's completely private, but it's associated with that one application and that's fine.

K

His entire existence is that one application, but when you have a multi-tenant kind of thing platform, with only one IP address, how do you have any privacy of the apps to me? That's sort of like each app needs to run in its own little virtual machine with its own bridge MAC address and it you know it has its own stack, I, don't I, don't know any other way to do it. How can an app hide without having its own stack its own IP address? That is completely opaque, so I think.

A

I'll attempt to answer that and I think the people at the mic can add to that. It depends what you mean by what we mean by hiding in the in the example or, let's say: I have a phone that is simultaneously trying to print on the coffee shop Network, but also talking to a medical device that I have right.

A

I would be okay if the printing system leaks that my IP address and people know that David's printing, but I would still want to keep hidden the fact that David has this medical device they or that David is running the this medical application and I. Think you, if one leaks the fact that there is an IP, that's sending packets still trying to hide like the name of services. It supports his value.

K

Okay, I would agree that my mind always races ahead to fingerprinting and so I can obviously tell that you're talking to a blood gas device because of its signature on the network, and so therefore I know because I've identified you as David I, can tell by your signature of behavior, of conversations as to who you're talking to otherwise you'd introduce random jitter and all I mean it goes on and on and on right to try and hide your behavior and your signature becomes a whole different set of problems.

K

But if you are one device with a virtual MAC address and a virtual stack and you you've completely privatized yeah, you can tell there's a conversation going on with a medical device, but I can't tell who's doing it. So anyway,.

G

Yeah yeah, we covered a bunch of different topics there. One thing I would say: is you you raise this hypothetical thing as if it was ridiculous, I, don't think it is I, don't think it is I. Don't think it is out of the question that we could imagine every application having its own MAC address and its own user space stack. Now, that's not the work of this working group, but that there is, there is increased yeah Kristi, saying we're going there.

G

Windows has pretty windows, has pretty good mac address randomization, which is Christian's, work and I. Think in the next in the coming decade, we're gonna see more and more awareness, there's been new new rule changes in the European Union about data privacy for customers. So there's a lot of awareness of this and I think stuff like that is going to happen.

G

The question of the granularity came to my mind because of a couple of examples and if I give those it might make it clearer many many, but ten years ago now, Apple launched this service called back to my Mac and it had similar privacy concerns that we used to call it. The Steve Jobs problem that when he checks into a hotel in New York with his laptop running back to my Mac, if it looks up the DNS records for s job members, Mac comm in the clear then the paparazzi can report paid.

G

Steve Jobs is in New York for some business meeting and staying at this hotel. So even back, then we had some rudimentary idea of not wanted to go around broadcasting your identity. This was before the iPhone existed and we didn't have portable devices broadcasting our identity.

G

One of the issues with back to my Mac is it is more or less a per device. Implementation. Laptop computers can have multiple user accounts. They can have multiple people logged in. At the same time, I can be locked in by SSH to a machine that someone else is using and my back to my Mac file system and their back to my Mac file system, we're all in the same file system. Our kernel doesn't support per user file systems, so you better trust what it comes down to. Is you better trust?

G

The other people who share your computer because there is some cross bleed in the backs, my Mac remote file systems and then the other example that I mentioned and Christine mentioned just a hypothetical example, but it makes it clear when my medical app on my phone is talking to my insulin, monitor or whatever it is, and I'm playing some some some free candy game on the iPhone, the people writing the free candy game have no business, knowing what my phone is doing and that really highlights that the simplistic back to my Mac model from 10 years ago is not adequate for today's world.

R

Christianism, oh yeah I mean my comment on your question. That is, that when I walk on privacy, I hear that objection all the time and the object. Let's talk to up the opposition is: why do you bother closing my leak when I can see this leak here well and we will close your sonic? Okay, that's.

E

So there was a comment on jammer from Daniel. Okay, so should a medical device really join a public Wi-Fi network for communicating with the phone, but I think here that it is using Wi-Fi, not the public Wi-Fi right, so it is talking over Wi-Fi, but it's not joining the public Wi-Fi right. That Stewart probably says yeah.

G

Hi Daniel I just ran up to the microphone. The concern we're looking at here is it a lower level than what we might call joining a Wi-Fi network or associating with an access point. If you're transmitting radio signals at all, then other devices in the vicinity can receive those signals, and we want to make sure that even though they can receive them, they can't make sense of what they mean.

E

Michael Lorenzen us so I was also thinking, so this is privacy is I, want, probably want to expose what services I'm doing differently to different devices, users and so on. Is this or is that what we're talking about here as well when it comes to sir, if I see what my device is broadcasting its broadcasting when I come here, sometimes I see my printer at home being broadcast well, why does it do that? It should not probably do that right.

E

So should it announce different services to different people, if I have setup that I know Stewart well and I'm, okay with him printing on my printer and not with someone else, is this part of the privacy discussion is that a policy discussion.

E

It is tied right so, but so so for me, it needs to be quite granular anyway, because I actually want to share some things with some people and I, don't want others to know anything. So its policy / previously discussion and it needs to be very fine. Granular, that's my know.

A

And I definitely agree that this is a positive question. These are the policies that we need to nail down, so we can start finding a solution and I sort of getting the sense that the room agrees that we want find your granularity. So then the finest we have today is probably an application.

A

Am I reading the room correctly if anyone disagrees kind of? Could they share? One.

R

So yeah I mean yes, I mean I I'm kind of convinced that we want to do application. There are also reason to the application like possibility that effect applications can move them from one machine to another, and things like that, that's and, and and yes, I mean I pretty much echo is your turn arises that we should walk for discovery proxy, mostly man, I I I I can't see why we would not okay and that for the slippiest. Now that scenario aya argue that, from the client point of view is not so much and.

R

Such measure dns SD scenario as an mdns in our the first one and basically it's back to the hostname, considered harmful I'll, see the the structure of mdns. As saying slacker, I publish my host name and I publish things like that, which tend to be unique identifiers. It can be talked and there are two live.

R

If you look at the draft at the privacy to aft, we at WestEd by saying that there are really two levels: I mean that does the effective EDM DNS mechanism in which you have, but they are also in the DNS SD publishing mechanism and we should publish a hostname when you publish a service and it's completely under the hood. So.

D

In the example on the screen there that you produce that's a printer and one would imagine the printer is in secret, people can see it it's there. You want to discover it's kind of unsafe public, but certainly well advertised within the organization or building, whereas in this situation, where it's a person, that's where yeah.

E

Attentively, what.

D

An actual embassy and when they each or one or both of those works through a sleeping proxy or a discovery proxies it's.

R

Questionable, but that what I was mentioning is that we to levels is one level which is the specific frame of mdns and privacy and.

E

R

Even I mean the the basics bucket you are. Data is in your OSAP address, because you need to advertise. You need to have a host name to advertise. Your IP address. We can link into services.

R

Well, that should be randomized I mean you should randomize that that you don't leave that information and that's not tied to any of the service discovery mechanism. It's some kind of a low-level thing that we may want to excise, and just do because that it has no influence on the service that hostname never appears on the UI, except on the black hats UI. So.

D

Right from a user's quality that fringe echo in should be called absolutely anything now this needs to be discoverable as the printer, a printer, offering the services. What yeah.

D

So we've got a message: we've got 12 minutes left. We need to do a little recap, so you've already got five or six minutes for anything else. Anyone wants to bring up relevant to this discussion in terms of the points we've raised. There's anything we've missed.

D

So there, and as it stands, the the material we have written in terms of things that are in draft there's what's inception to I, believe of Christian and Daniels DNS as the privacy draft there's Stuart's, essentially, considerations draft talks about many of the things we talked about there and there's the scaling draft.

D

How should we shape capturing these issues going forward? Should we try and bring all this down and distill it into one draft where we describe these requirements drawing from those three sources, whether that might all go into Stewart's existing draft I don't know which could be sucking fresh, but it sounds like we want to get all these things captured in one place and we would like presumably to encourage a couple of other areas to look at it as well.

D

Probably, security and applications would be interested in that sound reasonable and, if so, would that be interested of you who would be willing to help write this and pull the material together guessing Christian and should do it probably Chris? That's good and comment yeah.

J

My name is Nam kovalevskiy. We have been just emulating responding to that cue. Several years ago there was a GU project called webinos that was a cross-domain project and was trying to discover how what kind of all kinds of devices that people will use, including those they're wearing on their body, interact with the rest of the world. With the other things on the body or with things that other people are carrying on their body. There was a concept of like a personal domain or personal zone or cloud.

J

That's kind of just a kind of a bubble around you so as if you're running in a balloon right and these balloons basically would interact with each other or something like that, and maybe there's a lot of use case. Work done that immediately.

D

What's on the screen.

J

Now is well, you know there may be more like that right or they may be in a kind of a separation zone around like these individuals, that that is an entity in itself. That's currently not discovered here on these slides, and maybe it's worth looking worth looking at that I'm just I can share links to that. Yes, but in a place, if you could share that song, the Miriam.

A

I start be very helpful.

R

And I am the Sonic a bit concerned with these scenarios, because you can think of that as a personal cloud. But you can think of that too. As a personal Christmas tree and so.

A

So, regarding the good I'm.

J

Sure that the hiding new research hiding how these synchronizes, together with that concept, could be worth to look at.

A

So, regarding the what might become a requirements document do so Christians Jared Chris. Do you have a preference on which document that would be is storage? The simplest? Do you want a new one for your thoughts?

A

Yeah sounds good yeah yeah.

D

We've got three bodies of text to draw from there plus the discussion today where it goes, I think as chairs we mind, but it's important that the work starts. Moving forward continues to move okay, so I think with just a few minutes left to go, will draw and start drawing to a close. That's been very useful. Thank you. Everybody.

D

There was the one thing I accidentally skipped over, which was the state of some part drafts or want another word I think one of them was the road map which we obviously discussed, and we've agreed here to a doctrinal take to the list.

D

Another one was the discovery broker, which Ted briefly mentioned, but I don't think we formed any immediate consensus on what were the other two. Oh yes, one of them was the sleep proxy or the DNS. Is that something that's ongoing? More okay, so I think.

E

I think we've covered off all.

D

Of those so we're good there, the service, registration, yeah, that'll, obviously push forward, and the recharter in law will help with that. So the things I've got written down here is things you've agreed and maybe some actions just wrapping up the first one was the road map documents being agreed in the room, so we'll check that adoption with the list.

D

The next one was the relay, which I think we agreed to adopt as well. One thing that don't you and I think, however, also offered to have a quick look at that. It's not a not a big document, but if anyone else can review that that would be good as well.

D

The next thing was we agreed it's time the working group had a look at its Charter and we will I think through the list, decide what things need to go into the Charter and maybe what things come out so I think there's one of the things there is the the new unicast oriented work. What things we need there to support that the second one I think will be as David said, there's not much in there. If anything.

D

At the moment on privacy, so we need to add that and I think the third one picking up carries presentation will be to add something in there about into operation or collaboration with st work in other groups, to harmonize things as much as we reasonably can.

D

5Th thing I've got, then is there's probably scope. Has some new document I? Don't think we nail down anyone to specifically work on it at that? It's probably you can probably guess who it might be. We've got some good guidance on deployment in home net, but the deployment in the campus stroke enterprise world some document on guidance on that and that maybe again comes back to the type of thing that came up in edge of cause as well. That type of document would be good.

D

We've had some earlier work and thoughts on it from Tom and Ralph so pulling something together. There would be good, but we don't have any specific anyone in the frame right now in terms of the interrupts with core we've had indication, there's an inter off in April, and details of that will be sent to the lists.

D

I think some participation from this working group in that Interop, which I believe there's going to be virtual, would be a good thing for the group and then the last thing that the privacy work that we've agreed that we're going to pull together a draft, whether it's building on Stuart's existing one or new one, to describe security requirements and to scope that so we can then get a much clearer view of what we're doing with the future work. So I think that's so everything I have. Is that saying right, I'm getting nods for my right?

D

So unless there's any other comments, I think we can close the meeting and thank you everyone for coming along and thanks Barbara for taking the minutes and Michael for jabbering. Thank you. Everybody.

A

Thanks yeah, if you haven't signed the blue sheets, please come up. Otherwise you are in Montreal.