Re: [dnssd] Draft minutes of IETF 101 WG meeting

[Tim Chown <[e-mail]>]

Hi,

These minutes are now uploaded as final.

Best wishes,
Tim 

> On 22 Mar 2018, at 18:40, Tim Chown <[e-mail]> wrote:
> 
> Hi,
> 
> Please review the draft minutes by Thursday 29th March.
> 
> See: https://datatracker.ietf.org/meeting/101/materials/minutes-101-dnssd-00
> 
> Also attached below.
> 
> Many thanks again to Barbara for taking minutes, and Mikael for Jabber scribing.
> 
> Tim 
> 
> 
> 
> DNSSD WG Minutes
> 
> IETF101, London
> Thursday, 22nd March 2018
> Buckingham Room 09:30 - 12:00 local time
> 
> Chairs: David Schinazi, Tim Chown
> Notes: Barbara Stark
> Jabber: Mikael Abrahamsson
> 
> -------
> Chairs Introduction
> Tim Chown presented the Chairs' slides
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-chairs-slides-04
> There was no bashing of the agenda.
> ------------------------
> Status Reports
> Stuart Cheshire presented DNSSD Document Status Update
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-dns-stateful-operations-push-and-discovery-broker-update-00
> 
> Tim: any questions on DNS push?
> Thumbs up from Andrew Sullivan
> Tim: Any comments? <There were no comments.>
> Tim: Is there any reason to hold the documents up? Do we need more implementation experience?
> Stuart: Ted and I are working on implementation. We expect to have code running at the Montreal hackathon.
> Tim: Anyone else implementing? <some hands were raised>
> Stuart: There is a team at Cisco that have an implementation. And Marcus Steinberg has been working on an implementation.
> Tim: OK, so implementations can proceed in parallel with IETF process
> 
> Tim: How many are in favor of adopting the roadmap document as a WG text? <all hums were in favor>
> 
> ----------------------
> Update to Multicast DNS Discovery Relay, 
> and Simple Homenet Naming and SD Architecture
> 
> Ted Lemon presented DNS-SD Discovery Relay
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-dns-sd-discovery-relay-01
> 
> Tim: Has anyone read it? <not many hands>
> Tim: Will anyone read it? <some hands were raised>
> Stuart: I think it's a fairly new document so people haven't had much of a chance to read it yet. But I think it's good. I appreciate efforts from people in Cisco to do implementations. I think it makes a lot of sense and that may be why we haven't received much feedback. It fits naturally.
> Mikael: Do you know what version of OpenWRT you'll be working in?
> Ted: It's easy to integrate into anything.
> Mikael: Good to make it stable separate from OpenWRT.
> Ted: Good feedback.
> 
> Tim: All in facor of adopting as WG item? <all hums were in favor, none against>
> 
> Simple Homenet Naming Architecture
> Ted Lemon presented Simple Homenet Naming Architecture
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-simple-homenet-naming-architecture-01
> 
> Tim: Note this is already a homenet WG item. Going back to slide "Our ask for DNSSD WG". Any thoughts on these? Unicast/multicast position?
> Stuart: I wanted to expand on something Ted mentioned. Home automation, IoT are increasingly popular in homes. When you have a mesh it gets really hard to multicast. Personally, this is an area I think is important and will be working on. We will need this.
> Mikael: Yes we should move away from multicast. There are multicast issues with radios.
> Stuart: You make a good point. We will have cases where there is old and new, and mesh with all new. We need to have a solution ready.
> 
> Tim: Maybe it's time to renew our charter and and some items on this?
> Terry Manderson: <as AD> I'm willing to listen to the WG members and add this.
> Mikael: We need to make sure we're not reducing or impacting the experience others are trying to create.
> Tim: This can complement work in CoRE, etc.
> Stuart: <to Tim> Please send email to list with link to Charlie Perkins work.
> 
> Tim: We will take work on charter to the list. As for this draft, how many have read? <not many hands> It may be early for adoption? But it would be good for people to review?
> 
> Stuart: I agree it's not time for adoption but discussion on charter is good.
> Ted: I didn't want to get too deep into adoption discussion. DNS-SD has done a good job at addressing machinery of how to get interconnected devices to just work. Especially for EDUCAUSE case.
> Tim: It would be good to have equivalent viewpoint to what you are doing in homenet for enterprise.
> 
> Tim: Agreement was to work on update to charter. After that we will see which document we need to adopt.
> 
> --------------------
> CoRE Resource Discovery: DNS-SD mapping
> Kerry Lynn remotely presented CoRE RD and DNS-SD mapping
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-core-rd-and-dns-sd-mapping-01
> 
> Kerry: <speaking to the title slide> This is to harmonize work being done in CoRE with DNS-SD.
> 
> Dave Thaler: How do you derive structure from info in OIC?
> Kerry: I don't know. We're just starting. If we could have federated name scheme it could help us avoid having to document separately.
> Dave: I don't know why you would need that.
> Ted: Have you considered advertising CoRE as a DNS-SD service? -- if I were thinking  about how to get CoRE and DNS-SD together, I would do it another way.
> Kerry: It's clear it would be good to have more interaction. We will have interop.
> Christian Amsüss: Interop plans are not yet set in stone, but it will be virtual, in April
> Kerry: Just to advertise something as being CoRE or CoAP capable may not help.
> Stuart: Yes we could help with communication. Key challenge is the mapping of services, need common vocabulary to describe services.
> Christian A: one use case we're considering is a group of resource types that are offered over HTTP - advertise them over DNSSD to allow non-core devices to interoperate
> Barbara: We have something at Broadband forum that uses CoAP but doesn't do DNS-SD this way. It does have specific DNS-SD naming scheme. I will send you link to info.
> 
> --------------------
> DNS-SD Privacy requirements and scoping discussion
> Christian Huitema presented DNS-SD Privacy Scenarios
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-dns-sd-privacy-scenarios-00
> 
> Stuart: You can't assume devices in Scenario 2 were set up by same people.
> Christian H: You are right. Same requirement but not same scenario.
> 
> Christian Huitema presented DNS-SD Privacy Scaling
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dnssd-dns-sd-privacy-scaling-00
> 
> Dave Thaler: It would be useful to state comparative CPU requirements / speeds of solutions.
> Christian H: Yes
> 
> David S: Thank you. I'd like to now see if we can figure out requirements. What do we want to solve. What don't we want to solve. There are many compromises and options here.
> Chris Wood: There are newer flavors of cryptography that could be applicable here. Maybe we should mention that.
> David S: That's something we should consider. Please <to Chris> send info to list.
> Stuart: We do not wish to rule anything out just yet. I think this is a relatively new area.
> Kerry: I tried to understand what metadata is exposed by roaming client. You can't cloak the IP address. Will this be about cloaking what the client wants and what it gets back? And do we want to address that the client should only be doing what the user wants.
> Christian H: <described what header elements should be in the clear> Trying to protect metadata in DNS-SD protocol.
> Chris Wood: There will be new things that have not gone through this process.
> Tim: We have had a security review of Christian's initial pairing doc, but not a broader view on the topic as a whole from them
> Christian: We are protecting the metadata
> David: Yes 
> Dave Thaler: Discovery is only half the problem. I can discover you and open a channel, but are both sides private?  This topic, as secret handshaking protocol research, aka affiliate hiding authentication, has been around for years, but no standardised protocols. Need to make sure we preserve the identity of both sides. I have info I can send pointers to.
> David S: Yes please send.
> Tim: Need to answer some of the questions in Christian's slide deck.
> Christian H: There is a deeper thought that I have not brought here.
> David S: Do we have a requirement that private discovery can lead to bootstrap?
> Christian H: We have added solution to protect handshake.
> David S: On first one <item in dash list on DNS-SD Privacy Discussion slide> does anyone have an opinion on the topic?
> Stuart: On first one, my answer is probably yes. On 2nd the answer may be no.
> Tom Pusateri: Christian seems to be working independently of what you describe. It might be okay to have a subset of the privacy rules.
> David S: Yes, that might be possible.
> Mikael: What trusts what?
> David S: If I trust you I allow you to discover me. But who are you? Person? Device?
> Mikael: Yes.
> Dave Robin: What's the point in having this secret application that is clearly identified by the identity of the device? Problem is with device that has multiple independent applications.
> David S: It depends on what you mean by hiding. <provided an example of printer talking to medical device>
> Dave R: I can tell by behavior who you are talking to.
> Stuart: Imagine every application has its own IP address. Windows has good MAC address randomization. We need additional rule changes by regulators on using these tools. 
> Christian: This will evolve (IP and MAC 'randomisation')
> Daniel Kaiser <relayed from jabber>: Should a medical device really join a public WiFi network for communicating with, e.g., a phone?
> Mikael: When I come here I sometimes see my printer at home. Why does it do that? Is this privacy or policy? It needs to be granular. I want to share some things and not others.
> David S: We need to nail down some of this so we can define solution.
> 
> Tim: There are various drafts. How should we capture these issues going forward? Put into one draft drawing from these 3 sources? Who would be willing to help write? <Chris Wood, Ted Lemon and Stuart Cheshire raised hands>
> 
> Normen Kowalewski described 'personal cloud' device privacy based on some EU project work
> Christian H: I am concerned with this scenario.
> Normen: Other concepts should be looked at.
> 
> David S: Are there preferences as to start from one of the existing docs or start new? TBD.
> 
> ----------------------
> Wrapup
> 
> Tim: Actions:
> 1. Adopted roadmap -- check with list. 
> 2. Adopted discovery relay -- check with list; Barbara to review
> 3. Continue work on sleep proxy and discovery broker
> 4. WG to review charter with a view to update -- discuss on list to see what goes in and out of charter; e.g., privacy, unicast/multicast, CoAP interop
> 5. Continue to harmonize with other groups on CoRE work; seek to have WG presence at April CoRE RD interop
> 6. Need volunteers to produce guidance on naming architecture for enterprise like work done in homenet.
> 7. Need to pull together a new privacy requirements draft
> 
>