20180904 IETF homenet wg interim meeting ======================================== Logistics: ========== Webex details: https://ietf.webex.com/ietf/j.php?MTID=m93d597f51ac4742c67534735e694958c Jabber room: xmpp:homenet@jabber.ietf.org?join etherpad: https://etherpad.tools.ietf.org/p/notes-20180904-homenet Meeting was recorded and participants were informed of this fact. Attendees: ========== Chairs: - Barbara Stark - Stephen Farrell Present: - Michael Richardson - Ted Lemon - Daniel Migault Minute taker: - chairs + help, in etherpad Agenda: ======= Published at: https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-03-homenet-01/ 1. Agenda bash 2. Identify/progress issues with https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-02 3. Next call: 11:00-12:00 EDT; September 18, 2018 4. AOB Minutes: ======== 1. Agenda bash There were no changes to the agenda. 2. homenet-simple-naming Working from current version in Google docs. Contact Ted for access to Google docs version. Much live editing of google doc during call. In section "# DNSSEC Validation" - Addressing "trust" issues with zone signing and key signing keys - N routers on homenet (N>2) each with a DNSSEC key pair, - cross signing causes combinatoric explosion that we need to avoid Three things: 1) HNCP attribute to announce keys from a router. 2) HNCP election of a primary and secondary home.arpa name server. 3) a description of how the validation of KSK (key-signing key) and ZSK (zone-signing key) is done. In section "# Expected Host Behavior" is some description of host behaviors. But there is more host behaviors in "# HNR Behaviors". Ted will make sure all host behaviors are in one place (in the "# Expected Host Behavior" section). Various aspects of those sections need checking vs. currently deployed OSes Under "# Implementation" section are HNR requirements. Group discussed whether DHCPv6 server/client capabilities were required. Agreed it would be preferred if they were not required for purpose of simple-naming, and if all needed DNS info could be provided by RA and RDNSS. Need to check further on some OS support for RDNSS. If DNS info provided by DHCPv6 and RDNSS, then they need to supply the same info. Process-wise, add an "implementation status" section, (a ala RFC7942) that we can validate before publication - e.g. things we note about DHCPv6 may have changed by then MCR: for next call, work on some diagrams for section 7 to illustrate the problem we're solving and give us some names of things to talk about? All: good idea. Not sure of mechanics? Barbara: for next call, sync google doc to github? Ted will do that before next call 3. Next call: 11:00-12:00 EDT; September 18, 2018 4. AOB