Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)
On Mon, May 23, 2022 at 8:01 AM Francesca Palombini via Datatracker < nore...@ietf.org> wrote: > -- > 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: > OK, I've proposed adjustments to those two SHOULDs at https://github.com/MikeBishop/dns-alt-svc/pull/392 ... > -- > 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). > I don't think this text change is necessary, because any specification of the conversion necessarily also covers validation. A "conversion" in this context is an algorithm that accepts one input (an octet sequence) and produces one output, which is either an octet sequence or a failure indication. If the conversion fails, we say that the input was invalid. 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. > This text was slightly adjusted in -09 based on your comment. It now reads "_New_ entries in this registry are subject to an Expert Review registration policy" (emphasis mine). This is consistent with the example given in RFC 8126 Section 2.2. I believe the source of confusion here is that RFC 8126 defines "Private Use" twice, with incompatible meanings: Section 4.1 describes it as a Registration Policy, whereas Section 6 defines it as a Registration Status. This registry is using the latter definition. smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-05-24
Dear all, This is a gentle reminder to the WG that the interim meeting is scheduled for tomorrow, 24 May 2022, 17:00-18:00 UTC. Regards, Suzanne, Tim and Benno On 14/05/2022 12:10, Benno Overeinder wrote: Dear all, All information for the interim meeting (agenda, drafts and the slides if they are available) can be found here: https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/session/dnsop Regards, Suzanne, Tim and Benno On 13/05/2022 19:55, IESG Secretary wrote: The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2022-05-24 from 19:00 to 20:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: Agenda * Chairs, Administrivia (10 min) * Ulrich Wisser and Shumon Huque, DNSSEC Automation (25 min) https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/ * Peter Thomassen and Nils Wisiol, Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator (25 min) https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=45d75893-b015-4b13-b835-204c9de2b003 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)
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/ 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
