- db-wg - mailman.ripe.net

Meet Debbie, the RIPE Database Robot!
by Sandra Bras 24 Sep '12

24 Sep '12

[Apologies for duplicates] Dear colleagues, RIPE NCC E-Learning is pleased to introduce you to Debbie, the RIPE Database Robot. Debbie is your guide through a new series of e-learning videos designed to help you get the most out of the RIPE Database: http://www.ripe.net/lir-services/training/e-learning/ripe-database The RIPE Database e-learning collection has also expanded with the addition of three new videos: - Create More Specifics (Hierarchical Authorisation) - Create IPv4 Assignments - Create IPv6 Assignments There are now eight brief video tutorials (most around three minutes duration) giving step-by-step instructions for users to perform a range of different operations in the RIPE Database. If you have any comments or questions, please send an email to <e-learning(a)ripe.net>. Happy learning! Sandra Bras Trainer / E-Learning Project Manager, RIPE NCC

1 0

status and use/fulness of the geoloc: attribute
by Wilfried Woeber 19 Sep '12

19 Sep '12

Dear DB-Folks, in preparation for the upcoming WG Meeting in Amsterdam, and following up on dicussions during the previous one, I'd like to start the review and discussion on the geoloc: attribute in IPv4 and IPv6 inetnum objects. To get things going I'd like to solicit input from people and entities who/which have populated objects, and those making use of the information. What was your experience? Is this stuff useful? On a more general basis I'd like the community to review the current (sort of experimental) functionality and comment on the problems - if any - or suggest improvements! At the same time I am asking the NCC to provide us with some insight on the current use of this attribute. Thanks, Wilfried.

5 6

New on RIPE Labs: Registration History for Members - A Demo
by Mirjam Kuehne 17 Sep '12

17 Sep '12

[apologies for duplicates] Dear colleagues, Please see a new article on RIPE Labs describing a way to look at registration history in RIPEstat. This is a first demo and is only available to members: https://labs.ripe.net/Members/dfk/registration-history-for-members-a-demo Please note the request for feedback at the end of the article. Kind regards, Mirjam Kuehne RIPE NCC

4 5

RIPE65 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 10 Sep '12

10 Sep '12

Dear DB-WG folks, Chairpersons, "Meeting"! This is the 1st draft of an agenda for the DB-WG at RIPE65 in Amsterdam, September 26, 2012. For time slot allocations please refer to the most up-to-date meeting plan at http://ripe65.ripe.net/programme/meeting-plan The DB-WG Meeting is scheduled for *Wednesday*, starting at 09:00 local time / 07:00 UTC in the morning. The length of our timeslot is 90 Minutes. The overall (draft) RIPE 65 meeting outline is already available at https://ripe65.ripe.net/programme/meeting-plan/ Please feel free to propose additional topics to be discussed! I'd also suggest that you submit your points of view regarding the topics on the proposed agenda on the mailing list, preferably before the WG meeting's start :-) Best regards, hope to see you soon in Amsterdam (which happens to *not* be in Slovenia :-) as I have been told ), Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Update (N.N., RIPE NCC) C. Discussion GeoLoc data in the DB (WW144) - status, statistics, use - use / usfulness? D. Status update on IETF WEIRDS activities (Olof Kolkman, t.b.c.) Y. Input from other Working Groups and/or Task Forces Z. AOB ________________________________________________________________________

1 0

Call for agenda items, DB-WG Meeting during RIPE65, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 03 Sep '12

03 Sep '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear DB-WG folks, planning activities for the next RIPE Meeting - RIPE65 in Amsterdam, NL, September 24 - September 28, 2012, have already started a while ago - thus this _call for agenda items_ for the meeting of the Database Working Group. Please submit (to the WG list!) your item requests and|or suggest topics for discussion to be included in the draft agenda! Please note that the DataBase-WG meeting is *at the moment* scheduled for *Wednesday* (starting at 9:00 local time). This is according to the *draft* meeting plan - which is pretty stable already but may still need to be changed as we get closer to the meeting date! The overall (draft) RIPE 65 meeting outline is already available at https://ripe65.ripe.net/programme/meeting-plan/ Looking forward to a successful meeting and see you soon in Slovenia, Wilfried. PS: although the meeting is in Amsterdam, this time it is *not* at the Krasnapolsky, in the city center. Please consult the meeting pages! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQCVAwUBUESqFd/RXX7wrLNpAQJL5wQAqFgVPVkB5WEtkMQQ0qz+8CEu6L1inVXS gsbFit2L7IZddtQUtmHIJEHV4MPvHMglSfJlmA3x2dAX68mDtohjgy1yfrxx7mBu /IfcBIckExYX3ROCYEO/v7cQarreZnuIF4Vt0D7d96fS8e9uOwJoBytDCSMewSaq 3TWrDVpfu08= =ooqk -----END PGP SIGNATURE-----

1 0

Update of mntner object with mixed authentication
by Alexander Gall 29 Aug '12

29 Aug '12

I'm trying to update the "shared" 6to4 anycast-relay maintainer object RFC3068-MNT. My own authentication for the object is PGP. But how the heck do I get a full copy of the object including the other people's MD5 hashes if I don't have a password myself? Puzzled, -- Alex

5 6

Deprecation of DOMAIN object attributes
by Denis Walker 21 Aug '12

21 Aug '12

[Apologies for duplicate emails] Dear Colleagues, At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. A suggestion was put forward to deprecate the following attributes: mnt-lower: sub-dom: dom-net: refer: These were considered to be of no use after the removal of forward domain data and no longer allowing hierarchical, reverse delegation data. The RIPE NCC is now removing these attributes from the syntax. It will no longer be possible to create objects with these attributes. To modify objects already containing them, these attributes will need to be removed. As a follow up the RIPE NCC will "clean" the reverse delegation and ENUM DOMAIN object data to remove these attributes. The web forms for both updates and queries will also have these attributes removed. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

New delegation checking software
by Anand Buddhdev 08 Aug '12

08 Aug '12

[Apologies for duplicates] Dear colleagues, Tomorrow, 8 August 2012, the RIPE NCC will deploy a change to the RIPE Database update software. As part of this deployment, we will switch to a new DNS delegation checker, developed by .SE, the Swedish domain name registry. This change should not have any impact on the process of registering a reverse DNS delegation in the RIPE Database. However, the informational and diagnostic messages this software returns will look different from the ones you have been seeing so far. There should be no noticeable outage in any of the services during this deployment. There will be no change to any other parts of the RIPE Database update or query software with this deployment. Along with these changes to the back-end software, the RIPE NCC will also update the web-based delegation checker at: http://www.ripe.net/data-tools/dns This new web-based delegation checker will use the same software as the back-end. We will send another announcement after we have deployed this new software. If you have any questions or comments, please send an email to <dns(a)ripe.net>. Regards, Anand Buddhdev RIPE NCC

1 1

Support for SHA256 in ds-rdata checker
by Alexander Gall 02 Aug '12

02 Aug '12

I'm not sure whether this belongs here or in the dns-wg (or somewhere else?). I just updated the ds-rdata of one of our domain objects and realized that the RDNS checker does not support SHA-256, neither for the DS record nor as part of signature algorithm 8 (RSASHA256) ***RDNS: (related to set) INFO: 6199 8 2 03A50B02CC5FCBCC8071AD93212C923E8C399DE64AE7C042442E2DE2F0029592 ; uses a Digest type that is not implemented by this checker. We cannot verify if the chain of trust is intact. You should be conciously using digest types other than SHA1 ***RDNS: (related to ns2.switch.ch) INFO: The signature over DNSKEY is made with algorithm code 8 The checker does not implement this algorithm and can therefore not validate the chain of trust It is assumed that using algoritm type 8 is a conscious choice. SHA256 has been in use for both purposes for a number of years. Are there any plans to support it in the RDNS checker? Regards, Alex -- SWITCH Serving Swiss Universities -------------------------- Alexander Gall, Global LAN Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 22 alexander.gall(a)switch.ch, http://www.switch.ch

2 2

Syntax of the "nserver:" Attribute in Domain Objects
by Anand Buddhdev 27 Jul '12

27 Jul '12

[Apologies for duplicate emails] Dear colleagues, Following on from the removal of the forward DOMAIN objects from the RIPE Database, all DOMAIN objects are now used for either reverse DNS or ENUM delegations. For both these cases, the "nserver:" attribute is required. Currently this attribute is optional and there are many objects in the RIPE Database that do not have any "nserver:" attributes. These objects are ignored by the DNS provisioning service, because they have no operational value. The RIPE NCC proposes to make the "nserver:" attribute mandatory in DOMAIN objects and delete any objects from the RIPE Database that do not have this attribute. To simplify the parsing of DOMAIN objects, the RIPE NCC also proposes to deprecate the list option on the "nserver:" attribute (a list, when used in combination with end-of-line comments and continuation lines, is very complex to parse). This means adding multiple name servers to a single attribute will no longer be allowed. For example, an attribute currently formatted as: nserver: ns1.example.com ns2.example.net will have to be rewritten as: nserver: ns1.example.com nserver: ns2.example.net If glue records are required, they would be written like this: nserver: ns1.2.0.192.in-addr.arpa 192.0.2.1 nserver: ns1.2.0.192.in-addr.arpa 2001:db8::1 nserver: ns2.2.0.192.in-addr.arpa 192.0.2.2 nserver: ns2.2.0.192.in-addr.arpa 2001:db8::2 There are a number of domain objects in the RIPE Database which use the list feature, and list multiple name servers in a single "nserver:" attribute. As part of this syntax change, we would update these objects to use the new syntax. This would not affect DNS delegation in any way. This message has been sent to both the DNS and Database working groups, but we ask that discussion of this matter be kept on the DNS WG mailing list. Regards, Anand Buddhdev RIPE NCC

1 0

heads-up for the RIPE65 schedule, September 2012
by Wilfried Woeber, UniVie/ACOnet 06 Jul '12

06 Jul '12

Dear friends of the DB-WG, just as an early heads-up and "warning", according to the (draft) meeting plan for the September meeting in Amsterdam, https://ripe65.ripe.net/programme/meeting-plan/ the DB-WG meeting slot will be on *Wednesday morning*! This is a deviation from the usual scheduling for our WG in the past, which regularly placed our slot into Thurday or Friday (morning). Best regards, Wilfried.

1 0

Deprecation of DBConstat service
by Denis Walker 05 Jul '12

05 Jul '12

Dear colleagues, The RIPE NCC has carried out a thorough review of DBConstat, a service to check consistency of data in the RIPE Database and produce statistics. It was written over ten years ago and has changed little over that period. The current software is unmaintainable now. The results of this review are published on RIPE Labs: https://labs.ripe.net/Members/denis/review-of-dbconstat The review showed that this service produces a series of almost flat line graphs and provides an interactive service barely used by anyone and resulting in no significant improvement in data quality in the RIPE Database. The RIPE NCC believes this is not the way to address the few outstanding inconsistencies reported by this service. We therefore intend to deprecate this service, then investigate and address the remaining inconsistencies using other methods, as discussed in the article on RIPE Labs. If anyone has any concerns about this service, please reply to the mailing list within the next two weeks. Regards, Denis Walker Business Analyst RIPE NCC Database Group

2 2

Database Updates service recovery
by Kaveh Ranjbar 03 Jul '12

03 Jul '12

Dear Colleagues, The issues with our RIPE Database update services is resolved. All mail sent during the downtime is now processed and sync updates, web updates and API updates are back to normal. If you experience any problems, please contact ripe-dbm(a)ripe.net. The update service was down between 07:58 CET (05:58 UTC) until 9:55 CET (07:55 UTC) due to hardware issues. Further details on this issue will be posted to RIPE Database Working Group mailing list at db-wg(a)ripe.net. Kind Regards, Kaveh Ranjbar RIPE NCC Database Group Manager

2 1

Database Updates service disruptions
by Kaveh Ranjbar 30 Jun '12

30 Jun '12

Dear Colleagues, RIPE Database sync updates, web-updates and API updates are not responding at the moment. We are dealing with hardware problems on the machines used for the database update cluster. The service was affected from from 07:58 CET (05:58 UTC) and we are working to recover it as soon as possible. Queries will keep working and updates via emails are queued and will be processed as soon as the service is up. We will send an update message as soon as the service is up or when we have an estimate on how long it takes to fix the problem. Kind Regards, Kaveh Ranjbar RIPE NCC Database Group Manager

1 0

MD5 Hashes in the RIPE Database
by Denis Walker 23 May '12

23 May '12

Dear colleagues, It was clear from the discussions at RIPE 64 that we need to change the initial implementation of hiding the hashes for MD5 passwords in MNTNER objects. A suggestion was made to keep the "auth:" attributes in place. If the authentication token is an MD5 password we will remove the hash value. All PGP and X.509 values will remain unchanged. We have already worked on this and a sample MNTNER object would look like the object below. We can deploy this change within the next two weeks. Regards, Denis Walker Business Analyst RIPE NCC Database Group $whois -B DEV-ROOT-MNT % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf [Open URL] % Information related to 'DEV-ROOT-MNT' mntner: DEV-ROOT-MNT descr: Mntner for DEV-DBM-MNT admin-c: AA1-DEV tech-c: AA2-DEV upd-to: bitbucket(a)ripe.net mnt-nfy: bitbucket(a)ripe.net auth: MD5-PW # Filtered auth: PGPKEY-1290F9D2 notify: bitbucket(a)ripe.net mnt-by: DEV-ROOT-MNT referral-by: DEV-ROOT-MNT remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV # Filtered role: DEV ROLE nic-hdl: AA2-DEV address: Somewhere in nowhere phone: +12 34 567 8900 fax-no: +12 34 567 8900 e-mail: bitbucket(a)ripe.net abuse-mailbox: bitbucket(a)ripe.net admin-c: AA1-DEV tech-c: AA2-DEV mnt-by: DEV-ROOT-MNT remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV person: Test Person mnt-by: DEV-ROOT-MNT address: Somewhere in nowhere phone: +12 34 5678900 fax-no: +12 34 5678900 e-mail: bitbucket(a)ripe.net nic-hdl: AA1-DEV remarks: This is an automatically created object. changed: bitbucket(a)ripe.net 20051031 source: DEV % This query was served by the RIPE Database Query Service version 1.9-SNAPSHOT (UNDEFINED)

8 8

Fwd: WG Action: Web Extensible Internet Registration Data Service (weirds)
by Kaveh Ranjbar 16 May '12

16 May '12

Hello all, Below you can find the announcement from the IESG on the formation of the IETF Web Extensible Internet Registration Data Service (WEIRDS) Working Group. The aim of the working group is to work on a unified whois request-and-response format based on the web technologies. If you find the subject interesting, please kindly participate in discussions using the pointers in the original announcement. The RIPE NCC will do its best to make sure requirements and current practices of our community are reflected in the discussions but your direct participation is really appreciated. Kind regards, Kaveh. --- Kaveh Ranjbar, RIPE NCC Database Group Manager Begin forwarded message: > From: IESG Secretary <iesg-secretary(a)ietf.org> > Subject: [weirds] WG Action: Web Extensible Internet Registration Data Service (weirds) > Date: May 15, 2012 6:58:40 PM GMT+02:00 > To: IETF Announcement List <ietf-announce(a)ietf.org> > Cc: weirds(a)ietf.org > > A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. > > Web Extensible Internet Registration Data Service (weirds) > ---------------------------------------------------------- > Status: Proposed Working Group > Last updated: 2012-04-24 > > Chairs: > Olaf Kolkman <olaf(a)nlnetlabs.nl> > Murray Kucherawy <msk(a)cloudmark.com> > > Applications Area Directors: > Barry Leiba<barryleiba(a)computer.org> > Pete Resnick<presnick(a)qualcomm.com> > > Applications Area Advisor: > Pete Resnick<presnick(a)qualcomm.com> > > Mailing List: > Address: weirds(a)ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/weirds > Archive: http://www.ietf.org/mail-archive/web/weirds/ > > Description of Working Group: > > Internet registries for both number resources and names have > historically maintained a lookup service to permit public access > to some portion of the registry database. Most registries offer > the service via WHOIS (RFC 3912), with additional services being > offered via world wide web pages, bulk downloads, and other > services, such as RPSL (RFC 2622). > > WHOIS has never been internationalized. In the absence of formal > specification, ad hoc solutions to signal internationalized > registration data have been adopted and deployed. Providing a > standards-based solution that scales well could minimize further > proliferation of ad hoc solutions. > > WHOIS also has no data model: replies are basically just free-form > text. This means that processing of WHOIS output amounts to > "screen scraping", with specialized handlers for every service. > While many of the domain name registries share a basic common output > format, the addition of data elements changes the output > and causes problems for parsers of the data. > > The WHOIS protocol does not offer any differential service; it > cannot differentiate among clients to offer different subsets of > information or to allow different access rates to it. > > Various attempts to solve the limitations of WHOIS have met with > mixed success. The most recent of these was IRIS (RFC 3891). > IRIS has not been a successful replacement for WHOIS. The primary > technical reason for this appears to be the complexity of IRIS, the fact > that it builds upon many available technologies that in the aggregate > form a complex system. There may also exist non-technical reasons, > but they lie in areas upon which the IETF does not pass judgement. > > In recent years, ARIN and RIPE NCC have fielded production RESTful > web services to serve WHOIS data, and each has met with success. > It is widely believed that this simpler re-use of Web technologies > familiar to modern web developers has enabled this success. The > purpose of this working group is to broaden the use of RESTful web > services by achieving simple and common URI patterns and responses > amenable to all number resource and domain name registries. > > This Working Group shall determine the general needs of such a > service, and standardize a single data framework. That framework > shall be used to encapsulate objects that could form part of an > answer. The framework shall be for data to be delivered via a > RESTful data service using HTTP (optionally using TLS), and may use > standard features of HTTP to support differential service levels > to different classes of user. The data shall have one mandatory > format, though the working group may consider other optional formats. > The overall effort will be broadly aligned with > a subset of the Cross Registry Internet Service Protocol (CRISP) > Requirements (RFC 3707), but with the explicit additional goals of > producing a simple, easy-to-implement protocol, supporting > internationalized registration data and, specifically for > name registries, capturing the needs of internationalized > domain names in the data model. > > As the number registries have more experience with these services > and have found common ground, with their dissimilarities resulting in > more complete working group input documents, the goals of the working > group are to produce standards-track specifications for both number > and name registries using the fashion and pattern of the number registry > input documents, draft-newton-et-al-weirds-rir-query and > draft-newton-et-al-weirds-rir-json-response, as an initial basis. > > Work to specify the query for domain name registration data will be > based on draft-sheng-weirds-icann-rws-dnrd. > > The Working Group shall determine the general requirements of such a > service, using draft-kucherawy-weirds-requirements as an input document, > and standardize a single data framework. The working group will likely > not seek publication of this draft. > > Should the Working Group reach a point where it determines that the > problem of producing a grand unified specification for both numbers and > names appears to be intractable, it will be permitted to divide the > problem into separate tasks and amend its milestones accordingly. > > Milestones: > > Nov 2012 Draft specifying the common infrastructure document to the > IESG for approval as a Proposed Standard. > > Feb 2013 Draft specifying the RESTful URL query format for RIRs to the > IESG for approval as a Proposed Standard. > > Mar 2013 Draft specifying the format for responses to RIR queries > to the IESG for approval as a Proposed Standard. > > Jul 2013 Draft specifying the RESTful URL query format for domain name > registration data to the IESG for approval as a Proposed > Standard. > > Aug 2013 Draft(s) specifying the format(s) for responses to domain name > registration data queries to the IESG for approval as a > Proposed Standard. > _______________________________________________ > weirds mailing list > weirds(a)ietf.org > https://www.ietf.org/mailman/listinfo/weirds

1 0

Scheduled Maintenance on RIPE Database Update Server - successful
by Denis Walker 10 May '12

10 May '12

[Apologies for duplicate emails] Dear Colleagues, The migration of the RIPE Database update service, and the content of the RIPE and TEST Databases, to a new server has been successful. If you experience any issues with the new update service please contact our Customer Services on ripe-dbm(a)ripe.net. Any update sent to the email interface during the migration should have been completed. We suggest you check the database to confirm the success of those updates in case you did not get an acknowledgement message. We appreciate your cooperation and apologise for any inconvenience this may have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Re: [db-wg] Problems with Albanian Domains
by Nikolin hajj 10 May '12

10 May '12

You can check for Albania domain in host.al is the best that offer .al domain database whois for 4000 Domain name .al not .com.al

1 0

Scheduled Maintenance on RIPE Database Update Server - 10 May, at 14:00 UTC
by Denis Walker 08 May '12

08 May '12

[Apologies for duplicate emails] Dear colleagues, On Thursday, 10 May at 14:00 UTC (16:00 CEST), we will migrate the update service to a new server as part of our RIPE Database infrastructure upgrade. We expect the migration to take up to four hours. Part of this migration requires us to reload both the live and test database contents onto the new server. ----------------------------------- No changes during migration window ----------------------------------- No changes can be made to the RIPE Database or TEST Database during the migration. This includes the use of Syncupdates, Webupdates, RESTful API and the use of object editors provided through the LIR Portal. ----------------------------------- Hold off on sending email updates ----------------------------------- We also kindly request that you hold off on sending updates to the email update service (<auto-dbm(a)ripe.net>, <test-dbm(a)ripe.net>) during the migration window to allow us to make a clean restart of the new server and perform significant testing before processing any live updates. If any updates are sent to the email update service, they will be queued and run following the migration. If you do submit email updates during this time we recommend that you check the results later. ---------------------------------- RIPE Database queries unaffected ---------------------------------- Querying the RIPE Database will not be affected as this service is completely separated from the update service. However it will not be possible to query the TEST Database. We appreciate your cooperation and apologise for any inconvenience this may cause. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

rpsltool & odd prefixes in the RIPE db
by Erik Romijn 07 May '12

07 May '12

Hello, Running rpsltool[1] against the RIPE database, it broke on a rather odd object in the RIPE database: > inet6num: 2a02:4c8::1/64 > netname: ITDNET > descr: ITD Network, AD > country: BG > ........ > route6: 2a02:4c8::1/64 > descr: ITD Network AD > origin: AS9070 > ......... That doesn't seem right - the correct prefix would be 2a02:4c8::/64. I've asked the RIPE NCC about this, and they explained that internally, the database silently discards the host bits. So for the database, this is 2a02:4c8::/64. This is also visible in whois queries: searching for 2a02:4c8::1/64 yields no results, you have to search for 2a02:4c8::/64. Upon asking, the RIPE NCC responded that this is technically valid according to the relevant RFCs. But, they acknowledged that this behaviour can be confusing, and say they intend to disallow it at a later time. Down to my specific question: has anyone made the appropriate modifications to rpsltool to handle these kind of objects, and also silently discard the host bits in the address? I imagine we can't be the first people running into this. [1] http://www.linux.it/~md/software/ cheers, Erik Romijn

2 1

Re: [db-wg] Reverse aut-num queries in the database
by Wilfried Woeber, UniVie/ACOnet 20 Apr '12

20 Apr '12

David Freedman wrote: > After the feedback from the DB-WG Meeting in Vienna last week, I'd like > to bring this back to the list. > > I'd been trying to clean up an Aut-Num to return it to the NCC. I wanted > to know if there was a way of undertaking an inverse search against the > RPSL policies of my peers' Aut-Num objects to ensure they could remove all > references to be before handing the resource back. So - do I understand this correctly, you would like to have a query that lists all route[6]: objects with a particular origin: AS number in it? Or do you think about the Routing Policy analysis, e.g. the use of a particular AS number in a "macro"? > I'm currently doing this with a free-text search, since the database doesn't hold references to the tokens in the RPSL policy (or does it?) > > Any better ideas? > > Dave. Sorry for not responding to this message for so long. Blush :-( Wilfried

2 1

The WEIRDS effort at the IETF mentioned during the meeting
by Peter Koch 19 Apr '12

19 Apr '12

Dear all, the effort mentioned at the mike in the DB WG session few minutes ago is named "WHOIS-based Extensible Internet Registration Data Service" (WEIRDS). There have been two BOFs, which is the maximum number of official pre-WG meetings the IETF rules allow and the proponents are now working towards becoming an IETF working group. Absent that state, the full extent of nice tools is not yet available, but you will find the drafts relevant to the initiative at <https://datatracker.ietf.org/doc/search/?name=-weirds-&activeDrafts=on&sear…> There is also a mailing list in the archive of which you can find the latest proposed charter: <https://www.ietf.org/mailman/listinfo/weirds>. Various participants have blogged or otherwise shared their enthusiasm to eventually solve the "whois problem". Please use a search engine of your liking or start at <http://www.internetsociety.org/articles/something-weirds-way-comes>, noting that the IETF journal is always a nice source of overview information on what's up in the IETF. -Peter

1 0

New on RIPE Labs: Two new RIPE DB Related RIPEstat widgets
by Mirjam Kuehne 19 Apr '12

19 Apr '12

Dear colleagues, Please find two articles on RIPE Labs that describe two new RIPEstat widgets: 1. The object browser for RIPE database objects: https://labs.ripe.net/Members/becha/ripestat-objects-browser-for-ripe-datab… 2. The Address Space Hierarchy widget: https://labs.ripe.net/Members/becha/ripestat-address-space-hierarchy-widget Kind Regards, Mirjam Kuehne RIPE NCC

2 1

Re: [db-wg] RIPE64 DB-WG Draft Agenda V1 --> V2
by Wilfried Woeber, UniVie/ACOnet 19 Apr '12

19 Apr '12

This is a very late update/addition to the V1 draft agenda, bumping the version to V2 :-) Wilfried Wilfried Woeber, UniVie/ACOnet wrote: > Dear DB-WG folks, Chairpersons, "Meeting"! > > This is the 1st draft of an agenda for the DB-WG at RIPE64 in Ljubljana, > during CW16, April 2012. > > For time slot allocations please refer to the most up-to-date meeting > plan at http://ripe64.ripe.net/programme/meeting-plan > > The DB-WG Meeting is scheduled for *Thursday*, April 16th, starting > at 14:00 in the afternoon (in parallel with the meeting of the IPv6-WG). > The length of our timeslot is 90 Minutes. > > Please feel free to propose additional topics to be discussed! > > I'd also suggest that you submit your points of view regarding the > topics on the proposed agenda on the mailing list, preferably before > the WG meeting's start :-) > > > Best regards, > hope to see you soon in Slovenia, > Wilfried. > > ________________________________________________________________________ > > A. Administrative Matters > . Welcome > . select scribe > . finalise agenda > . approval of minutes from previous WG meeting(s) > . review of action list > > > B. Data Base Update (N.N., RIPE NCC) [~20 min] > - general update > - geolocation status/implementation > - internationalisation > > > C. RIPEstat (Daniel K., RIPE NCC) [~20 min] > - new way of accessing database content > - discussion about access control D. Review of implementation of auth: filtering - filtering of public key information - lack of hint about type/number of attributes omitted > Y. Input from other WGs and/or TFs > > > Z. AOB > ________________________________________________________________________ > > > > >

2 2

Geolocation beta functionality now in the RIPE DB
by Alex Band 18 Apr '12

18 Apr '12

Dear colleagues, We are happy to announce that geolocation functionality now is available as a beta in the RIPE Database. It can be optionally included in the INETNUM and INET6NUM objects. With the operational experience we gain with this beta, we will continue to develop it to a production service. Two attributes have been added: - "geoloc:" - "language:" The first attribute stores the geolocation data as longitude and latitude, specifying the area where the address space is used. The second attribute sets the preferred language that users of the address space wish to see content in. In addition, we are launching the Geolocation Finder: https://apps.db.ripe.net/search/geolocation-finder.html This tool helps you find geolocation data in the RIPE Database, by simply entering an IP address in the form. If the address is covered by either location or language data, the results are shown as text and on a Google map. Kind regards, Alex Band Product Manager RIPE NCC

1 0