Subject: Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt

From: Thomas Clausen <[email-masked]>
Date: Tue, 28 Jul 2015 17:45:17 +0200

Dear Steven, all,

[I am looping RTG-DIR and RTG-ADs back in on this, just so that they do not feel that we do not love them any more … ;) ]

> On Jun 20, 2015, at 15:56, Steven Barth <[email-masked]> wrote:
> 
> Hello Thomas,
> 
> thanks a lot for your elaborate review, we have just pushed revision -06

And I see that you have pushed ore than that in the month-or-so since my review. Thank you for that. 

I will state outright that I am taking this email as an excuse for “going back and looking at -08”,  in part as I go through the new I-D, and commenting as I go along. I still think that there may be reason to spin a -09, so I will hold back making the “official RTG-DIR follow-up review”  until that’s either done, or I am convinced otherwise ;)

But, guys, thanks for your efforts in both updating the doc and rebutting my comments. And congratulations on having produced something which  — for the most part — is *almost* there, and where it’s going to be easy to push it over the finishing line, I think.

Highlights of what I still think is needed (with details below, of course) from this document:

	o	A handful or so of “almost there, why don’t we add a sentence on …” that should be
		really easy to do, and should make me shut up on a great number of topics.

	o	An applicability statement [sorry, I’m insisting here, I feel this is important]

	o	Workable definition of “Endpoint” in terminology

	o	Still need versioning [sorry, I’m insisting here, I feel this is important]

As I said, details below — but good job getting from -05 to -08, and thanks to you both for having taken time to address and answer to my review in so painstaking detail, both in the draft, and in this exchange.

Authors, for all the points where I have said “fine”, if you reply to this mail feel free to cut those points out and retain only outstanding issues.

> of DNCP addressing your issues and comments and that of other reviewers.
> 
> Please see more detailed comments inline.
> 
> 
> Cheers,
> 
> Steven & Markus
> 
> 
> 
> On 16.06.2015 17:45, Thomas Clausen wrote:
>> Comments:
>> 
>> 	o	Is there any good reason why the authors have no listed affiliation?
> As we are independent consultants, an affiliation would probably not be
> much more useful than our names themselves.

OK, was just wondering if it was xml2rfc acting up.

> 
>> 	
>> 	o	It is somewhat contradictory that the abstract talks about
>> 		"...describes a protocol" and then later "...leaves some details
>> 		 to be specified in profiles, which define actual implementable DNCP
>> 		 based protocols"
>> 		
>> 		 Does that not mean, then, that this document specifies an algorithm,
>> 		 a framework, and not a protocol?
> This was debated publicly and tbh. we are not sure what the correct
> phrase would be, maybe “abstract protocol”, but even that was not liked
> by everyone. Other than that we tried to clear up the introduction and
> abstract in that regard.

OK; on a personal-preferences level, the separation between HNCP and DNCP seems artificial, and it probably is part of the reason why this is hard to describe. I probably would not have made that separation myself — but I am not suggesting that the WG goes back on that decision (just to be clear), rather that it be called out.

I can live with what is there.

>> 	o	On that, I see "DNCP protocol" several places. Expanded, that becomes
>> 		"Dynamic Network Configuration Protocol Protocol" ...
> Fixed, found only one. (long form is wrong btw.)
> 

I expected so ;)

>> 		
>> 	o	In general, and despite actually knowing some of the core algorithms
>> 		somewhat before this review, I found the document really tough to
>> 		read, with convoluted sentences, inconsistent requirements-language,
>> 		and a lack of introductory "here's the 1000ft view of the protocol,
>> 		what it does, how it works, and under which conditions it works".
>> 		
>> 	o	On that, I do not find the chosen structure of the document to be
>> 		optimal for conveying an unambiguous protocol specification. For one,
>> 		the same concepts are occasionally described slightly differently.
>> 		For another, it is often hard to find the information needed to
>> 		parse a specific mandated processing (for example). I provide an
>> 		example of what I would suggest a better structure in the below.
>> 			
>> 		The goal is to provide first concepts and an overview, followed by a
>> 		single, easy to identify place for "precise and unambiguous definitions
>> 		of concepts", and then use those in the detailed expression of the
>> 		protocol. Note that this is just an example, of course:
>> 				
>> 			Section "Terminology:"
>> 				The Network State Hash is a hash value which represents the
>> 				current state of the network, as known by a node.
>> 				
>> 			Section "Protocol Overview and Functioning"
>> 			
>> 				When receiving a FOO TLV, the DNCP node compares the received
>> 				Network State Hash with its own Network State Hash. This
>> 				represents the consistency check rom RFC6206. If same,
>> 				then...if not, then ....
>> 				
>> 			Section "Protocol Information Bases"
>> 				For the purpose of this specification, the Protocol
>> 				Information Bases are orgnaized as sets of tuples ... any
>> 					implementation can chose whatever representation it wants.
>> 				
>> 					The Network State Information Base in a DNCP node is a set
>> 					of tuples:
>> 						(x, y, z, w)
>> 					
>> 					where x is ..., y is ..., z is ..., and w is ...
>> 					
>> 			Section "How to calculate the Network State Hash":
>> 				
>> 				 The network State Hash is calculated using the information
>> 				 from the Network State Information Base, as follows:
>> 				
>> 					 	1. First, the tuples in that information base are sorted
>> 				 		   in ascending order based on ....
>> 				 	
>> 					 	2. Second, .... (concatenation)
>> 				 	
>> 					 	3. Third, the hash function from <profile> is used
>> 				 	
>> 					 	4. Fourth, the first n bits of the resulting hash value,
>> 					 	   are retained, witn n being from <profile>.
>> 
>> 			And then, in remaining sections simply reference the Network
>> 			State Hash, which is now ubiquitously defined in a single place.
>> 			
>> 			I am taking this example, since when reading section 5.3 I found
>> 			myself chasing through the document, finding multiple slightly
>> 			different definitions of "Network State Hash" --  but beyond this
>> 			example, it generally does apply to the document as a whole, and
>> 			certainly to all of the processing and generation considerations in
>> 			section 5.
>> 
> We reorganised the document a bit, wrote a better abstract and
> introduction and provided a “Protocol Overview” section, on top of that
> we reorganised the details in an “Operations” section.

OK; I am a good deal more happy now, although not perfectly happy just yet. 

I still think that it would be fantastic to have an applicability statement included. Reading the document without any context [as it might down the line if it was to become an RFC], it’s hard to understand if “hey, I have a problem, is DNCP the right lump of metal to use to make a hammer for it?”

As I said in my original review, I think that this is a matter of scoping the work right. The abstract, and the into, calls out “a generic state synchronization protocol” — I’ve heard OSPF described as such, also (hi Fred!) — which sounds very much like “boiling the ocean”, and which I think the WG is not trying to actually do.

Why don’t you put a subsection before the last paragraph of the Introduction “Applicability” and then expand on that?

I just want to note that I enjoyed the expanded terminology - thank you! There may be a small formatting snafu, at least in the HTML version, about missing blank lines between (for example) “Address” and “Endpoint”

Going back and looking at that, does it make sense to talk about “DNCP network”, out in the real world, or just in this document?

An HNCP network and a TNCP network (that’d be for "Thomas' Neat Configuration Protocol”) sure, and such two could co-exist (but not interoperate) so while they “in the abstract” would both be instances of DNCP networks, that’d be an abstract construction altogether.

Could I suggest that to the definition of “DNCP network” some verbiage to that effect be added?

Now we’re at tightening up on terminology, I am finding myself wondering about “DNCP profile” and “DNCP-based protocol” as terms, just a little.

A DNCP profile is 
		     a definition of the set of rules and values
                     defining the behavior of a fully specified,
                     implementable protocol which uses DNCP.  The DNCP
                     profile specifies transport method to be used,
                     which optional parts of the DNCP specification are
                     required by that particular protocol, and various
                     parameters and optional behaviors.  In this
                     document any parameter that a DNCP profile
                     specifies is prefixed with DNCP_.  Contents of a
                     DNCP profile are specified in Section 9.

Could we be a little bit more succinct:

“A DNCP profile consists of:
			o	The values for the set of parameters, given in section 9.
			o	The set of optional parts of this specification, which are to be used.”

For DNCP-based protocol, the doc says:

A DNCP-based protocol is:
			a protocol which provides a DNCP profile, and
		        potentially much more, e.g., protocol-specific TLVs
                        and guidance on how they should be used.

Could we be more precise (than “potentially much more”) on “DNCP-based profile”

“A DNCP-based protocol is:
			o	A DNCP profile, according to Section 9,
			o	Zero or more TLV assignments from the registries set up by this specification
			o	generation and processing rules for these TLVs

?

On the definition of “Address”:

	o	What does it mean to be “relatively transport agnostic”? I’d 
		say that it’s a little bit like being “relatively pregnant” — either you are, or you are not?

	o	Why not define an “Address” as  (IPv6-address, Transport, Port)?
		(and then, if someone comes along with something that doesn’t fit that tuple form
		down the line, deal with it then?)

Address, by the way, uses “endpoint” which is defined below. 

Endpoint, then, ends up being defined almost as an “address” *except* that there’s the clause “may be bound to a set of predefined unicast addresses” [would those be addresses as previously defined?]

When I read “Endpoint” I end up simply thinking “Socket, expressed as (IPv6-address, Transport, Port)” but as that was defined above it can’t be it? 

Could you clear that up, please? [Note, it’s better than the -05, but still confusing]

>> 	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.
> 
> We did another editing round with focus on normative language.

Much better, thanks. I’ll holler if I see something to fix on this front

> 
> 
>> 		
>> Major Issues:
>> 	
>> 	o	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 if
>> 		this is a framework, a protocol, a building block, an architecture, an
>> 		algorithm -- and, if either of those, what it is actually accomplishing,
>> 		and why one would chose to use DNCP. It does, however, transpire that
>> 		"whatever it is", it has two "modes" and that it requires something
>> 		(presumably a routing protocol) to provide each "node" with a topology
>> 		map.
>> 		
>> 		Suggest that a proper introduction consisting of three parts would be
>> 		beneficial: (i) what this document is, (ii) what doing DNCP actually
>> 		gets you, and (iii) the operating conditions under which the
>> 		DNCP is applicable.
>> 		
>> 		On the latter point, given that you state that DNCP requires profiles
>> 		to provide "actual implementable DNCP based protocols", it appears
>> 		important to understand what the limits for "what a profile can give
>> 		you" are.
>> 		
>> 		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".
> 
> As noted earlier, the introduction has been reworded and separated from
> protocol overview also considering your suggestions.

So this is good, thank you for doing that effort — it’s tedious, but it helped.

To section 3, therefore, a few suggestions:

	1)	Throw an initial paragraph in stating what DNCP does “state synchronization” and all that.

	2)	“DNCP discovers the topology of its nodes and …”
		Argh…almost there “its nodes”?
			-	would that be “the nodes in the DNCP network” (which has been defined…)?
			-	you’re discovering the topology (i.e., you actually produce a topology graph?)
				or just the presence or absence of nodes in the network (i.e., a destination list)?
		Just state what you do, and it’ll be good.

	3)	“bidirectionally reachable” — call out if that means “over one IP hop” (as in “on the same link”)
		or if it can be “bidirectionally reachable, possibly through a multi-hop path”

		Actually, why don’t you define that term in the terminology section, since it appears also
		in section 4, and it’d make me go away with this comment in more places than one ;)

	4)	“A hash tree is maintained by each node” — I’ve thought about that, and I think that you may
		want to expand a little more. “A hash tree, rooted in itself, is maintained by each node”?

	5)	And then, again, the text is almost there, bit just need a nudge…how is the tree constructed?
		You start fine “a node starts with a hash tree only consisting of itself”.
		Then it announces that, and gets updates. How are those “integrated” into the receiving nodes’
		hash tree. 

		Yes I know how it’d work out (I may be dense, but not *that* dense ;) ), but I think that it’d be 
		easy to capture all here and being complete, since it’s so close.

By the way, I would state that the hash tree is height 1 in this section, and add a forward reference to 4.1.

Overall, I really like section 3.

It might be a good litmus test to ask someone with no previous understanding of Trickle to give it a read-through and explain it back to you, though, just to be sure.

But I really like section 3. Thank you.

Section 4, I really like what you have done with it also. As a purely subjective matter, could there between 4 and 4.1 be some educational text that describes how the 6 subsections to 4 “fit together”? As it is right now, it’s a little abrupt.

>> 	o	The document, in my understanding, defines an exchange format with
>> 		limited ability to evolve, as simply "a steam of TLVs".
>> 
>> 		As long as there's never a need to evolve the TLV format itself, and
>> 		as long as you do not run out of TLV types, that's not going to be
>> 		a problem. The doc sets aside a 16bit TLV type space, that's reasonable
>> 		enough, but I worry if eventually a DNCPv2 will need to evolve the
>> 		format. One purely hypothetical example could be if a "sequence number"
>> 		would be needed in each DNCP message to detect "link success rates", or
>> 		something of that sort.
> 
> I think on this front we have to agree to disagree; as it is a stream of
> _unrelated_ TLVs with some rare exceptions (node endpoint ID => network
> state), a later spec such as DNCPv2 can specify if it wants to that
> every DNCP 'message' contains TLV of type $FOO and uses disjoint set of
> TLVs to do X. Hell, we do that in HNCP already.
> 

OK, then, in that case what you call a TLV is what I would call a “Message” — fair enough, I can do that mental substitution.

Now…that still doesn’t change the fact that you may end up having to evolve your Message format — I’m sorry, your TLV format — as it appears on the wire, as well as some of the behaviors that you exhibit through DNCP processing.

For that, you’ll need a version number. And again, I am sorry, I cannot come up with a concrete example and — again — that’s part of the dilemma: a future extension that we have not thought about is, by definition, a future extension that we have not thought about and so therefore we can’t predict if it will be interoperable with a what we have now.

> 
>> 		
>> 		I do not have an actual example in mind -- and that's exactly the point:
>> 		to be evolutive for the unknown future and (at the very least) be able
>> 		to discriminate between "old" and "new".
>> 		
>> 		A discussion could be had if a "version number" in each TLV would do,
>> 		or if a concept of "protocol message with a version number" is
>> 		preferential. I do not believe, however, that "no version number" is
>> 		viable.
> 
> Since DNCP is an abstract protocol, a concrete protocol on top of it
> might probably want to do versioning for its own purposes (i.e.
> different versions on top of the same DNCP version). In this case having
> versioning in both DNCP and the derived protocol serves little purpose.
> HNCP - as first derived protocol - defines a Version-TLV btw.
> 

Yes but that is a “version TLV” — what happens if the TLV format itself, or some of the DNCP specific processing.

This, incidentally, goes to the crux of why I — personally — would not have done the split. Had DNCP *exclusively* been an algorithm, or such, then I could see not needing a version in DNCP, but in the DNCP-based protocol (HNCP) only. Or, for that matter, had DNCP been just a frame format with no processing, or something, then I could see one sequence number sufficing.

By DNCP being part-signals-part-procesing-part-behavior-part-framework, which cannot exist on its own but which requires “another protocol which profiles it and which also defines its own signals, processing, and behavior”, yes, you actually having this “version number conundrum”.

You could not fix all this by having a DNCP version number only, but having a sufficiently large TLV type space? That way, you’d not need (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B and D (but not C) from HNCPv1, and would reserve and define TLV types X, Y, Z ?

>> 
>> 	o	Noting that the "overhearing n reduncant transmissions" is a key
>> 		retransmission suppression mechanism in Trickle, and that this
>> 		seems to assume broad/multicast, using unicast seems to contradict
>> 		the statement of "consists of Trickle", at least in the way the
>> 		algorithm is defined in RFC6206. Note: it's fine to use an algorithm
>> 		outside of its initial scope, but it should be with the caveat of
>> 		"which of the characteristics still hold, and which do not"
> If k < 2, even on point-to-point link, Trickle does reap benefits and
> provides exponential backoff timer. Obviously, we can spell this out
> more explicitly if it helps.
> 

YES, that sort of explanation would be good.

>> 
>> 	o	DNCP claims to be trickle based, yet supports unicast. It also
>> 		(apparently) is a request/reply protocol.  It doesn't have messages.
>> 		This document needs a good, and pedagogical, "protocol overview and
>> 		functioning" section somewhere: one needs to get through the end of
>> 		Section 5 before having even a vague idea of how DNCP works.
> Protocol overview added.

Perfect, as I said, I like what you did in section 3.
		
>> 	o	The use of normative language is not as tight as could be desired.
>> 		For example, a number of SHOULDs seem to really ought to be "MAYs" since
>> 		not following the SHOULD won't break the algorithm. It would be good
>> 		to walk through the document and take a careful look at these to
>> 		either MUST/MAY the SHOULDs, or to qualify the SHOULDs remaining.
>> 		
> Reworked.

That seems to have helped a great deal.

>> 	o	I am going to go out on a limb here, and say that "the protocol is
>> 		underspecified". That's a deliberately provocative statement, but it
>> 		was honestly how I felt upon having completed the review.
>> 		
>> 		The document does not help the reader get an intuitive understanding
>> 		of the protocol functioning, but jumps right into minute details --
>> 		requiring the reader to "build up her or his own model of how DNCP
>> 		works". On having read the document a few times, I think that I
>> 		understand it -- but there's nothing permitting me to verify my
>> 		understanding, and thereby I'd not feel confident to be able to
>> 		provide an interoperable and independent implementation. I've given
>> 		some comments in the "Comments" section as to what I think would be
>> 		viable ways to improve this point.
>> 
> Addressed.

Indeed you did. It seems a LOT better, and I appreciate your efforts here. As I said, I am trying to respond to those issues that seem to be outstanding in this email; I’ll go through the document once more in all its nitpicking detail once we’ve resolved those few issues that I think are still pending.

> 
>> 	 o	Section 5.3, penultimate paragraph:
>> 	
>> 	 		"If keep-alives specified in Section 6.1 are NOT sent by the peer
>> 		     (either the DNCP profile does not specify the use of keep-alives or
>> 		     the particular peer chooses not to send keep-alives), some other
>> 		     means MUST be employed to ensure its presence.  When the peer is no
>> 		     longer present, the Neighbor TLV and the local DNCP peer state MUST
>> 		     be removed."
>> 		
>> 		"...some other means MUST be employed to ensure its presence." --
>> 		followed by more MUST verage when a peer disappears...I am not sure that
>> 		that's conductive to interoperable implementations.
>> 		
>> 		Two implementatons may chose different "means" and then turn off keep-
>> 		alives - and be non-interoperable.
>> 		
>> 		For interoperability, we need:
>> 		
>> 				o	A mandatory to implement mechanism, that always is
>> 					present, but can be complemented by another "means", or
>> 					
>> 				o	A mandatory to implement mechanism, which by way of a
>> 					specified negotiation mechanism can be turned off between
>> 					two peers, to allow them to use another "means".
>> 					
>> 		If you argument is "...this will be specified in the profile", then
>> 		you still should provide the two above in this document, with the note
>> 		that "...and a profile may specify which from among these MUST be
>> 		used in a given deployment"
> 
> Clarified that “other means”, refers to existing transport-provided
> mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc.

Alright, good. Now where is it specified which is to be used? Is that part of the profile, or should it be? If so, call that out here.

I’m trying to avoid interoperability issues, for example if I am using “TCP keep-alives” and you are using something else, can we work together? If this is not a problem, call that out as something which a device can do as it sees fit (although, for example. TCP keep-alives presumably expects TCP which is a profile matter …)

I *think* that we are almost there also with this point, so convince me that the text there won’t cause interoperability issues? Hiving it off to a profile to specify would do just that (of course, I’d come back on that in HNCP, instead ;) ).

> 
>> 
>> 	o	Section 8:
>> 		Interesting; I am not a security expert, but I am very curious to
>> 		see the SEC-DIR review of this document. That said, section 8.3.1
>> 		contains normative verbage:
>> 		
>> 			"A node MUST be trusted for participating in the DNCP network if and
>> 			only if..."
>> 			
>> 		Which I think needs a qualifier of the "If the certificate based
>> 		trust model is used, then a node must be trusted for ...."
>> 	
>> 		Same goes for the subsequent SHOULD - it really reads as-if this
>> 		certificate based mechanism initially was intended as MTI, but then
>> 		was backed away from subsequently without a complete cleanup of the
>> 		text?
> 
> It was never intended to be MTI, the intention was that nodes not
> participating in the mechanism would ignore the whole section (and
> normative language), that is now explicitly stated in normative language
> in the beginning.

OK, this is not a comment, then, for the authors to action, but for the WG chairs: I would strongly recommend that you reach out to the SEC ADs to understand what their expectations are to this.

Speaking from not-so-ancient-experiences, the SEC-ADs have become more “strict” with what they let through, and what might have passed a year ago would not fly today. 

I am NOT a security expert, though, but as they say, a burnt child ...

>> 		
>> 		I do actually question the value of having a laundry-list of trust
>> 		management methods, and for one of those (certs) a laundry-list
>> 		of all sorts of trust relationship establishment methods, in this
>> 		document; this in no small part as the lists are explicitly indicated
>> 		as "non-exhaustive" and that none are listed as "mandatory to
>> 		implement". Was any thought given to factoring this into a seperate
>> 		document, and focusing in this document on one, mandatory-to-implement,
>> 		security mechanism?
> 
> This set is a 'useful base set' that e.g. HNCP requires. While I agree
> it is not exhaustive, as the original goal was just to split DNCP and
> HNCP, I consider it a success.

Not sure that I agree, but I think I will fold this into “discuss with SEC-ADs” since that’s for the most part not in my scope of competencies.

>> Minor Issues:
>> 
>> 	Introduction:
>> 		o	1st paragraph: "reachable nodes"; two things:
>> 		
>> 				-	I always have a problem with the term "node"; it is often
>> 					used as a shorthand for "routers and hosts, both". I was
>> 					given to understand that homenet specifically did not want
>> 					to consider host changes?
> DNCP is not strictly speaking about homenet (but a strict requirement
> for HNCP which is). Also even in homenet-case non-routers may join the
> network temporarily in order to e.g. do monitoring.

But, would those “non-routers” not speak at least part of the “home net specific protocols” and thereby not be “hosts” in the “got them from Best Buy and just clicked OK” sort of sense? 

So is the crux that we have “homenet-aware devices” and “legacy hosts”, and that either of us just need to get with the program? If so, can I insist (gently) on “homenet-aware devices” [with a suitable definition] instead of “nodes” since “nodes” are such an overloaded term that it’s not even fun any more.

>> 					
>> 				-	"Reachable" - does that mean something as in "radio range",
>> 					does it mean "on the same link", does it mean within a
>> 					specific (DNCP?) domain, or does it mean simply "on the
>> 					Internet somewhere"?
> 
> Clarified in the text as “bidirectionally reachable”, also added
> fwd-references to actual definition.

Suggest also defining in Terminology, and clarifying if this is a one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do not see a forward reference, btw, at least not in latest rev.

> 
>> 					
>> 		o	2nd paragraph: "nodes that are currently accounted for":
>> 				-	What does that mean?
>> 				
>> 				-	Also, the conclusion "Therefore unlike Time-To-Live (TTL) 	
>> 					based solutions, it does not require periodic re-publishing
>> 					of the data by the nodes" does actually not follow from
>> 					the previous sentence in that paragraph.
>> 
>> 				-	I actually do not think that the introduction describes
>> 					what DNCP does, and so the comparison to TTL-based
>> 					solutions is rather hard to get here.
> Fixed.	

Indeed it is.

> 
>> 					
>> 				-	Continuing:
>> 				
>> 						"On the other hand, it does require the topology
>> 						to be visible to every node that wants to be able to
>> 						identify unreachable nodes and therefore remove old,
>> 						stale data."
>> 						
>> 					This reads a lot more like an applicability statement than
>> 					an introduction; the take-away when reading this is:
>> 					
>> 						"Each node must have something that maintains
>> 						 a topology map of the entire network, such as
>> 						 a (LS) routing protocol, for DNCP to function"
>> 						
>> 					Is that actually the intent here?
>> 					
> Clarified, it was intended to be read as DNCP itself providing that
> topology.
> 

OK.

> 
>> 				-	"DNCP is most suitable for data that changes only gradually"
>> 					How is the reader to interpret "gradually"? Do you mean
>> 					"infrequently", or do you really mean "gradualy"?
> Clarified.
> 

OK

> 
>> 					
>> 		o Last paragraph:
>> 				"DNCP has relatively few requirements for the underlying
>> 				 transport; it requires some way of transmitting either unicast
>> 				 datagram or stream data to a peer"
>> 			
>> 			This is a bit of a forward comment, but we now have "nodes
>> 			that are accounted for" and "peers". I see neither defined in
>> 			the terminology section.
>> 				
>> 				"and, if used in multicast mode, a way of
>> 				 sending multicast datagrams."
>> 			
>> 			This is the first mention of two "modes" of this protocol. This
>> 			loops back to an earlier comment, that the introduction actually
>> 			does not introduce the protocol, but rather is an incomplete
>> 			applicability statement.
> Fixed and moved to more appropriate sections.
> 

And, it reads much better now. Thank you.

> 
>> 				
>> 				"If security is desired and one of the
>> 	 			 built-in security methods is to be used, support for some
>> 				TLS-derived transport scheme - such as TLS [RFC5246] on top of
>> 				TCP or DTLS [RFC6347] on top of UDP - is also required."
>> 
>>   			I am not pretending to be a security expert, but "some
>>   			TLS-derived...such as ... on top of TCP or DTLS..." (i) does not
>>   			sound like it could lead to interoperable implementations, and (ii)
>>   			does not sound sufficiently tight as a MTI security mechanism to
>>   			pass security reviews. Again, I am no security expert, but perhaps
>>   			getting one looped in early would be advicable?
> Clarified that profile MUST define details.
> 

Also good, thank you.

>> 			
>> 	Terminology:
>> 		o	Suggest adding "In this document ..." somewhere to this text:
>> 
>> 				"For readability, any DNCP profile specific
>> 				 parameters with a profile-specific fixed value are
>> 				 prefixed with DNCP_."
> Fixed.

Thanks

> 
>> 				
>> 		o	DNCP network: I read this twice, and came away with two different
>> 			understandings, perhaps you can clarify which it is:
>> 
>> 				o	A set of nodes running DNCP, within the same domain, and
>> 					for which a path betwen any two DNCP nodes includes only
>> 					other DNCP nodes; i.e., a DNCP network forms a connected
>> 					component with only other DNCP nodes.
>> 					
>> 				o	A set of nodes running DNCP. They may be anywhere on the
>> 					Internet, they are part of the same DNCP network as long
>> 					as they (through other means) have learned of each others
>> 					addresses.
>> 					
>> 			In the former, that'd be (for example) a deployment within my
>> 			home -- in the latter, it could be a node in my home and a node in
>> 			your home forming a DNCP network.
>> 			
>> 			The text is not quite clear on this point.
> Both are valid use cases; hopefully clarified.
> 

OK, sadly you clarified it ;) Well, no, not sadly, but you clarified it to be understandable to me in the above sense. But, if I come up with the aforementioned TNCP and I use the same transport as HNCP, would a TNCP and a HNCP node be on the same DNCP network, then?

>> 	
>> 		o	Link: a point of clarification here. In "DNCP network", there was
>> 			talk about "unidirectional links" and "bidirectional links"; in
>> 			"Link" the definition is somewhat vague "directly connected" and
>> 			"can communicate". Could something like "without decrementing TTL/
>> 			hop-count" be added, and could a statement on bidirectionality
>> 			(IOW, that this is just an IP link) be added?
> This isn’t IP specific as such; however, some better definition is
> welcome. some types of IP links are not strictly bidirectional either
> (hello, mesh).	

Hi, you rang? ;)

Actually “some mesh protocols” do go through the exercise of verifying bidirectionally before even considering them as useful for whatever the protocol tries to do.

What I am trying to get at, though, is not this discussion but rather: what does this Link present to the IP layer, in terms of properties?

>> 	
>> 		o	"Interface" is overloading the term "port" (IP port) which can be
>> 			confusing
> Done (stole definition from some RFC that is ‘port free’)

It’s, indeed, a very good idea to steal a good idea.
			
>> 		o	"Endpoint" - The definition "locally configured use of DNCP" is not
>> 			clear -- are you really not talking about a DNCP process?
>> 			
>> 			I am not sure that it is clear how a DNCP process can be "attached
>> 			to  ... a specific remote unicast address, or to a range of unicast
>> 			addresses that are allowed to contact"
>> 
>> 			I can see how a DNCP process can be configured to allow connections
>> 			from a specific range of addresses, or can be configured to connect
>> 			to a specific remote unicast address. Is that what you mean instead?
>> 			
> Clarified, endpoint most likely resembles network socket, i.e. bound to
> interface or connected to certain remote address etc.
> 

OK, I addressed that earlier in my comments.

> 
>> 			
>> 		o	"Peer" - states that two peers "communicate directly". For link,
>> 			the definition is "directly connected nodes can communicate".
>> 			Would it then not be easier to say "a DNCP node on the same link
>> 			as ..." ?
>> 		
> It is not. Removed directly if it helps.

Ah, so now it is just “someone out there in the network with whom I communicate” - fine, it’s clear.
> 
>> 		o	"Node state"
>> 				"The hash function and the number of bits used are defined
>> 				 in the DNCP profile."
>> 				
>> 			Suggest:
>> 				"The hash function and the length of the hash value are defined
>> 				 in the DNCP profile."
>> 			
> Done.

Thanks.

>> 			
>> 		o	"Network state hash" - same comment as for node state (above)
> 
> Done.

Thanks.

>> 		
>> 	Data model:
>> 		o	"Latest update sequence number"
>> 			This may just be my personal taste, but does it hurt to mandate
>> 			a specific way of doing the looping comparison? The reason I
>> 			suggest this is, that it's one of those things where creativity
>> 			in an implementation seems to simply be an invitation for bugs,
>> 			and for little gain
>> 			
> Done.

Thanks

> 
>> 		o	"Relative time delta"
>> 			Document talks about "a 32 bit number on the wire" -- does that
>> 			mean that wireless links are excluded?
> I thought this was an expression, but guess not, replaced with
> ‘transmitted as’ (both here + fragment stuff)

I’ve spent a good chunk of my career “off the wire” so I’m perhaps specially sensitive to that. Thanks for catering to my special sensitivities ;)

> 
> 
>> 			
>> 		o	Related to terminology, there seems to be some fuzzyness around
>> 			node and endpoint. For example, in data model one of the things that
>> 			a DNCP node may have is:
>> 
>> 				"Unicast address: the DNCP node it should connect with"
>> 			
>> 			Does that mean *any* DNCP process (i.e., *any* endpoint) at that
>> 			address, or a *specific* DNCP process at that address?
>> 			
>> 			The same, but inverse, for "Range of addresses: the DNCP nodes that
>> 			are allowed to connect" - is this "any DHCP process (i.e., *any*
>> 			endpoint) on any of these addresses?
>> 			
>> 			Following, the same section reads:
>> 
>> 				"For each remote (peer, endpoint) pair detected on a local
>> 				endpoint, a DNCP node has..."
>> 		
>> 			the following text indicating that there's some sort of distinction
>> 			between which endpoint.
>> 			
>> 			This whole thing needs some clarification.
> I think there was a general misconception about the term endpoint, which
> is hopefully cleared up in the latest revision.
> 

Hm, it was cleared somewhat, but there are still murky areas; see previous comment. I am still confused after having read through the relevant bits again, but I am confused in a different way now, than I was last time. That may be an improvement after all. I think the crux is the distinction between “Address” and “Endpoint” in the terminology, and once that is settled the rest will likely fall into place.

> 			
>> 		
>> 	Operation
>> 		
>> 		o	First a generic comment that Trickle itself has some operating
>> 			conditions which scopes its applicability, and it would behove
>> 			this document to, in its own applicability statement, call out
>> 			those.
> Added some comments regarding applicability.

Better, but I would like to see that reflected also in a dedicated applicability statement.

>> 			
>> 		o	On the same token, while the use of Trickle in an unicast fashion
>> 			is possible, I wonder if (in general) unicast use is advicable. I
>> 			appreciate that some links are point-to-point and so a broadcast
>> 			across it becomes an unicast -- but, does that necessitate being
>> 			called out?
>> 			
>> 			IF the reason for this "because we can use TCP", then be explicit
>> 			about this - but, also, that you're then not exactly using Trickle
>> 			where and how it was intended. I wonder if you could be explicit
>> 			as to what consequences this "alternate use of Trickle" have? It
>> 			seems that the use of unicast is directly contradicting the main
>> 			operating consideration of Trickle?
> 
> In general DNCP is transport agnostic, therefore calling out a specific
> transport such as TCP is a bit debatable. RFC 6206 seems to be all about
> picking right values at least; they DO NOT say it is multicast or
> broadcast only, only that it communicates with 1 address. that's what we
> do, it's just the other endpoint.
> 

OK, fair enough argument.

>> 			
>> 		o	2nd paragraph states:
>> 		
>> 				"the multicast transport does not have to be particularly
>> 				 secure"
>> 		
>> 			What is the definition of "not have to be particularly secure"?
>> 			Is cleartext OK? Authentication? Encryption?
>> 			Should I do something more?
>> 			
> Clarified: ‘.. does not have to be secured.’

Thanks.

> 
>> 	5.1 Trickle-driven status updates
>> 		o 	First paragraph:
>> 		
>> 				"Multicast MUST be employed on a multicast-capable interface;
>> 				 otherwise, unicast can be used as well"
>> 			
>> 			If the interface is not multicast-capable, then unicast can be
>> 			used as well as what? Certainly not multicast, since the interface
>> 			is not multicast capable...?
>> 			
> All fixed.

Yup, it is.

> 
>> 		o	Continuing:
>> 		
>> 				"If possible, most recent,"
>> 			
>> 			What would make it "not possible"?
>> 				
>>   				"recently changed, or best of all, all known Node State TLVs"
>>   			
>>   			OK, so assuming that for some reason (MTU limitation) it is not
>>   			possible, does the above represent an order that I MUST respect,
>>   			or is it "take a pick from among these, according to your whim of
>>   			the day"?
>> 
>> 				"(Section 7.2.3) SHOULD be also included,"
>> 				
>> 			SHOULD is a strong statement, especially when prefixed by
>> 			"if possible". That, essentially, renders it a MAY.
>> 			
>> 				"unless it is defined as undesirable for some reason
>> 				 by the DNCP profile
>> 			
>> 			Now it DEFINITELY is a MAY since apparently a profile can state
>> 			that these TLVs MUST NOT be included -- and, I assume, since the
>> 			document permits it to do so, it is possible without breaking the
>> 			algorithm.
> Degraded to MAY; while it improves convergence speed, it is not worth
> being too specific about it.

And that’s exactly what I like to see MAYs used for, so fantastic, thanks.

> 
>> 			
>> 		o	And, continuing again:
>> 		
>> 				"If the
>>   				 DNCP profile supports dense broadcast link optimization
>> 				 (Section 6.2), and if a node does not have the highest node
>> 				 identifier on a link, the endpoint may be in a unicast mode in
>> 				 which multicast traffic is only listened to.  In that mode,
>> 				 multicast updates MUST NOT be sent."
>> 
>> 			Really hard to parse. Is that not equivalent to saying:
>> 			
>> 				"If a DNCP endpoint is not configured to be in multicast
>> 				  mode, then it MUST NOT send multicast updates"
>> 				
>> 			?
>> 			
>> 			If it is, then say that -- if it is not, then a rewrite is needed,
>> 			as that's what I manage to extract from the text.
> Hopefully clarified now, about when multicast/unicast is used.

yep, I think it is.
	
>> 	5.2.  Processing of Received TLVs
>> 		o	First paragraph reads:
>> 		
>> 				"The DNCP profile may specify criteria based on which particular
>> 				 TLVs are ignored."
>> 			
>> 			Criteria for what? Do you perhaps mean:
>> 			
>> 				"The DNCP profile may specify which TLVs to process, and
>> 				 which to ignore"?
>> 			
>> 			Auxiliary question, then, and related to my penultimate comment
>> 			to 5.1, are there any constraints on that, any risks from ignoring
>> 			(or not) specific TLVs to the operation of the network?
> Added some text to the profile section and reference.
> 

Yup, good.

> 
>> 			
>> 		o	I am also confused by the 3rd sentence in the first paragraph:
>> 		
>> 				"Any ’reply’ mentioned in the steps below denotes sending of
>> 			 	 the specified TLV(s) via unicast to the originator of the TLV
>> 			 	 being processed."
>> 			 	
>> 			 This confusion is likely due to the lack of a "protocol overview
>> 			 and functioning" description [either as its own section, or as part
>> 			 of the introduction].
>> 			
>> 			 I know how trickle works. Trickle is a distributed consistency
>> 			 algorithm. When an inconsistency is detected, then an action is
>> 			 triggered that rectifies that inconsistency.  DNCP claims to be trickle based, but apparently also a sort of request/reply
>> 			 mechanism. Combined with trickle-over-unicast-links, I am not sure
>> 			 what the protocol logic actually is. Reading through to the end of
>> 			 Section 5, I think that I understand the idea, but I am not sure.
>> 			
>> 			 And the old "when in doubt, look at the state machines" didn't help
>> 			 either, there aren't any.
>> 			
>> 			 The point to this comment is, that the document immediately jumps
>> 			 into the details -- but forgets to give the "10000ft view" of the
>> 			 protocol functioning.
> Added protocol overview and made connection between trickle, merkle tree
> and requests more clear.
> 

Indeed, and “merkle trees” disappeared and became hash trees somewhere along the line ;)
> 
>> 			
>> 		o	First paragraph states two SHOULD. Would those not be MUST? What
>> 			breaks if not respecting those criteria?
> Done.

tnx

> 
>> 			
>> 		o	2nd paragraph, a "valid address", that definition is rather unclear.
>> 			I understand that that's something specified in "the profile", but
>> 			what is the relationship to the different addresses discussed in
>> 			the data model section?
>> 			
>> 			It is not clear what the parenthesis to this paragraph means,
>> 			but that is probably again a case of the "use case" and "protocol
>> 			overview" not being documented - the document so far has nowhere
>> 			described interaction with outside processes.
> Text changed.

Ok, I can live with that.

> 
>> 		
>> 		o	First bullet, but generally through these, and other, bullets:
>> 		
>> 			I had a really hard time deciphering this. First:
>> 			
>> 				"The receiver MUST reply
>> 		         with a Network State TLV (Section 7.2.2) and a Node State TLV
>> 		         (Section 7.2.3) for each node data used to calculate the
>> 		         network state hash"
>> 		
>> 		    Alright, off to find "network state hash".
>> 		
>> 		    The terminology tells me that it is:
>> 		
>> 		    	"a hash value which represents the current state of
>>  				 the network.  The hash function and the number of
>>                 bits used are defined in the DNCP profile.
>>                 Whenever a node is added, removed or updates its
>>                 published node data this hash value changes as
>>                 well. It is calculated over each reachable nodes'
>>                 update number concatenated with the hash value of
>>                 its node data. For calculation these tuples are
>>                 sorted in ascending order of the respective node's
>>                 node identifier.
>> 
>> 		    Searching further, I find Section 5.1, but that simply states:
>> 		
>> 		    	"The Trickle state for all endpoints is
>> 			     considered inconsistent and reset if and only if the locally
>> 			     calculated network state hash changes."
>> 
>> 			Next occurence is in these bullets, and then just before Section 6,
>> 			
>> 				"During
>> 			     the grace period, the nodes that were not marked reachable
>> 			     in the most recent graph traversal MUST NOT be used for
>> 			     calculation of the network state hash, be provided to any
>> 			     applications that need to use the whole TLV graph, or be
>> 			     provided to remote nodes."
>> 			
>> 			Alright, now I know what I can't use for calculating it.
>> 			
>> 			A few occurences later, in section 7.2.2, in what looks like a
>> 			section laying out the packet -- sorry, TLV -- format, I see for
>> 			"Network State TLV":
>> 			
>> 				"This TLV contains the current locally calculated network state
>> 				hash. It is calculated over each reachable nodes' update number
>>   				concatenated with the hash value of its node data in ascending
>>   				order of the respective node identifiers"
>>   				
>> 			Phew. Now, it does seem a little at odds with the terminology. The
>> 			terminology states something about tuples that are ordered. While
>> 			those tuples are not defined (they should be), at least what is
>> 			described is clear and possibly can be implemented. What is in 7.2.2
>> 			is not ant cannot.
> Unified and deduplicated the definitions and added appropriate references.
> 

Yay you! Thanks

>> 			
>> 			This is an instance of a general issue that I have with this
>> 			document: that it doesn't take a step back, and properly define
>> 			things in a proper order, but dives into (and repeats) details.
>> 			
>> 			
>> 		o	Also to section 5.2, for each of the cases that are described, could
>> 			a conceptual description of "what this corresponds to" be added? For
>> 			example:
>> 		
>> 				Upon reciept of a Node State TLV:
>> 					If the node identifier matches the local node identifier and
>> 					the TLV has a higher update sequence number than its current
>>    	     		local value, or the same update sequence number and a
>>    	     		different hash, the node SHOULD re-publish its own node data
>>    	     		with an update sequence number 1000 higher than the received
>>    	     		one.
>> 			
>> 		 	It's not clear why it is a "SHOULD re-publish" (not MUST, nor what
>> 		 	happens if SHOULD is not followed). And it is not clear why 1000 ...
>> 			
>> 			[I just pick this example, but it applies to all processing bullets]
> Hopefully all fixed.

I think so, yeah.

> 
>> 			
>> 	o	In the same cases, it is a lot more readable (IMO) to do nested bullets:
>> 	
>> 		o	If FOO; and either of:		
>> 	 			- BAR
>> 	 			- GNYF
>> 	 			- BLAB
>> 	 		Then do all of the following:
>> 	 			- ...
>> 	 			- ...
>> 	 			- ...
>> 	 	o 	Otherwise, if not-FOO, ...
>> 	 	
>> 	 	That's a personal preference, though, so feel free to disregard this
>> 	 	comment.
>> 	 		
>> 	 o	Section 5.3 and elsewhere, suggest replacing:
>> 	
>> 	 		"If it comes via..."
>> 	 	
>> 	 	by:
>> 	 	
>> 	 		"If received over …
>> 	 	

> Done.

Yup

>> 		
>> 	o	Last paragraph in 5.3:
>> 			Same comment as 3rd comment to 5.1 made above.
> Some rewriting done.
> 

yup

>> 		
>> 	o 	Section 5.4, first sentence:
>> 			"DNCP validates the set of data within it ..."
>> 			
>> 		Should that not be:
>> 			"A DNCP instance validates the data within its data sets ..."
>> 		
>> 		?
>> 
>> 		Also, "nodes that are currently accounted for; what's the definition
>> 		of "accounted for"?
> Replaced the whole paragraph.

Indeed you did, and it is better for it.

> 
>> 		
>> 	o	Section 5.4, first paragraph
>> 		The statement:
>> 		
>> 			"therefore,
>>   			 unlike Time-To-Live (TTL) based solutions, it does not require
>> 		     periodic re-publishing of the data by the nodes.  On the other
>> 		     hand, it does require the topology to be visible to every node that
>> 		     wants to be able to identify unreachable nodes and therefore remove
>> 		     old, stale data."
>> 		
>> 		which also appeared in the introduction, is copied verbatimly. Once
>> 		more, the statement is a claim which is not supported, and that which
>> 		follows "therefore" is not a consequence of that which comes before
>> 		"therefore".
> Got rid of duplicate.

Thanks

> 
>> 	
>> 	o	Section 5.4, first paragraph
>> 	
>> 			"When a Neighbor TLV or a whole node is added or removed, the
>> 			neighbor graph SHOULD be traversed, starting from the local node.
>> 			The edges to be traversed are identified by looking for Neighbor
>> 			TLVs on both nodes, that have the other node’s identifier in the
>> 			neighbor node identifier, and local and neighbor endpoint
>> 			identifiers swapped. Each node reached should be marked currently
>> 			reachable."
>> 			
>> 		First comment, why SHOULD and not MUST?
> Retained this part, there was a ‘lightweight’ node option that can do it
> without this; however, I consider it non-interesting so changed to MUST.

OK, thanks

> 
>> 		
>> 		Second comment, and now you made me go look...."neighbor" sounds like
>> 		"someone on the same link as me" so  the "neighbor graph" is really just
>> 		a set relating "this node" and "another node which is on the same link
>> 		as this node".
>> 	
>> 		Yet, looking in the terminology, I see "Neighbor graph" defined as:
>> 				"the undirected graph of DNCP nodes produced by
>>                 retaining only bidirectional peer relationships
>>                 between nodes.
>> 		
>> 		Which doesn't sound as much like a "neighbor graph" as it does a
>> 		"topology graph" for the whole network.
>> 		
>> 		So, is the terminology wrong, or is the definition wrong?
> Renamed to “Topology Graph” - probably confusion of non-native-speaking
> authors.
> 

…and this reviewer, who also is a non-native-english speaker. [We might have another language in common, though…?]

>> 	o	Section 5.4, 3rd paragraph
>> 		
>> 		Is it actually important that the content of that graph be "purged"?
>> 		That sounds like an implementation detail -- rather, it sounds like
>> 		the elements of the graph should "not be used for calculations and
>> 		MAY be removed". Or, is there a specific requirement that I am
>> 		missing?
> Added lots of text; gist of it, basically, is that unreachable nodes
> SHOULD be removed and MAY be removed immediately.

Yup, and it is actually nice and clear that text.
		
>> 	o	Section 6.1, I do not understand the parenthesis in this sentence:
>> 	
>> 			Trickle-driven status updates (Section 5.1) provide a mechanism for
>> 			handling of new peer detection (if applicable) on an endpoint
>> 		
>> 		Under what conditions is that applicable, and under which is it not?
> Actually always now; removed (if applicable).

good.

> 
>> 	
>> 	o	Section 6.2:
>> 	
>> 			"An upper bound for the number of neighbors that are allowed for a
>>   			 (particular type of) link that an endpoint runs on SHOULD be
>>   			 provided by a DNCP profile, user configuration, or some hardcoded
>>   			 default in the implementation."
>>   			
>>   		A couple of things to that:
>>   			1)	Can you explain the parenthesis? What type of link?
>>   			2)	How does "an endpoint runs on" a link?
>>   			3)	Why SHOULD?
>>   			4)	Is this specification seriously suggesting "some hardcoded
>>   				default in the implementation" as a SHOULD?
>> 
>> 		[I am tempted to upgrade this to a "Major issue" simply because of 4) ]   	
> Clarified, the choice to use it is not really visible externally. Now
> the text has per multicast-enabled link type constraints, and also
> per-profile support for extension at all.
> 
> 	
>> 		
>> 		
>> 		Also to 6.2, this particular optimization, do you have any
>> 		quantification of its actual benefit? What should I look for to
>> 		determine if this "optimization" yields a benefit or not? What are
>> 		you trying to optimize? Over what link types does this function?
>> 		I am dubious that it "optimizes" much, if anything, across an Ethernet, for example ...
> Oddly enough, most link-state routing protocols have this optimization.
> Added further description on why it is helpful.
> 

So, the things that you did to this, and the precious comment, helps. The “designated router” (or equivalent/derivatives/*) mechanism is, as you point out, well known and well used. I was yanking your chain a little bit here to get, well, pretty much the explanation and discussion that you gave. Thank you for that.

Nit, though, just so that I feel useful in doing this:

	OLD:
		MAY also be chosen at runtime.  Main consideration when selecting 

	NEW:
		MAY also be chosen at runtime.  The main consideration when selecting 

But, good job here.
		
>> 	o	Section 7
>> 		As indicated previously, having to search through the frame format
>> 		diagrams for "how to calculate the value" isn't ideal.
> Should be clearly defined earlier now.

It is.

> 
>> 		
>> 	o	Section 7.2.3, I worry when I see something like this:
>> 	
>> 			"The whole network should have roughly the same idea about the time
>> 			 since origination of any particular published state."
>> 			
>> 		What is the definition of "roughly"?
>> 		Is the "should" intentionally in non-caps?
>> 		What're the consequences if not?
>> 		[Note that trickle almost mechanically makes information propagate
>> 		with non-trivial jitter across a network, so how do you ensure this?]
> Clarified the paragraph, since the original text could be interpreted
> invertedly.
> 

Another nit…

	Every node, including the originating one

what is “the originating one”, is it “…including the node originating this TLV”?

Otherwise, yes to your clarification.

>> 		
>> 	o	Section 7.2.4, CUSTOM-DATA TLV.
>> 	
>> 		Given the description:
>> 			"This TLV can be used to contain anything; the URI used should be
>> 			 under control of the author of that specification."
>> 		
>> 		It seems that (i) the description is self-contradictory: it cannot
>> 		contain *anything* but can contain an URI?
>> 		
>> 		Secondly, how is this supposed to work, what does it mean [for DNCP]
>> 		that "the URI is under control of the author"?
>> 		
>> 		Thirdly, what does "that specification" refer to?
>> 		
>> 		Fourthly, why lower-case should? Indeed, why is the "control" of the
>> 		URI of any importance to DNCP?
> Removed, since it had issues (besides being ambiguously defined). DNCP
> profiles can define additional TLVs easily.

Just to be clear, you removed the whole TLV type? That’s fine by me.

> 
>> 
>> 	o	Section 9, the bullet:
>> 	
>> 			"When receiving messages, what sort of messages are dropped, as
>> 			specified in Section 5.2"
>> 		
>> 		Seems at odds with Section 5.2, which discusses TLV processing.
> Unified terms to “ignore”, added explanation mentioning security reasons
> 

Good.

> 
>> 		
>> 
>> Nits:
>>   		
>> 	Requirement Language:
>> 		o	Please reflect Errata 499 for RFC2119 in the boilerplate
>> 		
>> 		o	The RFC2119 boilerplate could conveniently be in the terminology
>> 			section, given that it is terminology.
>> 			
>> 
> Both done.
> 

Thanks. As I said, great job guys (and WG); IMO we’re really close with this.

Cheers,

Thomas

---

From: Steven Barth <[email-masked]>
Date: Tue, 28 Jul 2015 18:06:57 +0200

Hello Thomas,

let me just quickly say, thanks again for your detailed reviews. Together with
the others it helped us a great deal in advancing the draft to where it is today.

We have put your HNCP-review and this follow up for DNCP on our todo,
and will provide you with some detailed changes and replies once we are
through. Though since this is post-IETF time we have to go through the
piles on our desks and on top of that also holiday season, it will probably
take some more time for the next revisions.

Thanks,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 29 Jul 2015 14:06:53 +0300

First of all, thanks a lot again for review comments; I think you are the most critical reviewer we have had yet, and it helps to improve the document quality a lot :) We have had a number of reviews by this point, but I believe you have raised order of magnitude more changes than the second in line who also lives in Paris; is this a coincidence? I think not. Anyway, on to comments..

Caveat: These are my comments, Steven is likely to fix typos before we actually hit publish button on -09 :)

Executive summary: Minor edits, but as you are good with words, time to ask for advice - how would you explain “Endpoint” in the terminology? (Anyone else on the list too, feel free to chime up..)

Fact: It is not socket. I consider it essentially bidirectional mapping between an endpoint #, and some transport details (as it is used for both receiving and sending traffic).

Random examples from existing implementations:

- _a rule_ that matches that stuff from ::1 is endpoint #1 (on shared socket)
- _a rule_ that we try to contact 2001:db8::1 and denote it as endpoint #2 (on shared socket)
- a socket which is bound to eth0 + port X, and listens to multicast there, denoted as endpoint #3
- (shared socket on port Y) which is listens to eth1 multicast (and also deals with eth1 link-local unicast traffic), denoted as endpoint #4

The current text-monster is as follows:

Endpoint	a locally configured communication endpoint of a DNCP node, such as a network socket. An endpoint may be bound to a set of predefined unicast Addresses representing remote DNCP nodes to individually connect to or to accept connections from whereby communication with each node is separated (e.g., an individual unicast UDP message flow per remote node). An endpoint may also be bound to a whole network interface, then multicast communication is used (in addition to individual unicast flows) to send certain messages to all DNCP nodes connected therewith at once as well as to automatically discover new DNCP nodes. Endpoints are usually in one of the transport modes specified in Section 4.2.

> I can live with what is there.

I think the separation makes sense (as DNCP itself is generic algorithm, more or less); however, the point of separation I am not so sure about (e.g. concrete TLVs in DNCP feel bit wrong, but there are reasons for that too; easier to specify DNCP-based protocols).

> I still think that it would be fantastic to have an applicability statement included. Reading the document without any context [as it might down the line if it was to become an RFC], it’s hard to u…

Adding one in -09; however, it is still undergoing edits. Gist of it is to look at 

[1] min (keepalive-interval-if-nonzero, churn frequency * number of nodes) and compare it to Trickle parameters chosen
[2] consider amount of TLV change within TLV sets published by nodes (large set, small changes => may not be the best protocol for the job due to lack of per-TLV deltas)

> As I said in my original review, I think that this is a matter of scoping the work right. The abstract, and the into, calls out “a generic state synchronization protocol” — I’ve heard OSPF describe…

WG isn’t, but we wound up doing one anyway. Still, we’re adding applicability subsection in 09, as I think it is important to note that DNCP is _not_ the tool for many things.

> Why don’t you put a subsection before the last paragraph of the Introduction “Applicability” and then expand on that?

Addressed above.

> I just want to note that I enjoyed the expanded terminology - thank you! There may be a small formatting snafu, at least in the HTML version, about missing blank lines between (for example) “Addres…

Hopefully fixed.

> Could I suggest that to the definition of “DNCP network” some verbiage to that effect be added?

NEW: a set of DNCP nodes running DNCP-based protocol(s) that have matching DNCP profile.

The side effect is that if DNCP profiles match, essentially transit service is provided even if the implemented protocol is not same. (e.g. HNCP + SHSP currently.)

> 			o	The set of optional parts of this specification, which are to be used.”

Adopted the gist of it, although not going to convert to a list (and retained DNCP_ note as it is useful to understand DNCP_foo coming up shortly in the next few things).

NEW:
   DNCP profile      consists of the values for the set of parameters,
                     given in Section 9. They are prefixed with DNCP_ in
                     this document. It also specifies the set of
                     optional parts of this specification, which are to
                     be used.

> 			o	generation and processing rules for these TLVs

NEW:
DNCP-based protocol	a protocol which provides a DNCP profile, according to Section 9, and zero or more TLV assignments from the DNCP profile-specific TLV registry as well as their processing rules.

> 		say that it’s a little bit like being “relatively pregnant” — either you are, or you are not?

Got rid of some relatively’s.

> 		down the line, deal with it then?)

I am not sure it would help as such. The addressing may also occur inside transport - think multiple flows multiplexed over single stream connection, for example. Or local UNIX domain sockets :)

> Address, by the way, uses “endpoint” which is defined below. 

Transport protocol endpoint and DNCP endpoint are not neccessarily the same thing. They may have 1:1 relationship, but also 1:N (or possibly M:N) are possible. Got rid of endpoint in the new definition.

NEW:

Address	an identifier which specifies how to reach a particular instance of a transport protocol on a particular node. In case of an IPv6 UDP transport, an address in this specification refers to a tuple (IPv6 address, UDP port).

> Could you clear that up, please? [Note, it’s better than the -05, but still confusing]

I am not sure how. There has been literally half dozen iterations so far. I am not sure I like the current one, as it is overly verbose and apparently not much closer to the goal.

(see top)

> 	1)	Throw an initial paragraph in stating what DNCP does “state synchronization” and all that.

As this comes after the intro (which does that), I am not sure I agree with the need. Do you suggest cut-n-paste, or something new here?

> 		Just state what you do, and it’ll be good.

Using the first suggested text. Of course, this ’topology’ may be somewhat misleading too as we do not really necessarily have low-level topology, but just connectivity among DNCP nodes. *sigh*

(In point-to-point case, there may be arbitrary number of hops in the middle DNCP is blissfully unaware of.)

> 		in section 4, and it’d make me go away with this comment in more places than one ;)

Hmm. Given we leave actual transport out, I am not sure how it could be over one IP hop.

Anyway, added a definition (not cut-n-pasting here so Steven has time to fix it, cough).

> By the way, I would state that the hash tree is height 1 in this section, and add a forward reference to 4.1.

Added some forward refs, and updated the text.

A hash tree of height 1, rooted in itself, is maintained by each node to represent the state of all currently reachable nodes (see Section 4.1) and the Trickle algorithm is used to trigger synchronization (see Section 4.3). 

> For that, you’ll need a version number. And again, I am sorry, I cannot come up with a concrete example and — again — that’s part of the dilemma: a future extension that we have not thought about i…

TLV space is relatively large, and mostly undefined. I still do not see the problem.

I see much more of a problem defining e.g. 4 byte version thing, because after that speaking ‘both versions’ of the protocol becomes hard.

> By DNCP being part-signals-part-procesing-part-behavior-part-framework, which cannot exist on its own but which requires “another protocol which profiles it and which also defines its own signals,…

Why? The concrete DNCP-based protocol actually says what it supports, and e.g. future DNCP extensions are not implicitly part of HNCP, unless we specify them to be.

> You could not fix all this by having a DNCP version number only, but having a sufficiently large TLV type space? That way, you’d not need (say) HNCP version numbers, but a HNCPv2 would use TLV type…

HNCP has 2^16-few types to play with. Is that not enough?

(Only up to 32 and the local tinkering range are excluded from the DNCP profile specific registry HNCP will set up. However, conflicts in handling the 256+ range are currently being considered on how they should be handled.)

> YES, that sort of explanation would be good.

Added that to the applicability subsection too. (Pending Steven check, *grin*)

> I *think* that we are almost there also with this point, so convince me that the text there won’t cause interoperability issues? Hiving it off to a profile to specify would do just that (of course,…

This (like many other things in the spec actually) are local implementation choices; the MUST is that _a method_ must be used (if no keep-alives are used).

However, to cover the case without any method available, added following:

        If the peer does not send keep-alives, and no means to verify
        presence of the peer are available, the peer MUST be considered no
        longer present and it SHOULD not be added back as a peer until it
        starts sending keep-alives again.

.. omitted security stuff.

> So is the crux that we have “homenet-aware devices” and “legacy hosts”, and that either of us just need to get with the program? If so, can I insist (gently) on “homenet-aware devices” [with a suit…

Again, this has nothing to do with homenet, but it’s being pushed in homenet just because it is strict dependency on HNCP.

There is already one existing use of DNCP which is very non homenet, demoed in IETF93 BnB and presented in the WG; I expect there might be more if we do not make the spec overtly homenet-y.

> Suggest also defining in Terminology, and clarifying if this is a one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do not see a forward reference, btw, at least not in latest re…

Added rather verbose description.

> OK, sadly you clarified it ;) Well, no, not sadly, but you clarified it to be understandable to me in the above sense. But, if I come up with the aforementioned TNCP and I use the same transport as…

Yes. E.g. SHSP and HNCP share transport, but are ships passing each other in the night as far as understanding TLVs go. (And unwittingly, they proxy each other’s state.)

> What I am trying to get at, though, is not this discussion but rather: what does this Link present to the IP layer, in terms of properties?

(802-style) broadcast domain is what we’re probably looking for. There’s also ‘multiple access link’ in one place in the spec, to denote availability of link-local multicast I guess.

This terminology could use some further work I think though.
		
> Better, but I would like to see that reflected also in a dedicated applicability statement.

I do not think we can actually provide so concrete applicability stmt as Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the protocol it runs on + network size + ..

> Indeed, and “merkle trees” disappeared and became hash trees somewhere along the line ;)

We were misusing the term actually; original Merkle tree was binary hash tree _only_, and while later on the term became synonymous with (N-ary) hash tree, when asked for Merkle references, just renaming it hash tree seemed to be the sensible choice as we were abusing the (original) definition.

> 		MAY also be chosen at runtime.  The main consideration when selecting 

Thanks :) Addressed.
		
> Otherwise, yes to your clarification.

‘this TLV’ is also confusing, as you could say the TLV itself is sent by all nodes and as it is not passed verbatim (timestamp changes) it cannot be said to be originated by someone.

Inserted “Every node, including the node publishing the node data,” for now.

Cheers,

-Markus

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 29 Jul 2015 14:02:54 +0200

> On Jul 29, 2015, at 13:06, Markus Stenberg <[email-masked]> wrote:
> 
> First of all, thanks a lot again for review comments; I think you are the most critical reviewer we have had yet, and it helps to improve the document quality a lot :)

I *was* starting to worry if I needed to take out armed protection, simply due to the sheer volume  of my comments appearing  as a “late assault” :D  I am thrilled that I didn’t need to, and that to the contrary you really reflected them well in the spec.

> We have had a number of reviews by this point, but I believe you have raised order of magnitude more changes than the second in line who also lives in Paris; is this a coincidence? I think not.

Fun that you should mention it. I think that the person you refer to, and I, while we’re based in the same area, never actually have seen each other (despite repeatedly planning for it) in or around Paris. So rest assured, it’s not a “geographic conspiracy” afoot here ;)

> Anyway, on to comments..

Actually, when doing my review I tried if I could come up with some text that I would thing worked — which, if I had succeeded, I’d have been throwing it at you saying “…but this would make me happy”.

I didn’t come up with something that I actually liked. So instead, you get my random thoughts … 

> Fact: It is not socket. I consider it essentially bidirectional mapping between an endpoint #, and some transport details (as it is used for both receiving and sending traffic).

I guess I am troubled by having seen the terminology “a socket is an endpoint for communication” and “a connection is a pair of sockets” — taking from Wikipedia (which is not a source for anything but “what is commonly used, even if incorrectly - but, as such, is a good way to understand “how many people would misunderstand in the same way"):

	"A network socket is an endpoint of an inter-process communication across 
	 a computer network. Today, most communication between computers is 
	 based on the Internet Protocol; therefore most network sockets are Internet sockets."

Now, I am of course also troubled by the recursive definition of endpoint in the I-D:

	Endpoint: a locally configured communication endpoint of a DNCP node, such as a network socket.

> - (shared socket on port Y) which is listens to eth1 multicast (and also deals with eth1 link-local unicast traffic), denoted as endpoint #4

So that sounds a little bit like (for the 2nd bullet) that it’s (in part) a “connection” (the “we try to contact ….” part)?

> I think the separation makes sense (as DNCP itself is generic algorithm, more or less); however, the point of separation I am not so sure about (e.g. concrete TLVs in DNCP feel bit wrong, but there…

As I said, I am not suggesting to go back on that decision — so we can have that discussion somewhere away from the ears of the ADs some other time ;)

> [2] consider amount of TLV change within TLV sets published by nodes (large set, small changes => may not be the best protocol for the job due to lack of per-TLV deltas)

Sounds good.

> WG isn’t, but we wound up doing one anyway. Still, we’re adding applicability subsection in 09, as I think it is important to note that DNCP is _not_ the tool for many things.

Great, sounds like we’re perfectly aligned here, and I look forward to seeing the text.

> The side effect is that if DNCP profiles match, essentially transit service is provided even if the implemented protocol is not same. (e.g. HNCP + SHSP currently.)

And that *sounds* right and *sounds* as if it is by design, so that’s great.

> Adopted the gist of it, although not going to convert to a list (and retained DNCP_ note as it is useful to understand DNCP_foo coming up shortly in the next few things).

Yes, the DNCP_ note should be retained. My bad for *not* doing that, thanks for catching it.

>                     optional parts of this specification, which are to

Works for me.

> DNCP-based protocol	a protocol which provides a DNCP profile, according to Section 9, and zero or more TLV assignments from the DNCP profile-specific TLV registry as well as their processing rules.

Works.

> Got rid of some relatively’s.

;)

> I am not sure it would help as such. The addressing may also occur inside transport - think multiple flows multiplexed over single stream connection, for example. Or local UNIX domain sockets :)

OK, but now I am back to being confused — how does “multiple flows multiplexed over single stream connection”, “address” and “endpoint” then fit together?

> Address	an identifier which specifies how to reach a particular instance of a transport protocol on a particular node. In case of an IPv6 UDP transport, an address in this specification refers to a…

*mumble* - Let me give this whole part some thought, and see if I can come up with something constructive to say on this point (other than “not sure that that’s clear”).

> I am not sure how. There has been literally half dozen iterations so far. I am not sure I like the current one, as it is overly verbose and apparently not much closer to the goal.

Yup. Needs some thought here. I’ll peg that as a todo; if we end up with that as the only outstanding point, and we’re no closer to an alternative, then the conclusion could be “Thomas is just too dense to understand this”, which I trust that the ADs would be comfortable with. 

> As this comes after the intro (which does that), I am not sure I agree with the need. Do you suggest cut-n-paste, or something new here?

Well, “A TLV-based distributed state synchronization protocol, DNCP operates primarily using unicast exchanges…” as the first sentence would really do it for me.

> (In point-to-point case, there may be arbitrary number of hops in the middle DNCP is blissfully unaware of.)

That works.

> Anyway, added a definition (not cut-n-pasting here so Steven has time to fix it, cough).

OK, I’ll wait to see what comes

> A hash tree of height 1, rooted in itself, is maintained by each node to represent the state of all currently reachable nodes (see Section 4.1) and the Trickle algorithm is used to trigger synchron…

Awesome, clear now.

> I see much more of a problem defining e.g. 4 byte version thing, because after that speaking ‘both versions’ of the protocol becomes hard.

Alright, I’ll peg that as issue #2 that needs an isolated discussion and where the ADs may have to decide that I am in the rough (which is fine) if needed. I just observe that I’ve seen a strong move in other contexts in the IETF for “version numbers” so I would expect that to become an issue here also.

> Why? The concrete DNCP-based protocol actually says what it supports, and e.g. future DNCP extensions are not implicitly part of HNCP, unless we specify them to be.

It’s always hard to speculate on extensions, so … this may sound silly.

Say we wanted DNCPv2 to, for some reason, not use TLVs but use LVTs, or that it redefined the way of calculating the Network State / Node State — for some reason. For the LVT-option you’d be screwed ;) for the “new way of calculating Network State / Node State” you’d say “define a new TLV type”?

I’d imagine that a DNCPv2, or perhaps a device using DNCPv2, would somehow be able to maintain a “backwards compatible mode”, say, if I see DNCPv1-based protocols hanging around, then I’d probably fall back to use those, but if I don’t then I’d want to use the new-fancy DNCPv2-based protocols (which might use some of the same TLVs, but use them differently).

I think that you’re shooting yourself in the foot here.

> (Only up to 32 and the local tinkering range are excluded from the DNCP profile specific registry HNCP will set up. However, conflicts in handling the 256+ range are currently being considered on h…

Proposal….you say that you have a large TLV type space so ….why don’t we set aside the first two bits in the TLV type field, call that “Version”, and define “if both are cleared, then it means this specification, DNCPv1" and then have 2^14 “TLV types” — with a potential for 4 DNCP “versions”?

Then, we take an appointment in 15 years time. If by then we still have not found a reason to flip either of these two version bits, then (i) we write an “Updates DNCPv1” RFC which reassigns that field as “16 bit TLV Type”, and I buy lunch — otherwise, lunch is on you? 

;)

> Added that to the applicability subsection too. (Pending Steven check, *grin*)

Great

>        starts sending keep-alives again.

That seems to work for me. Thanks

> There is already one existing use of DNCP which is very non homenet, demoed in IETF93 BnB and presented in the WG; I expect there might be more if we do not make the spec overtly homenet-y.

Ok, being general where it makes sense is good.  We’ll take this discussion in HNCP, then.

> Added rather verbose description.

;)

> Yes. E.g. SHSP and HNCP share transport, but are ships passing each other in the night as far as understanding TLVs go. (And unwittingly, they proxy each other’s state.)

OK, with the proposed text somewhere up above in this email, this is clear — so that works for me also.

> This terminology could use some further work I think though.

Thanks, let me know when you want me to look at something concrete.

> I do not think we can actually provide so concrete applicability stmt as Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the protocol it runs on + network size + ..

I do not want to see RAM, LoC, etc. —  and what you mentioned up above in the email seems to be the right direction that you are going. One operating condition for trickle to make sense is, for example, that you do not have a continued flow of “changes to reflect” — hey, you say that somewhere in the document already, that’s part of “where DNCP is applicable”.  So I think that in doing the other stuff you’re actually addressing this here.

> We were misusing the term actually; original Merkle tree was binary hash tree _only_, and while later on the term became synonymous with (N-ary) hash tree, when asked for Merkle references, just re…

Yup, and that’s quite fine.

>> 		MAY also be chosen at runtime.  The main consideration when selecting 

;)

> Inserted “Every node, including the node publishing the node data,” for now.

I think that this works.

Recapitulating, I see basically two potential issues where we do not yet have resolution:

	o	Versioning 
	o	Address/Endpoint terminology

That’s already great progress. 

For the former, either the proposal I made in this email (which included a lunch appointment in 15 years time), or it may be one of those cases where we will agree to disagree and have the RTG-ADs figure out what they want to take it as.

For the latter, I’ll try to come up with something that might make sense (I may meet Pierre tomorrow and bounce it around with him over coffee) and shoot back, but anybody else with a proposal…please chip in.
 
Thanks for this exchange, it’s engaging and constructive and I can’t wait to review -09 (regardless of what comes from the two above items).

Cheers,

Thomas

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 29 Jul 2015 14:01:56 +0200

Hello Markus,

I could not find-out what french-guy-living-in-Paris you are referring to, so I wanted to make sure I at least have the 3rd position. ;)

I think the complexity about the Endpoint definition mostly comes from the fact that a DNCP Endpoint is half-defined by configuration and half-defined by the profile. Some parameters such as trickle parameters are defined as Profile parameters, while they should, IMHO, be defined "per-endpoint".

This may require some work but I think the document should specify on one side what are the global parameters that must be shared by all participating nodes (the global profile), and on another side what are the different endpoint parameters that must (or sometimes not, as Trickle parameters) be shared by all DNCP nodes on a given ‘’’’’link’’’’’ (with lots of ‘’’), i.e., the endpoint profile, and allow them to exchange packets and establish a durable neighboring relationship.

With that approach it looks to me that a Endpoint could be defined this way (Probably not best wording, but you will get the idea):

Endpoint: Set of rules and parameters associated with a unique Endpoint identifier which:
	- Determines how to send DNCP packets toward other DNCP nodes.
	- Determines how to establish, keep and teardown neighboring relationships between two DNCP nodes.
	- Classifies a received DNCP packet as received on a given Endpoint (If a received packet can’t be associated with any Endpoint, it MUST be ignored).

Now, adopting such an approach in the document may have significant impact over its organization, but at least it would help separate what is globally unique from what is local to neighboring relationships.

On a different topic, I think reserving 32 TLV types to DNCP is far from being enough. 
If DNCP is successful, it may be used by many different profiles. There could be a need to extend DNCP in order to improve all profiles at once. Limiting DNCP extensions to only 21 new TLVs is unnecessary and would make that process harder. Reserving more TLVs would be virtually free and help in the future.
I guess that comment joins Thomas’ comment about version numbers, with which I agree (that we should add one). It’s not because DNCP is not a protocol that we should not think about how it could be improved and extended such that all already-defined profiles profit from the improvement. Sure it would not be *impossible* to do it with the current document. But it costs nothing to make it easier.

Cheers

- Pierre

> Le 29 juil. 2015 à 13:06, Markus Stenberg <[email-masked]> a écrit :
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Dave Taht <[email-masked]>
Date: Wed, 29 Jul 2015 15:07:37 +0200

a bit offtopic, it would be good to have IANA assign some port numbers
soon, if they have not already. (?)

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 29 Jul 2015 16:31:17 +0300

> I could not find-out what french-guy-living-in-Paris you are referring to, so I wanted to make sure I at least have the 3rd position. ;)

You probably do. It is clearly a conspiracy.

> Now, adopting such an approach in the document may have significant impact over its organization, but at least it would help separate what is globally unique from what is local to neighboring relat…

I think this is overriding (or perhaps compressing) terminology too much; I believe you are describing an instance of a ’endpoint profile’ (and how one maps to endpoint identifiers), which does not describe what _is being identified_, i.e. the endpoint itself. At least to me, your description of ‘endpoint’ is actually less clear than Steven’s (in the current dncp-08 text), and I find both unclear.

Given a protocol that uses actually two types of transport (e.g. someday-updated SHSP draft will have both [some scope] unicast-only and link-local unicast+multicast endpoints - I have some of the code but not the updated spec yet), it gets even more murky. While the profile may specify that this is the transport, how it maps to the particular endpoint identifiers (and what those identifiers identify) becomes rather painful. Not to mention if we want to provide per-link type handling guidance on Trickle k value.. sigh. :p

> I guess that comment joins Thomas’ comment about version numbers, with which I agree (that we should add one). It’s not because DNCP is not a protocol that we should not think about how it could be…

I guess I have to discuss this with Steven; the original idea was to essentially leave 8 bits in the type unused for e.g. bit vector use at some point, when I chose the 16-bit T size, but it did not make it to the DNCP draft. 

Current texts we have are wrong at any rate, as 256+ are specified as available _both_ in DNCP and HNCP registry (based on the current .xml texts we have for not-yet-published dncp-09 and hncp-08), and that is not optimal situation either if there is a conflict. 

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Jul 2015 10:09:53 -0400

> soon, if they have not already. (?)

The way to do this would be for the chairs to ask Terry for an early allocation.   Assuming he agrees, the IESG discusses it, and IANA issues it.

---

From: Steven Barth <[email-masked]>
Date: Wed, 29 Jul 2015 16:12:20 +0200

> soon, if they have not already. (?)
DNCP is not the place for this since it is abstract and for that
matter does not define any ports ever.

We have to wait until HNCP is mature enough at least.

Cheers,

Steven

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 Jul 2015 14:18:10 +0000

On Jul 29, 2015, at 10:09 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 29, 2015, at 9:07 AM, Dave Taht <[email-masked]<mailto:[email-masked]>> wrote:
a bit offtopic, it would be good to have IANA assign some port numbers
soon, if they have not already. (?)

Hi Ted,
As per RFC 7120 (section 3), the request only has to go through the chairs and ADs - no IESG review required. Anyway, with all the implementation activity, I believe we should move forward with the early allocation process. We do this frequently in the routing area.
Thanks,
Acee

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Ray Bellis <[email-masked]>
Date: Wed, 29 Jul 2015 15:23:01 +0100

On 29/07/2015 15:18, Acee Lindem (acee) wrote:

> Hi Ted, 
> As per RFC 7120 (section 3), the request only has to go through the
> chairs and ADs - no IESG review required. Anyway, with all the
> implementation activity, I believe we should move forward with the early
> allocation process. We do this frequently in the routing area. 

I'll look into it.

Ray

---

From: Steven Barth <[email-masked]>
Date: Thu, 30 Jul 2015 10:47:39 +0200

> oVersioning 
> oAddress/Endpoint terminology
>

We have changed the IANA section like this now:

      <t>11-31: Free - policy of 'standards action' should be used</t>
      <t>32-511: Reserved for per-DNCP profile use</t>
      <t>512-767: Free - policy of 'standards action' should be used</t>
      <t>768-1023: Private use</t>
      <t>1024-65535: Reserved for future protocol evolution (for example, DNCP version 2)</t>

This gives us 6-bits to play with later on (e.g. versioning, flags, etc.) and also a broader pre-defined range for DNCP and per-profile TLVs.

We also did another rewrite of address and endpoint to make them less verbose. The following is
what at least passed our "internal review" ;)

      <c>Address</c>

      <c>an identifier used as source or destination of a DNCP message flow,
      e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport.</c>

      <c /><c />

      <c>Endpoint</c>

      <c>a locally configured termination point for (potential or established)
      DNCP message flows. An endpoint is the source and destination for separate
      unicast message flows to individual nodes and optionally for multicast
      messages to all thereby reachable nodes (e.g., for node discovery).
     
      Endpoints are usually in one of the transport modes specified in <xref
      target="dt" />.

Besides that all instances of "broadcast" should be gone now and have been,
replaced by "multicast" or "multicast enabled" or similar since that seemed to
be more accurate in most cases anyway.

Please let us know what you think ;)

Cheers,

Steven