Re: [RTG-DIR] RtgDir review: draft-ietf-homenet-hncp-07.txt

[Steven Barth <[e-mail]>]

Hello Thomas,

as you might have seen already, we pushed hncp-08 yesterday and dncp-09 the day before
and for hncp the editorial changes have been quite big. Now please also find our detailed
reply to the points you raised and, as usual, we tried to address them as best as possible.



Thanks,

Steven (& Markus)


> 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

dncp is more mature now, so hopefully that has been covered.

> 	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.

Agreed. An effort has been made in -08 :)

> 	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?

Homenet is tasked not to cause _backwards-incompatible_ changes to hosts. While the design is such that it is enough for routers only to participate in it, and the e.g. routing and addressing experience should work, advanced hosts MAY also if they want to e.g. do their own routing and in that case they may also want to do automatic address assignment by themselves. The text now differentiates more clearly between nodes and routers and has appropriate terminology.

> 			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

Added terminology section.

> 		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.			


Added imported terminology lists for both DNCP and PA.

> 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".	


Rewrote introduction to some extent, and added applicability subsection which refers to DNCP applicability where applicable (smirk).

> 	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"

Rewrote the text.

> 			1)	"some of its applications" -- what are those?

Enumerated applications.

> 			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....

Text disappeared in rewrite.

> 			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?

It is something that 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?

SLAAC is the default. All HNCP routers MUST send RAs. RFC 7084 (which we “import”) says A-flag MUST be 1 by default. Also our text says “In case no router was elected, stateful DHCPv6 is not provided.“. Some people need DHCPv6 either for PD for “legacy routers” or to collect hostnames since cross-platform naming is totally screwed up with v6, so we try to handle it gracefully.

> 				
> 				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.

It should be more clearly explained now. Background is that IIRC homenet architecture RFC as well as WG in general wants automatic border discovery so we have to do some black magic using DHCP interactions here to fulfill that. If you have anything (technically) better in mind then please let us know.

> 			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.	

It was really talking about ad-hoc category, and not actual low-level things. Fixed, hopefully.

> 			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"

See above.

> 			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.

Rewritten, hopefully clearer now.

> 			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"?

Kind of. We’re talking of using DNCP state to determine (sub)set of nodes that have shared view of the link. In practise, it is the whole subnet, except in meshy cases (ad-hoc fixed category), it is just the local interface as we cannot make any guarantees about anything else.

> 		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?

I think there are some misunderstandings here based on earlier text. Hopefully the rewritten version clears it out.

> 	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?

Section 4.4, NetState handling of DNCP. Added reference.

> 			2)	How does a node generate an identifier which is not used by any
> 				other node?

It uses a new random node identifier which is not used by any other node at the time, based on the current DNCP network state. Text changed.

> 		It would seem that if 2) is actually possible, then a colission should
> 		never ever happen.

It is essentially a race condition (network split/join come to mind). Notably, when a network boots, it is a series of joins.

> 		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"
>
> 		;)

Juliusz said this stuff worked like magic in IETF93, I guess this is further proof of that :)

> 		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.

It is not; SHOULD is for ‘the default’ which is Ethernet-like links, and the other part is e.g. ad-hoc category lossy non-transitive links. Even they _do_ work with the k=1, given keep-alives are essentially extra Trickle updates that are sent by _every_  node periodically.

> 		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?

(DNCP) It is in data model section, and numerous (hopefully correct) references to ‘Trickle instances’.

Added per-interface Trickle interface text there.

 		
> 	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.

We try to steer clear of link types; interface types (=categories) care only about transitivity or non-transitivity (all categories except ad-hoc are assumed to be transitive; ad-hoc can be either transitive or non-transitive). Added a note to Common Link in terminology about (default) transitivity assumption. Also interface categories have been reorganized.

> 	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?
Rewritten

> 		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?
Clarified, text now has 2 sections: one defining all categories, one defining the selection.

> 		
> 		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).
Clarified that.

> 		
> 		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...

Added to terminology and further specified in 2 other sections.

> 		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?

As noted earlier auto border discovery is even mentioned in the architectural RFC.
Drafts predating HNCP have defined similar schemes already before (by using dedicated new DHCP options) so this stuff is not exactly new. Also it is not mandatory to implement and is a “MAY use”, you can always use fixed categories and do whatever you want with DHCP.

I added a subsection to applicability denoting HNCP assumes certain level of control over DHCP servers. This is not only true for border discovery here but obviously if you have a DHCP-server handing out different prefixes your clients are in trouble anyway.

> 		
> 		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.		

Added note about it after it (rather not avoid the clumsy language). A lot of reordering of the text as well. Server and client behavior is now more correctly split.

> 		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.

Moved the behavior to the interface category section, added more text in general to clarify.


> 		
> 	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.
> 		

Added border router to terminology.  RFC 7084 as referenced specifies more detailed behavior.

> 	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.

Explicitly note what is part of connection information and referenced the relevant TLVs for encoding.

> 		
> 			"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?

Yes.

> 				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?

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?

It should be more clear now. We completely reorganized all TLV definitions into a single section.
There are general rules (partly referencing those from DNCP rules), saying e.g. that integers are unsigned + network byte order by default and that TLVs may contain other sub-TLVs that MUST be ignored. In general we switched from defining “what should can be in a container” to “where might a TLV occur” so this is now clearly defined for each TLV and the text says other occurrences MUST 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.
As noted, we redefined TLV definitions to state where they can occur. We are sticking with a single TLV space for now since it is probably more easy to manage and grasp, also we already have at least one TLV already which can occur in different containers which would also cause duplication then.


> 	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

Names changed to “Valid/Preferred Lifetime Since Origination” and added descriptive text.


> 		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.
Got rid of that imbagiuous wording, IPv4 / ULA generation deals with locally generated prefixes.

> 		
> 	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.			

Addressed, now simply stated as fact.


> 	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.
That should be clear now with the TLV reorganization as noted above.

> 		
> 		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.

I do not see the point. The point of DNCP’s TLV ordering is to facilitate fast delta processing, and the more nested the TLV structures become, the less valuable it becomes (as you wind just removing+adding big container TLVs). Due to that, HNCP TLV space was originally defined to be _as flat as possible_ given the data structures being encoded (-Markus).

Furthermore I think that the term message is incorrect here since External-Connection is  a container simply for reasons of aggregation: “An External Connection TLV is a container-TLV used to gather network configuration information associated with a single external connection.“ and a single router might have multiple external connections (i.e., a second uplink) and with that more than one EC TLVs, so the aggregation is necessary to correlate and distinguish between multiple connections of a multi-homed router.

Prefix Assignment (TLVs) do not need any aggregation since they are “self-sufficient”. You can simply find the delegated prefix they belong to (based on significant bits) but that’s all there is to it. There is no auxiliary data and no additional policy for an assigned other than what is encoded in the AP TLV itself. (-Steven)


> 	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.

Added.

> 			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.

Updated to be more descriptive.


> 			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>

Agreed. Go hunt Pierre down.
Can I take you up on that implementation? :P (-Steven)

> 			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?

Unified, got rid of the “distributed”, was probably just buzzword bingo fodder.

> 	
> 	 	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?"

PA ‘subroutine’ in PA draft specifies it - ‘desired’ stuff is done something about. I do not think we want to replicate the logic here.	
		
> 		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?

Replaced, but see above. ‘desired’ is PA term.

> 		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.

Correct. 3) was apparently added a condition later. Modified 3), and added 4) which is unconditional ‘MUST NOT’.

> 	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 ..."?

Got rid of the route thing, replaced with “MUST forward traffic destined to said prefix to the respective link.“

> 	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.

Addressed (it talks about DHCPv6-PD).

> 		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"?

DHCPv6-PD client of a legacy router. Replaced client with that in this paragraph.

> 	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?

“Applied Assigned Prefix” is a PA term, correctly capitalized and added PA terminology import.

> 		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?

It is arbitrary. However, all routers must use same scheme, so we specified an arbitrary value. Please come up with a better one if you can :)

> 			"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 ...?

Added some text.

> 		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.

As mentioned, we have a centralized TLV section now, though not as structured as you suggested (no generation, processing etc), instead we added references back to appropriate sections that discuss generation and processing. So there might be a bit room for improvement still.

> 	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.

Added ‘for example’, it does not really aim to be comprehensive. Alternatively we also accept comprehensive text.

That said, out of scientific curiosity, what percentage of _deployed_ IGPs support asymmetric crypto?

> 		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.

If you do not have L2 link security (either crypto or rabid attack dogs), yet insist on not using HNCP security (e.g. DTLS), the game is lost already. I do not think we can exhaustively enumerate the broken L2s here, as I believe e.g. currently _about anything wireless_ is broken (you can mount off-line dictionary attacks on keys of WPA*, not to even mention TKIP, or WEP). WPA2-Enterprise has non-broken modes (from my point of view) but that is it, and that is also subject to change based on future results.

Added some text that the scheme SHOULD be used only with secured unicast transport, and why (the correct reasoning is bit more complex what you say).

Bullet-proof guarantee seems rather hard, as we do not want to have MUST on the security in general.

Also absent of this approach there is nothing which naturally creates any PSK so the probable outcome would be that protocols requiring some sort of PSK for authentication (like many PSKs) would in practice probably more likely be used completely unsecured.

> 	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".

We reserved 6 bits in the Type-Field of TLV in DNCP for that purpose.

> Minor Issues:
>
> 	o	General comments:
> 	
> 			o	I recommend using "non-zero" when referring to numerical values,
> 				and not "non-null"

Changed.

> 	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.

Used (and added service discovery, which differs from name resolution).

> 	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?

Intro is hopefully better now. (Further improvements welcome of course.)

> 	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..."
> 		
> 		?

Changed text in general, n/a now.

> 			"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?

Yes, it said ‘unique’, but now saying ‘locally unique’.

> 		Could that be called out both in this document, and perhaps in DNCP more
> 		clearly?

Addressed in DNCP.

> 		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"
> 		
> 		?

Added reference to TLVs that specify 0 behavior (it isn’t quite that either).

> 		[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"
> 			
> 		?

Changed.

> 		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).

Moved security to the end as it is SHOULD; also Trickle parameters (same reason). This _is_ the kitchen sink ;)

> 	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"?

Rephrased “Each HNCP router SHOULD allow setting the category for each
      	interface which may be connected to either an internal or external
      	device (e.g., an ethernet port that can be connected to a modem,
      	another HNCP router or a client).“

> 		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

Clarified now, Internal is MUST for all nodes, External is additional MUST for routers.

> 		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"?

Changed to “This is useful,
        e.g., if the link is shared with a non-HNCP router under control and
        still within the borders of the same network.”

> 	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)

Force of habit. I am not convinced it is good idea anymore either, but perhaps late to change (-Markus).

> 	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?

Moved Versioning section to the beginning.

> Nits:
>
> 	o	Any reason why some TLV types are written in ALL-CAPS whereas others in
> 		Hyphenated-Camel-Case?

Found one (managed-psk) and fixed.

> 	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 ;)
Addressed.