Hello Denis and All.
Thank you very much for your reply.
For instance with an entry like shown below, we will be using NL as the
country.
As you rightly said, that is for the organisation.
So, we are working on moving to something more accurate on the city level.
Thank you very much.
With best
Hi Arcadius
If you download the inetnum split file from the RIPE ftp site you will
see there are already some "geofeed:" attributes in there as well as
some still using the earlier "remarks: geofeed" option.
denis$ zgrep "^geofeed:" ~/Desktop/ripe.db.inetnum.gz | wc -l
289
denis$ zgrep
Hello Jori, Edward and All.
I apologise for resurrecting this very old thread.
We are using the files in the ripe DB for creating our own geo-location DB.
It's straightforward to get country level geo-ip classification.
We are now looking into a city level geo-ip information and I have just
come
Hi Ed,
On 4/8/2021 3:36 PM, Edward Shryane via db-wg wrote:
Hi Jori,
On 8 Apr 2021, at 14:42, Tyrasuki wrote:
Hi Ed,
This seems like a good implementation to me.
However, I don't think it's a good idea to limit the values on the "remarks"
attribute in this way, as this could cause
Hi Jori,
> On 8 Apr 2021, at 14:42, Tyrasuki wrote:
>
> Hi Ed,
>
> This seems like a good implementation to me.
>
> However, I don't think it's a good idea to limit the values on the "remarks"
> attribute in this way, as this could cause unwanted side effects with for ex.
> messages left on
Hi Denis,
On Thu, Apr 08, 2021 at 12:55:32AM +0200, denis walker via db-wg wrote:
> I don't see the issue of what, if anything, should be validated as a
> show stopper for introducing the "geofeed:" attribute. This is my idea
> of utilising the RIRs to improve the value of services with increased
On Thu, Apr 08, 2021 at 02:27:13PM +0200, Edward Shryane via db-wg wrote:
> > On 8 Apr 2021, at 13:54, Randy Bush via db-wg wrote:
> >
> >> Could we consider creating an NWI with a reduced scope?
> >
> > as an exercise, how minimal can we get?
>
> Given the draft RFC:
>
Hi Ed,
This seems like a good implementation to me.
However, I don't think it's a good idea to limit the values on the "remarks"
attribute in this way, as this could cause unwanted side effects with for ex.
messages left on objects for other network operators.
Also:
> "Do not support
Hi Randy,
> On 8 Apr 2021, at 13:54, Randy Bush via db-wg wrote:
>
>> Could we consider creating an NWI with a reduced scope?
>
> as an exercise, how minimal can we get?
>
> randy
>
Given the draft RFC:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?include_text=1
I
> Could we consider creating an NWI with a reduced scope?
as an exercise, how minimal can we get?
randy
Yeah that's a good point, I guess "non-error status code" rather than
"200 status code".
-Cynthia
On Thu, Apr 8, 2021 at 12:47 AM George Michaelson wrote:
>
> I'd say rather than a 2xx, Allowing for 30x redirection, HTTP->HTTPS
> uplift and other things. And, gzip compression. So, basically,
>
Guys
I don't see the issue of what, if anything, should be validated as a
show stopper for introducing the "geofeed:" attribute. This is my idea
of utilising the RIRs to improve the value of services with increased
validation. That's why I changed the subject line and started it as a
different
I'd say rather than a 2xx, Allowing for 30x redirection, HTTP->HTTPS
uplift and other things. And, gzip compression. So, basically,
completion of a data exchange.
Probably in the spirit of what you meant. As long as thats what "200"
means, I'd be fine!
cheers
-G
On Thu, Apr 8, 2021 at 8:42 AM
Hi Denis,
I have so far not seen anyone (other than you) suggest doing anything
more than checking that the URL is valid and doesn't 404.
The people who have so far commented on this are: me, Job, George
Michaelson, Leo Vegoda.
Could we consider creating an NWI with a reduced scope?
If I start
The Geofeed: field is a URL.
It points to a resource.
The semantic content of the resource should not be checked, what
matters is that the URL is not a 404 at the time of publication.
if you want to check it isn't a 404 after that, its like Lame checks:
good to do, not strictly essential in the
Hi,
I just wanted to clarify my stance on validation a bit more.
I am totally against trying to validate the data itself, that is not
what the NCC is supposed to do.
Validating the format of the CSV might be okay but honestly anything
beyond validating that it is not a 404 not found is a bit too
Hi Denis,
This message is in response to several in the discussion .
In brief: I have seen network operators distraught because their
network was misclassified as being in the wrong geography for the
services their customers needed to access and they had no way to fix
that situation. I feel that
HI Cynthia
I don't take criticism personally. I am known for my wild
ideas...occasionally I come up with a good one :)
But let's take another look at this geofeed. Any service offered by or
through the RIPE Database should be a high quality and reliable
service. It doesn't matter if it is an
Hi Denis,
Apologies if this email comes off as rude or harsh, that isn't my
intention, but I am not quite sure how else to phrase it.
So when I say things like this, it's not because of cost or anything like
that.
I say it because I don't think validating the CSV is something that would
be a
Hi guys
I've changed the subject as it goes a bit off topic and becomes more
general and reaches out beyond just the DB-WG. I've been going to say
this for a while but never got round to it until now. Apologies for
saying it in response to your email Job but it's not directed at you.
There are
20 matches
Mail list logo
