Mirja Kühlewind has entered the following ballot position for draft-ietf-6lo-ap-nd-14: 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: ---------------------------------------------------------------------- A couple of small comments: 1) Sec 2.2: If actually all terms from all the RFC listed in section 2.2 are used, all the reference would need to be normative. Maybe double-check this! 2) Sec 3: I would have expected that section 3 says something about backward compatibility (what if not all nodes in a network are updated?) and gives a strong recommend to use this scheme (or even obsolete the old one?) 3) Nit sec 4.4: s/it an be found/it can be found/ 4) Sce 6: Use of normative language: s/The node may use a same Crypto-ID/The node MAY use a same Crypto-ID/ 5) Security Consideration Section: Is there a new risk/possible attack because computational complexity of the proposed scheme is higher than the one in RFC8505? Could that be used as an attack against a central node? Would it be necessary to rate limit requests somehow? Or is there already a rate limit (that should be mentioned here)? _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
