Hello Brian, thank you for your feedback.
> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have no objections to the publication of this document, but I do have a > couple of points that I want to discuss... > > * The spec says that all TLVs are transmitted every time any value in the > TLV set changes. Section 1 says that a delta synchronization scheme is > not defined. What is the justification for not using a delta > synchronization approach? The ordering of the TLVs needed to compute the > hash can be done at the receiver and a delta approach would minimize > bandwidth consumption. I think it would be useful to provide some > justification in the spec for the design decision made to not use a delta > synchronization approach. Delta synchronization was mainly omitted due to our intended goal of focusing on optimizing for simplicity and only infrequent and potentially larger (in relation to the whole dataset) state changes as noted in 1.1. Applicability. It is therefore not in the base draft, however it should not be too difficult for a DNCP-based protocol that is in need of such a feature (e.g. due to it being "on the edge" of DNCPs applicability) to add it as an extension. > * Section 4.4 says that all responses are sent unicast, even for requests > received via multicast over a multi-access medium. Was consideration > given to use multicast responses and supporting message suppression on > other nodes? Or, was the design decision made to ensure that all nodes > responded with their TLV set to the requester? Either approach may be > reasonable, but there is no justification given. There are multiple factors involved here. One important issue is that securing these multicast transactions is difficult and I don't even know if there is a standardized and deployed way to do this e.g. using (D)TLS that we use for unicast. This is slightly touched in 4.2. Data Transport and 10. Security Considerations. Another reason is that on some link types - such as Wifi - multicast transmissions can be disadvantageous and reducing their number can be beneficial in many cases. > * When responding to a multicast request over a multi-access medium, why > is the randomization of the transmit time only a SHOULD? I would think > that needs to be a MUST. I think this more or less depends on the type of link and its characteristics and the current state, so I'm not sure if a MUST is necessary in all cases. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. I think the mention of the trickle variable 'k' in section 1 is > gratuitous and causes confusion. Since the meaning does not really suffer we can simply remove the bracket "(ideally with k < 2)" if that makes it less confusing. > 2. Why does this document say (section 7) that the hash function is > non-cryptographic? Shouldn't that be determined by each profile? The intended meaning was really "not necessarily cryptographic", we might just remove the word "non-cryptographic" in that section if that makes it more apparent. 9. DNCP Profile-Specific Definitions provides some guidance on the choice of functions already and indicates that it can be either. Regards, Steven _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
