[Apologies for the after-WGLC review] Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-homenet-hncp-07.txt Reviewer: Thomas Heide Clausen Review Date: July 21, 2015 IETF LC End Date: Intended Status: Standards Track Summary: o I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: o This document is a profile for and specialization of draft-ietf-homenet-dncp, and has a normative dependency on that document. Note that I produced a RTG-DIR review of draft-ietf-homenet-dncp with several suggestions a short while ago, to which the authors recently responded with an updated document. I have not had a chance to review that update, and iterate with the authors, yet. I also note a RTG-DIR review by Les Ginsberg, as well as several points raised by Juliusz Chroboczek on the topic of draft-ietf-homenet-dncp, the resolution of which I believe may impact draft-ietf-homenet-hncp somewhat significantly. This is one reason for my summary (above) of "Significant concerns..." -- before this document can be processed, draft-ietf-homenet-dncp should be squared off. It is not, however, the only reason o As a general comment, the document would do well with a good editorial overhaul to bring consistency in language usage, consistency in 2119 terminology, coherence in defined terms and their definition, document structure, etc. o Related to this, I found that the lack of a terminology section was unfortunate, and ended up -- for helping my own reading of the document -- making a napkin-terminology to refer to as I walked through the doc. (FWIW, I personally prefer the 2119-paragraph to be part of a terminology section, although that is a minor issue / personal preference). The words I'd suggest including, and defining, would be: o Node -- is that a router, a host, or both? Again, I was given to understand that HOMENET did not want to redefine host behavior, and so I believe that the right term would be router? o Privat Link - Common Link -- If you *insist* on having these concepts, then they definitely need a clear-cut definition here ; I would prefer, though, to not have those concepts. o External Interface o Internal Interface o Border o Border router You "import" a lot of terminology from DNCP and from [I-D.ietf-homenet-prefix-assignment], and I found myself constantly hunting through to figure out which terminology was from where. Suggest adding a paragraph to the terminology section (assuming you make one) which recapitulates something like: "Additionally, this document uses terminology from DNCP, specificially the terms XXX, YYY, ZZZ are to be interpreted as described therein. This document also uses terminology from [I-D.ietf-homenet-prefix-assignment], specifically the terms WWW, UUU, QQQ are to be interpreted as described therein". Reason being: when I came across a term (say "Shared Link"), I wanted to make sure that I understood what that was. So I went to the terminology section. Well, there was none. So I went to grep through this document. Didn't really find a definition. So I started looking through the references to see if there might be something that made sense. Fortunately, my guess of what I-D to check first was right, but it still was more work than it should have been. Major Issues: o I made this very same comment to draft-ietf-homenet-dncp, as I am going to make here. The introduction does not read well; it contains parts of something that could be considered as part of an applicability statement (without it being called out as such, and without forming a complete applicability statement), and does not actually introduce the protocol. Reading just the introduction and the abstract, it is very obscure what HNCP is actually accomplishing, and why one would chose to use HNCP. It does, however, transpire that "whatever it is", it imposes a src-dst routing protocol -- although, that is actually at odds with the claim (from the Abstract) that the use of HNCP allows "...seamless use of a routing protocol." ... given that, afaik, no standardized src-dst routing protocols currently exist. As I recommended for DNCP (hey, at least I'm being somewhat consistent...) I suggest that a proper introduction consisting of three parts would be beneficial: (i) what this document is, (ii) what doing HNCP actually gets you, and (iii) the operating conditions under which HNCP is applicable. I am calling this out as a major issue, since I believe that it is not just editorial, but is a matter of scoping this document correctly, and in particular not falling into the trap of "claiming applicability where it's not". o 4. Common Links From the document: "HNCP uses the concept of Common Links for some of its applications. A Common Link usually refers to a link layer broadcast domain with certain properties and is used, e.g., to determine where prefixes should be assigned or which neighboring nodes participate in the election of a DHCP(v6) server. The Common Link is computed separately for each local interface, and it always contains the local interface. Additionally, if the local interface is not in ad-hoc mode, it also contains the set of interfaces that are bidirectionally reachable from the given local interface, i.e. every remote interface of a remote node meeting all of the following requirements:" Several issues here: 0) "refers to a link layer broadcast domain" -- sounds like a "full broadcast link" or "something that looks like an Ethernet" 1) "some of its applications" -- what are those? 2) "usually refers to a ..." -- so, that means that there are situations where you use it to refer to something else, then? Please don't do that.... 3) "is computed seperately for each local interface" -- wait, in 0) it was defined in terms of physical properties, now it is something which is computed? 4) "which neighboring nodes participate in the election of a DHCP(v6) server" -- is that a hidden requirement that slid in, that DHCP(v6) servers are part of the architecture? SLAAC is out, then? Is that a conscious architectural decision? Now, I actually read in section 5, bullet number 2 that "if an interface can receive a delegated prefix by running a DHCPv6 client on the interface, it must be considered external". So, at least, if a "common link" connects "internal interfaces" then if DHCPv6 servers are active on a common link, then this imposes constraints on what these DHCPv6 servers are allowed to serve ... This *really* merits being called out, the relationship DNCP-DHCP is murky, at best. 5) "if the local interface is not in ad-hoc mode" -- haaaaang on, if we are talking about an 802.11/WiFi interface, "ad hoc mode” does not result in links that look like in 0) ....not at all, actually. 6) "if the local interface is not in ad-hoc mode" -- I am not sure that this is actually "the right term" nor that it is universally understood. At least, I have personally had a heck of a time conveying what that meant when charaterizing a link — especually within the IETF" 7) Reading forward in the document, there's something more on that in section 5 on page 6 where the document talks about an "ad hoc category", and where it actually says something about "transitivity properties" -- specifically that it is not assumed, then a reference to section 4 is given as-if there was any further discussion on this point. 8) "set of interfaces that are bidirectionally reachable from the given local interface" -- I take it that this means that the below specifies a part of a protocol (HELLO protocol), which only run over "ad hoc interface types"? If "yes" to 8), then I would recommend that you define the interface types, and their behaviors, completely -- both what characteristics you expect from the interface (and "ad hoc mode" is not sufficient...), and what behaviors you exhibit across them. You have, in this text, half-way defined "broadcast link type" and half-way defined a "non-transitive non-reflexive link type" Also, I really do not understand the choice of "Common Link" as section header, and as a term. How is that definition different from "an IP link"? Are the protocol mechanisms that you provide for what you call "ad hoc mode" providing something which looks like an IP limk to "the rest of the protocol", etc. I am afraid that I do not understand what a common link is. Are you trying to define a link model? o 3. DNCP Profile The document reads: "A node implementing HNCP SHOULD generate and use a random node identifier. If using a random node identifier and there is a node identifier collision, the node MUST immediately generate and use a new random node identifier which is not used by any other node." Awesome, but that raises two questions: 1) How does a node detect identifier collision? 2) How does a node generate an identifier which is not used by any other node? It would seem that if 2) is actually possible, then a colission should never ever happen. Also, if 1) and 2) are done "by this protocol", put in a forward reference to where the corresponding mechanisms exist. Or if done by DNCP or something else, stick in a reference. As it is, it reads a little like: "...and then some magic happens, and then poppies and pink unicorns" ;) The document reads: "o HNCP nodes use the following Trickle parameters: - k SHOULD be 1, as the timer reset when data is updated and further retransmissions should handle packet loss." I am wondering what the justification for "k=1" is here? Actually, I can infer what it is: the topology in a homenet is constituted by full-broadcast Ethernet links, with the assumption that "if one station receives a transmission, all stations on the link received the transmission" -- if so, then this is actually part of the applicability statement for HNCP: "MUST only be used on Ethernet-like links and MUST NOT be used on non-transitive, non-reflexive, or on lossy, links". If this interpretation is correct, then you probably should explain yourself -- for once, I am mostly in agreement with the use of a SHOULD. One question, however: for a router with multiple interface, do you run the Trickle algorithm per interface? Would probably merit clarification. If it is already said in DNCP (I do not recall if it is, and couldn't immediately find it), perhaps a reminder and a pointer would be good? o Section 4 & 5 The document seems to define a set of interface types and link types, but without any clear relationship between them -- and, worse, without any discussion of what characterize each, what behaviors are exhibited over each, and what impacts on the system/network behavior and performance each has. Further, the definitions of the different interface/link types are incomplete, and seem tied to (without naming explicitly) specific L2's...hinted at, but not actually referenced. o Section 5 The document reads: "HNCP router's interfaces are either internal, external or of a different category derived from the internal one." So, this text tells me that there are n different categories of interface, where n>=2 -- but does not tell me what defines those different interface categories, or what the actual value for n is. Nor does this tell me if I should expect different behaviors across these interfaces, or not. Could the document be more specific? The text goes on: "It is suitable for both IPv4 and IPv6 (single or dual-stack) and determines whether an HNCP interface is internal, external, or uses another fixed category." So what's "another fixed category"? Is that different from "a different category derived from the internal one" discussed earlier? Again, what behaviors to expect, exhibit, across these? With that being said, I would really recommend that the document defines what a border is, in this context. How do I identify it, what characterizes a boarder (which perhaps falls off from "what characterizes an internal and external interface). I assume that "internal interface" means "internal to the Internet" whereas "external" means "external to the internet, i.e., part of the homenet" -- right? Of course, I am yanking your chain here, but you must define precisely what these mean. External and Internal are relative terms... On that, reading through the algorithm that you give, eseentially you define as "external" anything on which a DHCPv4 or DHCPv6-PD server answers, correct? Other than having a hard time reconciling that with issue 4 under "common links" in Major Issues, that does seem to assume an architectural choice which imposes constraints ("thou shalt not run a DHCP server inside a homenet whilst running HNCP") which, at least, needs to be called out in the applicability statement for HNCP, and probably even merits more global discussion and decision by the WG? But wait, then below the algorithm I read this: "In order to avoid conflicts between border discovery and HNCP routers running DHCPv4...." ...and then, requirements that such routers must include a User-Class string. That actually means that the specified algorithm is incorrect -- underspecified: the algorithm must capture the "...unless an User-Class string of .... is included", where appropriate. Sure, with efforts of the "...I thought this over, and I am sure that the authors must have meant XXXX", it's probably possible to implement but I'd much prefer to have the document tell me what to implement, rather than have it tell me to guess. The last paragraph in section 5 is hugely important: that is where the normative behavior for each interface category is detailed - but, I think, only part of the normative behavior is actually specified therein. This is relative to what I mentioned earlier, that for an interface/link type/category, it would be helpful to have specified precisely (i) how to determine if a given interface/link falls within it, (ii) what precise behaviors to expect over than interface/link. o Section 6 Related to my last comment above to section 5, section 6 brings out "border routers" -- which is not actually defined in the document. Some specific behavior is specified for a "border router" and that brings me to expecting to see: o A precise definition of when a router is, or is not, a border router (given a router, how do I determine if I should configure it to exhibit that "specific behavior" o A precise and complete definition of which behaviors a "border router", once identified, should expect and exhibit. The current text does not do that. Again, I could perhaps try to guess, but for a document aiming for std.track, I really should not have to. o Section 6.1 "Each HNCP router MAY obtain external connection information from one or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or static configuration. This section specifies how such information is encoded and advertised." What is "connection information"? Do you mean "prefixes, addresses, routing information, DNS resolvers" and such? Or does it mean "bitrate, error rate, propagation delay"? Or something else? Again, I could probably guess, and might even get it right, but in a std.track document I really shouldn't have to. "o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 Data TLV encoding options associated with the External Connection but MUST NOT contain more than one of each otherwise the External Connection TLV MUST be ignored. o MAY contain other TLVs for future use. Such additional TLVs MUST be ignored." Several comments to that specifically, and to the TLV description in general (please apply also to the other signals/TLVs as appropriate, the comments to this TLV description / bullet apply through section 6): 0) You define a TLV "EXTERNAL-CONNECTION", within which you have other TLVs, correct? Would it not be clearer if those "other TLVs" be called "sub-TLVs" and that term used systematically, so as to distinguish them from the top-level DNCP TLVs. I note that you then set up "sub-sub TLVs" such as "Prefix Domain". So that means that we'll see: o An EXTERNAL-CONNECTION TLV, containing o A DELEGATED-PREFIX TLV, containing o A PREFIX-DOMAIN TLV Correct? The first question that springs to mind is one of IANA registries. Are you setting up, for each TLV type, a new registry for sub-TLV-types? Or, are all TLV types out of one global space? More importantly, if out of a global TLV type space, what happens if, say, a "PREFIX-DOMAIN" TLV is received outside of a "DELEGATED-PREFIX" TLV? Is that valid? Should it be? What behavior should I, as an implementer, exhibit if I receive that? This, really, is a question about what the context for processing each (sub)TLV os, or should be, which is not specified in the document. It is also related to issue 2) below. 1) I would suggest a phrasing such as: "MAY contain at most one ... and at most one DHCPv4 ... with the external connection." 2) The second part of the first bullet: "MUST not contain more than one ... MUST be ignored" That should, IMO, be a generic comment for all (sub)-TLVs, and brought forward to section 6.0 or 6.1, for example some wordsmithing on: "Any received TLV, which does not satisfy the requirements specified in the below, MUST be silently discarded, and MUST be ignored for processing. More to the point, these TLVs (and (sub-)TLVs) are speicified as being in a specific order, or at least in a specific hierarchy (TLV within another TLV) on transmission. What are the constraints on their processing? At what point shall I discard information based on it being received "out of place" (such as a "DELEGATED-PREFIX" TLV not contained in an "EXTERNAL-CONNECTIVITY" TLV)? 3) This leads to a general question: are all the constraints on the sub-TLVs contained in this TLV completely specified? I would actually like to see a check-list of "constraints" that I could implement checks for, both when generating and processing protocol messages. 4) Generally, to the fields in the TLVs, I do not see the encoding, (unsigned/signed, endianness, ...) stipulated. Rather important for interoperability, this MUST be clarified. 5) I am generally not a great fan of having some constraints in the picture (such as the length >= 9) and some in the text (such as "MUST NOT have more than n occurences of FOOBAR"). 6) "May contain other TLVs or future use" -- sure, but then you go on to say "these MUST be ignored". Strictly speaking, that means that you can't "future use" them either. How about: "May contain TLVs of other type, for future use. For the purporse of the processing specified in this document, such TLVs of unknown TLV type MUST be ignored". Note the subtlty here: "unknown TLV types" -- what does that mean? We're actually back at the IANA/hierarchical/sub-TLV discussion. Assuming that you have just one, flat IANA registry, such as you actually have. An EXTERNAL-CONNECTIVITY TLV sure is a "known TLV Type". If you get a DELEGATED-PREFIX TLV containing an EXTERNAL-CONNECTIVITY TLV, is that valid, or must that be ignored? So, with the current set-up of IANA registries, the "unknown TLV types" is not the right phrase. My preference in this sort of situation is actually to set up hierarchical IANA registries: o DNCP sets up the top-level TLV type registry. o HNCP specifies (from within that regitry) the EXTERNAL-CONNECTIVITY TLV type, which: o Sets up a new registry for sub-TLV types o Allocates the DELEGATED-PREFIX from that new registry (and so on). What it does is to set up a context in which "unknown TLV type" (and such) means something -- and also solves the rest of the processing context comments above Alternatively, sure, you could put something like: "May contain TLVs of other type, for future use. For the purporse of the processing specified in this document, TLVs of types other than FOO, BAR, FOOBAR, and GNYF type MUST be ignored". IMO this is less flexible and leads to more repetition. o Section 6.1.2 The document reads: "Valid Lifetime: The time in seconds the delegated prefix is valid. The value is relative to the point in time the Node-Data TLV was last published. It MUST be updated whenever the node republishes its Node-Data TLV." I just can't parse that. Well, I can, but what I get doesn't make sense to me: "relative to the point in time the Node-Data TLV was last published" So, I publish a NODE-DATA TLV. Must I now remember when I did that, say, at t0, and then next time I publish a NODE-DATA TLV include (t-t0) as Valid Lifetime? That does look like what the text says, but it also doesn't sound like a "Vaid Lifetime". Given the name of the field, Lifetime, I would expect it to mean "Upon receiving this TLV, please consider the information valid for this much time" -- but, that's not what the text says. Same comment applies to Preferred Lifetime Also, from this section: "* Zero or more Prefix Domain TLVs. In absence of any such TLV the prefix is assumed to be generated by an HNCP-router and for internal use only." Could gain from being a little more specific: what is "internal use only" (internal to whom?) -- related to my previous comment about definition of External/Internal. Also "use" -- do you mean that "this prefix MUST NOT be leaked externally, i.e., addresses from within this prefix MUST NOT be used as a source address for traffic outside the homenet? If so, does this mean that you allow a homenet router to grab any odd global prefix and treat as private? Or, is this a matter of simply reflecting the already existing "don't route 192.168/16" (and equiv.) rules? Either way, that needs to be clarified. o 6.2.1 "All HNCP nodes running the prefix assignment algorithm MUST use the following parameters:" First, I think that an element of clarification would be good. These parameters, where are they from? Do they come from [I-D.ietf-homenet-prefix-assignment], are they in that specification given as "optional" (so that one might get the idea to not use them), or? Second, is it the parameters - or their values - that must be used? This goes a little bit deeper; I think that what you are doing here is, in part, to specify "which values to assign to the different parameters from [I-D.ietf-homenet-prefix-assignment]" -- although that document is not particularly clear on which parameters form the interface to HNCP and to other protocols. But, the question is, what does it mean to "MUST use the following parameters" here? I can see that using these terms/definitions in the description of HNCP makes sense, but that does not a "MUST use the following parameters" make. So, I simply do not understand what you intend with 6.2.1. o Section 6.2.2, 6.3, etc.... This links in with previous comments regarding the hierarchy and location of protocol elements. The TLVs defined herin, are they "top level TLVs" or are they sub-TLVs, to be carried within another TLV? And, what's the context of their processing. This point is particularly obscure since the protocol does not act symmetric nor consistent here: o it defines an "EXTERNAL-CONNECTION" TLV (which really is what other protocols would call a "messagge") which carries sub-TLVs that have to do with describing "EXTERNAL CONNECTIONS". o But, for Prefix Assignments, it does, as far as I can tell, not define a "PREFIX-ASSIGNMENT" message (apologies, TLV) which contains the related sub-TLVs I would like to see this through through -- ideally, re-engineered to be homogenous and consistent, but (at the very strict minimum) called out and explained clearly. o 6.2.3. Making New Assignments "Whenever the Prefix Assignment Algorithm subroutine is run on a Common Link and whenever a new prefix may be assigned (case 1 of the subroutine), the decision of whether the assignment of a new prefix is desired MUST follow these rules: " Hold on there for a second: 1) What is "the Prefix Assignment Algorithm subroutine"? Throw a citation into [I-D.ietf-homenet-prefix-assignment] here, so the random reader knows what you're talking about -- and, a section reference, also. 2) This is exacerbated by the fact that the descripton pointing to "case 1 of the subroutine". I guess that that correspinds to "bullet number 1" on page 9 in [I-D.ietf-homenet-prefix-assignment], but in a proposed standard, guessing should not be needed. 3) That aside, subroutines are programming constructs, not specification elements. Just out of spite, I'll go implement HNCP using GOTO's instead of "subroutines" 4) I notice that sometimes this is called the "Distributed Prefix Assignment Algorithm", at other times "prefix assignment algorithm”, then "Prefix Assignment Algorithm subroutine", etc. o Are they all the same? o If yes, then why are they written, and capitalized, differently? o If no, then what're the differences between them? Next, the document reads: "If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, and the meaning of one of the DHCP options is not understood by the HNCP router, the creation of a new prefix is not desired. This rule applies to TLVs inside Delegated Prefix TLVs but not to those inside External Connection TLVs." What does "is not desired" mean? "...a new prefix MUST NOT be created?" "...a new prefix SHOULD NOT be created?" "...a new prefix MAY be created, but is not necessary?" The document reads: "If the remaining preferred lifetime of the prefix is 0 and there is another delegated prefix of the same IP version used for prefix assignment with a non-null preferred lifetime, the creation of a new prefix is not desired." Suggest replacing "non-null" by "non-zero" -- but, beyond that, what does "is not desired" mean? Same comment for the next paragraph: "Otherwise, the creation of a new prefix is desired" Am I right in reading these three paragraphs as: 1) If then new prefix MUST NOT be created 2) if then new prefix MUST NOT be created 3) Otherwise, if then new prefix MUST be created That is how the text reads, which begs the question: Is it possible for , , and to all not be satisfied, and what happens in that case? I *think* that this is a case of underspecification, or at least where it looks like there's a case of underspecification. o 6.2.4: "MUST create an appropriate route ..." What's "an appropriate route"? Do you mean "install entry into the routing table", or do you mean to launch a routing process to discover, calculate, or otherwise obtain that route? Do you need the entire path, or just the "next hop towards ..."? o 6.2.6 "When an HNCP router receives a request for prefix delegation ..." OK, how does a HNCP router receive such a request? Grepping through the document fpr "request" I see no protocol signals that correspond to this. Then, this: "The assigned prefixes MUST NOT be given to clients" made me wonder what a "client" is. I see DHCPv6/v4 client used, occasionally, and in other places I see just "client" -- is this intentionally, and, if so, what is a "client"? o 6.3 "Nodes MAY, at any time, try to reserve a new address from any applied Assigned Prefix" What is an "applied Assigned Prefix". Given capitalization, it is an "Assigned Prefix" that is applied somewhere, I suppose, but where and to what? The document reads: For any assigned prefix for which SLAAC cannot be used, the first quarter of the addresses are reserved for routers HNCP based address assignments, whereas the last three quarters are left to the DHCPv6 (resp. DHCPv4) elected router (Section 10 specifies the DHCP server election process). For instance, if the prefix 192.0.2.0/24 is assigned and applied to a Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP nodes and the remaining addresses are reserved for the elected DHCPv4 server. Why "the first quarter"? It seems a rather arbitrary value? Is it known to be enough/too much/too little? "HNCP routers assign themselves addresses using the Node Address TLV" OK, but...do they send that TLV to themselves? Or do they send it to someone else, or ...? Part of the answer to this question is embedded in the text below the picture in section 6.3, but not all -- and, I believe, this is potentially another problem of more global scope. Generally, for each message (or TLV) it's good to know how it is formatted, but it's fantastic to know also how it's generated and how it is processed. I fali to find that (through and through) in this document, and that makes it harder to implement. Would it be possible to do something like this, (generally, for the TLV types defined?): Section X. FOOBAR TLVs Section X.1 Generation A FOOBAR TLV is generated when a, b, c happens. When generating a FOOBAR TLV, its content is determined as follows.... Section X.2 Processing On receiving a FOOBAR TLV, take the following steps ... That would also be the place (in X.1) to state where to put information (for example, when a TLV must be inside another TLV) or constraints on processing (X.2) for example if a TLV is invalid unless if contained inside another TLV. o 9 Securing Third-Party Protocols I take issue with the below: "Pre-shared keys (PSKs) are often required to secure IGPs and other protocols which lack support for asymmetric security." Pre-shared keys are chosen, in some scenarios and for whatever reasons, regardless of the capacity of the underlaying protocols -- even when the protocol(s) (IGP or otherwise) are fully capable of and completely supports assymetric security. Please address this by a less broad claim for when PSK are used. But, I wonder, reading this section as a whole: you generate, and distribute through HNCP, a PSK? So all it takes to get access to said key is to sit by and passively listen to traffic for a bit? That does strike me as a dangerous option to have...reading the security considerations section, there seems to be nothing securing HNCP against eavesdropping -- or, if there is, that's not called out. I note that the security considerations of DNCP start out by saying: "If specified in the DNCP profile, either DTLS [RFC6347] or TLS [RFC5246] may be used to authenticate and encrypt either some (if specified optional in the profile), or all unicast traffic" And, section 3 of HNCP states: o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as described in DNCP if exchanged over unsecured links. UDP on port HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP security MUST support the DNCP Pre-Shared Key method, SHOULD support the DNCP Certificate Based Trust Consensus and MAY support the PKI-based trust method. Note the "SHOULD" and the conditonals "unsecured links" (not sure what this would be, precisely). I do not know anything meaningful about DTLS, but I would imagine that sking the SEC-DIR folks about its use would make sense. All that said...sadly, in many conditions and scenarios "getting security to work is hard" and in a home scenario the choice (to minimize the amount of support calls, ...) it would not be hard to imagine either turning OFF or using lowest-common-denominator security. Say "nothing" over an Ethernet "because physical access required", and WEP for WiFi (yes, people still do that) and then declare links "not unsecured" and therfore consider it legitimate to not implement the SHOULD. Effectively, what I fear here is that if HNCP "proposes to share PSKs" then a (slightly naive) process might actually trust those PSKs to be useful for security -- which, in fact, they are not since they can be exposed by simple eavesdropping? I'd really like a bullet-proof guarantee that any shared PSKs can't have been (easily) eavesdropped on -- or, would ratehr that HNCP does not tempt the use of compromized PSKs. o Section 10 What's the solution if the message format changes? For example, that the type field needs to grow/shrink? I've mentioned this in my DNCP review, but I strongly believe that it is required to have versioning also capture "the frame format", and not just the "payload". Minor Issues: o General comments: o I recommend using "non-zero" when referring to numerical values, and not "non-null" o Abstract Questions: is it clear what "naming" referres to? Is it "name resolution"? Idem for "network borders", do you configure those, or discover those? Routing-specific question here: What does "seamless use of a routing protocol" mean? That any IP routing protocol can be used unmodified? I *think* that that's not the case, given that the use-case that is often trotted for homenet includes a multi-homed home - and the introduction says as much so the abstract probably should reflect that. How about somehting like this for the abstract: "This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables automated configuration of addresses, name resolution, discovery of network borders, and the use of any src-dest-routing capable routing protocol. o Introduction "HNCP synchronizes state across a small site in order to allow..." What precisely is a "small site"? Can we qualify that in terms of, say, number of routers? "The protocol enables use of border discovery" I am not sure that I understand what this means -- in which way is border discovery *enabled*? Or, do you mean "This protocol discovers borders"? Or something else? "naming and other services across multiple links." So, the first paragraph teaches me that HNCP is applicable somewhere not too big -- but, of course, I do not know what exactly that is -- , and it does "some stuff, and other services" -- but, of course, I do not know what those are, or how they are characterized. That's a little imprecise for an introduction. Suggest being extremely precise. Something like: HNCP "Synchronizes state" by way of [dncp], and specifies and uses state for providing the following network services: o FOO o BAR o FOOBAR All specified in this document. Additionally, HNCP enables other services, characterized by ______, for example prefix assignment as defined by [I-D.ietf-homenet-prefix-assignment] Which brings me to a question. The abstract, and introduction, state that HNCP "enables automated configuration of addresses" -- how is that different from [I-D.ietf-homenet-prefix-assignment]? Or, is the answer "it isn't, that I-D is required to do that", in which case what does it mean that HNCP "enables" it? [Of course, reading the document it becomes clear that HNCP does this by way of a normative reference to [I-D.ietf-homenet-prefix-assignment], but the abstract and introduction really are unfortunately phrased] Reading just the introduction, I'd like to be able to know what HNCP would bring me, exactly? Implementing and turning on HNCP would do what to my network? o 3. DNCP Profile "HNCP is defined as a profile of DNCP..." Is it not more correctly to say that" "HNCP is a profile for DNCP..." ? "HNCP routers MUST assign a unique 32-bit endpoint identifier to each interface for which HNCP is enabled." Any additional requirements to that identifier? Reading into DNCP, that is actually not entirely clear there. I *think* that the endpoint identifier MUST be unique to the local node, but that there's no requirement beyond that -- correct? Could that be called out both in this document, and perhaps in DNCP more clearly? Following the above: "The value zero is reserved for internal purposes." What internal purposes would that be? Reading through, hidden in the description of the frame format (6.2.2) I read: "The endpoint identifier of the local interface that belongs to the Common Link the prefix is assigned to, or 0 if the Common Link is a Private Link (e.g., when the prefix is assigned for downstream prefix delegation)." OK, so leaving that slightly odd phrasing (and the notion of "Common Link" and "Private Link" -- both of which we will come back to) for a later comment, can we not bring this up to section 3, thus: "HNCP routers MUST assign a 32-bit endpoint identifier, unique to the local node, to each interface for which HNCP is enabled. The value zero MUST NOT be used, except as endpoint identifier for an interface towards a Private Common Link" ? [but, I am no great fan of "Private Link" or "Common Link", see other comments] About this: "Received datagrams with an IPv6 source or destination address which is not link-local scoped" How about: "Received datagrams where either or both of the IPv6 source or destination address is not link-local scoped" ? As a general comment, this section contains an unordered set of bullets, where a grouping and some common discussion probably would make sense. For example, a few concern security directly (e.g., 3 & 5) but are not really DNCP parametrizations -- whereas others are (e.g., 6, 7, 8). The bullet-set reads somewhat like "the kitchen sink". (Numbers indicate count from the first bullet in the block). o 5. Border Discovery The document reads: "A router MUST allow setting a category of either auto-detected, internal or external for each interface which is suitable for both internal and external connections. In addition the following specializations of the internal category are defined to modify the local router behavior:" What defines if an interface is "suitable" for an external, or internal, or both, connections? What does "connections" mean in this context? What requirements are there for an interface to be "suitable" respectively "unsuitable"? As part of the discussion of the different categories, some are declared as SHOULD, others as OPTIONAL. I do not see any which are MUST. I see that the two SHOULD should be MUST Also: Hybrid category: This declares an interface to be internal while still running DHCPv4 and DHCPv6-PD clients on it. It is assumed that the link is under control of a legacy, trustworthy non-HNCP router, still within the same network. Detection of this category automatically in addition to manual configuration is out of scope of this document. Support for this category is OPTIONAL. What makes a router "legacy"? What makes it "trustworthy"? o In section 6.1.2 I see: "Nested TLVs: Other TLVs included in the Delegated Prefix TLV and starting at the next 32-bit boundary following the end of the encoded prefix:" "Prefix: Significant bits of the prefix padded with zeroes up to the next byte boundary." Question: Other than "because historically that's how we did things, because, at the time, that was a good idea", is there any good reason that you're insisting on byte/32-bit alignments here? It's been a good while since I've personally written code where 32 bit alignment was a major concern -- but, when generating a packet I sure could see it as a minor nuisance to do the alignment. So, I actually see this as "a nuisance introduced in packet generation, for no real gain in parsing". (Note that this is in the MINOR category, though) o 6.2.3: "In any case, a router MUST support a mechanism suitable to distribute addresses from the considered prefix if the link is intended to be used by clients. In this case a router assigning an IPv4 prefix MUST support the L-capability and a router assigning an IPv6 prefix MUST support serving router advertisements. In addition if an assigned IPv6 prefix is not suitable for Stateless Address Autoconfiguration the router MUST also support the H-capability as defined in Section 10. To your credit, you put a forward pointer to Section 10. With that being said, would it not be more logical to discuss that (which appears as "the overall message format of HNCP") somewhere earlier? Nits: o Any reason why some TLV types are written in ALL-CAPS whereas others in Hyphenated-Camel-Case? o I saw a few "e.g." and "i.e.", which I believe the style guide prescribes should be "i.e.," and "e.g.,". Yeah, the RFC Editor will catch this ultimately, but if you re-spin the document then might as well make their life just a bit easier ;)