Oliver Gasser <[email protected]> wrote: > 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?
If someone blocks too-fine, and the host is using temporary/privacy v6
addresses, then the /128 block will not work. v4-shutins won't understand
this. Make it explicit is what I'm saying.
Some v6 examples would be good too.
>> 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.
Thank you.
I think it will be a common "You got this wrong" pointer.
>> " 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?
All the examples are IPv4.
So telling me that it works for v4 seems redundant, and makes me wonder if
there is something I missed.
>> 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
Thank you.
>>> 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.
Russ agrees with removing this detail.
The detail here makes me (and maybe others) think that there is something
different here, and there isn't.
--
] 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
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
