Hi Job,
On 24 Feb 2022, at 16:31, Job Snijders <job@fastly.com> wrote:
Dear Ed,
Thank you for the message. Apologies for nitpicking a bit more :-)
Not at all, thank you for reviewing the details.
In the 'inet6num' listing you reference ">= /48", did you mean to write "> /48"? (which would conceptually align with the cut-off in ipv4: "> /24")
This is intentional and as currently implemented, we do not allow geofeed on any assignments that are reasonably assumed to be related to one individual user. From the Legal analysis in November: "In order to be on the safe side, we suggest to allow the geofeed attribute to registrations as follows: - For inetnum objects, equal or larger than the minimum allocation by the RIPE NCC, i.e. equal or larger than /24 - For inet6num objects larger than the minimum recommended assignment to end customer CPE devices, i.e. larger than /48 (please see here - https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio... - “Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose”) " i.e. for inetnum do *not* allow geofeed on assignments smaller than /24 (given the minimum allocation size), and for inet6num do *not* allow on (more specific, not top-level) assignments equal to or smaller than /48. Regards Ed Shryane RIPE NCC
Kind regards,
Job