[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
[DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: No Objection 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-nsec3-guidance/ -- COMMENT: -- Thank you for the work on this document. Before reading Alvaro's comment, I was going to bring up that the following paragraph in Section 3.2 could be confusing for a reader who is aware of the "Updates" RFC header. Note that this specification updates [RFC5155] by significantly decreasing the requirements originally specified in Section 10.3 of [RFC5155]. See the Security Considerations for arguments on how to handle responses with non-zero iteration count. I see that Alvaro is questioning if this doc should actually update 5155, I personally don't have a strong opinion, and don't think it is absolutely necessary, although I am curious to hear if there has been discussion in the community about it. In any case I think it would be good to rephrase the above paragraph to avoid saying that this doc updates 5155 when it doesn't. Thanks, Francesca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)
Hi Ben, Thanks for your reply. Some additional thoughts inline. Francesca From: iesg on behalf of Ben Schwartz Date: Thursday, 3 March 2022 at 19:27To: Francesca Palombini Cc: Tim Wicinski , dnsop , dnsop-chairs , The IESG , draft-ietf-dnsop-svcb-ht...@ietf.org Subject: Re: Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)On Wed, Mar 2, 2022 at 5:13 PM Francesca Palombini via Datatracker <nore...@ietf.org> wrote:--DISCUSS:--Thank you for the work on this documentMany 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 textabout why these are SHOULD and not MUST or MAY. OK. I've noted the instances you've identified at https://github.com/MikeBishop/dns-alt-svc/issues/355 FP: Thank youI also have a number of non blocking comments and questions. I will appreciateanswers to my questions, to improve my understanding. If any clarificationcomes out of it, I hope it will help improve the document. I've attempted to answer questions inline, and tracked the other comments at https://github.com/MikeBishop/dns-alt-svc/issues/372. ... --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 doesdefine requirements etc. Maybe it is normatively described somewhere else? Yes, this section highlights some requirements but does not include any normative language. Any normative requirements mentioned in this section are defined normatively elsewhere in the document. Thena pointer to that makes sense. OK, we can add more forward references to this section. (Tracked at https://github.com/MikeBishop/dns-alt-svc/issues/371.) Also why does this mention encoding and formatbut there is no encoding specified. This section of the introduction is just an overview, for a reader who is not familiar with SVCB. The detailed specification of encodings, formats, and other requirements is later in the document. FP: Thanks, I added a note in the github with a suggestion on text – basically removing “non-normative manner”. 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. Ordering is unspecified in presentation format, but must be sorted in wire format. 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. This "MAY" is intended as an exception to "Clients SHOULD try higher-priority alternatives first" in Section 3. FP: You don’t need to add this as a BCP 14 “MAY”, as “SHOULD” already allows for exceptions, and again this text is only describing an example, so in my opinion should not be adding requirements but just describe behavior. 7. - For example, the following is a valid list of SvcParams: ech=... key65333=ex1 key65444=ex2 mandatory=key65444,echFP: I expected this to be a comma separated list. Section 2.1 notes that "SvcParams are a whitespace-separated list". The SvcParamValue for "mandatory" is a comma-separated list ("key65444,ech"). FP: Thanks, I missed it. 12. - All protocols employing "http://" or "https://" URLs SHOULD respect HTTPS RRs. For example, clients that support HTTPS RRs and implementFP: I am not sure how the first sentence is supposed to be implemented, hencewhy BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not bethe clearest wording. There are many protocols that are "layered on top" of HTTP in some fashion, e.g. generating an HTTP URL and performing an HTTP connection as part of some process. This text was originally written for WebSocket (wss://), but it could also potentially apply to something like MTA-STS, which generates an HTTP URL to fetch information about a mail server. The SHOULD applies primarily to implementers of such protocols, who may need to configure their HTTP implementations appropriately. I think the word "respected" was used because HTTPS-record support is optional for HTTP in general.
[DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)
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/ 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 MA
Re: [DNSOP] [art] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
Jean, thank you so much for the thoughtful review! I balloted no objection. Thanks authors for addressing Jean’s comments. Francesca From: art on behalf of Jean Mahoney via Datatracker Sent: Saturday, September 4, 2021 2:29 AM To: a...@ietf.org Cc: last-c...@ietf.org; dnsop@ietf.org; draft-ietf-dnsop-dns-tcp-requirements@ietf.org Subject: [art] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12 Reviewer: Jean Mahoney Review result: Ready with Nits Reviewer: Jean Mahoney Review result: Ready with nits A well-written, easy-to-read document. Love Appendix A! Question about Appendix A.2 and Updates - Should this document also update RFC 1536? Current text in A.2: The informational document [RFC1536] states UDP is the "chosen protocol for communication though TCP is used for zone transfers." That statement should now be considered in its historical context and is no longer a proper reflection of modern expectations. Nits: General - Document status (Informational, Standards Track, etc.) should be capitalized, and Standards Track is not hyphenated (There's just one instance of hyphenation). Section 2.4 - 35%of / 35% of Section 3 - transport.[TDNS] / transport [TDNS]. Section 5.1 Current: "the steady-state of lost resources as a result is a 'DNS wedgie'." Perhaps: "the steady state of the resulting lost resources is a 'DNS wedgie'." Section 5.2 - Expand the acronym KSK. Section 7 - The Acknowledgments section should be located just above the Authors' Addresses section. It looks like the names are supposed to be in alphabetical order, but they aren't quite. Section 9 - fragmenetation / fragmentation Section 10 - Since DNS over UDP and TCP use / Since DNS over UDP and TCP uses Section 11.2 - [ROLL_YOU_ROOT] has a mangled author name and a TBD. Appendix A - The construction "The [RFC] document..." (in A.3, A.4, A.5, A.7, and A.13) reads oddly to me. Perhaps "This document [RFC] ". Appendix A.8 - The verb tenses are mixed in this section. Appendix A.32 - as a a / as a There are other nits I could pick more easily if this doc was in a GitHub repo. They can be left to the RPC to clean up. :-) Thanks! Jean ___ art mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/art ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: No Objection 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/blog/handling-iesg-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-dns-tcp-requirements/ -- COMMENT: -- Thanks for the work on this document. Many thanks to Jean Mahoney for her ART ART review: https://mailarchive.ietf.org/arch/msg/art/YAoRhQIrKn4g0L6XFZvV45bWL44/. I only have one very minor comments, to take or leave as you please: headers are 40 bytes (versus 20 without options in IPv4). Second, it seems as though some people have misinterpreted IPv6's required minimum MTU of 1280 as a required maximum. Third, fragmentation in FP: The "some people" is quite cryptic, in my opinion. What people? Does this come from analyzing implementations? Then it would probably be good to state so instead. Francesca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] Artart telechat review of draft-ietf-dnsop-rfc7816bis-10
Thanks Valery for your review! I balloted No objection (https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ballot/ ). Francesca On 18/08/2021, 10:24, "art on behalf of Valery Smyslov via Datatracker" wrote: Reviewer: Valery Smyslov Review result: Ready I am the assigned ART directorate reviewer for this document. These comments were written primarily for the benefit of the ART area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes the technique called DNS Query Name Minimisation, which was originally defined in RFC 7816, and since then has been widely using in the Internet to improve privacy. The goal of this document is to replace RFC 7816 (which has an Experimental status) with a Standards Track RFC, adding some clarifications based on the experience of using this technique in the Internet. The DNS Query Name Minimisation doesn't change DNS protocol, it only defines the way the resolver constructs DNS queries, so the interoperability is preserved. The document is well written and easy to read. Nit: RFC 7626, referenced in the document, has been just obsoleted by RFC 9076. ___ art mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/art ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: No Objection 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ -- COMMENT: -- Thank you for the work on this document. Thanks to Valery Smyslov for the ART ART review, please address his comment with the next update: > Nit: RFC 7626, referenced in the document, has been just obsoleted by RFC > 9076. Francesca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)
Francesca Palombini has entered the following ballot position for draft-ietf-dnsop-iana-class-type-yang-03: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ -- DISCUSS: -- Thank you for the work on this document. (This is a "let's talk" DISCUSS, which I don't expect to hold after the telechat) I wonder if it wouldn't make sense to add a step where IANA gets the help of the designated experts from each respective registry when elements are added to the DNS class or RR type registries, either by the experts creating the substatements to be added, or at least checking and confirming those created by IANA. A couple of minor comments below. Francesca -- COMMENT: -- 1. - models along with standard management protocols such as NETCONF and RESTCONF can be effectively used in DNS operations, too. In fact, FP: Please expand NETCONF and RESTCONF on first use. 2. - FP: I believe it would be good to add a sentence in the terminology section stating that DNS terminology is used throughout the document, and point to RFC 8499 and/or RFC 1035. I think informatively would be enough. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
Reviewer: Francesca Palombini Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-attrleaf-fix-04 Reviewer: Francesca Palombini Review Date: 2018-09-24 IETF LC End Date: 2018-09-25 IESG Telechat date: Not scheduled for a telechat Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Major issues: N/A Minor issues: N/A Nits/editorial comments: I give some proposal for clarification here, feel free to take them or leave them. The idnits tool however produced several output, I would suggest to fix those before publication. The use of underscored node names is specific to each RRTYPE that is being scoped. As an non-expert in the area, I would have appreciate a ref to a document introducing RRTYPE. This section provides a generic approach for changes to existing specifications that define straightforward use of underscored node names, when scoping the use of a "TXT" RRset. Same for "TXT" RRset. An effort has been made to locate existing drafts that do this, register the global underscored names, and list them in this document. Since the effort has been done, I would have appreciated the full list here. An effort has been made to locate existing drafts that do this, register the global underscored names, and list them in this document. Same as previous comment. An effort has been made to locate existing drafts that do this and register the associated 'protocol' names. Same as previous. 3.1. and 3.2. is the formatting of the updated sections (after "And is to be updated to the new text:") wanted? Why not use the same format as in 3.3., with OLD and NEW? + Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry [RFC6335]" Move the end quote after Registry. + Those listed in "Enumservice Registrations [RFC6117]. Missing end quote after Registrations. " Signaling Trust Anchor Knowledge in DNS Security Extensions Remove the space after the quote. John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul In Acknowledgements, one name is not encoded correctly. >From running the idnits tool (https://tools.ietf.org/tools/idnits/), several comments, warnings and one error were raised, which I snipped and pasted below as a summary: -- The draft header indicates that this document updates RFC, but the abstract doesn't seem to mention this, which it should. (see https://www.ietf.org/id-info/checklist) --> I see that the abstract generally mentions "the existing specifications that use underscore naming", but I think to make this correct, it should explicitely list them as well. -- The document seems to lack a disclaimer for pre-RFC5378 work (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) == Unused Reference: several documents are included in the list of references, but no explicit reference was found in the text --> if my editorial comments are taken, they should fix this one. ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
