Reviewer: Ted Lemon Review result: Ready with Nits The introduction references RFC1035. This may have been exactly the right thing to do, but RFC1035 is a fairly old representation of the state of the art of the domain name system at this point. When it was written, RFC1034 might have been a better entry point unless the authors assumed that the readers would necessarily already be familiar with it (a not unreasonable assumption). However, in this modern time, I think that it might make sense to reference RFC9499 first and RFC1035 second. That might sound like an odd choice, but please read the introduction to RFC9499 before dismissing it entirely! The particular reason I think this is relevant is that RFC9499 doesn't update RFC1035, so the reader won't get a clue to reference it from the metadata for RFC1035, and I think RFC 9499 adds significant value. I don't feel strongly about this--I think it's likely that most readers will already have the information they need. However, this document updates a fairly core document in the suite of internet standards, and so it might make sense to account for the occasional naive reader. Needless to say, I leave it up to the authors and ADs whether this is a good idea, but I think it might be. --- Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of 4.1.1.1 not a MUST NOT? What is the exception? -- Section 5.1 doesn't say what to do with chained CNAMEs. It might be worth saying more here. A strict reading of the spec here would I think treat chained CNAMES correctly in the sense that if the target of the CNAME is treated as the initial name, then each target would be processed the same way, by first looking for a CNAME. And of course a full-service resolver will do the CNAME work for the SMTP client. So perhaps clarifying that the "resulting name" is the result of fully following the CNAME as described in RFC1035 section 7.1. Or maybe this is unnecessary--I leave this to the judgment of the authors and ADs. -- Does section 5.1 need to talk about the NULL MX? This was discussed earlier, but isn't mentioned here. -- I found this text in 5.1 to be a bit more obscure than necessary: Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. Why not just say that any other response, including a CNAME even if it ultimately points to an A or AAAA record, is not a valid response and MUST be ignored? -- My general experience of this document as a DNS directorate reviewer is that I found a lot of questions that had answers, and very few that did not. :) -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
