Hi Michael,
On 10/15/25 4:53 PM, Michael Richardson wrote:
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.
We'll add that example to the draft.
>> " 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.
How about the following change?
OLD:
Note that this specification can be applied to IPv4 as well as IPv6
networks.
NEW:
Note that this specification can be applied to IPv6 networks as
well.
>>> 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.
Yep, we'll remove that.
--
] 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
Cheers,
Oliver
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
