May 2012 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

RIPE NCC Training Courses April-June 2012 - IL, BE, IS, PL, RU, FI, NL, DE, ES, HR
by Training Mailbox 08 Oct '12

08 Oct '12

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Tel Aviv, Brussels, Reykjavik, Belfast, Gdansk, Yekaterinburg, Helsinki, Amsterdam, Munich, Seville and Croatia. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 4

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