Minutes interim-2018-homenet-03: Tue 11:00

Meeting Minutes Home Networking (homenet) WG Snapshot
Title Minutes interim-2018-homenet-03: Tue 11:00
State Active
Other versions plain text
Last updated 2018-09-06

Meeting Minutes

20180904 IETF homenet wg interim meeting


Webex details:
https://ietf.webex.com/ietf/j.php?MTID=m93d597f51ac4742c67534735e694958c Jabber
room: xmpp:homenet@jabber.ietf.org?join etherpad:

Meeting was recorded and participants were informed of this fact.


- Barbara Stark
- Stephen Farrell

- Michael Richardson
- Ted Lemon
- Daniel Migault

Minute taker:
- chairs + help, in etherpad


Published at:

1. Agenda bash
2. Identify/progress issues with
3. Next call: 11:00-12:00 EDT; September 18, 2018
4. AOB


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

3. Next call: 11:00-12:00 EDT; September 18, 2018

4. AOB