Thanks for the detailed comments, Éric!
See inline for more details.
Cheers,
Oliver
On 11/28/25 11:48 AM, Éric Vyncke via Datatracker wrote:
É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...
Sure, we can add a reference here. Which reference specifically did you
have in mind?
Is it really only an IPv6 issue in `prefix size for IPv6 geolocation` ?
We'll rephrase this to include IPv4 as well.
Why "should" rather than "must" in `In all places inetnum: is used, inet6num:
should also be assumed` ?
We'll change this to "must".
### Section 3
s/using Carrier-Grade NAT (CGN) [RFC6598]/using Carrier-Grade NAT (CGN)
[RFC6598] *or proxies*/
Will fix.
### 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 ?
Empty has the same meaning as '1' for the third field. We'll clarify this.
### 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.
We'll add a general statement that all statements about CGN in this
document also apply 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).
We'll add this to Section 3 as well.
### Section 3.4
This section (longest prefix) must appear before section 3.3 as section 3.3
example uses longest prefix match.
Will change.
### 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` ?
We'll change the first SHOULD to MUST.
For the second one I think there might be valid reasons for consumer
implementations to take the second entry instead of the first one, e.g.,
if it is clear that the first entry is erroneous due to a fat finger
mistake.
Please define `significant horizontal scale` or use other terms.
We'll rephrase this.
`This document also suggests an optional signature` should probably be in the
introduction section.
It already is, see the last sentence 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.
It is unclear if `prefixlen:` or `extref:` will be adopted by all RIRs.
Therefore, this I-D specifies how prefixlen files can be discovered in
WHOIS using the three mentioned attributes.
### 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.
We deem it relevant as this influences how consumers find prefixlen data.
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.
This is implicitly done as the signature won'T be valid for address
ranges outside the address range.
@Russ can you confirm this?
### 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.` ?
@Russ I defer to you on this one.
### 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"?
We'd like to keep this in Section 7 to avoid the introduction section
becoming bloated.
Isn't the last paragraph implicit by the normal use of HTTP (and associated
CDN/proxies)?
We'd like to keep this in there as not all implementors will be reading
the respective HTTP, CDN, proxy specifications.
### Section 8
s/At the time of publishing this document/In November 2025/
Will change. Btw, the prefixlen: attribute has since been implemented by
the RIPE NCC: https://docs.db.ripe.net/all-docs-combined. We'll update
the text to reflect that.
`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 :-(
These are not real choices but rather differences in naming of objects
and attributes between the RIR databases.
## 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.
Will fix.
### e.g.
s/ e.g./, e.g.,/
s/i.e./, i.e.,/
Will fix.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
