Home Networking Control Protocol
draft-ietf-homenet-hncp-10

Note: This ballot was opened for revision 09 and is now closed.

(Terry Manderson) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-11-19 for -09)
No email
send info
I support Brian's Discuss.

1)  In Sec 1.1, it states "...in homenet environments where multiple IPv6 
   source-prefixes can be present, routing based on source and destination 
   address is necessary [RFC7368]."
  
   Looking at RFC7368, I don't see anything that matches the strength of this
   assertion which says in Sec 3.2.4 merely  "Another avenue is to introduce support
   throughout the homenet for routing that is based on the source as
   well as the destination address of each packet."

   While src-dest routing is certainly a solution - and an interesting one - it doesn't
   seem at all appropriate for an HNCP spec to assert that it is necessary.

2) For the DNCP profile,  draft-ietf-homenet-dncp-12 says  "Anything received over multicast, except Node Endpoint TLV (Section 7.2.1) and Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST ignore all Node State TLVs received via multicast
 on a link which has DNCP security enabled in order to prevent spoofing of node state changes."
Could you please align and clarify the desired behavior for HNCP?

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-11-17 for -09)
No email
send info
Minor Issues:
===========

-4, 1st paragraph, last sentence:
I confused by the fact this sentence says nodes MUST include HNCP-Version, then goes on to talk about nodes _not_ including it.

-6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address and - if it supports IPv4 - MUST announce an IPv4 address,"
I don't suppose there's any way we can make IPv6 a MUST?

-7.4, 2nd paragraph:
The MUST seems to conflict with the SHOULD in the third paragraph of section 8.

-14.2:
It looks like some, maybe most, of the informative references  need to be normative. They are cited with 2119 language,  cited in other protocol definition, or are otherwise required to fully understand this draft:
3004, 2131, 3315, 3633, 4291, 1321, 6762, 6763, 2132, 4193, 7084, 7217, 4861, and 6092.


Editorial Comments:
=================

-4, 2nd paragraph: "Any node announcing the value 0 is considered to not advertise the respective capability and thus does not take part in the respective election."

Am I correct to assume this means "any node announcing the value 0 for a particular capability..."?

- 5.1:"Internal category":"HNCP traffic MUST be sent and received."
What must send and receive it? (Similar comments for External Category).

-6.5:
Please expand "ULA" on first mention.

- 9, 1st paragraph: "The scheme SHOULD be used only in conjunction"
"SHOULD ... only" is a subtle way of saying SHOULD NOT. I suggest the following:
OLD:
The scheme SHOULD be used only in conjunction...
NEW:
The scheme SHOULD NOT be used unless in conjunction...

- 14.3:
Looks like neither URL will be cited once the RFC editor removes the appendices marked for deletion.

(Benoît Claise) (was Discuss) No Objection

Comment (2015-11-26 for -09)
No email
send info
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.

Alissa Cooper No Objection

Comment (2015-11-18 for -09)
No email
send info
-- How does a node end up in the leaf or guest category? Is it only if a fixed category is configured? If so, who decides that that configuration should happen? I think this info belongs in the draft.

-- Section 5.1 says:

"Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the restrictions of the Leaf
      category, HNCP routers MUST filter traffic from and to the
      interface such that connected devices are unable to reach other
      devices inside the HNCP network or query services advertised by
      them unless explicitly allowed."

What is the mechanism for explicitly allowing selective access for guest nodes? Is this left for firewall policy configuration? I think this warrants some explanation.

-- In Sec 6.4, I'm unclear on whether the address selection process specified in the bulleted list would ever be used to obtain a IPv6 address. If not, then this comment is not relevant. But if it might be used in some case where the node is using v6 but for some reason cannot use the mechanism specified in RFC7217, I think additional guidance is needed here about self-assignment, in line with the ongoing work on draft-ietf-6man-default-iids. Nodes might be tempted to embed a link-layer address in the IID as a means of ensuring that their self-assigned addresses do not collide with others, but they should be discouraged from doing so. So I think some text to the effect that nodes SHOULD assign themselves semantically opaque addresses even if they cannot use the RFC7217 mechanism and SHOULD NOT embed the underlying link-layer address in the IID is warranted here.

(Spencer Dawkins) No Objection

Comment (2015-11-18 for -09)
No email
send info
I support Kathleen's Discuss on DTLS as MTI, and am watching the discussion in that thread (so if you work things out with Kathleen, I'll almost certainly be satisfied).

The transport characteristics seem well thought out for a UDP application. Thank you for that.

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-12-04)
No email
send info
Thanks for addressing my discuss about the options for 
using DTLS. Sorry for being slow with this ballot update.

The comments below are old, I didn't check if you've
made related changes. Happy to chat about that if you
want, (or not if you prefer not:-)

- I agree with Kathleen's discuss that the implementation
requirements for DTLS need to be clarified, hopefully (from my
POV) to make that MTI but I'll leave that discussion to the
other thread.

-Section 9: You should refer to HKDF and not HMAC-SHA256 though
the reference to RFC 6234 is still right. HMAC-SHA256 itself
is not a key derivation function, which is what you want here.

- Please take a look at the secdir review [1] and respond to
that as it raises one issue not (I think) otherwise mentioned.
What is the effect (on a home) of one compromised hncp router?
Perhaps you'll say that's obvious, or perhaps not, but I'm 
interested in what you do say, in case it's not obvious:-)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06098.html

(Brian Haberman) (was Discuss) No Objection

Comment (2015-11-30)
No email
send info
-- Old DISCUSS Points --

* I see where HNCP describes how interfaces are classified as internal or external, but how does an interface get classified as leaf, guest, or ad-hoc?  Is this some manual configuration step that needs to be described somewhere?

* The definition of Leaf in 5.1 is unclear.  It says "Such an interface uses the Internal category with the exception that HNCP traffic MUST NOT be sent on the interface, and all such traffic received on the interface MUST be ignored." The "all such traffic" is ambiguous. Based on the definition of the Guest category, I think "all such traffic" is really "all HNCP traffic".

* The text in section 5.3 seems incomplete. It gives a 4-step algorithm for border discovery, but says "if the node does not implement auto-detection, only the first step is required." If auto detection is not supported and a fixed category is not configured, what happens? Does this mean that if auto detection is not supported manual configuration of the border is required?

* Section 7 describes how to handle non-HNCP capable routers. However, I don't see any operational issues described that could arise from having a non-HNCP capable router connecting two clouds of HNCP within the same home network. It seems like that could cause problems with a bunch of the services provided by HNCP.

-- Old Comments --

* Section 3 has several ambiguous/confusing statements:

1. Does "locally unique" mean unique to the node or unique to the link/network?

2. On a node ID collision, which node re-computes? The one detecting, I assume.

3. "7 doublings" is an odd phrase.  Why not say "Imin * 2^7"?

* I support the other DISCUSS positions raised.

Barry Leiba (was Discuss) No Objection

Comment (2015-11-28)
No email
send info
Version -10 addresses all my comments.  Thanks very much for considering them!

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-12-03)
No email
send info
Thank you for addressing my prior two discuss points.

Alvaro Retana No Objection