Mike Bishop has entered the following ballot position for draft-ietf-dnsop-structured-dns-error-23: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # IESG review of draft-ietf-dnsop-structured-dns-error-23 CC @MikeBishop ## Discuss ### Section 4, paragraph 5 ``` Contact URIs conveyed in the "c" field MUST use URI schemes registered in Section 11.3. ``` This is presumably aimed at the security discussion in 10.2. However, it's a bit odd to create a registry of entries that are already in another registry. What is the expected behavior upon encountering a URI scheme not in this registry versus one added to this registry later that the client doesn't implement any particular behavior for? I would consider eliminating this registry entirely and instead saying that clients MUST/SHOULD ignore URI schemes they don't specifically support here, and recommend these two be the only ones supported. ### Section 4, paragraph 15 ``` is returned. The "s" field MUST convey the primary blocking cause. The "j" field MUST be used to provide additional context describing all applicable causes. ``` What is the relative priority between an optional field that MUST convey certain information? That is, should this be read as "MUST ... if present" or as "MUST be present and ..."? ### Section 4, paragraph 26 Are clients required to enforce these requirements on names they don't recognize? If so, what behavior is a client required to take when processing a non-compliant error response? If not, why are these normative requirements? ### Section 10.2, paragraph 6 There are currently 66,149 such organizations. Are clients expected to check against the list in real-time or embed the list in their code? What is the guarantee that these organizations are trusted? ### Section 10.2, paragraph 7 How does the client determine the intent of a text string? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Comments ### Section 3, paragraph 2 These are very long bullet points. Might they be easier to digest as subsections? ### Section 3, paragraph 2 ``` the host component [RFC3986] of an HTTP URL is blocked, the network security device (e.g., Customer Premises Equipment (CPE) or firewall) presents a block page instead of the HTTP response from the content provider hosting that domain. This works successfully with HTTP. ``` I'm unclear why this is scoped to "if the host component is blocked." The host is the only thing there is at the DNS layer. Or are you trying to say this technique could be used to insert a proxy in the middle to perform more granular path-based filtering on a given site? ### Section 4, paragraph 12 It seems odd to say a field can be omitted entirely, but cannot be empty. ### Section 5.2, paragraph 4 The second MAY is not normative; perhaps "might" or "could"? ### Section 10.3, paragraph 1 "from" => "only from"? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 1, paragraph 7 ``` - [RFC8914] which says the information in EXTRA-TEXT field is intended + [RFC8914], which says the information in EXTRA-TEXT field is intended + + ``` #### Section 4, paragraph 23 ``` - To avoid exceeding the maximum EDNS0 size [RFC9715] the generated + To avoid exceeding the maximum EDNS0 size [RFC9715], the generated + + ``` #### Section 5.2, paragraph 4 ``` - Servers MAY decide to return small TTL values in filtered DNS - ---------- ``` #### Section 5.3, paragraph 4 ``` - client MUST treat the data as invalid, MUST NOT process it - ^ + client MUST treat the data as invalid and MUST NOT process it + ^^^^ ``` ### Section 5.1, paragraph 2 ``` The presence of the SDE option indicates that the client desires the DNS server to include an EDE option in the DNS response when DNS filtering is performed, and that any data conveyed in the EXTRA-TEXT field of the EDE option is encoded and processed in accordance with this specification. ``` The client desires ... that any data ... is ... processed in accordance with this specification, but the client is the one doing the processing. Rephrase that part as the client advising the server that it will attempt to process any such data according to this specification. (Or desires that it *can be* so processed.) _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
