Alissa Cooper has entered the following ballot position for draft-ietf-6lo-ap-nd-17: No Objection
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-6lo-ap-nd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4.4: "If it is not present, it can be found in an abstract table that was created by a previous message and indexed by the hash." Reading the document top to bottom, I was confused about what this was referencing when I first came across it. Given that this is explained later, a forward section reference might help. Section 7: I think somewhere in here there should be a brief discussion about how use of this specification could facilitate correlation attacks by providing an identifier that allows traffic from multiple source addresses to be tied back to the same node via the Crypto-ID. That is, if a node intends to use multiple addresses to defend against the 6LR or being able to correlate traffic originating with each address, it should not use the mechanism specified in this document. (I'm assuming this is a corner case for these kinds of deployments but it's worth saying anyway. Also, if there is some other cross-address identifier that the 6LR always has anyway, this isn't actually a problem.) Section 8.3: Are there protocol-specific reasons why "IESG Approval" is a valid registration policy for this registry? Specification Required on its own seems appropriate to me. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
