Ted, Thanks for the careful reading and review. Responses inline below. --On Tuesday, October 15, 2024 07:13 -0700 Ted Lemon via Datatracker <noreply@xxxxxxxx> wrote: > 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. Let me see if I can walk through the problem. RFC 1035 is referenced in many places. A quick scan got me Sections 1.1, 1.2, 2.3.5 (several times), 4.1.2, 4.2.4.2, and 5.1, but no guarantees I didn't miss one. In most of those cases, including the two in the introduction, they are referring to specific features, not to terminology. For them, I believe that a reference to RFC 9499 would be incorrect and might add confusion. Then we get to Section 2.3.5. The first mention of RFC 1035 is a definition of "labels". I think that citation could be replaced by a pointer to 9499, but SMTP does not allow zero-length labels (the notorious "foo..bar.example" case) and the graph theory explanation might be opaque to the audience for the current draft, so some explanation might be required in addition to just swapping out the citations. The second mention is about the notorious "preferred name syntax" terminology. RFC 9499 does not define it, it just circles around it in the definition of "Host name" with a number of statements that include handwaving qualifiers like "often meant to be", "is also called", and "might include". Maybe that would be ok, but there is a certain simplicity in a definition that is ok for SMTP and at least appears (in RFCs 1034 and 1035) to be unambiguous. In Section 4.1.2, we are back to a specific normative requirement of RFC 1035, not a terminology reference. None of that makes it a bad idea, but there are questions as to whether implementing it is worth the trouble. Even without looking at the other sections, my point is that altering the current references to use RFC 9499 is going to require examination of each case where RFC 1035 is now mentioned or invoked and making decisions about whether the topic is terminology or a reference to a specific operation or requirement. Even where something is clearly a reference, the definition in RFC 9499 should be examined to be sure that referencing it instead would not add to, rather than reducing confusion. Some of those decisions might be very subjective and painful judgment calls. As discussed in part of my response to Donald Eastlake's/SECDIR review, for at least some of these references (I have not taken the time to check) the text was in RFC 5321 or earlier, there is no evidence that it caused confusion or harm, and messing with it now may not be justified. My tentative conclusion is that, while there are probably places were referencing RFC 9499 instead of, or in addition to, 1035 would add some small amount of clarity, it would not justify the amount of time and effort needed to work through all the cases and then do enough review to be sure that any changes are correct. I believe that is consistent with decisions the WG has made about conditions for altering established text and avoiding making changes that are not strictly necessary, even if they might be nice. > --- > > Non-DNS question: why is the "SHOULD NOT" in paragraph 2 of 4.1.1.1 > not a MUST NOT? What is the exception? I'll like to hear from others in the WG, but there was a certain reluctance to invalidate (i.e., render completely non-conforming) existing conforming implementations without clear evidence of harm. There is no harm here if servers accept it (rather than treating it as an error), even if they then ignore it, which is what the first part of the sentence essentially says. At the other extreme, SMTP servers are basically allowed to decline to accept a message for any reason(s) they find appropriate, so why should this be the exception? I don't have any idea how many SMTP clients do send that information or whether people who think market size is important would consider any such client worth considering. > -- > > 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. I _think_ the WG's conclusion was that, if a more extensive discussion on this subject was needed at all, it should be in the Applicability Statement. I do think there was some concern about CNAME loops, e.g., A IN CNAME B B IN CNAME C C IN CNAME A especially if A, B, and C were in different domains. Again, this is unchanged text from RFC 5321 and essentially unchanged from RFC 2821, so we have gone a very long time without evidence of confusion or other harm. > > -- > > Does section 5.1 need to talk about the NULL MX? This was discussed > earlier, but isn't mentioned here. No opinion. I don't think it would be either hard or dangerous to add a sentence there, perhaps as a second sentence in paragraph 2, indicating that, if one of those is encountered, the lookup is over and include a reference to those earlier discussions. WG? > -- > > 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? Don't remember. We might have been concerned about possible further DNS extensions or the advent of IPvX and AAAAAAAAA records. > > -- > > 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. :) Thanks. That was certainly the WG's intention, to say nothing of the author's :-) On the other hand, it is long, complex, and suffers from the paste-together integration discussed in Sections 1.2 and 1.3 so it is a relief but, in a way, a bit surprising that careful readings with fresh eyes, yours and Donald's included, have not turned up even more issues. john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
