Éric Vyncke 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-dnsop-zoneversion-08 Thank you for the work put into this document. The value for troubleshooting is clear and I would have ballot a YES (once my trivial DISCUSS is resolved) if this I-D was standard track rather than informational. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tim Wicinski for the shepherd's short write-up including the WG consensus even if the justification of the intended status could provide more information (informational seems a low bar, why not PS for such an important change). I hope that this review helps to improve the document, Regards, -éric # DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ## Wrong BCP 14 Easy to fix: the BCP 14 template is the old one. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non-blocking) ## Intended status While the IANA "DNS EDNS0 Option Codes (OPT)" registry does not require a standard track document, many other entries are PS, e.g., RFC 7828 for the edns-tcp-keepalive option. Why not aiming for this status? Especially when using normative BCP 14 language. ## Abstract s/since the version and the data are provided atomically/since the version and the DNS answer are provided atomically/ ? Data being relatively vague. ## Section 1 Suggest repeating the RFC 5001 reference. s/such as relational databases/such as replicated databases/ ? `To accomodate these use cases, new ZONEVERSION types should be defined in future specifications` perhaps s/should/could/ ? ## Section 3.2 In `A name server MUST ignore invalid ZONEVERSION options` what is an "invalid" ZONEVERSION in this context? Related to this point, what should a server do when receiving the option with a non-zero length ? ## Section 7.1 Should https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11 be added ? # NITS (non-blocking / cosmetic) ## Section 1 s/authoritative DNS severs to provide/authoritative DNS se*R*vers to provide/ s/distrubtion/distribution/ It seems that the I-D would benefit from a automated corrector pass ;-) I will stop doing this role ## Section 2.1 s/1 octet Label Count/1-octet Label Count/ ? _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
