On Aug 27, 2025, at 7:10 AM, Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > Thank you for the work put into this document. Even with my DISCUSS ballot, I > really like the idea.
Thanks. I believe it will solve a long-standing issue. > ### Abstract > > As flagged by id-nits, when a document updates others, it must also mention > them in the abstract (bonus with concise description about what is updated). This document updates RFC5216 and RFC9190 to define an unauthenticated provisioning method. Those specifications suggested that such a method has possible, but they did not define how it would be done. This document also updates RFC9140 to deprecate "eap-noob.arpa", and replace it with "n...@eap.arpa" > ### Section 3.7 > > Please use a MUST NOT in `names in the "eap.arpa" domain SHOULD NOT be looked > up in DNS`. Of course, existing implementations won't implement the MUST NOT > but a SHOULD would allow cheap implementation to hammer the DNS. Done. > ### Title > > s/The eap.arpa domain and EAP provisioning/The eap.arpa. domain and EAP > provisioning/ (trailing dot after a FQDN). The RFC editor will have the final > say. I've taken a pass through and cleaned up all uses of eap.arpa. Some uses had quotes, others didn't. I've also qualified each use to distinguish the eap.arpa realm (no trailing dot) from the eap.arpa. domain (trailing dot). To make this distinction clearer, I've added text too the terminology section: > Readers of this document should note that the NAI is different from > a domain name. The NAIs defined by this specification end with the > realm "eap.arpa", which does not include a trailing ".". However, > this specification often refers to the domain name "eap.arpa.", > which includes a trailing "." for consistency with other DNS > terminology. > ### Section 1 > > s/EAP peer have pre-provisioned credentials/EAP peer*s* have pre-provisioned > credentials/ Done. > ### Section 3 > > Please always add a trailing dot to all FQDN in an I-D, this happens several > times and has been noted bu the DNS directorate review. Fixed as above to distinguish the realm from the domain name. > Who is the "we" in `We note that this specification`? The author ? The WG ? > The > IETF ? Let's be clear ;-) Also in other sections, e.g., 3.4. Fixed. > ### Section 3.2 > > Please add an informative reference to `IANA Extensible Authentication > Protocol > (EAP) Registry` Done. > About the RECOMMENDED and SHOULD in `It is RECOMMENDED that the first > subdomain` and `realm registry SHOULD be similar enough` why not using > "SHOULD" > and "MUST" ? If the terms are kept unchanged, then an explanation must be > stated when the SHOULD can bypassed. Sure, I've fixed it. > In addition to "v" for vendor, should there be one for private or > experimental ? I don't think we need a private one. Any private one can just use "v.". For experimental, we can use "ietf.org.v......." I'll add some text. > ### Section 3.4.2 > > What is `malformed EPI` ? Should examples be given (e.g., not matching the > IANA > registries) ? The next sentence discusses the issue of an EPI which is not recognized, i.e. not matching the IANA registries. A malformed EPI is one which ends with "eap.arpa", but which is otherwise an invalid NAI. e.g. contains invalid characters. I'll add some text. > In a world of randomized MAC address, how can a EAP server implement: `Servers > SHOULD rate-limit provisioning attempts` ? It's hard. The real limitation is that MAC addresses are not randomized for each session. > Should this be a MAY in `Implementations SHOULD use functionality such as the > RADIUS Filter-Id` ? After it is a local deployment issue. The SHOULD is there in order to reinforce the idea that these methods result in limited network access. I'll add a reference to the earlier section which discusses this. > Should there be some text that the underlying network (e.g., Wi-Fi AP) MUST > prevent inter-EAP-peer communication ? I.e., no hostile EAP peer can attack > victim EAP peer while the latter is being provisionned ? Hmm... yes. I'll add text. > ### Section 3.6.2 > > s/to create credentials which do not expire/to create credentials *that* do > not > expire/ ? Fixed. > ### Section 5.1 > > An informative reference to `web CAs` would be beneficial. I'll add a ref to the CA/Browser forum. > ### Section 5?2 > > The 3rd paragraph is about network access restriction, why not simply pointing > to section 3.4.2 ? Sure. > ### Section 6 > > Unsure whether "deprecated" is the right term in `The "n...@eap-noob.arpa" > registry entry is deprecated`, suggest using "deleted" but obviously IANA will > have the final say. I think it's worth marking it deprecated rather than deleted. > Please provide informative references (including URI) for all registries, > e.g., > https://www.iana.org/domains/arpa Done. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
