IETF Last Call Review of draft-ietf-opsawg-prefix-lengths-07
review-ietf-opsawg-prefix-lengths-07-opsdir-lc-farrel-2025-10-06-00

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?

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.

---

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

Further, I suspect you mean to consider overlapping prefixes?

---

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].

= 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.

---

<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"?

---

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.

---

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?

---

3.2

   CGN end sites would is specified as follows:

s/is/be/

---

The plural of inetnum: as inetnum:s is ugly!
Maybe s/inetnum:s/inetnum: instances/

---

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"?