[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-zoneversion-11: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-zoneversion-11: 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-zoneversion/ -- COMMENT: -- thanks! ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] John Scudder's Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-zoneversion-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-zoneversion/ -- DISCUSS: -- Thanks for this document, it seems useful and I found it well-written. I have one blocking concern about the choice of Informational vs. PS, and one minor nit. ### DISCUSS I agree with other reviewers that this appears to be most appropriately Proposed Standard and not Informational. Regrettably, the shepherd writeup doesn't explain the reason for this choice, so I am balloting DISCUSS. We could resolve this by changing the track, or by helping me understand why Informational is the right choice. -- COMMENT: -- ### Section 7.2 "assignments in the 1-245 values are to be made through Specification Required Review" I assume you mean "Specification Required review" (lowercase "review"). Sorry, I realize this is a very picky point, but by capitalizing "review" you make it appear as though you are referring to a policy named "Specification Required Review", which isn't a policy defined in RFC 8126. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-error-reporting-07: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-dns-error-reporting-07: 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-dns-error-reporting/ -- COMMENT: -- Thanks for this useful and readable specification. I have one comment – Section 6.1 says, “The EDNS0 Report-Channel option MUST NOT be included in queries.” Section 6.2 says, “There is no requirement that the EDNS0 Report-Channel option is present in queries.” While the two are not technically in conflict, the second understates; it seems like you could, and should, remove it. But perhaps there’s some subtlety I’m not understanding here. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: 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-alt-tld/ -- COMMENT: -- One comment -- Section 3.2 has "DNS server operators MAY be aware that queries for name ending in .alt are not DNS names, and queries for those names were leaked into the DNS context." The RFC 2119 MAY appears misused in this context. (Also, in that quote, s/queries for name/queries for names/) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-rfc5933-bis-13: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-rfc5933-bis-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/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-rfc5933-bis/ -- COMMENT: -- The document is short and readable, I have no objection to it as such. Roman's DISCUSS position makes sense to me, however, as does his proposed solution (even though the additional work is regrettable). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's Yes on draft-ietf-dnsop-dnssec-bcp-05: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-dnsop-dnssec-bcp-05: Yes 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-dnssec-bcp/ -- COMMENT: -- Thanks, Paul, for this useful and easy-to-read document. Thanks also to Tim Wicinski for putting in the work to build the excellent evaluation table. ## COMMENT ### Section 1 ~~~ This document lists many (but not all) of the RFCs that should be considered by someone creating an implementation of, or someone deploying, modern DNSSEC. ~~~ Why not list all the ones that should be considered? That seems like a bit of a tease! But maybe (probably?) you meant that the list is not guaranteed comprehensive, in which case perhaps something like this ~~~ This document lists RFCs that should be considered by someone creating an implementation of, or someone deploying, modern DNSSEC. Although an effort was made to be thorough, it would be unwise for the reader to assume this list is comprehensive. ~~~ could be used. But maybe you meant exactly what you wrote, in which case, OK. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
John Scudder 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: -- Thanks for this document, I found it easy to read and useful. I have only a few nits: 1. In the Introduction: “This sacrifices the tamper-resistance proof of non- existence offered by NSEC3” That doesn’t parse. Probably what you mean is “This sacrifices the tamper-resistance of the proof of non-existence offered by NSEC3” (added “of the”)? Or "... the tamper-resistant proof" would also work. 2. In Sections 2.4 and 3.1, I suggest “re-signing” (signing again) instead of “resigning” (quitting). 3. Appendix B has “The table (Appendix C) below” The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I guess you either should caption it and xref that caption, or just remove the xref? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
John Scudder 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 well-written document! A few comments -- 1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to update the Standards Track documents in question. If I had a better option to offer at this stage in the document's history, I would, but under the circumstances I don't. If we had it to do over again, my preference would have been to progress a small PS to update the Standards Track documents, and a BCP to provide all the rest of the content. In addition to the points Ben made, my discomfort also stems from the fact that the advice regarding implementations has inherently short shelf life (relatively speaking) whereas the updates are forever (or at least until the updated documents are bis'd). I'm not requesting any change with this observation, just putting it out there for discussion (without making it a DISCUSS...). 2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part seemed especially loosy-goosy to me as written, as to what precisely is updated in RFC 1536. The flow of the prose is nice, but the conclusion is less than clear. I do think some rewrite of this section would be helpful. 3. Section 6 says applications should perform “full TCP segment reassembly”. What does that mean? A quick google search doesn’t suggest it’s a well-known term of art. I'm guessing that what you mean is that the applications should capture (and log, etc) the bytestream that was segmented and transmitted by TCP? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
