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 <markus.stenb...@iki.fi> a écrit :
>
> 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.
>
> On 28.7.2015, at 18.45, Thomas Clausen <i...@thomasclausen.org> wrote:
>> 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.
>> 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.
>
> 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).
>
>>> 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?”
>
> 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 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.
>
> 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) “Address” and “Endpoint”
>
> Hopefully fixed.
>
>> 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?
>
> 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.)
>
>> 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.”
>
> 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.
>
>
>> 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
>
>
> 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.
>
>> 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?
>
> Got rid of some relatively’s.
>
>> 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?)
>
> 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).
>
>> 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]
>
> 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)
>
>>>> 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.
>
> 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?
>
>> 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.
>
> 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.)
>
>> 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 ;)
>
> 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).
>
>> 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.
>
> 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).
>
>> 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.
>
> 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.
>
>>>> 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”.
>
> 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 types A, B and D (but not C)
>> from HNCPv1, and would reserve and define TLV types X, Y, Z ?
>
> 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.)
>
>>>>
>>>> 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.
>
> Added that to the applicability subsection too. (Pending Steven check, *grin*)
>
>>>> 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 ;) ).
>
> 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.
>
>>>> 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.
>
> 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.
>
>>>> - "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.
>
> Added rather verbose description.
>
>>>
>>>>
>>>> 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?
>
> 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.)
>
>>>> 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?
>
> (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.
>
>>>> 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.
>
> 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 + ..
>
>>>> 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 ;)
>
> 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.
>
>>>>
>>>> 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.
>
> Thanks :) Addressed.
>
>>>> 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.
>
> ‘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
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
