Hi Alan, Thanks for taking care of this. All changes looks good.
When checking -10, I see that 5.3.1 repeats some of the considerations already in 3.2 (formatting, etc.). Citing 3.2 in 5.3.2 would be more appropriate IMO for those aspects rather than repeating them. Referring to 3.2 would also help inherit other considerations (e.g., the updated text on experimentation handling and so on). Cheers, Med > -----Message d'origine----- > De : Alan DeKok <[email protected]> > Envoyé : jeudi 4 septembre 2025 19:49 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : The IESG <[email protected]>; [email protected]; > [email protected]; [email protected] > Objet : Re: [Emu] Mohamed Boucadair's No Objection on draft-ietf- > emu-eap-arpa-09: (with COMMENT) > > > 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 > <https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2F > ietf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C064bd8 > 2d12ee452c01f308ddebdb5daf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0% > 7C0%7C638926049601123882%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > yfQ%3D%3D%7C0%7C%7C%7C&sdata=CIoh%2B%2BPQMUKQtFvRY01z0vCa2BMRPyln9 > z8bqEqunUk%3D&reserved=0>" 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. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
