> Section 5.2 explicitly says how to reach to each TLV (and no semantics > about this, IIRC).
> Section 5.3 states what Node Endpoint TLV means (=I want to be your > neighbor), section 5 (start) says that that TLV is used for forming > bidirectional peer relationships.. > How would you make it more explicit here? A DNCP node MUST reply to a request from any valid address, as specified by a given DNCP profile, whether this address is known to be the address of a neighbour or not. (This provision satisfies the needs of monitoring or other host software that needs to discover the DNCP topology without necessarily participating in the full DNCP protocol.) Or perhaps ... without contributing to the replicated DNCP state.) > Section 6.2. (You don’t pick randomly who to pick, but e.g. prefer > highest ID, and everyone follows same alg and _one_ node on shared link > _has_ to peer with everyone). Ah, I see. Should there be a forward reference in the first paragraph of 5.1? >> Please make this rationale more explicit in the draft -- it's said in the >> introduction, please repeat it in Section 5.4. > I dislike repeating myself in a document. Any suggestions on wording on > how to stay this nicely? ;) Just repeat it and be done with it. There's nothing wrong with stating the rationale in both the introduction and the protocol description. > The main reason I am against TTL stuff is actually that it invalidates > the use of Trickle; I think it's too late to be discussing this here. Let's have beer in Prague and yell at each other. -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
