Thank you to the authors for writing this, and the WG for the review. It's a well written and easy to understand draft, but I do have a few minor comments that I’d like addressed before I start IETF LC — addressing these now will avoid issues later in the process.
1: The document says "Updates: 1034, 1035 (if approved)" - the Abstract should contain sentence or two summarizing what it updates in those RFCs. 2: Section 4.2. Answer with a Synthesised HINFO RRSet "The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX" -- I'm concerned that someone will start looking for this string in the HINFO field and doing something "clever" with these (who knows what, but it feels like an attractive nuisance) - should there be a recommendation that automated systems should not rely on this string in HINFO and make decisions from it? (this is a question, I'm fine with "Nope") 3: Section 4.3. Answer with Best Guess as to Intention "Some implementations have implemented the spirit of this document by returning all of CNAME or (MX A and AAAA)" Is it possible to reword this? I'm not sure that "or (MX A and AAAA)" is especially clear. Again, these are minor, but addressing #1 will prevent issues at IETF LC / IESG review. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
