Hello Benoit,
thanks for the review. On 18.11.2015 15:20, Benoit Claise wrote: > 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. DNCP (and thus HNCP) uses multicast only for unsolicited messages, e.g. messages triggered by Trickle. Every solicited message (= reply to a multicast or unicast packet) MUST always be sent using unicast. This is mandated in the DNCP draft. So I think there should not be an inherent conflict with this draft here. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. Okay we will discuss this one in the coming days and try to come up with something more clear. > - 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. We don't yet, but it would probably be something defining network interface related. I will try to investigate if there is a relevant RFC already that we could reference. > Below is Sheng's OPS-DIR review. Sorry, that somehow slipped through my radar until today, I just sent a direct reply to that mail-thread. Cheers, Steven _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
