On Thu, Feb 24, 2022 at 04:48:57PM +0100, Edward Shryane wrote:
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.
Ah, right. I guess my question was what classes of space *under the newly proposed validation rules* (still) would not be eligible. :-) Apologies for presenting my question in a perhaps somewhat confusing way. My goal is to get an overview of the 'inverse' of what followed from this message: https://www.ripe.net/ripe/mail/archives/db-wg/2022-February/007271.html You wrote "Accordingly, we will allow geofeed: <snip>"; which prompted me to ask what classes would not be allowed. Kind regards, Job