Reviewer: Di Ma Review result: Ready with Nits Generally speaking, I think the extension to DNS proposed by this document will not affect DNS operations adversely since it is common and mature to extend EDNS0 to carry DNS signaling information as far as I observed.
I have got several technical comments for the authors to consider: As stated in section 5.2 “If EDE support is signaled in the query the server MUST NOT return the "Forged Answer" extended error code...”, is “Forged Answer” the only code that is not allowed? I suggest authors articulate the rule not just an instance, in order to facilitate the consistency among different implementations. As in section 5.3, “On receipt of a DNS response with an EDE option from a DNS responder, the following actions are performed on the EXTRA-TEXT field”, are all those “actions” ordered or unordered? I think it needs to be specified. In section 6, RPZ is not standardized by IETF. I suggest removing “Interoperation with RPZ Servers” or moving it to appendix since this draft is intended to be a standards track RFC. And I also have some editorial comments: In section 4, “The contact details of the IT/InfoSec team to report mis-classified DNS filtering. This field is structured as an array of contact URIs (e.g., tel, sips, https). At least one contact URI MUST be included. This field is mandatory.” It is necessary to reference RFCs to “tel, sips, https”. In section 5.3, there is an in-paragraph long space breaking “If a DNS client has enabled opportunistic privacy profile (Section 5 of [RFC8310]) for DoT, the DNS client will either fall back to an...” ...and “encrypted connection without authenticating the DNS server...”. In section 5.3, the first action is described as “Verify the field contains valid JSON.” which is the only segment using a verb to describe the very action. I think it would be better to align all the action description wording. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
