[homenet] Benoit Claise's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-homenet-hncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I moved my DISCUSS to a COMMENT:
One issue to be discussed: the link with the future BCP
draft-ietf-v6ops-reducing-ra-energy-consumption-03, on the same telechat.

draft-ietf-v6ops-reducing-ra-energy-consumption-03 mentions:
   "On links with a large number of battery-powered devices, sending
   solicited Router Advertisements multicast can severely impact host
   power consumption."

>From this document: I see "HNCP operates on multicast-capable interfaces
only"
Do we expect battery-powered devices in homenet? I guess so: my phone for
example.
I discussed this topic with Mark Townsley, who is on it already.

Discussing with Terry, we believe that some words that highlight the
awareness of
draft-ietf-v6ops-reducing-ra-energy-consumption, and that any homenet
implementer should be cognisant of the impact on battery powered devices
is certainly sane.

=================================================================

   As HNCP uses DNCP as the actual state synchronization protocol, the
   applicability statement of DNCP can be used here as well; HNCP should
   not be used for any data that changes rapidly and constantly, and
   locators to find such services should be published using it instead.
   This is why the naming and service discovery (Section 8) TLVs contain
   only DNS server addresses, and no actual per-name or per-service data
   of hosts.

What is it in in "using it"? If DNCP, then it contradicts
https://tools.ietf.org/html/draft-ietf-homenet-dncp-12#section-1.1:

    However, there are certain cases where the protocol as defined in
    this document is a less suitable choice. ...  frequently changing
data:  DNCP with its use of Trickle is
    optimized for the steady state and less efficient otherwise.

Chatting with Mark Townsley, he proposed some clarifying text:
    HNCP should not be used directly for data that changes rapidly and
constantly, though
    stable locators to find such data by other means may be advertised
within HNCP.



- Each HNCP router MAY obtain external connection information such as
   address prefixes, DNS server addresses and DNS search paths from one
   or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
   static configuration. 

If you know pf the YANG model already, you should mention it.


Below is Sheng's OPS-DIR review.

1. HNCP describes Prefix and Naming configuration. But it is not very
clear how they are matched in the DNCP architecture. It would be help to
understand if some description using DNCP architecture, like node state
and network state, etc., could be added.

2. It would be very useful to add a bootstrap and configuration procedure
of HNCP. So far, this is not clear.

3. Section 6.5 "only the one published by the node with the highest node
identifier". It is not very clear how to compare the value against node
identifier.