Sorry for the delay, and thanks for the careful review. On Jun 3, 2019, at 4:52 AM, John Dickinson <[email protected]> wrote: > > Reference to SUDN in Introduction is no longer needed.
Fixed. > DNS-over-TLS and DNS-over-HTTPS are both abbreviated to DoT in the Security > Considerations Fixed. > Section 4 P3 s/returen/return/ Fixed. > Section 4 and 5.2 are a bit hard to follow (maybe I need more caffeine). I > would suggest that you use the term key-value pair in place of name-value > pair. Using the word name in DNS docs is bound to lead to confusion. I am hesitant to make that change because "name" is the term used consistently in JSON (and thus also in I-JSON). JSON uses "name/value pair", so I'll change to that, but I recognized that this is not a substitute for caffeine. > Also I was a bit confused by > > 4: “All names in the returned object MUST be defined in the IANA registry > or begin with the substring "temp-“” and > “As defined in Section 5.2, the > IANA registry will not register names that begin with "temp-", so > these names can be used freely by any implementer” > > 5.2: “Name: The name to be used in the JSON object. This name MUST NOT > begin with "temp-". > > until I reread the words “or begin with the substring "temp-“” I think the > could be clearer, something like: > > All keys in the returned object MUST either be defined in the IANA registry > or if for local use only they MAY begin with the substring "temp-“ since IANA > registry will not register names that begin with "temp-“. Good suggestion; fixed. > Finally, section 2 > > “Note that the answer given by the resolver cannot be validated with DNSSEC.” > Whilst I understand the reasons, is it reasonable that we are still trying to > standardise responses that can not be signed? That wording was left over from the -00 draft and is incorrect. Fixed. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
