[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: <review just after WGLC>
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)	<general rant> 
				That aside, subroutines are programming constructs, not
				specification elements. Just out of spite, I'll go implement
				HNCP using GOTO's instead of "subroutines"
				</general rant>
				
			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 <condition1> then new prefix MUST NOT be created
				2)	if <condition2> then new prefix MUST NOT be created
				3)	Otherwise, if <condition 3> then new prefix MUST be created

		That is how the text reads, which begs the question:
		
			Is it possible for <condition1>, <condition2>, and <condtion3>
			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
				<description>
				
			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 ;)