> On 28.5.2015, at 23.45, Juliusz Chroboczek <[email protected]> > wrote: > > >> 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.)
Slightly different wording choice for me (‘adding to the state in the network’), but hopefully same semantics. >> 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? Added there: 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 which only listens to multicasts. In that mode multicast updates MUST be omitted. Added related comment also to 5.3: 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 which only listens to multicasts. In that mode, all peers except the one with the highest node identifier MUST NOT have Neighbor TLV (Section 7.3.2) published nor any local state. >>> 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. .. copied intro one almost verbatim. Thanks for the comments! This is what I added in the end (+ one minor edit in the end to fix ordering of DNCP profile requirements that I noticed when proofreading yet again through the text). https://github.com/fingon/ietf-drafts/compare/108e558bf9671f99254af36e9f62c71c4007df78...b9096da5b648fd5d04d17a590335b64ac3b844e3 Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
