geofeed issue: can't add geofeed attribute to PI /48
Dear all, Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle: https://sobornost.net/~job/geofeed.png """Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed.""" No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward. How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process? Kind regards, Job
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
drumroll! and the best path forward is? :) my non-ecc memory is that this is ncc legal trying not to get highly specific. i.e. it is not a wg matter. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Hi Randy, On Mon, 3 Jan 2022 at 18:19, Randy Bush via db-wg <db-wg@ripe.net> wrote:
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
drumroll! and the best path forward is? :)
My personal preference would be for the restriction to be lifted. I’m sceptical the restriction is achieving its intended purpose, and at the same time it seems to be hindering Geofeed deployment. my non-ecc memory is that this is ncc legal trying not to get highly
specific. i.e. it is not a wg matter.
To me it seems this database feature is broken: I can reference my geofeed file via one method, but not via another (nicer) method. Regardless of the cause of the dysfunctionality, I think the Database Working Group is the appropriate forum to discuss the problem of being unable to use the geofeed RPSL attribute in database objects. Kind regards, Job
mornin' job
Regardless of the cause of the dysfunctionality, I think the Database Working Group is the appropriate forum to discuss the problem of being unable to use the geofeed RPSL attribute in database objects.
my point is that i think the wg already did. ncc legal, in post-wg review, added this restriction. i.e. we have run the process already. i really like the ncc legal folk, so would be happy to join you in a zoom or two to explore the issues with them. but this is not a hill on which i am inclined to shed blood. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
On 03/01/2022 12:36, Job Snijders via db-wg wrote:
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
1. Feature parity should be enforced if the intention is to transition toward using the geofeed attribute over 'remarks: Geofeed', for certain. The last thing you need in this situation is for the old/bodge mechanism to be more featureful than the purpose-designed mechanism. 2. Should an individual assignee of a /48 determine that their privacy is indeed sacrosanct, then surely it is their decision (as the publisher of their own geofeed.csv file) to determine the level of location granularity that they are comfortable with? 'UK,,,' tells you nothing about me that you couldn't already infer from the headers from this email, and some data from the NLNOG ring. I don't doubt that good guidance for ISPs that are populating this information will be important, particularly for /56s, /64s or smaller. However, it would fall squarely within the guidelines that already exist for Data Protection in their own territory. -- Tom
On 2022 Jan 03 (Mon) at 12:36:49 +0000 (+0000), Job Snijders via db-wg wrote: :Dear all, : :Like all good netizens, I tried to align information I publish in the :RIPE database to reality, but there is an obstacle: : : https://sobornost.net/~job/geofeed.png : : """Adding or modifying the "geofeed:" attribute of an object with a : prefix length greater or equal to 48 is not allowed.""" : :No such restriction exists if you use the 'remarks: Geofeed' approach, :as demonstrated here: : : $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed : remarks: Geofeed https://sobornost.net/geofeed.csv : :I appreciate concerns about privacy, but I'm not wholly convinced :restricting /48s from having a proper 'geofeed:' attribute is the best :path forward. : :How does the working group feel about this restriction? Is it useful? :Should it be lifted? If the latter, what would be the process? : :Kind regards, : :Job I think that this restriction is silly. This /48 was assigned by RIPE NCC, there is no parent that you can add the geofeed to. I think the restriction in general should be lifted, but if a restriction *should* exist, then it should always be allowed for the smallest of the "assigned by RIPE NCC" / "allocated by RIPE NCC" sizes, even if that is a smaller size than what was issued by RIPE NCC. (e.g., in IPv6 you could always add the geofeed: attribute to a /48, even if it is inside an allocated /29). -- The reason computer chips are so small is computers don't eat much.
This seems weird, I would assume it should be greater than 48, not greater than or equal to 48. Ed, can you confirm if this is intended or not? Also I agree with Peter Hessler, you should always be able to add a geofeed attribute to all blocks assigned/allocated by the NCC. And to not make it a massive mess, if there is going to be a limit make it "not *greater than* 48" for v6 and "not *greater than* 24" for IPv4. If for some legal reason this is not an option, then I think an exception needs to be made for the top level resource allocated/assigned to the LIR/end user. -Cynthia On Mon, Jan 3, 2022 at 1:46 PM Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear all,
Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle:
https://sobornost.net/~job/geofeed.png
"""Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed."""
No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here:
$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Cynthia,
On 3 Jan 2022, at 19:44, Cynthia Revström <me@cynthia.re> wrote:
This seems weird, I would assume it should be greater than 48, not greater than or equal to 48.
Ed, can you confirm if this is intended or not?
We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed). We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user. The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio... Regards Ed
Hi all If people want to add geofeed for smaller sizes this runs the risk of maintaining a dual system, "geofeed:" and "remarks: geofeed". We could end up with "remarks:" values being parsed as they used to be for abuse contacts before we added "abuse-c:". My understanding was that a "geofeed:" could be added to a smaller prefix and in the referenced url add data for any prefix you wish, including a /48. Just for reference, for those of you who use the "geofeed:" attribute, how many want to add data for a /48? Is this a wide scale issue or a corner case? cheers denis co-chair DB-WG On Tue, 4 Jan 2022 at 10:00, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Cynthia,
On 3 Jan 2022, at 19:44, Cynthia Revström <me@cynthia.re> wrote:
This seems weird, I would assume it should be greater than 48, not greater than or equal to 48.
Ed, can you confirm if this is intended or not?
We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed).
We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user.
The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio...
Regards Ed
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
On Tue, Jan 04, 2022 at 10:28:04AM +0100, denis walker via db-wg wrote:
If people want to add geofeed for smaller sizes this runs the risk of maintaining a dual system, "geofeed:" and "remarks: geofeed". We could end up with "remarks:" values being parsed as they used to be for abuse contacts before we added "abuse-c:".
My understanding was that a "geofeed:" could be added to a smaller prefix and in the referenced url add data for any prefix you wish, including a /48.
Just for reference, for those of you who use the "geofeed:" attribute, how many want to add data for a /48? Is this a wide scale issue or a corner case?
Seems all /48 PI assignments are affected. That's a couple of tens of thousands? Kind regards, Job
On 2022 Jan 04 (Tue) at 10:28:04 +0100 (+0100), denis walker via db-wg wrote: :Hi all : :If people want to add geofeed for smaller sizes this runs the risk of :maintaining a dual system, "geofeed:" and "remarks: geofeed". We could :end up with "remarks:" values being parsed as they used to be for :abuse contacts before we added "abuse-c:". : :My understanding was that a "geofeed:" could be added to a smaller :prefix and in the referenced url add data for any prefix you wish, :including a /48. : :Just for reference, for those of you who use the "geofeed:" attribute, :how many want to add data for a /48? Is this a wide scale issue or a :corner case? : I have several /48 PI allocations, and would like to add geofeed attributes to them. Since they are not children of a larger allocation I control, I currently cannot add a geofeed attribute to them. Additionally, a /48 is the smallest acceptable size in the DFZ and I can easily see people wanting to list geofeeds for those announcements. :cheers :denis :co-chair DB-WG : :On Tue, 4 Jan 2022 at 10:00, Edward Shryane via db-wg <db-wg@ripe.net> wrote: :> :> Hi Cynthia, :> :> > On 3 Jan 2022, at 19:44, Cynthia Revström <me@cynthia.re> wrote: :> > :> > This seems weird, I would assume it should be greater than 48, not :> > greater than or equal to 48. :> > :> > Ed, can you confirm if this is intended or not? :> > :> :> We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed). :> :> We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user. :> :> The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio... :> :> Regards :> Ed :> :> :> -- :> :> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg : :-- : :To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- Cleaning your house while your kids are still growing is like shoveling the walk before it stops snowing. -- Phyllis Diller
Hi Peter Just out of interest, in terms of privacy and identifying individuals, is a /48 PI any different to a /48 PA assignment? Is PI used more for business than by individuals perhaps? cheers denis co-chair DB-WG On Tue, 4 Jan 2022 at 10:39, Peter Hessler via db-wg <db-wg@ripe.net> wrote:
On 2022 Jan 04 (Tue) at 10:28:04 +0100 (+0100), denis walker via db-wg wrote: :Hi all : :If people want to add geofeed for smaller sizes this runs the risk of :maintaining a dual system, "geofeed:" and "remarks: geofeed". We could :end up with "remarks:" values being parsed as they used to be for :abuse contacts before we added "abuse-c:". : :My understanding was that a "geofeed:" could be added to a smaller :prefix and in the referenced url add data for any prefix you wish, :including a /48. : :Just for reference, for those of you who use the "geofeed:" attribute, :how many want to add data for a /48? Is this a wide scale issue or a :corner case? :
I have several /48 PI allocations, and would like to add geofeed attributes to them. Since they are not children of a larger allocation I control, I currently cannot add a geofeed attribute to them.
Additionally, a /48 is the smallest acceptable size in the DFZ and I can easily see people wanting to list geofeeds for those announcements.
:cheers :denis :co-chair DB-WG : :On Tue, 4 Jan 2022 at 10:00, Edward Shryane via db-wg <db-wg@ripe.net> wrote: :> :> Hi Cynthia, :> :> > On 3 Jan 2022, at 19:44, Cynthia Revström <me@cynthia.re> wrote: :> > :> > This seems weird, I would assume it should be greater than 48, not :> > greater than or equal to 48. :> > :> > Ed, can you confirm if this is intended or not? :> > :> :> We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed). :> :> We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user. :> :> The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio... :> :> Regards :> Ed :> :> :> -- :> :> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg : :-- : :To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
-- Cleaning your house while your kids are still growing is like shoveling the walk before it stops snowing. -- Phyllis Diller
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
I'm not 100% certain about the usage patterns, but in my case the PI spaces are not identifying individual users and the resolution is not more specific than metro/city. On 2022 Jan 04 (Tue) at 11:59:12 +0100 (+0100), denis walker wrote: :Hi Peter : :Just out of interest, in terms of privacy and identifying individuals, :is a /48 PI any different to a /48 PA assignment? Is PI used more for :business than by individuals perhaps? : :cheers :denis :co-chair DB-WG : :On Tue, 4 Jan 2022 at 10:39, Peter Hessler via db-wg <db-wg@ripe.net> wrote: :> :> On 2022 Jan 04 (Tue) at 10:28:04 +0100 (+0100), denis walker via db-wg wrote: :> :Hi all :> : :> :If people want to add geofeed for smaller sizes this runs the risk of :> :maintaining a dual system, "geofeed:" and "remarks: geofeed". We could :> :end up with "remarks:" values being parsed as they used to be for :> :abuse contacts before we added "abuse-c:". :> : :> :My understanding was that a "geofeed:" could be added to a smaller :> :prefix and in the referenced url add data for any prefix you wish, :> :including a /48. :> : :> :Just for reference, for those of you who use the "geofeed:" attribute, :> :how many want to add data for a /48? Is this a wide scale issue or a :> :corner case? :> : :> :> I have several /48 PI allocations, and would like to add geofeed :> attributes to them. Since they are not children of a larger allocation :> I control, I currently cannot add a geofeed attribute to them. :> :> Additionally, a /48 is the smallest acceptable size in the DFZ and I can :> easily see people wanting to list geofeeds for those announcements. :> :> :> :cheers :> :denis :> :co-chair DB-WG :> : :> :On Tue, 4 Jan 2022 at 10:00, Edward Shryane via db-wg <db-wg@ripe.net> wrote: :> :> :> :> Hi Cynthia, :> :> :> :> > On 3 Jan 2022, at 19:44, Cynthia Revström <me@cynthia.re> wrote: :> :> > :> :> > This seems weird, I would assume it should be greater than 48, not :> :> > greater than or equal to 48. :> :> > :> :> > Ed, can you confirm if this is intended or not? :> :> > :> :> :> :> We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed). :> :> :> :> We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user. :> :> :> :> The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio... :> :> :> :> Regards :> :> Ed :> :> :> :> :> :> -- :> :> :> :> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg :> : :> :-- :> : :> :To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg :> :> -- :> Cleaning your house while your kids are still growing is like :> shoveling the walk before it stops snowing. :> -- Phyllis Diller :> :> -- :> :> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- It is easier for a camel to pass through the eye of a needle if it is lightly greased. -- Kehlog Albran, "The Profit"
[ i wanted to write to you off-list, but illegal header mangling by the list software prevented it. ]
The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio...
i suspect some confusion caused by the term "end user." i do not expect there are many assignments of /48s to individual human beings. i suspect that what was meant by end "user was" more in the realm of a PoP, or head end, or ... end users in the PII sense tend to be given /56../64 randy
+1 This seems like legal might have forgotten that end user could mean a legal entity (and probably does in far more cases than not). Also I don't get why the geofeed attribute would not be acceptable, when you can add an admin-c attribute with the individual end-users name, address, and phone number. It kinda seems like the geofeed attribute should be one of the least problematic things in the RIPE DB from a PII perspective. Especially when you consider things like how the NCC is just publishing a URL and how a /47 could have a geofeed attribute containing details for individual /48s (or even more specific prefixes). Could someone direct me to what NCC legal's reasoning behind this was? (if it was published) While I would assume they know lots about this as they work at the NCC, I just don't understand the logic and it feels like maybe there was a misunderstanding somewhere. I feel like I am both a bad and good example as I do have a /48 PI that is registered to me as a person, which is kinda what I am trying to say is not common... However a geofeed attribute is nothing compared to the fact that my legal name, address, email address, and phone number are published in the RIPE DB in order for me to have that PI resource. So with regards to PI resources at least, not being able to do Geofeed for /48 makes absolutely no sense to me, in what does it matter if I publish which city I am in if my address is already published. I think this would be the case for all PI resources as they are not to be further assigned to customers and I do think that the address is required according to some policy if I recall correctly. -Cynthia On Tue, Jan 4, 2022 at 7:18 PM Randy Bush via db-wg <db-wg@ripe.net> wrote:
[ i wanted to write to you off-list, but illegal header mangling by the list software prevented it. ]
The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio...
i suspect some confusion caused by the term "end user." i do not expect there are many assignments of /48s to individual human beings. i suspect that what was meant by end "user was" more in the realm of a PoP, or head end, or ...
end users in the PII sense tend to be given /56../64
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi, On Tue, Jan 04, 2022 at 10:00:54AM +0100, Edward Shryane via db-wg wrote:
We currently only allow "geofeed:" to be added to IPv6 prefixes *smaller* than /48, the message is consistent (i.e. greater than or equal to /48 is *not* allowed).
We are following Legal's recommendation not to allow geofeed to be added for assignments that are reasonably assumed to be related to one individual user.
The IPv6 address policy clearly states that it's up to the ISP what size they want to assign to end users (up to a maximum of /48 per end user site, or something). So an ISP registering a /48 as AGGREGATED-BY-LIR and assigning /56s out of that would be fully compliant with the existing policy, and the NCC should not meddle with their intent to register that block any way they want. Please tell Legal to re-read the existing IPv6 policies and re-think their opinion on what can be "reasonably assumed to be related to one individual user", based on actual policy text. Maybe speak with one or two large operators on existing deployments.
The /48 prefix size is the maximum size suggested in the "BCOP for Operators: IPv6 prefix assignment for end-users": https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-optio...
The /48 size in the BCOP is a recommendation, but *policy* gives the ISPs leeway to assign whatever they find suitable. Typically, this has been /56 in many large eyeball provides, for a long time now - and /48s for "business customers". Gert Doering -- somewhat involved with policy and IPv6 -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Job, Colleagues,
On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg@ripe.net> wrote:
... I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
I will ask our Legal team to re-examine the prefix size restriction and keep you and the DB-WG informed. Regards Ed Shryane RIPE NCC
Hi Job, Colleagues, Firstly, apologies for the delay in finding a solution to the /48 restriction on the geofeed implementation. Our Legal team have considered the concerns from a part of the community regarding the eligible size for “geofeed:” validation and concluded the following: Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation. Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6). We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency. Please let us know what you think. We would like to implement these changes soon and include them in a new Whois release 1.103. Regards Ed Shryane RIPE NCC
On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear all,
Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle:
https://sobornost.net/~job/geofeed.png
"""Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed."""
No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here:
$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Ed, Thanks for the work done. On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency.
I think you should not enforce anything on remarks. For what I know, remarks have been a free text field up to now. In my view: (1) RIPE NCC promotes the "geofeed" field for the geofeed purpose, instead, using "remarks" it is not the practice suggested by RIPE NCC and so I don't believe it is RIPE NCC's responsibility; (2) Users can always encode the same information in remarks without geofeed (which would just increase the mess and bypass the check); (3) starting to validate the content of remarks creates a precedent in which RIPE NCC is responsible for checking remarks content (possibly, in the future, not only about geofeeds). But I don't know anything about legal things, so this is just my point of view. Ciao, Massimo
Please let us know what you think. We would like to implement these changes soon and include them in a new Whois release 1.103.
Regards Ed Shryane RIPE NCC
On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear all,
Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle:
https://sobornost.net/~job/geofeed.png
"""Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed."""
No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here:
$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Massimo,
On 21 Feb 2022, at 16:29, Massimo Candela via db-wg <db-wg@ripe.net> wrote:
Hi Ed,
Thanks for the work done.
Thank you!
On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency.
I think you should not enforce anything on remarks. For what I know, remarks have been a free text field up to now.
I agree! In general, Whois doesn't attempt to validate free-text fields, since they can contain anything, in any format. However, the RFC draft that we base the implementation on, allows for a "remarks: geofeed <url>" as an alternative to a "geofeed:" attribute: Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document defines the syntax of a Geofeed remarks: attribute which contains an HTTPS URL of a geofeed file. The format MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary. (Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
In my view: (1) RIPE NCC promotes the "geofeed" field for the geofeed purpose, instead, using "remarks" it is not the practice suggested by RIPE NCC and so I don't believe it is RIPE NCC's responsibility;
The DB team have implemented the draft RFC to standardise "geofeed:", but "remarks:" is defined as the alternative. As "remarks:" can be used as an alternative to "geofeed:", if we don't also validate "remarks:" it can be used to bypass any validation done on "geofeed:". The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text). If the two constructions are considered equivalent by clients, any unequal validation on "geofeed:" will be a disincentive to replace "remarks:", and we will be left with both indefinitely.
(2) Users can always encode the same information in remarks without geofeed (which would just increase the mess and bypass the check);
Correct, I am proposing that we validate both equally to avoid this (we don't want an incentive for "remarks:").
(3) starting to validate the content of remarks creates a precedent in which RIPE NCC is responsible for checking remarks content (possibly, in the future, not only about geofeeds).
Correct, it's already possible to write anything in "remarks:", however if we don't validate we're giving an incentive to keep using "remarks:" for geofeed.
But I don't know anything about legal things, so this is just my point of view.
I am open to suggestions on how to resolve this. For example, instead of validating "remarks: geofeed", can this construction be deprecated (removed) in favour of "geofeed:" ? Not doing any validation is not an option given the Legal review. Regards Ed Shryane RIPE NCC
Ciao, Massimo
On Tue, Feb 22, 2022 at 09:54:24AM +0100, Edward Shryane via db-wg wrote:
Not doing any validation is not an option given the Legal review.
Why not? Kind regards, Job
Hi Job, Colleagues,
On 22 Feb 2022, at 10:01, Job Snijders <job@sobornost.net> wrote:
On Tue, Feb 22, 2022 at 09:54:24AM +0100, Edward Shryane via db-wg wrote:
Not doing any validation is not an option given the Legal review.
Why not?
Kind regards,
Job
To be clear, the Legal review looked at the "geofeed:" attribute alone, and did not consider "remarks:". There is no requirement to validate "remarks:". Given this, and thanks to your feedback, I will drop my suggestion to validate "remarks:", and update the impact analysis for "geofeed:" only. Regards Ed Shryane RIPE NCC
On 22/02/2022 13:33, Edward Shryane wrote:
To be clear, the Legal review looked at the "geofeed:" attribute alone, and did not consider "remarks:". There is no requirement to validate "remarks:".
Given this, and thanks to your feedback, I will drop my suggestion to validate "remarks:", and update the impact analysis for "geofeed:" only.
Good! Thanks Ed! Ciao, Massimo
Hi Ed, On 22/02/2022 09:54, Edward Shryane wrote:
(Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
I remember that :)
The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text).
The RFC defines a structure for the user to insert their entries, and for the readers to parse those entries. But it does not say that the RIR should start validating remarks, and no other RIR is doing that. What was defined in NWI-13 was defined for the new "geofeed" attribute, not for remarks. By using remarks, the rfc promotes a self-organized approach to use current geofeed technology in current whois technology, it doesn't introduce nothing new in the logic of remarks.
(2) Users can always encode the same information in remarks without geofeed (which would just increase the mess and bypass the check);
Correct, I am proposing that we validate both equally to avoid this (we don't want an incentive for "remarks:").
What I meant is that, you can enforce a regex "geofeed URL" in remarks as much as you like, but as soon as users realize that, they can bypass that with another syntax. What it take it's just one big geolocation provider to suggest an alternative syntax. When things get too complicated, users find ways around it, making the problem worse.
Correct, it's already possible to write anything in "remarks:", however if we don't validate we're giving an incentive to keep using "remarks:" for geofeed I am open to suggestions on how to resolve this. For example, instead of validating "remarks: geofeed", can this construction be deprecated (removed) in favour of "geofeed:" ?
At the moment RIPE NCC is the only one having a specific field for "geofeed", so I would not drop the support for "remarks". It is also the only one validating "remarks". Honestly, for how it is getting complicated, I am more in favor of dropping "geofeed" and go back to remarks. Ciao, Massimo
Hi Ed On Tue, 22 Feb 2022 at 09:54, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Massimo,
On 21 Feb 2022, at 16:29, Massimo Candela via db-wg <db-wg@ripe.net> wrote:
Hi Ed,
Thanks for the work done.
Thank you!
On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency.
I think you should not enforce anything on remarks. For what I know, remarks have been a free text field up to now.
I agree! In general, Whois doesn't attempt to validate free-text fields, since they can contain anything, in any format.
However, the RFC draft that we base the implementation on, allows for a "remarks: geofeed <url>" as an alternative to a "geofeed:" attribute:
Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document defines the syntax of a Geofeed remarks: attribute which contains an HTTPS URL of a geofeed file. The format MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary.
(Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
Just a point on the RFC. As I have said in many discussions recently, wording is important. The RFC says "Until such time...". We have a "geofeed:" attribute now so we are past 'such time'. We should no longer even consider, or support, "remarks:'' as an option for geofeed. (Maybe after a defined transition period of time.) We have a precedent for this with abuse contacts. People used to put them in "remarks:" until we introduced "abuse-c:". Now we advise people to use "abuse-c:" and not put abuse contact details in "remarks:". We should give the same advice for "geofeed:". Of course some people still put abuse details in "remarks:" as well, and they may continue to do so with "geofeed:". It has a free text format so people can put whatever they like there and the DB software should not try to parse it in any way. cheers denis co-chair DB-WG
The RFC says "Until such time...". We have a "geofeed:" attribute now so we are past 'such time'. We should no longer even consider, or support, "remarks:'' as an option for geofeed.
you have the wrong end of the horse. it is the seeker/fetcher of geofeed data who decides whether they look inside remarks: and/or geofeed: attributes. repeat ten times: "remarks are opaque and their interpretation is only in the eye of the beholder." [0] randy 0 - an american legal joke about pornography. quoting bloomberg In a 1964 decision, U.S. Supreme Court Justice Potter Stewart said he would not attempt to define hard-core pornography, and “perhaps I could never succeed in intelligibly doing so.” He famously added, “But I know it when I see it.” --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Hi Ed Can you clarify this comment...
Our Legal team have considered the concerns from a part of the community regarding the eligible size for “geofeed:” validation and concluded the following: Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation.
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
Are you saying you will ONLY allow geofeed on resources with these status values? What about SUB-ALLOCATED PA and AGGREGATED-BY-LIR? The nature of these status values suggests they are not personal data. "an equal prefix size may receive the “geofeed:” validation." Or are you saying any object with a size equal to any allocation can have a "geofeed:" attribute? That would mean a /24 for IPv4. cheers denis co-chair DB-WG
Hi Denis,
On 21 Feb 2022, at 17:10, denis walker <ripedenis@gmail.com> wrote:
Hi Ed
Can you clarify this comment...
Our Legal team have considered the concerns from a part of the community regarding the eligible size for “geofeed:” validation and concluded the following: Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation.
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
Are you saying you will ONLY allow geofeed on resources with these status values? What about SUB-ALLOCATED PA and AGGREGATED-BY-LIR? The nature of these status values suggests they are not personal data.
Legal have made a distinction between the resources allocated or assigned by the RIPE NCC and resources assigned on a second level by our members or provider independent resource holders. If SUB-ALLOCATED PA and AGGREGATED-BY-LIR are not personal data (since they are used for grouping network blocks together), then we can allow "geofeed:" on them.
"an equal prefix size may receive the “geofeed:” validation." Or are you saying any object with a size equal to any allocation can have a "geofeed:" attribute? That would mean a /24 for IPv4.
The RIPE NCC are creating /24 top-level allocations, but this size could also be used as a single (second level) assignment. However, we don't have a way (yet, see NWI-4) to distinguish between an allocation and assignment of the same size. Geofeed is allowed on a top-level resource but not on a more specific assignment within that. Regards Ed Shryane RIPE NCC
cheers denis co-chair DB-WG
The RIPE NCC are creating /24 top-level allocations, but this size could also be used as a single (second level) assignment. However, we don't have a way (yet, see NWI-4) to distinguish between an allocation and assignment of the same size. Geofeed is allowed on a top-level resource but not on a more specific assignment within that.
I hope you only mean for /24 and /48 (or more specific), as in I hope I would still be able to add a geofeed attribute to for example a /32 under the /29 allocated to the LIR by the NCC. -Cynthia On Tue, Feb 22, 2022 at 10:35 AM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Denis,
On 21 Feb 2022, at 17:10, denis walker <ripedenis@gmail.com> wrote:
Hi Ed
Can you clarify this comment...
Our Legal team have considered the concerns from a part of the community regarding the eligible size for “geofeed:” validation and concluded the following: Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation.
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
Are you saying you will ONLY allow geofeed on resources with these status values? What about SUB-ALLOCATED PA and AGGREGATED-BY-LIR? The nature of these status values suggests they are not personal data.
Legal have made a distinction between the resources allocated or assigned by the RIPE NCC and resources assigned on a second level by our members or provider independent resource holders.
If SUB-ALLOCATED PA and AGGREGATED-BY-LIR are not personal data (since they are used for grouping network blocks together), then we can allow "geofeed:" on them.
"an equal prefix size may receive the “geofeed:” validation." Or are you saying any object with a size equal to any allocation can have a "geofeed:" attribute? That would mean a /24 for IPv4.
The RIPE NCC are creating /24 top-level allocations, but this size could also be used as a single (second level) assignment. However, we don't have a way (yet, see NWI-4) to distinguish between an allocation and assignment of the same size. Geofeed is allowed on a top-level resource but not on a more specific assignment within that.
Regards Ed Shryane RIPE NCC
cheers denis co-chair DB-WG
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi, On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane via db-wg wrote:
Please let us know what you think.
I think the NCC's legal team is still off a weird tangent... Prefixes assigned to legal entities (non-persons) are never PII. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear Ed, WG, Thank you for the update! On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane via db-wg wrote:
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
Perhaps a typo slipped in: I assume "on top-level" in the above sentence was meant to read "or top-level"?
We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency.
I guess imposing restrictions on the contents on "remarks:" fields serves to counter the argument "no such restriction exists for the remarks: field", offered in the initial posting [1]. In effect this means the flexibility of the "remarks:" field is being downgraded because of a dispute between db-wg@ripe.net and the RIPE NCC legal team. I don't see much benefit to that aspect of the proposed course of action. I'd like to suggest this NEW and ADDITIONAL restriction is reconsidered. Kind regards, Job [1]: https://www.ripe.net/ripe/mail/archives/db-wg/2022-January/007246.html
hi ed: one step forward, one back. in a previous life, i was a programming language hacker snd compiler writer. we used to make very strong negative review of any proposals to muck about with semantics in comment fields. just don't. randy
Hi, My opinions on this can probably be summed up with me pretty much entirely agreeing with Job, Randy, and mostly with Gert. With regards to Gert's reply I would just like to say that I think trying to decide who is and isn't a legal entity is something really complicated and last I checked the NCC didn't seem to be great at it. Some kinds of legal structures like partnerships or associations might be legal entities in some jurisdictions but not in others. I think a better argument here is that being able to create an inet(6)num object with a tech-c/admin-c that has someone's personal details in it but no ability to put a geofeed attribute in it due to the prefix size seems like an extremely weird situation. If the NCC legal team thinks this makes sense then I would love to hear how on earth they think it makes more sense to publish someone's name, address, and phone number, than to publish a URL that might contain the location of the device(s) using that IP address (which the NCC doesn't publish directly). (especially as I think people would rarely make it more specific than a city or borough) -Cynthia On Mon, Feb 21, 2022 at 9:06 PM Randy Bush via db-wg <db-wg@ripe.net> wrote:
hi ed:
one step forward, one back.
in a previous life, i was a programming language hacker snd compiler writer. we used to make very strong negative review of any proposals to muck about with semantics in comment fields. just don't.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 UNSUBSCRIBE ------- Original Message ------- On Tuesday, February 22nd, 2022 at 1:50, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
Hi,
My opinions on this can probably be summed up with me pretty much
entirely agreeing with Job, Randy, and mostly with Gert.
With regards to Gert's reply I would just like to say that I think
trying to decide who is and isn't a legal entity is something really
complicated and last I checked the NCC didn't seem to be great at it.
Some kinds of legal structures like partnerships or associations might
be legal entities in some jurisdictions but not in others.
I think a better argument here is that being able to create an
inet(6)num object with a tech-c/admin-c that has someone's personal
details in it but no ability to put a geofeed attribute in it due to
the prefix size seems like an extremely weird situation.
If the NCC legal team thinks this makes sense then I would love to
hear how on earth they think it makes more sense to publish someone's
name, address, and phone number, than to publish a URL that might
contain the location of the device(s) using that IP address (which the
NCC doesn't publish directly). (especially as I think people would
rarely make it more specific than a city or borough)
-Cynthia
On Mon, Feb 21, 2022 at 9:06 PM Randy Bush via db-wg db-wg@ripe.net wrote:
hi ed:
one step forward, one back.
in a previous life, i was a programming language hacker snd compiler
writer. we used to make very strong negative review of any proposals
to muck about with semantics in comment fields. just don't.
randy
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -----BEGIN PGP SIGNATURE----- Version: ProtonMail
wnUEARYKAAYFAmIUJZoAIQkQj6WtEth1vqMWIQQHtrd3aktNVejGGPiPpa0S 2HW+o58XAQDj8M/ZeHJoNpmLQC09FfoUhjERqkJJxGV/zhyCNHvAtAEAwRT1 gQXSV7DFkNqA5ji9Lsi4PeV1QIT+HJ3wlYQkkg0= =iX29 -----END PGP SIGNATURE-----
Hi Ed, On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane wrote:
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
For completeness sake, can you clarify which types of objects (under the new rules) are NOT eligible to specify the 'geofeed:' RPSL attribute? Kind regards, Job
Hi Job,
On 24 Feb 2022, at 13:19, Job Snijders <job@sobornost.net> wrote:
Hi Ed,
On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane wrote:
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
For completeness sake, can you clarify which types of objects (under the new rules) are NOT eligible to specify the 'geofeed:' RPSL attribute?
The Legal review in November recommended: "if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered personal data. " And from the clarification this week: "Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation. " Following these recommendations, for inetnum: - ALLOCATED PA: Allocated by RIPE NCC, Geofeed is allowed - ALLOCATED UNSPECIFIED: Not assigned to an invididual, Geofeed is allowed - LIR-PARTITIONED PA: Not assigned to an individual, Geofeed is allowed - SUB-ALLOCATED PA: Not assigned to an individual, Geofeed is allowed - ASSIGNED PA: Second-level resource may be assigned to an individual, Geofeed is not allowed on prefix size > /24 - ASSIGNED PI: Allowed on top-level PI assignments from RIPE NCC. Second-level resource may be assigned to an individual, Geofeed is not allowed on prefix size > /24 - ASSIGNED ANYCAST: Not assigned to an individual. Geofeed is allowed. - LEGACY: May be used by an individual. Geofeed is not allowed on prefix size > /24 And for inet6num: - ALLOCATED-BY-RIR: top-level allocation by RIPE NCC, geofeed is allowed - ALLOCATED-BY-LIR: not assigned to an individual, geofeed is allowed - AGGREGATED-BY-LIR: not assigned to an individual, geofeed is allowed - ASSIGNED: second-level resource may be assigned to an individual, geofeed is not allowed on prefix size >= /48 - ASSIGNED ANYCAST: not assigned to an individual, geofeed is allowed - ASSIGNED PI: second-level resource may be assigned to an individual, geofeed is not allowed on prefix size >= /48 I am updating the Impact Analysis for Geofeed accordingly. I believe this is consistent with their recommendations, but will ask Legal to review before implementing any changes. Regards Ed Shryane RIPE NCC
Kind regards,
Job
Dear Ed, Thank you for the message. Apologies for nitpicking a bit more :-) On Thu, Feb 24, 2022 at 04:28:39PM +0100, Edward Shryane via db-wg wrote:
On 24 Feb 2022, at 13:19, Job Snijders <job@sobornost.net> wrote: On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane wrote:
Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6).
For completeness sake, can you clarify which types of objects (under the new rules) are NOT eligible to specify the 'geofeed:' RPSL attribute?
The Legal review in November recommended:
"if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered personal data. "
And from the clarification this week:
"Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation. "
Following these recommendations, for inetnum:
- ALLOCATED PA: Allocated by RIPE NCC, Geofeed is allowed - ALLOCATED UNSPECIFIED: Not assigned to an invididual, Geofeed is allowed - LIR-PARTITIONED PA: Not assigned to an individual, Geofeed is allowed - SUB-ALLOCATED PA: Not assigned to an individual, Geofeed is allowed - ASSIGNED PA: Second-level resource may be assigned to an individual, Geofeed is not allowed on prefix size > /24 - ASSIGNED PI: Allowed on top-level PI assignments from RIPE NCC. Second-level resource may be assigned to an individual, Geofeed is not allowed on prefix size > /24 - ASSIGNED ANYCAST: Not assigned to an individual. Geofeed is allowed. - LEGACY: May be used by an individual. Geofeed is not allowed on prefix size > /24
And for inet6num:
- ALLOCATED-BY-RIR: top-level allocation by RIPE NCC, geofeed is allowed - ALLOCATED-BY-LIR: not assigned to an individual, geofeed is allowed - AGGREGATED-BY-LIR: not assigned to an individual, geofeed is allowed - ASSIGNED: second-level resource may be assigned to an individual, geofeed is not allowed on prefix size >= /48 - ASSIGNED ANYCAST: not assigned to an individual, geofeed is allowed - ASSIGNED PI: second-level resource may be assigned to an individual, geofeed is not allowed on prefix size >= /48
In the 'inet6num' listing you reference ">= /48", did you mean to write "> /48"? (which would conceptually align with the cut-off in ipv4: "> /24") Kind regards, Job
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
On 20220224, at 16:48, Edward Shryane via db-wg <db-wg@ripe.net> 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.
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. Greets, Jeroen
Hi Jeroen,
On 24 Feb 2022, at 16:50, Jeroen Massar <jeroen@massar.ch> wrote:
On 20220224, at 16:48, Edward Shryane via db-wg <db-wg@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
Hi, On Thu, Feb 24, 2022 at 06:21:55PM +0100, Edward Shryane via db-wg wrote:
We need to satisfy the Legal review to not allow geofeed on a prefix reasonably assumed to be related to one individual user,
Yes.
by not allowing it on ASSIGNED PA or ASSIGNED PI (not assigned by the RIPE NCC).
No. ASSIGNED status does not allow the assumption "this will be one individual user". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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
Hi all, On 24 Feb 2022, at 16:48, Edward Shryane via db-wg 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.
From the Legal analysis in November:
I am very puzzled by this entire thread. We’re in this giant thread, picking apart statuses and prefix sizes, with the goal of reliably determining when an inet(6)num is considered “reasonably assumed to be related to one individual user”, because legal said you can’t have a geofeed attribute then. Which they have said because at that point, this would introduce additional personal data which creates GDPR issues. Right? To start with, this works in one direction: if my ISP gives me, an individual person, a /56, and creates an inet6num for that, and adds a geofeed attribute, I can see the case that geofeed on that inet6num could be seen as personal data. But then, the actual issue is with the inet6num being created, rather than the geofeed attribute specifically. All the concerns about geofeed apply to all the other fields. If my ISP puts my name in the netname, we have exactly the same kind of problem. So the issue here would not be “does the database allow geofeed” but “which inet(6)nums are being created, do they contain personal data, and does that meet GDPR?”. But it gets worse: by having a list of rules of where you can add geofeed, we haven’t stopped people from publishing personal data. If I publish a geofeed for my /32 ALLOCATED-BY-RIR, I could list every individual customer with a /48 in there with their location. It can be as granular and personal as I want. So we haven’t actually prevented any publication of personal data. In short: this conversation sounds like we think the geofeed attribute says something about the location of an inet(6)num. But actually, it may say something about each individual IP address in that inet(6)num. Now, you could argue that that is my problem: the geofeed is on my server, this is about my customers, I’m responsible. The RIPE db merely contains a URL. But if that is the position, why can’t I put a URL, where I am responsible for the contents, in my ASSIGNED PI /48? Either the RIPE db is responsible for the personal data in that URL, and by extension we consider that as publishing personal data in the RIPE db, or it is not. Sasha
Hi Sasha, I think you have partially understood it but also just the NCC's side. I think both myself and others have argued basically the same thing you are arguing here but in slightly different words. I have talked about how it makes no sense to not be able to publish a geofeed url for a prefix you can publish an admin-c and tech-c for (and other personal details). And how the NCC is not publishing the data in the geofeed, but simply publishing a URL. I think this is also why it has gone on for so long, myself and others find it extremely confusing or difficult to understand how this could possibly make any sense. -Cynthia On Thu, Feb 24, 2022 at 11:20 PM Sasha Romijn via db-wg <db-wg@ripe.net> wrote:
Hi all,
On 24 Feb 2022, at 16:48, Edward Shryane via db-wg 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.
From the Legal analysis in November:
I am very puzzled by this entire thread.
We’re in this giant thread, picking apart statuses and prefix sizes, with the goal of reliably determining when an inet(6)num is considered “reasonably assumed to be related to one individual user”, because legal said you can’t have a geofeed attribute then. Which they have said because at that point, this would introduce additional personal data which creates GDPR issues. Right?
To start with, this works in one direction: if my ISP gives me, an individual person, a /56, and creates an inet6num for that, and adds a geofeed attribute, I can see the case that geofeed on that inet6num could be seen as personal data. But then, the actual issue is with the inet6num being created, rather than the geofeed attribute specifically. All the concerns about geofeed apply to all the other fields. If my ISP puts my name in the netname, we have exactly the same kind of problem. So the issue here would not be “does the database allow geofeed” but “which inet(6)nums are being created, do they contain personal data, and does that meet GDPR?”.
But it gets worse: by having a list of rules of where you can add geofeed, we haven’t stopped people from publishing personal data. If I publish a geofeed for my /32 ALLOCATED-BY-RIR, I could list every individual customer with a /48 in there with their location. It can be as granular and personal as I want. So we haven’t actually prevented any publication of personal data.
In short: this conversation sounds like we think the geofeed attribute says something about the location of an inet(6)num. But actually, it may say something about each individual IP address in that inet(6)num.
Now, you could argue that that is my problem: the geofeed is on my server, this is about my customers, I’m responsible. The RIPE db merely contains a URL. But if that is the position, why can’t I put a URL, where I am responsible for the contents, in my ASSIGNED PI /48? Either the RIPE db is responsible for the personal data in that URL, and by extension we consider that as publishing personal data in the RIPE db, or it is not.
Sasha
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
On 2022 Feb 24 (Thu) at 16:48:57 +0100 (+0100), Edward Shryane via db-wg wrote: :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. I don't understand why /24 and /48 are different. In my view, they need to be the same. Alternatively, I propose we *drop* the geofeed: attribute and remove it from the database. -- Nothing cures insomnia like the realization that it's time to get up.
On 2022-02-25 07:48, Peter Hessler via db-wg wrote:
Alternatively, I propose we *drop* the geofeed: attribute and remove it from the database.
Can you motivate the suggestion? The suggestion appears like a regression to me, we both see value in “geofeed:” (provided we can actually use it), right? Kind regards, Job
On 2022 Feb 25 (Fri) at 10:05:15 +0100 (+0100), Job Snijders via db-wg wrote: :On 2022-02-25 07:48, Peter Hessler via db-wg wrote: :> Alternatively, I propose we *drop* the geofeed: attribute and remove it :> from the database. : :Can you motivate the suggestion? : :The suggestion appears like a regression to me, we both see value in :“geofeed:” (provided we can actually use it), right? : The motivation is if the attribute is too restricted to be useful, then lets not encourage a broken implementation. (ps, the signature was chosen randomly and not changed ;) ). -- Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it.
On 20220225, at 10:20, Peter Hessler via db-wg <db-wg@ripe.net> wrote:
On 2022 Feb 25 (Fri) at 10:05:15 +0100 (+0100), Job Snijders via db-wg wrote: :On 2022-02-25 07:48, Peter Hessler via db-wg wrote: :> Alternatively, I propose we *drop* the geofeed: attribute and remove it :> from the database. : :Can you motivate the suggestion? : :The suggestion appears like a regression to me, we both see value in :“geofeed:” (provided we can actually use it), right? :
The motivation is if the attribute is too restricted to be useful, then lets not encourage a broken implementation.
The attribute is not the technical problem, it is a legal party that restricts it because of mostly unfounded concerns: if a LIR has permission of a user to publish their info, then they should be able to. If a LIR does not have permission of the end-user, then the LIR is liable when they do publish. Noting, that anybody can provide a geofeed.csv with even up to IPv4 /32 or IPv6 /128 (so single IP) level entries... It is just a restriction in RIPE DB in the geofeed field, but not in remarks. Which is why the restriction is so utterly pointless. In the same way that one can always "lie"/misrepresent in the geofeed file, or give "less accurate" details (eg. saying you are in Amsterdam, while actually being in a small village like Zoetermeer) and given that traffic typically flows over Amsterdam in .nl (like most traffic in .ch is going over Zurich, as that is where peering/DSLAM termination etc happens), not unreasonable to do that that way. But it could be that in a /24, there are /28s that are in different countries, thus it is needed to be able to specify that, especially because the large corporations base their ads on IP addresses, but also languages (instead of respecting this magic Accept-Language HTTP header...) Greets, Jeroen
Hi Ed, Colleagues Following on from all the responses here, perhaps the RIPE NCC legal team can take another look at this matter and re-evaluate their legal analysis. cheers denis co-chair DB-WG
Hi Denis, Colleagues, Thank you for your feedback. I've asked the RIPE NCC Legal department review this feedback, and to prepare a response for the DB-WG. Regards Ed Shryane RIPE NCC
On 25 Feb 2022, at 22:12, denis walker <ripedenis@gmail.com> wrote:
Hi Ed, Colleagues
Following on from all the responses here, perhaps the RIPE NCC legal team can take another look at this matter and re-evaluate their legal analysis.
cheers denis co-chair DB-WG
Dear db-wg, Hope this email finds you in good health. Please see my comments below, inline... Le vendredi 25 février 2022, Jeroen Massar via db-wg <db-wg@ripe.net> a écrit :
On 20220225, at 10:20, Peter Hessler via db-wg <db-wg@ripe.net> wrote:
On 2022 Feb 25 (Fri) at 10:05:15 +0100 (+0100), Job Snijders via db-wg wrote: :On 2022-02-25 07:48, Peter Hessler via db-wg wrote: :> Alternatively, I propose we *drop* the geofeed: attribute and remove it :> from the database. : :Can you motivate the suggestion? : :The suggestion appears like a regression to me, we both see value in :“geofeed:” (provided we can actually use it), right? :
The motivation is if the attribute is too restricted to be useful, then lets not encourage a broken implementation.
The attribute is not the technical problem, it is a legal party that restricts it because of mostly unfounded concerns:
Hi Jeroen, Thanks for your email, brother! ...if the legal assessment/advice is broken, as most of the active members of this WG are saying, and if RIPE NCC choose to add it within the "geofeed:" attribute's implementation; then the situation appears to be the same :-/
if a LIR has permission of a user to publish their info, then they should be able to. If a LIR does not have permission of the end-user, then the LIR is liable when they do publish.
Noting, that anybody can provide a geofeed.csv with even up to IPv4 /32 or IPv6 /128 (so single IP) level entries...
It is just a restriction in RIPE DB in the geofeed field, but not in remarks.
...if the "remarks:" attribute is not targeted; then how to do with the same legal team's advice?
Which is why the restriction is so utterly pointless.
Are you saying that the implementer shall not consider the legal advice for the "remarks:" attribute? In the same way that one can always "lie"/misrepresent in the geofeed file,
or give "less accurate" details (eg. saying you are in Amsterdam, while actually being in a small village like Zoetermeer) and given that traffic typically flows over Amsterdam in .nl (like most traffic in .ch is going over Zurich, as that is where peering/DSLAM termination etc happens), not unreasonable to do that that way.
But it could be that in a /24, there are /28s that are in different countries, thus it is needed to be able to specify that, especially because the large corporations base their ads on IP addresses, but also languages (instead of respecting this magic Accept-Language HTTP header...)
...though, i am of the view that it's difficult to understand the rational of the legal team's advice regarding the ability to add a URI as a value inside an attribute..."geofeed:" & "remarks:" too(?) Question: Is that URI a new type of personal data? Thanks. Shalom, --sb.
Greets, Jeroen
--
[...]
-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #LASAINTEBIBLE|#Romains15:33«Que LE #DIEU de #Paix soit avec vous tous! #Amen!» #MaPrière est que tu naisses de nouveau. #Chrétiennement «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)
Hi, On Thu, Feb 24, 2022 at 04:28:39PM +0100, Edward Shryane via db-wg wrote:
The Legal review in November recommended:
"if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered personal data. "
This is something I'd agree to. The consequences of that ("insert arbitrary rules into the RIPE DB based on assumptions on what might or might not consider an end-user assignment, and disallow some attributes on that"), not. We don't ever register inet(6)num: for individuals, only for corporate customers. Even if we did, if I had agreement from the customer (in writing!) that they are fine with me putting their full name, phone number, postal address *and* geofeed attribute in the DB, this is not the NCC's business to disallow "geofeed", while allowing all the other PII data. (Just for completeness, I don't actually intend to *use* geofeed, but this discussion really upsets me, because it's wasting life time for no good reason) Gert Doering -- LIR contact -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 20220224, at 16:56, Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,
On Thu, Feb 24, 2022 at 04:28:39PM +0100, Edward Shryane via db-wg wrote:
The Legal review in November recommended:
"if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered personal data. "
This is something I'd agree to.
The consequences of that ("insert arbitrary rules into the RIPE DB based on assumptions on what might or might not consider an end-user assignment, and disallow some attributes on that"), not.
We don't ever register inet(6)num: for individuals, only for corporate customers.
Even if we did, if I had agreement from the customer (in writing!) that they are fine with me putting their full name, phone number, postal address *and* geofeed attribute in the DB, this is not the NCC's business to disallow "geofeed", while allowing all the other PII data.
^---- +1 on all that what Gert writes. While RIPE NCC should provide guidance, it should not restrict it so much that one cannot do this. Greets, Jeroen
participants (14)
-
Cynthia Revström -
denis walker -
Edward Shryane -
Elad Cohen -
Gert Doering -
Jeroen Massar -
Job Snijders -
Job Snijders -
Massimo Candela -
Peter Hessler -
Randy Bush -
Sasha Romijn -
Sylvain Baya -
Tom Hill