20180821 IETF homenet wg interim meeting ======================================== Agenda/minutes template Logistics: ========== Call details: https://ietf.webex.com/ietf/j.php?MTID=m2f68121c49aaf07cc3bb11571ca55c1c Jabber room: xmpp:homenet@jabber.ietf.org?join etherpad: http://etherpad.tools.ietf.org:9000/p/notes-20180821-homenet (raw minutes still there) Chairs - didn't forget to hit "record" button:-) Attendees: ========== Chairs: - Barbara Stark - Stephen Farrell Present: - Ted Lemon - Daniel Migault - Barbara Stark - Stephen Farrell (SF) - Michael Richardson (MCR) Minute taker: - chairs + help Agenda: ======= 1. Agenda bash 2. Discuss document location (github vs. Google docs) and format 3. Identify/progress issues with https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02 4. AOB Minutes: ======== (As always discussion at interims is to be confirmed or not on the list.) 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 https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02 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 this 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? Yes. 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.