Brian Haberman has entered the following ballot position for draft-ietf-homenet-dncp-09: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ ---------------------------------------------------------------------- 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. * 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. * 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. I think the mention of the trickle variable 'k' in section 1 is gratuitous and causes confusion. 2. Why does this document say (section 7) that the hash function is non-cryptographic? Shouldn't that be determined by each profile? _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
