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 wrote:
>
> Hi Ed, Colleagues
>
> Following on from all the
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 a
écrit :
>
>
> > On 20220225, at 10:20, Peter Hessler via db-wg wrote:
> >
> > On 2022 Feb 25 (Fri) at 10:05:15 +0100 (+0100), Job Snijders via
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
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription
> On 20220225, at 10:20, Peter Hessler via db-wg 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.
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
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),
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
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
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
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
Hi Jeroen,
> On 24 Feb 2022, at 16:50, Jeroen Massar wrote:
>
>> On 20220224, 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
>>
> On 20220224, at 16:56, Gert Doering via db-wg 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
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
On Thu, Feb 24, 2022 at 04:48:57PM +0100, Edward Shryane wrote:
> Hi Job,
>
> > On 24 Feb 2022, at 16:31, Job Snijders 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
> On 20220224, at 16:48, Edward Shryane via db-wg wrote:
>
> Hi Job,
>
>> On 24 Feb 2022, at 16:31, Job Snijders 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'
Hi Job,
> On 24 Feb 2022, at 16:31, Job Snijders 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
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 wrote:
> > On Mon, Feb 21, 2022 at 03:56:00PM +0100, Edward Shryane wrote:
> >> Accordingly, we will
Hi Job,
> On 24 Feb 2022, at 13:19, Job Snijders 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).
>
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 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
> 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
Hi Ed
On Tue, 22 Feb 2022 at 09:54, Edward Shryane via db-wg wrote:
>
> Hi Massimo,
>
> > On 21 Feb 2022, at 16:29, Massimo Candela via db-wg wrote:
> >
> > Hi Ed,
> >
> > Thanks for the work done.
> >
>
> Thank you!
>
> >
> > On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
> >
> >> We
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
Hi Job, Colleagues,
> On 22 Feb 2022, at 10:01, Job Snijders 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
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
Hi Denis,
> On 21 Feb 2022, at 17:10, denis walker 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
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 unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
Hi Massimo,
> On 21 Feb 2022, at 16:29, Massimo Candela via db-wg 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
UNSUBSCRIBE
--- Original Message ---
On Tuesday, February 22nd, 2022 at 1:50, Cynthia Revström via db-wg
wrote:
> Hi,
>
> My opinions on this can probably be summed up with me pretty much
>
> entirely agreeing with Job, Randy, and
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
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
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
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
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
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
Hello Jeroen,
Firstly apologies for the delay in finding a solution to the /48 restriction on
"geofeed:".
I'm discussing a possible alternative with our Legal department, and hope to
have an answer for you and the DB-WG soon.
Regards
Ed Shryane
RIPE NCC
> On 11 Feb 2022, at 17:16, Jeroen
> Hi Job, Colleagues,
> > On 3 Jan 2022, at 13: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
+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
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
[ 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":
>
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
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 wrote:
>
> On 2022 Jan 04
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
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
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:"
Hi Cynthia,
> On 3 Jan 2022, at 19:44, Cynthia Revström 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*
Hi Job, Colleagues,
> On 3 Jan 2022, at 13: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
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
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,
Hi Randy,
On Mon, 3 Jan 2022 at 18:19, Randy Bush 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.
>
> drumroll! and the best path forward is? :)
My personal
On 2022 Jan 03 (Mon) at 12:36:49 + (+), 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
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
> 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
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
54 matches
Mail list logo
