[db-wg] Role of RIPE NCC in geofeed, abuse-c checks, etc

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 regards

Arcadius

% Tags relating to '156.150.0.0 - 156.150.255.255'

% RIPE-REGISTRY-RESOURCE


inetnum: 192.68.230.0 - 192.68.230.255

netname: Atos-MEV

*country: NL*

org: ORG-OB2-RIPE

admin-c: DUMY-RIPE

tech-c: DUMY-RIPE

status: LEGACY

notify: Global-IPcoordinator at atos.net

mnt-by: RIPE-NCC-LEGACY-MNT

mnt-routes: MNT-VALUESOLUTIONS

mnt-by: GIPC-ORIGIN-MNT

created: 1970-01-01T00:00:00Z

last-modified: 2017-08-24T08:32:00Z

source: RIPE

remarks: ****************************

remarks: * THIS OBJECT IS MODIFIED

remarks: * Please note that all data that is generally regarded as personal

remarks: * data has been removed from this object.

remarks: * To view the original object, please query the RIPE Database at:

remarks: * http://www.ripe.net/whois

remarks: ****************************




On Tue, 12 Apr 2022 at 20:12, denis walker <ripedenis at gmail.com> wrote:

> 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 "^remarks:\s*geofeed" ~/Desktop/ripe.db.inetnum.gz  | wc -l
>       13
>
> Although from the 289 there are only 161 unique organisations.
>
> There are still a lot of people using the (old) "geoloc:" attribute.
> denis$ zgrep "^geoloc:" ~/Desktop/ripe.db.inetnum.gz  | wc -l
>    35453
>
> You mentioned getting country level geo-ip, are you using the
> "country:" attribute? If so which one? The ones in the INET(6)NUM
> objects are undefined to anyone other than the resource holder. The
> only one that is defined is the "country:" attribute in the referenced
> ORGANISATION object for allocations and PI assignments. This is the
> country the resource holder is legally based in.
>
> cheers
> denis
> co-chair DB-WG
>
> On Tue, 12 Apr 2022 at 19:09, Arcadius Ahouansou via db-wg
> <db-wg at ripe.net> wrote:
> >
> >
> > 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 across this old thread about "geofeed"
> >
> > It would be great to know whether this geofeed is already being
> implemented in the ripe FTP.
> >
> > Thank you very much.
> >
> > With kind regards.
> >
> > Arcadius,
> >
> > On Thu, 8 Apr 2021 at 15:18, Jori Vanneste via db-wg <db-wg at ripe.net>
> wrote:
> >>
> >> 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 <tyrasuki at pm.me> 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 objects for other network operators.
> >> > Given the draft states:
> >> >
> >> > " Any particular inetnum: object MAY have, at most, one geofeed
> >> >     reference, whether a remarks: or a proper geofeed: attribute when
> one
> >> >     is defined."
> >> >
> >> > Do we enforce this by validating that there is only one "remarks:
> Geofeed" value (or "geofeed:") in the object?
> >> My apologies, I think I missed this section in the draft, thanks for
> >> clarifying the reason to me.
> >> >> Also:
> >> >>> "Do not support non-ASCII values in URL domain names or path (these
> must be converted beforehand)"
> >> >> Do you by this mean not supporting non-ASCII entirely? Or to have
> for ex. the web-interface convert IDNs to punycode, and have this listed on
> the object?
> >> >>
> >> > The RIPE database uses the Latin-1 character set, so IDN domain names
> or non-ASCII values in the URL path will be substituted with a '?'
> character, by default.
> >> >
> >> > We could support non-ASCII values by automatically converting them
> (like we do with non-ASCII domains in email addresses).
> >>
> >> That sounds like a good approach to me, thanks for clarifying. :)
> >>
> >> I think this is indeed a good starting ground for a minimal NWI, and
> >> would like to see where this goes.
> >>
> >> >> If the latter, and remarks can remain free-form, I'd say let's
> implement.
> >> >>
> >> >>
> >> >> Cheers,
> >> >> Jori Vanneste
> >> >> FOD11-RIPE
> >> >>
> >> > Regards
> >> > Ed
> >>
> >>
> >> Best regards,
> >> Jori Vanneste
> >> FOD11-RIPE
> >
> >
> >
> > --
> > Arcadius Ahouansou
> > Menelic Ltd | Applied Knowledge Is Power
> > Office : +441444702101
> > Mobile: +447908761999
> > Menelic Ltd: menelic.com
> > SmartLobby: SmartLobby.co
> > Hosted Apache Solr Services: solrfarm.com
> >
> > ---
> > --
> >
> > To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://mailman.ripe.net/
>


-- 
Arcadius Ahouansou
Menelic Ltd | Applied Knowledge Is Power
Office : +441444702101
Mobile: +447908761999
Menelic Ltd: menelic.com
SmartLobby: SmartLobby.co <https://smartlobby.co/>
Hosted Apache Solr Services: solrfarm.com

---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20220414/4632a4a5/attachment.html>