I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-radext-dynamic-discovery-13 Reviewer: Martin Thomson Review Date: 2015-03-21 IETF LC End Date: 2015-03-20 IESG Telechat date: 2015-04-19 Summary: This document is of a quality I rarely see even for proposed standard. It is certainly fit for publication as an experimental RFC. (In case it isn't clear, I agree with the decision to choose experimental here, this is in a tricky area and deployment experience will validate choices.) Major issues: None Minor issues: S-NAPTR tags for RADIUS are defined, but none for Diameter. I'm sure this was considered, but it seems odd on first reading. S2.1.1.2 uses SHOULD to recommend that clients retry with their other certificates. I'd recommend use of MAY here, unless you would like to expand on why this a SHOULD is valuable. S2.1.1.3.3. I know that this is experimental and all, but this seems a little too hand-wavy even for that. I think that this is the right design, but the section could be a little more confident (and precise) in the description of how this works. It took me a couple of goes to understand how this was intended to work. One important realization was that a common root for the realm needs to be configured. I'd like to see this section expanded slightly (my initial inclination would have been toward removal, but the content is in line with the experiment, so it's probably valuable). S2.2 says: Since the Domain Name System is not necessarily trustworthy (e.g. if DNSSEC is not deployed for the queried domain name), it is important to verify that the server which was contacted is authorized to service requests for the user which triggered the discovery process. This implies that DNS integrity is the only reason for authentication. To paraphrase Steve Bellovin: you hand your packets to the attacker to deliver. Also: It MAY substitute labels on the leftmost dot- separated part of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Use the singular form here to avoid confusion: It MAY substitute the leftmost dot- separated label of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". S3.4.1 is the first mention of UTF-8 realms, which are not permitted by RFC 4282. This was a point of confusion for me. I note that the new nai draft permits UTF-8 realms. Please just cite that and remove the reference to 4282. S 3.4.3 doesn't cover how to handle NAPTR records with flags set to "a", though other parts of the document describe that. I think there is some refactoring of the dependency on the S-NAPTR algorithm, and an allowance for a default port. Nits/editorial comments: S1.3 Capital 'P' on first bullet S2.1.1.1 Missing period on first note. S2.1.1.2 Please provide a reference for "Effective TTL". S2.1.1.3 s/PKS/PSK/ and "used for in the subsequent" (S2.1.3 Please be consistent with the trailing period in DNS record entries) 2.1.3.c. "x-" ugh...RFC 6648 S.3.4.4 "If these TTLs are very low, thrashing of connections becomes possible; the Effective TTL mitigates that risk." - isn't this the MIN_EFF_TTL instead? S3.4.4 the last MAY here can be a SHOULD, I think S5 "the result O can not be trusted" -> "the result of the discovery process can not be trusted"