>> Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to >> a REQ-NODE-STATE MUST NOT contain the optional part.
> I assume you are talking about REQ-NET-STATE. The underlying problem here [...] > Now that we discuss it, I think SHOULD NOT might be correct, though; if > you haven't shared it with _anyone_, obviously first one is at least > unknown to the rest of the network. This explanation is enlightening and should be in the draft. >> Still in the same section, when a duplicate node-id is detected, the new >> seqno chosen myst be significantly higher than the one received. Why is >> that? Is +1 not enough? (I'm using +42 right now, of course.) [...] > Funnily enough I thought +1 was enough at first too. This explanation is enlightening and should be in the draft. Markus, DNCP is a beautiful protocol. There are a number of things that I've asked before that are subtle enough to warrant an explanation. In addition to the two points above, the following come to mind: - the fact that you use a single-line change to Trickle that has huge consequences on its behaviour in case of persistent desynchronisation; - the fact that flooding link-local data, while wasteful of storage, avoids the need for keeping reliable state beyond what is in the Merckle tree. These things need to be clearly explained to the naive implementor. I've been deliberately copying the list with all of my questions (sorry for the spam) so that we can have a record. Now somebody (somebody with strong nerves) needs to go through my recent flurry of epistolar activity and decide, for each of my questions, whether I'm just being stupid or whether this deserves a clarification. In case of doubt, clarify. I realise I'm being a pain, especially since it contradicts our motto "it was difficult to write, there's no reason it should be easy to read". > Hmm. Wonder if removing the guidance altogether is the preferable choice > here. No, please leave it, just add the missing pair of brackets, and add "where (a % b) represents the remainder of a modulo b and (a & b) represents bitwise conjunction of a and b". [Aside: I think the official IETF definition of seqno comparisons is in RFC 1982, which uses a slightly different definition than both HNCP and Babel: comparision between s and s + 2^(n-1) is undefined, "implementations are free to return either result, or flag an error". Yeah, right. They use a definition by cases. RFC 793 Section 3.3 says "There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values.", and then they define the "in-window" relation by cases. RFC 6126, simply says "seqno > seqno' ... where sequence numbers are compared modulo 2^16", with no further ado. End of aside.] >> Section 4.5 suggests sending a unicast REQ-NETWORK-STATE when receiving >> ENDPOINT. If adding the peer fails (say, out of memory), won't this cause >> a livelock? > > Given stream case, yes, as there is no guarantee of second one ever > showing up. > > For datagrams, next ENDPOINT should do it, no? Not if allocation fails again. Am I being even more paranoid than you? I suggest putting a word of caution in there. >> 6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3. > > Hm, true. Any suggestions on better wording? Even the current one is bit > cumbersome, and repeating it twice with even more stuff in it is not very > appealing either. This really needs to be stated accurately. I think you have two choices: you either repeat the definition of Trickle in this document, or you put precise references to RFC 6206 whenever you mention a Trickle action. I think the latter is a better choice from the implementors point of view, the former is the better choice for the casual reader. Screw the casual reader. In this particular instance, I think what you want to say is "and starts a new trickle interval, as in step 2 of Section 4.2 of RFC 6206". -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
