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. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet