Minutes IETF105: dnssd
minutes-105-dnssd-01

IETF 105 DNSSD Minutes
* Montreal, Canada
* 2019-07-25 13:30-15:30 (EDT) (Thursday Afternoon session I)
* Meeting Room: Duluth

Chairs: David Schinazi, Barbara Stark
AD: Éric Vyncke
Jabber: Tim Wattenberg
Notes: Michael Richardson, Christian Amsüss

============== Agenda + Notes ==============

## Introduction (Chairs - 15 minutes)

Chair slides
https://datatracker.ietf.org/meeting/105/materials/agenda-105-dnssd-03
Github organization
https://github.com/orgs/dnssd-wg/

Today's session goals: See agenda, plus future plans.


## Update on DNS Push (Stuart Cheshire - 15 minutes)
https://datatracker.ietf.org/meeting/105/materials/slides-105-dnssd-stuart-cheshire-update-on-push-00
  * draft-ietf-dnssd-push
	  - TLS close_notify vs. TCP reset
	  - Allowing subscribe request in TLS early data?
	  - Implementation report and demo

Publication requested, feedback received and updated.
What's new:  reality is that anything that connects to a server that does not
support push, should limit how often, and the document now talks about this.
Also advice about when to use TLS early data.

Discussion about TLS close_notify thread...
Document now details when to TCP RST, when to use retry, etc.
Duplicate SUBSCRIBE messages might be benign, or might be okay,
but we want to make sure it gets flagged and fixed.

hackathon: Ted, Barbara and Stuart had a productive time at the Hackathon
working on the DNS responder for Mac, Linux and OpenWRT (prebuilt packages).
Did demos and everyone can dogfood this at home.
https://github.com/IETF-Hackathon/mDNSResponder

Barbara: Friday Code Lounge at 10:00. will try to plug things together.
Michael Richardson (MCR): Stuart, you have plugged the device's wired WAN port
into home device, creating two layers of routers, and on inner port can now
see the outer devices?
Stuart: yes!  (He goes on to explain benefit to Wi-Fi bandwidth)

Ted explains that you want to do a build before Friday, because it takes more
than 2 hours to build everything.


## Discovery Relay (Ted Lemon, 5 mins)
https://datatracker.ietf.org/meeting/105/materials/slides-105-dnssd-dnssd-discovery-proxydiscovery-relayservice-registration-protocol-00
  * draft-ietf-dnssd-mdns-relay
	  - Implementation report
	  - Future of the draft

Ted explains features of this software in slide 2.

Stuart Cheshire: Discovery Proxy is valuable for OpenWRT. Convincing enterprise
routers to include it will be a harder sell, and maybe not a good idea because
it will never be updated until end of lifetime.  Tom asked about usability of
VLANs instead. If configured, makes sense -- should add paragraph on how to
choose one would be a good addition.
David on document: Already adopted, WGLC failed for lack of interest.
Nobody but authors had much interest. So chair question: If this is aimed at
enterprise market, is there anyone from there who would say this is useful?
As chair believe it's a good document, but to proceed as WG document needs
more voices.
Tim Wattenberg: If this is intended for enterprise vendors, then those routers
probably can do VLANs. Would be interesting to hear good use cases not covered
by this. No particular idea of whether good or bad. If not aiming for consumer
but enterprise, question is whether it can't be solved in another way already.
MCR: Sorry about silence there. People this is targeted at may not be in this
room. This would be attractive for companies with farly remote locations. Even
if there are VLANs, multicast is probably turned off over ancient frame-relay
satellite links.

Barbara: Which WG would you suggest?
MCR: Maybe EMU, as the architecture is similar in how 802.1x works and EAP is
backhauled over radius, not via VLANs/

David/Barbara: Update the document, and we'll start another WGLC.

Stuart: It's only 29 pages, no more than an hour to read. If people have
uninvolved contacts in enterprise, please pass on contacts so we can contact
individually.
Tom Pusateri: Operators know how to troubleshoot VLANS and they learned how to
troubleshoot BOOTP relays but a Discovery Relay is different and they won’t
know how to troubleshoot it. Another way to do this: IGMP proxying over a
tunnel, and AMT. Compare approaches.

Ted: Just to clear this up: There are two things. Discovery proxy is smart and
does multicast resolution, Discovery Relay is the dumb thing just forwards.


## Service Registration (Ted Lemon, 15 minutes)
  * draft-ietf-dnssd-srp
	  - Latest updates to the draft
	  - Tom Pusateri’s comments
	  - Implementation report
	  - Future of the draft

SRP updates services.arpa -> service.arpa  makes more sense to Ted, so seems
like the right way.  TLS supported.  either we say: "SRP update" / "RR update",
or we say "RR Add" -> maybe **Register** says Tom Pusateri
Tom: Call it an SRP Registration instead of an SRP Update.
Ted: OK, I'll do that.

Should we require TLS support?
Tim: YES.
Keith Moore via Jabber: Yes, require TLS always, even on LAN.
Bernie Innocenti: Who signs the TLS certificates?
Ted: Opportunistic.
Bernie: TOFU?
Ted: Would need to describe how to do that, but would like to use DANE but
not ready yet.

MCR: But you were already running over TLS.
Ted: This is trying to solve a different problem.
MCR: I don't think this is a useful feature. No device so constrained that it
can't do TLS should be doing this. The gateway can be the thing that is the
translator.
Ted: This is not to do some mapping between Core and SRP.
MCR said stuff that will get repeated on the Mailing list :-)

Stuart says that the Thread group does not have a discovery protocol, but rather
assumes the cloud does stuff. Homekit is not interested/has-not-deployed such a
system, and wants it to work in the home without cloud help.  Stuart suggests
that the Thread world could provision a mesh local address for SRP updates.  Ted
agrees; suggests that this would work well.

SLEEP PROXY: MCR suggests that unless the document is too big, or unless Sleep
Proxy can exist without SRP, then it might as well be in the document, and the
IESG will be happier with fewer documents.
    
Ted: SRP registrations are the same for all use cases, to DNS server, to
constrained network border router, or to SRP sleep proxy)

Tim Wattenberg: Agree with previous statements. Good to have things in one
document but clearly separated, because too many documents don't make it better.

And now for something completely different: SRP protocol on 802.15.4 development
board. (<10K of code) Tim wrote a simple SRP client at the IETF 102 hackathon.
However, it does not do SIG(0) for update.  Also implemented SRP proxy;
receive SRP updates on port-53, and update a zone with DNS-update.

Tom Pusateri brought up the issue, that we might wanna have a de-registration as
well (if a service is taken down before the end of the lease lifetime).


## Future of the Working Group (Chairs - 30 minutes)

David brings up option to move the privacy work to another WG and close this WG.
Feedback: Stuart: agrees with what David is saying.  Privacy is really
important, and there is a lot more awareness of privacy.  Thought about the
questions about how to discovery in the privacy preserving way.  If there are
other people in the WG with good ideas, then happy to support that.  Would not
like to wrap up the WG just as the world is realizing that there is privacy.
Ted: attended a side meeting on Wednesday, the NETUP(?), some of those people
might be interested.  Distributed something Privacy.  Ad-hoc privacy... Sounds
related says David.  Work to come up with ways to do ad-hoc keying... Daniel
Khan-Gilmore, encrypted email that doesn't suck (but has a good experience).
There are synergies involved.

Christien Huitema: has been trying for some years to get the privacy work
started in this WG, and had come to the conclusion that it isn't going to
happen.  We have done some work that needs to be published, and he would like to
find a way to publish the requirements documents.  But as for the solution, but
they have to come organically from the other groups that are doing discovery.
David asks how many have read document... (about 10)
Christian notes that the document expired, but can be revived.  

Michael McCool: WoT co-chair in W3C, and want to do it in a privacy preserving
way.  But fundamentally need a discovery service to distribute metadata.  The
real question is, where does this work belong?  In DNS, and also there one in
Core (RD).  Two questions: what are the available services, and how do I find
the service.  But, some have said that if it's published, then it's already
leaked.  maybe DNS should only be the springboard to a controlled service that
does not leak.

Tim Wattenberg: the WG does valuable work, and we are not finished, so closing
it down does not make sense.  There is a problem with lack of participation on
the ML.  Today we got good discussion on the topics.    Tom probably didn't want
the WG to shutdown, but was making a wake-up call.  Can not answer how to get
the people in here.

Éric Vyncke: Lack of interaction on privacy is concerning, good that reviewers
showed. Document can stay here, but publicity to other WGs (DPRIVE) is good,
people with privacy knowledge are there.
David: Tried that, got little support from IETF community at large, nobody came
here. Maybe they care about privacy but not in this context.
MCR: SAAG is running right now, we're in conflict. People you wanted are over
there. Would have gone there but thought this was interesting having read
Christian's documents. Was unaware documents were stalled. Yes WG has
difficulties, but not point to give up. Let's get SRP published. We're not done,
encourage Christian to resume.

Barbara: We would probably have been supposed to forward existing discussion
to support rechartering.
Ted: Support what Mike said. Missed TLS often because it was opposite DNS-SD.
Likelyhood to get deepply committed  privacy people opposite any SEC area is
minimal. Doesn't have to happen at IETF meeting. Could present at HotRFC.
W/rt energy on documents: reviewed all, sent substantial comments, then stopped
seeing new versions. Not blaming anybody b/c done same things being busy on
implementations. Lots of expertise in room, would be shame to disband. Clock
rate of this WG is not 3x/a. It appears it's because it's not that fast. Not a
reason to disband.

Barbara: In Singapore we could have a joint meeting with HomeNet?

Stuart: HotRFC would be great opportunity. Sec Area listed as a conflict.

Tom Pusateri: Doesn't take a lot of work to say "I think it's good". Who are we
doing this for? Initially people came with problem to be solved. Those are
gone -- are they deploying it? Ask they vendors to implement it so they can
deploy it? Need to answer that.

David: What's actually supported in handheld devices?
Stuart: Ted has been working (as contractor, now full time at Apple)
on implementing this in mac- & iOS. iOS 13 and macOS Catalina have a fully
functional push notification client. Connects to OpenWRT router. Pleasing to
turn services on/off and see it working.

Tom: Implementers went ahead and solved the problem in switches and routers in
non-optimal way; those solutions are deployed today in campuses. Have to find
compelling reasons to stop that and start this.
MCR: Implementation question: Will I discover devices at home when connected
via VPN?
Ted: Yes.
MCR: Wonderful. Killer app.
Ted: When demoing at Apple, used that feature. Printout over Internet from
California. Had IoT camera pointed at it.
Stuart: Ted did demo for guy in charge. Didn't think it makes a difference
because had a slide. But something about showmanship -- whole room in applause.

David: Feels to me that consensus is on still being energy, not crazy fast but
OK. Keep things open, keep shorter meeting in Singapore, joint w/ Homenet.
Depend on what we get on agenda. Please don't wait for day before meeting.

Ted: announcing DNS-SD homenet interaction for Singapore.

## Conclusion (Chairs - 5 minutes)