Hi Adrian,
Thanks for your constructive review! Comments/questions inline.
On 10/6/25 12:05 PM, Adrian Farrel via Datatracker wrote:
Document: draft-ietf-opsawg-prefix-lengths
Title: Publishing End-Site Prefix Lengths
Reviewer: Adrian Farrel
Review result: Has Nits
Reviewer: Adrian Farrel
Review result: Ready with nits
Hello,
I have reviewed this document as part of the Operational
Directorate's ongoing effort to review all IETF documents being
processed by the IESG.
These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the
IESG review. Document editors and WG chairs should treat these
comments just like any other last call comments.
Regards,
Adrian
===
Reviewer: Adrian Farrel
Draft reviewed: draft-ietf-opsawg-prefix-lengths-07.txt
Review Result: Ready with nites
This document describes an augmentation to the inetnum: file
format to indicate prefix lengths.
This document is easily readable and ready for publication modulo a few
minor points and nits that could be usefully cleared up.
= Manageability =
Thank you for including Section 7 to give the operational
considerations. This made my job much easier. I see no other
manageability considerations that need to be covered.
= Minor =
I think you have backward compatiblity covered in Section 4, but it
takes some working out. The cases to cover are:
- How will legacy implementations react on encountering the additional
inetnum fields?
- Will a new implementation correctly parse a legacy prefixlen file?
This draft specifies prefixlen files for the first time, so there are no
legacy prefixlen files. Can you clarify what you mean by "legacy
prefixlen file"?
Might it be worth calling this out in a separate section for clarity?
---
Section 3 specifies some clear rules for how prefixlen files must be
formed. But I did not find an explanation of what to do if a malformed
entry line or file is found. This may be something that can be explained
by reference to a previous document.
Added clarification in Section 3 that erroneous entries should be skipped.
---
Section 3.5
Duplicate prefix entries MUST be considered an error
Is it necessary to expand on the definitin of "duplicate"?
Initially it appears that "duplicate" applies to "entry" such that an
example would be:
2001:db8::/32,56,1
2001:db8::/32,56,1
But, (obviously?) you mean lines that refer to the same prefix, but
might be otherwise different. That is not just:
2001:db8::/32,56,1
2001:db8::/32,56,1 # Ooops, a duplicate
... but also:
2001:db8::/32,56,1
2001:db8::/32,56,2
... and:
2001:db8::/32,56,1
2001:db8::/32,64,1
All of the above are considered duplicate prefix entries. We'll clarify
this in the text.
Further, I suspect you mean to consider overlapping prefixes?
If by overlapping you mean sub- and super-prefixes, these are not
considered duplicate prefix entries. This scenario is already covered in
Section 3.4. We'll add additional text to make this clear.
---
Section 4
You have...
In addition to publishing the location of prefixlen files in WHOIS
with the prefixlen: or remarks: approaches, there is currently a
proposal being discussed to introduce a new RPSL attribute of type
extref: for generic external references
[I-D.ymbk-opsawg-rpsl-extref]. With this extref approach a prefixlen
can be referenced as follows:
inetnum: 192.0.2.0/24 # example
extref: Prefixlen https://example.com/prefixlen
I'm sure draft-ymbk-opsawg-rpsl-extref is a worthy document. But I think
the text here makes it into a normative reference, which would be
unfortunate for the rapid progress of this document.
Probably you could leave out this paragraph. Alternatively reduce it to
something like:
An aproach to introduce a new RPSL attribute of type extref: for
generic external references is described in [I-D.ymbk-opsawg-rpsl-
extref].
Updated paragraph with your proposed text. Do you suggest to also remove
the specification of how prefixlen references are used for extref? I.e.:
inetnum: 192.0.2.0/24 # example
extref: Prefixlen https://example.com/prefixlen
= Nits =
I think the Abstract assumes I should know what a "prefixlen data file"
is. Perhaps I should!
Looking ahead to Seciton 3, I find a detailed definition, which is good.
But there it has:
prefixlen files are CSV (Comma Separated Values) files in UTF-8
[RFC3629] text format; not HTML, richtext, or other formats.
So, it appears that all prefixlen files are CSV files. In that case, the
Abstract is ambiguous or tautological when it says:
prefixlen comma-separated values (CSV) data files
Please have a think about the Abstract and whether it needs cleaning.
We'll update the abstract for clarity.
---
<pedant alert>
Section 1
Therefore, there are countless variations of
different end-site prefix length present in the Internet
Are they countless? I mean, there are only 128 different prefix lengths
available.
Maybe "very many"?
Will fix.
---
Section 1
[I-D.ietf-opsec-ipv6-addressing] recently also raised this issue.
Maybe future-proof the text as:
[I-D.ietf-opsec-ipv6-addressing] also raises this issue.
Will fix.
---
Section 1
* Geolocation: Getting the right prefix size for IPv6 geolocation is
similarly hard. If you aggregate too little, you throw together
different clients in different locations, and if you aggregate too
much, you fill up the geolocation database with unnecessary
entries.
Is this back-to-front? That is, too much aggregation throws together
addresses from different locations, while too little aggregation fills
the geolocation table?
Good catch!
---
3.2
CGN end sites would is specified as follows:
s/is/be/
Will fix.
---
The plural of inetnum: as inetnum:s is ugly!
Maybe s/inetnum:s/inetnum: instances/
Will fix.
---
7.
Harvesting and publishing aggregated prefixlen data outside of the
RPSL model should be avoided as it can have the effect that more
specifics from one aggregatee could undesirably affect the less
specifics of a different aggregatee.
Is that "SHOULD BE"?
Will fix.
Cheers,
Oliver
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
