Murray Kucherawy has entered the following ballot position for draft-ietf-emu-tls-eap-types-12: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2.1: Which define Master Session Key (MSK) and Extended Master Session Key (EMSK). This seems to be part of a larger sentence that's partly missing. It is RECOMMENDED that vendor-defined TLS-based EAP methods use the above definitions for TLS 1.3. There is no compelling reason to use different definitions. Why isn't this MUST if there's no compelling reason to do otherwise? I concur with Roman's comment about the SHOULD NOT in Section 2.4. In Section 2.2: Where || denotes concatenation. I understand the earlier citation I made above now, but still this should be a complete sentence. You later have: where CMK[n] is taken from the final ("n"th) inner method. ...which is better in that it looks more like a continuation of something, but still it could be better. Suggest: In this context, CMK[n] is taken from the final ("n"th) inner method. In Section 3.1: In other weds, [...] I think you meant "words". The outer identity SHOULD use an anonymous NAI realm. [...] I suggest you add a sentence or two explaining why an implementer might legitimately choose not to do this. This practice is NOT RECOMMENDED. User accounts for an organization should be qualified as belonging to that organization, and not to an unrelated third party. There is no reason to tie the configuration of user systems to public realm routing, that configuration more properly belongs in the network. This formulation is curious; you first give implementers an "out" with NOT RECOMMENDED, and then basically argue that it should be a MUST NOT. I suggest revisiting this pattern anywhere you've used it. If you prefer to keep it, I suggest changing the prose a bit to explain why one might choose to deviate from the advice presented. Thanks for including Section 5. In Section 6.1: There MAY be additional protocol exchanges which could still cause failure, so we cannot mandate sending success on successful authentication. This should just be "may", not "MAY". You're not presenting an implementation choice. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
