[As Med is a co-author, he cannot be the responsible AD for this document, hence, I have been selected as the responsible AD]
# Éric Vyncke, INT AD, AD review for draft-ietf-dnsop-structured-dns-error-19 CC @evyncke Thank you for the work put into this document. It is very easy to read. Please find below my AD review. As the responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call. Special thanks to Benno Overeinder for the shepherd's detailed write-up including the WG consensus, the history behind the 2nd "publication request", and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric Note: this AD reviews follows the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## Critical issues ### Shepherd's write-up Q18 got it wrong as sections 11.2 et al. request the creation of a new registry. ### Abstract I am not sure whether `including *network* security` is correct as it does not really protect the network per se but more the IT system or the end users. Suggest either rephrase it or remove it. ### Section 1 Why not adding a reference to RFC 7754 section 6 `promptly informing the endpoint that blocking has occurred provide necessary transparency to redress any errors, particularly as they relate to any collateral damage introduced by errant filter`? ### Section 3 In bullet 1, `The HTTPS server hosted on the network security device will have access to the client's IP address and the hostname being requested. `, isn't this the same issue with DNS server in all 3 scenarios ? The difference there is for the *path* component and not the *host* part of the URL. ### Section 4 `IT/InfoSec team` or "DNS operator" or "DNS administrator" as used later in the section? As a resident of a country, Belgium, with THREE national languages (not to mention the common use of English), I find *VERY* limiting the use of a single language... Why not an array of languages ? or a 'accept language' in the DNS query SDE option? Relying on `optionally translate it` is wishful thinking (especially for small messages). Can the JSON object be empty as all JSON names are optional ? Should there be text about this special case ? Why JSON and not CBOR ? ### Section 5.2 What can the server do when there are several blocking causes (e.g., malware + court order)? ### Section 5.3 What is the client behavior when receiving more than 1 EDE option ? Should bullet 2 and 3 be swapped ? ### Section 10 Should there be a 'privacy considerations' sub-section ? ### Section 11 "IETF review" seems like a pretty high bar to me, why not "specification required" ? ### Section 11.2 Please add a field in table 1 for "Mandatory (Y/N?)". ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Section 3 s/succesfully/successfully/ s/a end user/an end user/ (more than once) For readability, I wonder whether `This document defines a structured, machine-readable....` part should appear either as a new paragraph in bullet 3 or even outside of the bulleted list (of course adding a reference to bullet #3). ### Section 8 Consider using a 'dig' request to show the SDE & EDE encoding. BTW, the length of the example is about 100 octets... hence a justification for not using CBOR is mostly required. ### Section 11 The formats and apparences of the sub-sections are all different (use of bullet, bold, ...), please fix.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
