Hello Les, > > [Les:] We are not understanding each other. Let me try to explain more > clearly than I did the first time. > > DNCP has two dependencies: > > 1)The (routing) protocol which uses it I'm sorry, but I can't seem to follow your logic. Are you thinking of a DNCP-based routing protocol here? But even then how can a thing using DNCP be a dependency of DNCP?
> 2)The profile "protocol" which completes the specification of what > information needs to be sent by DNCP. Let me tackle this another way: Trickle does not depend on DNCP, but DNCP depends on Trickle. That's why the DNCP specification has a Normative Reference on Trickle, but not the other way around. Similarly RPL uses Trickle, but that doesn't affect Trickle either and does not make it responsible if something was missing in RPL. > To have high confidence that the DNCP specification is complete we would like > to have experience w multiple routing protocols/profile protocols. So... I don't see how building routing protocols out of DNCP proofs or disproofs anything. Furthermore, in general how could adding something proof or disproof the completeness of it, especially if the original thing is deliberately abstract? Or do you think existing routing protocols have any impact on DNCP? That is not the case either, i.e. DNCP-based profiles can rely purely on link-local communication - like HNCP does - and are thus unaffected by presence or absence of routing protocols. Or are you referring to mentions of "IGP" and "routing protocol" in the HNCP draft? If so, then these are unrelated to DNCP since they are in a separate draft. However even for HNCP there is not much sense, since it merely tells the router whether to run or not run any routing protocol on a network interface. It can also optionally provide a pre-shared key to use for authentication, but that's about it. > This makes me concerned that we don't really know what gaps/problems might > exist in DNCP because we simply don't have enough experience with it yet. You may want to scan through https://www.ietf.org/id/draft-jin-homenet-dncp-experience-00.txt for some up-to-date information on the current state of DNCP and HNCP implementations. This draft also includes simulation results using a relatively bare-metal DNCP-profile (e.g. just using DNCP-TLVs IIRC). > [Les:] Well "neighbor" is not defined - though yours would not be the only > specification to omit that definition. And I could intuit using "peer" to > identify other nodes operating the protocol who are not necessarily neighbors > - but that can't be done using your definition of "peer". The sentence you quoted didn't have the term "neighbor" in it but rather "Neighbor TLV" which is clearly defined as one of the TLVs in the document. >> TLVs that are part of the database are sent within the Node State TLV (Node >> Data field). Said Node State TLV is mentioned just before "Any other TLV" >> in the same list and thus not meant to be part of "other TLV"s. The text now >> states this explicitly. > [Les:] But there can be TLVs within the Node State TLV - and these cannot be > discarded - though they could be ignored. So there seem to be two classes of > "unrecognized TLVs" - those within the Node State TLV and those not > associated with the Node State TLV. > ?? Yes, "Any other TLVs" as well as all the other elements of that enumeration are referring to top-level TLVs, not nested ones. I currently propose "TLVs not recognized by the receiver MUST be silently ignored unless they are sent as part of the payload of one of the TLVs above (such as TLVs in the Node Data field of a Node State TLV)." to make that more clear. Furthermore the definition of the Node State TLV already states that the Node Data content MUST not be modified, so it should be fine. > >> This is described in detail in 4.2, a reference has been added. >> > [Les:] Ahhh - thanx for the pointer. I searched for "Node Endpoint" - but > Section 4.2 uses simply "Endpoint" - so I did not find a match. If you could > use the full TLV name in Section 4.2 that would be helpful. Yes, I noticed that as well when adding the reference and corrected it. Cheers, Steven _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
