Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-prefix-lengths-08: 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-opsawg-prefix-lengths/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-opsawg-prefix-lengths-08 CC @evyncke Thank you for the work put into this document. This document addresses a real issue especially for IPv6 networks. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to John Levine for the shepherd's detailed write-up including the WG consensus (noting only 4 reviewers :-( ...) *but it lacks* the justification of the intended status especially since this I-D could have been BCP or informational. Other thanks to Sheng Jiang, the Internet directorate reviewer, that reviewed this I-D as "ready": https://datatracker.ietf.org/doc/review-ietf-opsawg-prefix-lengths-08-intdir-lc-jiang-2025-11-09/ I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## COMMENTS (non-blocking) ### Intended status Did the WG discuss whether this I-D should be published as BCP or informational rather than PS ? ### Section 1 Should there be a reference to `CAPTCHA` ? E.g., in 10 years, people may wonder what this was about... Is it really only an IPv6 issue in `prefix size for IPv6 geolocation` ? Why "should" rather than "must" in `In all places inetnum: is used, inet6num: should also be assumed` ? ### Section 3 s/using Carrier-Grade NAT (CGN) [RFC6598]/using Carrier-Grade NAT (CGN) [RFC6598] *or proxies*/ ### Section 3.1 `Note the third field being set to '1', which signals the absence of CGN or proxies.` why not empty in this case ? I.e., what is the meaning of an empty 3rd field ? ### Section 3.2 Except for the first sentence, all the rest of this section appears to work only with CGN and not proxies. Please clarify that this is also applicable to proxies. ### Section 3.3 `If both the second and third fields are empty, this means that the publisher does not want to disclose any prefix length information.` should really be in section 3. (note: I hesitated to raise a blocking DISCUSS on this point). ### Section 3.4 This section (longest prefix) must appear before section 3.3 as section 3.3 example uses longest prefix match. ### Section 3.5 Why not a "MUST" in `Publishers SHOULD take measures to ensure there is one and only one entry per prefix` and in `consumer implementations SHOULD skip that entry` ? Please define `significant horizontal scale` or use other terms. `This document also suggests an optional signature` should probably be in the introduction section. ### Section 4 What an ugly nightmare to be backward compatible... Why does this I-D proposes `extref: Prefixlen` in addition to `prefixlen:` ? The client then would have to process only `prefixlen:` and `remarks: Prefixlen`. I am also unclear why not only `prefixlen:` having intermediate steps can be cumbersome on the long term as 'remarks: Prefixlen' will probably stay forever. ### Section 5 Does the discussion about RDAP vs. WHOIS relevant to this I-D ? IMHO, it is much broader, i.e., it does not belong within this I-D. Why restricting to only unsigned files `When reading data from an unsigned prefixlen file, one MUST ignore data outside the referring inetnum: object's address range.` ? I do not see why signed files can escape this common sense check. ### Section 6 Why using an IP address range rather than the usual prefix notation used through all this I-D in `The RPKI Signature's IP address range MUST match that of the prefixlen URL in the inetnum: that points to the prefixlen file.` ? ### Section 7 This section contains the first use of NIR and LIR. Should this rather be done in the introduction or terminology by stating (like for the equivalence of IPv4 and IPv6) that "using RIR for RIR/LIR/NIR"? Isn't the last paragraph implicit by the normal use of HTTP (and associated CDN/proxies)? ### Section 8 s/At the time of publishing this document/In November 2025/ `the "NetRange" attribute/key must be treated as "inetnum", and the "Comment" attribute must be treated as "remarks".` should this be part of section 4 ? Of course at the obvious risk of offering even more choices :-( ## NITS (non-blocking / cosmetic) ### draft-ietf-regext-rdap-geofeed As indicated by id-nit, draft-ietf-regext-rdap-geofeed is now RFC 9877, please update the references. ### e.g. s/ e.g./, e.g.,/ s/i.e./, i.e.,/ _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
