Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: 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-svcb-https/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work on this document Many thanks to Cullen Jennings for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/. I am concerned by the use of SHOULD in this document. In several places (see 1. below for what I identified as problematic SHOULDs) the document lacks text about why these are SHOULD and not MUST or MAY. I agree with John Klensin, who formulated it very clearly: If SHOULD is used, then it must be accompanied by at least one of: (1) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise. Examples are fine but, except in plausible and rare cases, not enumerated lists. (2) A statement about what should be done, or what the considerations are, if the "SHOULD" requirement is not met. (3) A statement about why it is not a MUST. I also have a number of non blocking comments and questions. I will appreciate answers to my questions, to improve my understanding. If any clarification comes out of it, I hope it will help improve the document. Francesca 1. ----- FP: SHOULD lacking additional context: Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller SvcPriority value SHOULD be given preference over RRs with a larger SvcPriority value. In AliasMode, the SVCB record aliases a service to a TargetName. SVCB RRSets SHOULD only have a single resource record in AliasMode. If multiple are present, clients or recursive resolvers SHOULD pick one at random. In AliasMode, records SHOULD NOT include any SvcParams, and recipients MUST ignore any SvcParams that are present. Zone-file implementations SHOULD enforce self-consistency. If the client is SVCB-optional, and connecting using this list of endpoints has failed, the client SHOULD attempt non-SVCB connection modes. If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. If the client is unable to complete SVCB resolution due to its chain length limit, the client SHOULD fall back to the authority endpoint, as if the origin's SVCB record did not exist. For compatibility with clients that require default transports, zone operators SHOULD ensure that at least one RR in each RRSet supports the default transports. Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD have a defined specification for use with SVCB. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2. ----- This subsection briefly describes the SVCB RR in a non-normative manner. (As mentioned above, this all applies equally to the HTTPS RR which shares the same encoding, format, and high-level semantics.) FP: I am not sure about why this section is described as non-normative but does define requirements etc. Maybe it is normatively described somewhere else? Then a pointer to that makes sense. Also why does this mention encoding and format but there is no encoding specified. 3. ----- format specific to the SvcParamKey. Their definition should specify both their presentation format and wire encoding (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys and FP: I have the feeling "should" is not the right term here, I suggest to change to "must" or "is required to". Also, it would have been useful to me to add a pointer to RFC 8499 in the terminology about "presentation format". 4. ----- The value is then validated and converted into wire-format in a manner specific to each key. FP: Section 15.4 states registration policy ([RFC8126], Section 4.4). The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry This covers the conversion, but does not cover the validation mentioned above. 5. ----- SvcParams in presentation format MAY appear in any order, but keys MUST NOT be repeated. FP: Seems to contradict SvcParamKeys SHALL appear in increasing numeric order. 6. ----- If the client has an in-progress TCP connection to [2001:db8::2]:1234, it MAY proceed with TLS on that connection using ech="222...", even though the other record in the RRSet has higher priority. FP: I believe this is descriptive of the example and should not use BCP 14 MAY. 7. ----- For example, the following is a valid list of SvcParams: ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech FP: I expected this to be a comma separated list. 8. ----- length prefix. In presentation format, the value is a single ECHConfigList encoded in Base64 [base64]. Base64 is used here to FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5)) 9. ----- FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)" should include a change controller field. 10. ----- Table 1 FP: The table reports that | 65280-65534 | N/A | Private Use | (This document) | But that is not specified in the text above, that only talks about first come first serve registration policy. That should be made consistent. # Nits and Editorials 11. ------ When the "=" is omitted, the value is interpreted as empty. FP: When the optional "=" SvcParamValue is omitted 12. ----- All protocols employing "http://"; or "https://"; URLs SHOULD respect HTTPS RRs. For example, clients that support HTTPS RRs and implement FP: I am not sure how the first sentence is supposed to be implemented, hence why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be the clearest wording. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
