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

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