Éric Vyncke has entered the following ballot position for draft-ietf-emu-eap-noob-04: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I really like the ideas behind this OOB authentication. Please find below some non-blocking COMMENT points (**but replies would be appreciated esp around CBOR**), and some nits. Special thanks to Dave Thaler for his early IoT directorate review (and the CBOR discussion with Carsten): https://datatracker.ietf.org/doc/review-ietf-emu-eap-noob-01-iotdir-early-thaler-2020-06-12/ https://mailarchive.ietf.org/arch/msg/iot-directorate/PNi6nxtR7_1T2rxu7O49HRx5Kdg/ I hope that this helps to improve the document, Regards, -éric PS: when the ballot for this document was created, I failed to spot the DNS & IoT aspects of it, hence, the absence of INT and IoT directorates telechat reviews. == COMMENTS == Like Carsten, I am really puzzled by the lack of consideration of CBOR to replace JSON especially for a protocol aimed at constrained devices. Was this discussed at the WG level ? I was unable to read any discussion on the mail list except about the IoT directorate thread. This non-obvious choice of encoding ***should really be discussed*** in the document. -- Section 2 -- Please apply the current BCP 14 template and not the old RFC 2119 one. -- Section 3.1 -- "timeout needs to be several minutes rather than seconds" can this lead to a DoS against the server, which potentially needs to keep states for minutes ? -- Section 3.2.1 -- I am not a EAP expert, so bear with my possibly naive question, "based on the realm part of the NAI", isn't it always "eap-noob.arpa" in this case ? -- Section 3.2.2 -- What happens if the peer does not support any of the server's ciphersuite? Esp in the world of IoT where peers are old and cannot always be updated.Should there be a forward pointer to section 3.6.4 ? -- Section 3.2.3 -- Suggest to give a hint to the reader for "Hoob": is this Hash of OoB ? Same comment for "Noob". == NITS == Global nit: I prefer the use of 'octet' rather than 'byte'. -- Section 1 -- Please avoid the use of 'we' as in 'We thus do not support'. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
