Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-svcb-https-09: 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/. Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed v-09 and I noticed 4 points were not addressed (or I missed them). Do let me know if you think no further clarifications were necessary - just making sure these were not missed, as I have not seen any answers to them. Re: the use of SHOULD - thank you for adding context to most of them. I did not see any added context to these following two SHOULDs: > Zone-file implementations SHOULD enforce self-consistency. and > If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. 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. Francesca ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 4. ----- The value is then validated and converted into wire-format in a manner specific to each key. FP: Section 15.3.1 states registration policy ([RFC8126], Section 4.5). The designated expert MUST ensure that the Format Reference is stable and publicly available, and that it specifies how to convert the SvcParamValue's presentation format to wire format. This covers the conversion, but does not cover the validation mentioned above. (This could be really easily addressed by making sure that not only it specifies how to convert but also how to validate). 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 expert review registration policy. That should be made consistent. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
