Document: draft-ietf-emu-eap-arpa Title: The eap.arpa. domain and EAP provisioning Reviewer: Patrick Mevzek Review result: Ready with Nits I was chosen to review draft version 9 of draft-ietf-emu-eap-arpa specifically regarding DNS related matters. I mostly concur with the previous reviewer of version 6 stating: > This draft doesn't introduce any new use of the DNS. Instead it simply asks for a new Special Use Domain name (RFC 6761) and uses domain names strictly as a naming convention for identifiers. This seems like a perfectly good use for a Special Use Domain, and, in fact, it is just following the example set by 'eap-noob.arpa.'. >From previous reviewed version, I see that names got an added trailing dot as it was one suggestion, when the name is used in the sense of domain name, separate from its use in the sense of a "realm", so I consider previous review to have been taken into account, and be closed. I do note that this new version goes toward deprecating previous eap-noob.arpa. to instead register eap.arpa. and then use it as base for all possible future needs. I believe this to be a good move, avoiding the need to possibly have to register lots of different domain names and involving IANA each time. Requesting special domain usage, section " 6.1.2.1. Domain Name Reservation Considerations " follows the RFC 6761 requirements to list in 7 points any specific details for the domain requested. Some comments: - section 2: The EPI is an NAI which ends with "eap.arpa" Maybe this should be specified more precisely. Because ends with, without any other specification of format for an EPI, would mean that "noteap.arpa" also "ends with" eap.arpa. Specially since NAI defined in §2.2 of RFC7542 allows basically X or @Y or X@Y forms. Based on the further text I tend to understand that the EPI should be an API of the form X@Y where Y is set to be "eap.arpa" or a subdomain of it. If so, maybe explaining that more specifically than "ends with". (which basically seems to be first paragraph of §3, so a matter of reorganizing order maybe) - section 3.2: I find it confusing. It says > The first subdomain of the eap.arpa. domain SHOULD use the EAP method name, as defined in the IANA Extensible Authentication Protocol (EAP) Registry, sub-registry "Method Types". And then explains that this sub-registry does not have domains listed, nor may even have meaningful domains defined anyway. So I don't see the value of saying the subdomains of eap.arpa will be defined by a IANA registry that obviously can't do that. The text says "Where it is not possible to make a direct mapping between the EAP Method Type name" but the sub registry listed doesn't even have a "name" field. Just a value and a description. So what is the name in that registry? - nitpick: "3.4.1 EAP Peer" vs "3.4.2 EAP Servers". Maybe both plural or both singular? - nitpick: in §3.4.2 the paragraph about "Peers MUST rate-limit their provisioning attempts." should instead be in the previous section §3.4.1 EAP Peer - nitpick (maybe just me because not English native) in §3.7 reading "When we say that the eap.arpa realm is not routable in an AAA proxy framework" gives me the impression this was discussed earlier in document, but it wasn't. - nitpick §5.1: "Whether or not the server certificate is ignored, the peer MUST treat the local network as untrusted. [RFC8952], Section 6.2 has more discussion on this topic." That specific section in RFC5952 does not seem to hold lots of discussion on the topic of trust, maybe section 6.1 is more relevant there, or in fact the whole section 6 together? - typo, extra dot: "requires that the server certificate is always validated. . For the provisioning case, it is acceptable in some " - unclear: "since the device likely is configured with CAs for the web issued by [CAB]". What does the CAB issues? CAs? Not even sure what CAB mention here adds. The matter of which CAs each peer accepts or not for certificates is probably far out of scope here, so I see no reasons to restrain it to WebPKI and the sub case of public CAs following CABForum guidelines. - nitpick: "IANA is instructed to update the "Special-Use Domain Names" registry as follows: NAME eap.arpa"; here the trailing dot is missing, that registry use fully dotted names - formatting problem in "6.1.2.1.". Because of an extra paragraph, what should be item 7 now appears alone as a new list and item 1. - unclear in §6.2 "The Network Access Identifier in [RFC7542] format. Names are stored as DNS A-Labels [RFC5890], Section 2.3.2.1" What part of the NAI is considered here as a name to be A-labels? The part before the @, if any? The part after? Both? If like the `noob.eap.arpa` part, one could say this is just a name, maybe no need to resort to "A-Labels", just mention it follows IDNA? Also shouldn't that make this document also clearly update RFC7542? Because its definition of "utf8-realm" (right part of the @) is basically any kind of Unicode characters with some exceptions and specifically encoded as UTF-8, while writing about IDNA above clearly coerces that far more. - unclear in §6.3.1 "The intent is for the NAI to contain both a reference to the EAP Method Type, and a description of the purpose of the NAI. For example, with an EAP Method Type "name", and a purpose "action", the NAI SHOULD be of the form "action@xxxxxxxxxxxx"." Where does "foo" comes from? Why is the EAP Method Type "name" missing? - in §6.3.1 too, same problem as above when using "must end with": "The NAI MUST end with the eap.arpa realm." Does noteap.arpa ends with eap.arpa? Of course not with the sense of the specification, but the text makes that possible. Regards, -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
