Hi Michael,
> On 8 Jan 2021, at 15:16, Michael Kafka via db-wg wrote:
>
> Dear members,
>
...
> Much more critical are the 100k or maybe even millions of RIPE-db
> entries, containing name and street address of natural persons which
> are under the sole control of RIPE.
>
> Best regards,
>
>
Hello all,
On 5 Jan 2021, at 19:29, Edward Shryane via db-wg wrote:
> On 5 Jan 2021, at 14:30, denis walker wrote:
>>
>> Hi Ed
>>
>> Can you do a quick count on INETNUM and INET6NUM objects and see how
>> many currently have a "remarks: Geofeed" attribute and if any have
>> more than one.
>
Agoston,
I think that it's fine to help push adoption ahead of the IETF process.
The proposal is not super complicated (which is good). While possibly
the authentication details within the feed will change I don't think the
RPSL attribute will need to be modified from the current draft.
Would it make sense to wait with implementation until the the ietf draft
comes out of draft status? Seems like jumping into beta waters to me.
Agoston
On Sun, Jan 3, 2021 at 8:22 PM Randy Bush via db-wg wrote:
> hi cynthia
>
> >> Why not use the RPKI to distribute geofeed information?
> >
> >
Hi Denis, Colleagues,
> On 5 Jan 2021, at 14:30, denis walker wrote:
>
> Hi Ed
>
> Can you do a quick count on INETNUM and INET6NUM objects and see how
> many currently have a "remarks: Geofeed" attribute and if any have
> more than one.
>
I found 47 inetnums, 17 inet6nums and 2 aut-num
Should the DB reject such an update? Should the geofeed client pick
one at random? Should it pick the first one? Or the last one? Or none?
my personal opinion would be, as the spec says only one, an attempt to
add a second should fail. as should an initial attempt to create with
more than one.
>> from draft-ietf-opsawg-finding-geofeeds
>>
>> Any particular inetnum: object MAY have, at most, one geofeed
>> reference, whether a remarks: or a proper geofeed: attribute when
>> one is defined.
>>
>> now all we need is for the someone or someone's automated system to read
>>
On 2021-01-04 21:41, Randy Bush via db-wg wrote:
What happens when someone (or someone's automated system) pushes an
object with a "remarks: Geofeed" again?
from draft-ietf-opsawg-finding-geofeeds
Any particular inetnum: object MAY have, at most, one geofeed
reference,
> What happens when someone (or someone's automated system) pushes an
> object with a "remarks: Geofeed" again?
from draft-ietf-opsawg-finding-geofeeds
Any particular inetnum: object MAY have, at most, one geofeed
reference, whether a remarks: or a proper geofeed: attribute when
One more question after coffee:
> > On deployment update any objects in the RIPE Database containing a
> > "remarks: Geofeed" with a correctly formatted url into a "geofeed:"
> > attribute.
>
> Sounds simple enough
What happens when someone (or someone's automated system) pushes an
object
Hi Denis,
> Would you say a possible Solution statement could be as simple as:
>
> Implement a new "geofeed:" attribute in the INETNUM and INET6NUM
> objects based on the IETF draft
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/
> On deployment update any objects in the
Hi Job
So if we were to create a new NWI with your suggested Problem statement:
Associating an approximate physical location with an IP address
has proven to be a challenge to solve within the current constraints
of the RIPE database. Over the years the community has chosen
to
> And on the note of the main challenge, I also think a part of making it
> simple to implement is to try to have the same API for this between all of
> the RIRs
https://github.com/massimocandela/geofeed-finder
what remains is to go from a remarks: attribute to a first class
geofeed: attribute,
hi cynthia
>> Why not use the RPKI to distribute geofeed information?
>
> I think using RPKI for this will make it needlessly complicated for people
> to use. I think we want to make this as simple as possible for someone to
> find.
as i said to job over on the dark side of the force, the ietf,
Hi Job and db-wg,
I just want to start out by saying that I think this is a very worthwhile
endeavour IMO, and thank you Job for reminding me of this thread. :)
I have also written some opinions about your questions and ideas below, and
I would like to hear some input from people on the WG as
Dear DB-WG chairs,
Today an acquaintance (who works at an ISP) reached out to me describing
some annoying Geo IP location issues they were facing.
I thought to myself "didn't we have a solution to such issues?" and was
reminded of this thread.
Chairs, how do we proceed to work towards the
Purely as a point of information, Randy also asked for APNIC to
consider this field, and it has been put into the Opportunity process
inside Registry Product, of which I am the manager.
I am following this discussion. My primary concerns are the effects on
tools, of a new type:value assertion
> "should we have a geofeed attribute that accepts a URL, or just a remarks
> attribute with a value prefixed with Geofeed?"
>
> "remarks: Geofeed https://example.com/geofeed.csv;
> vs
> "geofeed: https://example.com/geofeed.csv;
and we're currently trying to bridge two tensions.
there will be
aclar.com
>
> Munich, Germany
>
> [image: linkedin] <https://www.linkedin.com/in/matthias-merkel/>
>
>
>
>
>
> *From:* db-wg *On Behalf Of *Elad Cohen via db-wg
> *Sent:* Wednesday, 7 October 2020 17:01
> *To:* Horváth Ágoston János ; Job Snijders <
> j...
Hi Elad,
> Not everyone will add the "geofeed" value and the geolocations in the csv
will not validated by a 3rd party and may also be not up to date.
It is a fair point that not everyone will use this, but I think a
significant enough number will to warrant addition. On the point of
validation
Sent: Wednesday, 7 October 2020 17:01
To: Horváth Ágoston János ; Job Snijders
Cc: db-wg@ripe.net >> Database WG
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'
+1
and I would like to suggest an adjustment:
Not everyone will add the "geofeed" value and the geolocati
Well, not really. Say, if geofeed: is accepted, that also sets the way how
to store geolocation data in the RIPE Database. I mean, allowing geofeed:
and then adding country:, city: attributes in inetnum would be inconsistent
and confusing.
So it is much more than just an optional attribute. I do
On Wed, Oct 07, 2020 at 04:50:43PM +0200, Horváth Ágoston János via db-wg wrote:
> You are aware you ignored 90% of my points and picked a single one out of
> my email?
Correct. The rest of the email is interesting but directly related to
the contents of a geofeed file, which is a discussion more
ards,
Elad
From: db-wg on behalf of Job Snijders via db-wg
Sent: Wednesday, October 7, 2020 5:19 PM
To: Horváth Ágoston János
Cc: db-wg@ripe.net >> Database WG
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'
On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horváth Ágoston János wrote:
You are aware you ignored 90% of my points and picked a single one out of
my email?
But let me answer this with an example.
Say, 192.168/16 has 5 children, each a /24.
You put in the geofeed file for a single 192.168/16 a /20, covering four of
these.
The /20 does not exist in the RIPE DB. So a
On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horváth Ágoston János wrote:
> An interesting proposal, but merging an external data set with RIPE
> Database arises some questions:
>
> - RIPE Database is set up to contain hierarchical data already. With this
> proposal, we would take some of this data
> - RIPE Database is set up to contain hierarchical data already. With this
> proposal, we would take some of this data outside the database in a manner
> that does not guarantee consistency with the database itself. For example,
> 192.168/16 specifies a geofeed file that has different prefixes in
An interesting proposal, but merging an external data set with RIPE
Database arises some questions:
- RIPE Database is set up to contain hierarchical data already. With this
proposal, we would take some of this data outside the database in a manner
that does not guarantee consistency with the
> If nobody ever adapts RPSL to the new requirements, RPSL is dead. So
> the question is: Should we throw away the RRDB in favour of something
> else, or do we extend RPSL in the way it was designed?
we have a lot of rpsl-based toolchains out there. this does not mean
we should not work on next
ubject: Re: [db-wg] proposal: new attribute 'geofeed:'
+1 this is a much more reasonable solution than remarks imo
- Cynthia
On Tue, 6 Oct 2020, 18:29 Job Snijders via db-wg,
mailto:db-wg@ripe.net>> wrote:
Dear DB-WG,
Some colleagues are working to address the never-ending-story of
+1 this is a much more reasonable solution than remarks imo
- Cynthia
On Tue, 6 Oct 2020, 18:29 Job Snijders via db-wg, wrote:
> Dear DB-WG,
>
> Some colleagues are working to address the never-ending-story of 'where
> the heck are IPs geographically?'. This problem space has been brought
>
On Wed, Oct 07, 2020 at 06:31:11AM +, Lutz Donnerhacke via db-wg wrote:
> > By enriching the RPSL dictionary and having a “geofeed” RPSL attribute
> > (which by the way should not be mandatory)
Indeed, it is not mandatory.
> > will be easier for someone to extend his parser to use that
> By enriching the RPSL dictionary and having a “geofeed” RPSL attribute
> (which by the way should not be mandatory) will be easier for someone
> to extend his parser to use that field without overloading the parser
> with many “if” and regex expressions. Plus the upcoming RFC specifies
> A that
Hi Job, all
> On 6 Oct 2020, at 18:28, Job Snijders via db-wg wrote:
>
> Dear DB-WG,
>
> Some colleagues are working to address the never-ending-story of 'where
> the heck are IPs geographically?'. This problem space has been brought
> up numerous times in the Database Working Group, but we
Dear DB-WG,
Some colleagues are working to address the never-ending-story of 'where
the heck are IPs geographically?'. This problem space has been brought
up numerous times in the Database Working Group, but we never managed to
solve it. As with all compsci problems adding a layer of indirection
35 matches
Mail list logo
