Alissa Cooper has entered the following ballot position for draft-ietf-6tisch-enrollment-enhanced-beacon-13: 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-6tisch-enrollment-enhanced-beacon/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- == Section 2 == "If this field is not present, then IID is derived from the layer-2 address of the sender as per SLAAC ({?RFC4662})." RFC 8064 recommends that the default IID generation scheme for use with SLAAC is not to use the layer-2 address, but to use the mechanism specified in RFC 7217. Is there a reason this specification is making a different recommendation? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == Section 1.3 == This sentence is not comprehensible: "Although However, even in this case, a unicast RS may be transmitted in response[RFC6775] reduces the amount of multicast necessary to do address resolution via Neighbor Solicitation (NS) messages, it still requires multicast of either RAs or RS." == Section 2 == s/({?RFC4662})/[RFC4862] == Section 4 == A network doesn't have privacy considerations. The draft might want to discuss how this specification reveals information about network topology, but that isn't a privacy consideration. DODAGID needs to be expanded on first use and needs a citation to be provided. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
