Mohamed Boucadair has entered the following ballot position for draft-ietf-emu-eap-arpa-09: 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-eap-arpa/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Alan, Thank you for the effort put into this specification. Appreciate the detailed operational considerations discussed through the document. Please find below some few comments: # Abstract CURRENT: This document also updates RFC9140 to deprecate "eap- noob.arpa", and replace it with "[email protected]" * There is no [email protected] mention in the document. Should this be changed to “eap.arpa”? * Alternatively, given that RFC9140 reasons also with [email protected], should this text mention “@noob.eap.arpa" # STD13 vs RFC1034 CURRENT: The subdomain MUST follow the syntax defined in [RFC7542], Section 2.2, which is a more restrictive subset of the domain name conventions specified in RFC1034. .. However, that registry does not follow the domain name conventions specified in RFC1034, so it is not possible to make a "one-to-one" mapping between the Method Type name and the subdomain. I suggest to replace all occurrences of RFC1034 with [STD13] # Experimental Use CURRENT: For experimental uses, it is RECOMMENDED that the "ietf.org" realm is used. Different uses SHOULD be distinguished by using the name of a working group or document, such as "emu.ietf.org.v.eap.arpa". Why is this restricted to WGs? Couldn’t other experiment forms be considered beyond the IETF or you think that those can be covered by use of a vendor subdomain? # Inappropriate use of normative language OLD: Other EAP methods MAY omit the username as RECOMMENDED in [RFC7542]. NEW: Other EAP methods MAY omit the username as recommended in [RFC7542]. The reco is already covered in 7542. # Field CURRENT: result, the EAP peer MUST NOT have a field which lets the user identifier field be configured directly. Nots sure what “field” means here. I suspect that you meant configuration knob or something similar. If so, you can consider this change: NEW: result, the EAP peer MUST NOT expose a configuration option which lets the user identifier field be configured directly. # Why this is not “MUST NOT”? CURRENT: While EAP peers allow users to enter user identifiers directly for existing EAP methods, they SHOULD NOT check whether those identifiers match any EPI. # Redundant behavior Section 3.4.1 has the following: EAP peers MUST rate limit attempts at provisioning, in order to avoid overloading the server. Section 3.4.2 says: Peers MUST rate-limit their provisioning attempts. Please consider keeping this in 3.4.1 only. Pleas note that 3.4.2 is about servers. # Unspecified behavior in Section 3.4.1 CURRENT: This rate limiting SHOULD include jitter and exponential backoff. This text does not explicit how these parameters are defined/used to avoid overload. I see that Section 3.4.2 zooms into this: The peer SHOULD retry provisioning no more than once every few minutes, and SHOULD perform exponential back-off on its provisioning attempts. I think that it is better to move para to be under 3.4.1 as this is about peers behavior and also answers some of the questions triggered by the current 3.4.1 text: Peers MUST rate-limit their provisioning attempts. If provisioning fails, it is likely because provisioning is not available. Retrying provisioning repeatedly in quick succession is not likely to change the server behavior. Instead, it is likely to result in the peer being blocked. The peer SHOULD retry provisioning no more than once every few minutes, and SHOULD perform exponential back-off on its provisioning attempts. # General network access?! CURRENT: The limited network MUST NOT permit general network access. I guess I understand what is meant here, maybe “unrestricted network access” is more explicit about the intent. # Redundant behavior in Section 3.5 CURRENT: Implementations MUST NOT permit EAP method negotiation with provisioning credentials. That is, when an EPI is used, any EAP Nak sent by a server MUST contain only EAP method zero (0). These are the same requirement. The second MUST is an explanation of the MUST NOT. Please fix this: NEW: Implementations MUST NOT permit EAP method negotiation with provisioning credentials. That is, when an EPI is used, any EAP Nak sent by a server must contain only EAP method zero (0). # Background and rationale This section is very useful but too late in the document. Please consider adding a pointer to this section early in the document. Cheers, Med _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
