Markus, Steven, 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. Why is that? If I've recently republished my own data (e.g. because I gained a neighbour), it makes sense to me to send my own NODE-STATE in order to avoid a round-trip.
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.) The DNCP profile MUST provide guidance about how to deal with node-id collisions. Where is that guidance provided in HNCP? The expression defining the circular ordering is written in C syntax, but I think it assumes different priorities than C. Please put brackets around the bitwise conjunction. 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? Shouldn't the first part of 4.5 be moved into 4.4? 4.6, MUST be traversed Either immediately... Is it not better to say that it must be traversed before the next message is scheduled to be sent? 6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
