[db-wg] geofeed issue: can't add geofeed attribute to PI /48
- Previous message (by thread): [db-wg] geofeed issue: can't add geofeed attribute to PI /48
- Next message (by thread): [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Edward Shryane
eshryane at ripe.net
Thu Feb 24 18:21:55 CET 2022
Hi Jeroen, > On 24 Feb 2022, at 16:50, Jeroen Massar <jeroen at massar.ch> wrote: > >> On 20220224, at 16:48, Edward Shryane via db-wg <db-wg at ripe.net> wrote: >> >> ... >> 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. > > But one could have a /48 with linknets or even delegations of /56 that go to several separate users in the same city. > > At which point, pointing to the city is well, needed, and cannot currently be done. > Can you use the inet6num status AGGREGATED-BY-LIR to document this? AGGREGATED-BY-LIR – With IPv6, it is not necessary to document each individual End User assignment in the RIPE Database. If you have a group of End Users who all require blocks of addresses of the same size, say a /56, then you can create a large, single block with this status. The “assignment-size:” attribute specifies the size of the End User blocks. All assignments made from this block must have that size. It is possible to have two levels of ‘AGGREGATED-BY-LIR'. We need to satisfy the Legal review to not allow geofeed on a prefix reasonably assumed to be related to one individual user, by not allowing it on ASSIGNED PA or ASSIGNED PI (not assigned by the RIPE NCC). AGGREGATED-BY-LIR is meant for an aggregation of end user assignments and we can allow geofeed on it. Regards Ed
- Previous message (by thread): [db-wg] geofeed issue: can't add geofeed attribute to PI /48
- Next message (by thread): [db-wg] geofeed issue: can't add geofeed attribute to PI /48
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]