Hi Michael,
Thanks for your constructive review! Comments/questions inline.
On 10/10/25 10:01 PM, Michael Richardson wrote:
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.
Can you elaborate how temporary v6 addresses affect this?
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.
This is just another example and therefore still falls under the
"End-site prefix length with CGN or proxies" section. We'll start a new
paragraph for this sentence to make that clear.
" 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.
That's exactly what this statement is saying: prefixlen files can be
used to signal end-site prefix sizes for IPv4 and also end-site prefix
sizes for IPv4. This is also true for the CGN scenario, which is more
prevalent in IPv4 than IPv6. Do you think it's less confusing if we
remove that sentence entirely?
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?
Good catch, will fix.
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?
In that case consumer MUST prioritize prefixlen:. We'll clarify this in
the document: prefixlen > extref > remarks
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?
It's not like HTTPS has the TXT/BIN issue that FTP had.
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 RPKI 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'll let Russ chime in on all the signature-related comments above.
I didn't see any obvious nits.
Cheers,
Oliver
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
