To: opsawg@ietf.org, opsawg-chairs@ietf.org, rtg-dir@ietf.org,
Subject: rtg-area review of draft-ietf-opsawg-prefix-lengths-07

Hello

I have been selected to do a routing directorate review of this draft.
​https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths

Document: draft-ietf-opsawg-prefix-lengths
Reviewer: Michael Richardson
Review Date: 2025-10-10
Intended Status: standards track

Summary:

This document is basically ready for publication, but has nits that should be considered prior to being submitted to the IESG.

Comments:

1. I think that point 1 of introduction"
"*  Blocklisting/throttling: In IPv4, IP addresses can be blocked..."
should, when mentioning blocking at too-fine a level mention temporary v6
addresses.

2. "If on the other hand these 4000 CGN end-sites are"...
I suggest that this sentence start a 3.2.1 section that can more easily be
referenced when explaining to ISPs how they got something wrong.

"  Note that this specification can be applied to IPv4 as well as IPv6
   networks.
"

This reads weirdly; I would have thought the point was that if someone was
doing NPT6 or something that they could also use it.  It's not just for v4.

Maybe:
   prefixlen remarks: attribute MUST be as in this example, "remarks:
   Prefixlen ", where the token "prefixlen" MUST be case-sensitive,

should be:
   prefixlen remarks: attribute MUST be as in this example, "remarks:
   Prefixlen ", where the token "Prefixlen" MUST be case-sensitive,

?? if it's case-sensitive?

Can there be prefixlen: attribute and "remarks: Prefixlen"? entries, and
extref: entries?  If so, should the consumer prioritize them in anyway?
Or process them all?  What if they conflict?

" If there is more than one type of attribute in the inetnum: object,
  the prefixlen: or extref: attributes MUST be used."

okay, so remarks is last in the priority, what if both extref: and prefixlen:
exist?

We went down this with RFC9632.  Would an informational reference help here?
"This document adopts the same incremental deployment process as was done for
geofeed data in [RFC9632]"  ?

Section 5 about WHOIS data suggests FTP over WHOIS.
Given that there are ~5 RIRs, I guess the choice of FTP,WHOIS,RDAP can be
made by a human.

Is a canonicalization process really important for the signature?
Why not just CMS-detached-sign whatever the series of bytes present is?
I guess that this is identical to RFC9632, and I suggest noting that.
I see that an eContentType is allocated, which is good.
It should be mentioned in section 6, paragraph 6, along with the rest of the
details.

>   The signing certificate MUST NOT include the Autonomous System
>   Identifier Delegation certificate extension [RFC3779].  If it is
>   present, the authenticator is invalid.

I think the point here is not to use your RPLI certificate to sign?

>   The Certification Authority (CA) SHOULD sign only one prefixlen file
>   with each generated private key and SHOULD generate a new key pair

But, CAs do not sign prefixlen files.  They sign EEs that sign them, right?

>   Identifying the private key associated with the certificate and
>   getting the department that controls the private key (which might be
>   stored in a Hardware Security Module (HSM)) to generate the CMS
>   signature is left as an exercise for the implementor.

This adds nothing, and just confuses.  Remove it.
The amount of detail about the verification process seems excessive.
Is it needed, as it all just seems like normal CMS stuff.

I didn't see any obvious nits.