On Sep 3, 2025, at 4:02 AM, Mohamed Boucadair via Datatracker <[email protected]> wrote: > 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”?
It should be "@noob.eap.arpa", which is what the rest of the text uses. > * Alternatively, given that RFC9140 reasons also with [email protected], > should this text mention “@noob.eap.arpa" Yes. > # STD13 vs RFC1034 > ... > I suggest to replace all occurrences of RFC1034 with [STD13] Done. > # 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? After other reviews, I've made a note that vendors can use their own domain for experimental use. The intent here is limit use of the "ietf.org <http://ietf.org/>" domain to use within the IETF. > # 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]. Done. > 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: Perhaps "configuration interface". I'll reword. > # 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. Sure, I'll change it to MUST NOT. > # 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. Addressed via another review. > # 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: Addressed via another review. > # 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. Done. > # 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). Fixed. > # 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. I've moved it to the introduction, as per an earlier review. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
