Minutes interim-2018-homenet-01: Tue 16:00

Meeting Minutes Home Networking (homenet) WG
Title Minutes interim-2018-homenet-01: Tue 16:00
State Active
Other versions plain text
Last updated 2018-08-21

Meeting Minutes

   20180821 IETF homenet wg interim meeting
Agenda/minutes template


Call details:
https://ietf.webex.com/ietf/j.php?MTID=m2f68121c49aaf07cc3bb11571ca55c1c Jabber
room: xmpp:homenet@jabber.ietf.org?join etherpad:
        (raw minutes still there)
Chairs - didn't forget to hit "record" button:-)


- Barbara Stark
- Stephen Farrell

- Ted Lemon
- Daniel Migault
- Barbara Stark
- Stephen Farrell (SF)
- Michael Richardson (MCR)

Minute taker:
- chairs + help


1. Agenda bash
2. Discuss document location (github vs. Google docs) and format
3. Identify/progress issues with
4. AOB


(As always discussion at interims is to be confirmed or not on the

1. Agenda bash

Added item to discuss document location (github vs. Google docs) and format.

2. Github.com vs. google docs

(Notes on this may be sketchy, SF had audio issues while taking notes)

Conclusions reached:
-  create a github.com repo for this document
        - DONE https://github.com/ietf-homenet-wg/simple-naming
- Agreed to use github's issue tracker for issues.
- Main editor (Ted) will also keep a google doc version that he'll
  sync up with github.com frequently.

3. Identify/progress issues with

The group dived into issues prompted by MCR's review...

MCR issues:
    - service discover broker (ref #17), biggest process question, draft
      expired 2017, not updated, not adopted by dnssd yet, and a key part of
      this doc
    - how's that gonna work?
Ted: doc expired 'cause...  lack of Stuart cycles to update this document, and
     document has not been high priority.
Ted: suggests "hosts in homenets don't have to use mdns at all"
     discovery broker and/or discovery proxy may  (may or MUST?) do mdns for
     you (the host)
MCR: but if I have a device now that can do mdns but doesn't know about
discovery broker,
     would the discovery broker give me answers?
Ted: no, discovery broker would only answer on local link, don't think there's
such devices MCR: Linux/avahi currently tries mdns that way now Ted: "we should
find a way to fix that" MCR: yep, but exists, what can we depend on in host
Ted: macs, android, iphones currently don't have that problem (SF missed what
Ted said they do do) MCR: trying to avoid issues (if they exist) for e.g.
deployed media servers and TVs Ted: with 2 routers doesn't work today MCR: with
1 router... Ted: if 1 router it'll work MCR: shunners (SHNRs:-) co-located with
discovery proxy in my one router will work ok Ted: expects shunner and
discovery proxy to be one bit of s/w Barbara: are hosts supposed to find
shunner/proxy and then stop doing mdns themselves? Ted: they don't have to but
could MCR: how does host know it has a shunner/proxy Ted: you (host) don't see
those as different Ted: RFC6763 tells you how to discover local browsing
domains Ted: homenets REQUIRED to provide single domain search list and you're
supposed to use that to discover DNSSD info Ted: @ietf102 could use that MCR:
people have been trained to ignore that (for security reasons) Barbara: is
search-list in RDNSS (RFC8106)? Ted: it's in DHCPv4 and RA and (in principle)
DHCPv6 (discussion of current domain search list from DHCPv4) Ted: we could
define new RA/DHCP options but he doesn't think we ought... MCR: easier with
RAs, host can get more RAs and DHCP as it happens
        ACTION (Ted): go check what devices actually do with search-domain
Ted: this draft has to match what devices actually do
MCR: propose new section between 4/5 called e.g. "assumed device behaviour"
with a fair few references to RFCs, e.g. not using search path for DNS but
search path is available (for this..) MCR: if there are new behaviours we'd
like devices to do (but can't depend on yet) we could describe those too Ted:
doesn't like a new DHCP option or RA option as zero devices support that, if
existing search domain doesn't work another approach (rdns based) may be
needed/wise (SF not clear on what that new rDNS scheme may be) MCR: would like
a couple of diagrams showing SHNR(or whatever they get called) MCR: and say
things like "we know we have a SHNR if.... " and an appendix saying what
a host does when it has no SHNR MCR: suggests that appendix could say "that
host can then continue to do mDNS it if finds no shunner" MCR: what does a host
do if it finds a browsing domain on one i/f only Ted: treat as separate domains
(but it only has 1?) MCR: how can I tell in RFC1918 space via rDNS that there
are zero, 1, more shunners with >1 i/f on host? Ted: answers about when you
see 2 shunners ... Ted: how do I know the name of the homenet, suggests use DS
MCR: ULA could provide indication MCR: suggesting RRSIG may differentiate
different homenets Ted: suggests depending on key uniqueness (SF: I have seen
re-used keys:-) Daniel: we've been chatting about behaviour from host
perspective, we also need to describe from router perspective MCR: yep, would
like a section that declaratively says router will do things a,b,c. ... so
implementers/vendors can say thay do/don't  do 'em MCR/Ted: We will continue
having in-depth discussions like this one in the next call (and subsequent
calls). SF: Ted, please list actions you have identified.

Summary of ACTIONs for Ted:
    - check out what current devices do in terms of discoverying search domains
    - add section called something like Assumed Device Behavior.
    - add appendix about what hosts do when browsing domain discovery fails
    - how to distinguish different homenets when they have the same domain name
    (suggestion: different ZSKs, even if both using same /24) - section that
    enumerates all the things homenet routers do

Target date for those actions?
        Ted: says he'll progress those before Sep 4th meeting
And are we gonna post 'em as "issues" in GH?
Ted will contact Carsten (has already done this) to get current xml converted to
Kramdown (MD). Then send resulting MD to Barbara to create homenet-wg github
repository with Ted and Stuart as repository team.

MCR: should s/automatically/autonomically/ be done in tihs draft? doesn' want
answer now but will ask again later

MCR: have more notes happy to process later (we do have email too:-)

3. AOB

None. Adjoured after ~55 mins.

Next meeting Sep 4th.