- db-wg - mailman.ripe.net

Re: Re[2]: Removal of selected sets of contact information from the RIPEDatabase
by hostmaster＠bsws.de 23 Aug '01

23 Aug '01

owner-db-wg(a)ripe.net wrote on 23.08.2001 15:34:38: > At the moment there is not. I have just spoken to DENIC though, and > they told me they were migrating those person objects to an own DENIC > database. The same was done for domains quite a while ago also by the > way, domains were stored in the RIPE database and have been ported to > DENIC. Also, most other NICs have - according to my infos - already > migrated to own databases, why would not DENIC do also? That's not the question here. The problem is he way DENIC wants to migrate and their non-existant information politics. As always, not a single statement on public-l(a)denic.de - but that's not RIPE's fault of course. Thanks for the information (we should have had from DENIC long time ago) and keep up your good work. Greetings Henning -- BS Web Services | www.bsws.de Roedingsmarkt 14 | hostmaster(a)bsws.de 20459 Hamburg Germany

1 0

RPSL: Providers exchanging full tables.
by Low, Adam 23 Aug '01

23 Aug '01

Hi, Mr. Nipper had pointed out an interesting issue with our as-macro recently, I believe its the first situation we've come across that isn't easily depicted within an RPSL routing policy without the requirement to manually update multiple near identical objects. The situation arises when we exchange full route tables with another provider, we then in turn should announce their prefixes listed in their macro onto our other providers and they too should do the same for our respective macro. So by adding each others macros to each others macros, we effectively create loops. Now is this a real problem ? In my opinion, I don't think it is, I believe that to truly understand the policy between two peers you have to take into account more (aut-num/import/export) than just the contents of an as-macro and that any tool that uses as-macros to generate prefix lists should check for duplicates and loops. It also appears that the tools we use today (RtConfig/peval) are not adversely effected by providers listing each others macros, output is as expected. Does anyone else have a view on this or a good idea of how it can be easily depicted within RPSL ? Cheers, Adam

1 0

Re: Removal of selected sets of contact information from the RIPEDatabase
by Christian Zietz 23 Aug '01

23 Aug '01

Hi, > 1. The following unreferenced person objects will be deleted: > - objects referenced only from *.de domains, according to the list > provided by DENIC (or list of mntners that define that set); > - objects that are un-maintained. Did I understand that correctly? Objects (e.g. persons) referenced only from .de domains are going to be deleted even if they are maintained (e.g. by DENIC-P). Imho that would be quite a big problem because DENIC's database relies on the RIPE database for person objects. Afaik there's no possibility to create a person object directly in the DENIC database. Christian

4 3

draft agenda (v1), for DB-WG meeting, RIPE 40, Prague
by Wilfried Woeber, UniVie/ACOnet 23 Aug '01

23 Aug '01

Dear WG list members, fellow chair persons, dear "meeting" role account! Attached please find the 1st (very rough) draft: Proposed Agenda for the DB-WG Meeting in Prague, CZ. As usual, comments, suggestions and additions are welcome! I am going to be on the road from Aug. 24th to Sept. 16th, probably with very limited access to The Net (if at all). Therefore it might take a while for me to respond.... Looking forward to see many of you in Prague, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-40, Oct. 1-5 2001, Prague, CZ 1. Draft XyzAday, October ???, 2001 ??:?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . volunteering a scribe . circulate list of participants . agenda bashing . status of minutes B. Actions Items . status of actions . C. DB update (RIPE NCC, N.N.) 30min . operations report . software status . migration summary D. removal of "orphaned" person objects (RIPE NCC, N.N.) 10 min . report and conclusions (if any :-) E. Status of the Merit RADB/IRRd 20 min (Larry J. Blunk, Merit Network, Inc.) F. Report and final discussion: irt: object implementation 20 min (Wilfried W., RIPE NCC, N.N.) . review of implementation proposal . review of operational impact (scripts/marketing...) . interworking with "abuse-pointers"? Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 23-AUG-2001 15:34:49 _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Removal of selected sets of contact information from the RIPE Database
by Joao Luis Silva Damas 23 Aug '01

23 Aug '01

Dear all, (apologies for duplicates) As you know, the subject of storage of person and role objects in the RIPE Database has been the focus of attention for some time, particularly information being stored in the Database that is not directly related to RIPE NCC activities and/or some of the people whose information is stored in the RIPE Database are not aware of the fact. During the RIPE 39 meeting in Bologna, I reported on increasing concerns about data privacy issues and potential legal implications the RIPE NCC could be involved in due to some of this data. Call it a coincidence,but we have been approached by the Dutch Data Protection Agency a few weeks ago to discuss this matter. The agency's action is taken on behalf of other similar global agencies who have requested their Dutch counterparts to act as the RIPE NCC is based in the Netherlands. As a result of the discussions, the authorities have requested the RIPE NCC to remove all unreferenced data currently stored in the Database. This affects mainly person objects related to domain name registration information stored in the RIPE Database. In order to minimise annoyances to users and the membership we would like to proceed with the process in a timely manner. In order to prevent undue deletions we propose the following process: 1. The following unreferenced person objects will be deleted: - objects referenced only from *.de domains, according to the list provided by DENIC (or list of mntners that define that set); - objects that are un-maintained. 2. Those who want to protect their objects in the database should tag them with a special mntner (RIPE-NCC-PN-NONE-MNT). This procedure is solely meant for personal use by individuals interested in keeping their personal data in the RIPE Database. However, this is subject to change in the future. 3. All of the object deletions will be performed in one step. There will be an outage in updates for ~1 day. We plan to start the process Friday, 21 September 2001 in the evening and finish by the end of Saturday. More concrete details will be provided in the coming weeks. Best regards, Joao Damas RIPE NCC

2 1

New RIPE-147 needed!
by Berislav Todorovic 23 Aug '01

23 Aug '01

Maybe this will sound like a hassle, but ... ... Everytime I receive a ripe-147 form from teh customer I have to "patch" it myself, to make it compliant with the new RPSL syntax. Any chance to get the new, RPSL-capable form in place (but as a NEW RIPE document, please!)? Here's what should be changed: * Add "as-name:" attribute. * Replace "as-in:" with "import:" and "as-out:" with "export:". * Check to see if RPSL syntax is honored. * Check the examples and make them compliant with RPSL syntax. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0

Limitation in the RPSL DB
by Stephen Burley 08 Aug '01

08 Aug '01

Hi We have hit a small problem with the RPSL DB structure. As the RPSL DB is supposed to reflect the real routing world we need some functionality adding to the DB. It is possable for PA that is part of a multihomed customer to have a differant origin to that of the main block of ip space. Can we get this refelected the in RPSL DB structure? Would you like me to explain further? Regards Stephen Burley UUNET EMEA Hostmaster

4 3

sub-allocations or something similar
by Dmitry Morozovsky 08 Aug '01

08 Aug '01

Hello there colleagues, for some last years I'm working with RIPE DB I think it would be useful to have some kind of "sub-allocation" inetnum objects. Brief example in our current situation: there is downstream provider behind us, currently without its own address block, so I've assigned /21 for them. All that space was of course well-documented, with ripe-141's covering all the nets, and appropriate inetnum objects have been created. But, for aggregating purposes, I suppose aggregating inetnum for the whole /21 would be useful and self-documenting. I can create such object, but such object is considered as overlapped. I think about explicit route-object also, but size behind current minimum allocation size (/19 for 195/8 or /20 for newer) somewhat stops me :) Your (both community and especially RIPE NCC people) suggestions are strongly expected ;-) Thank you. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(a)rinet.ru *** ------------------------------------------------------------------------

4 4

Problems with Albanian Domains
by Elvis.Samson＠ernst-young.de 26 Jul '01

26 Jul '01

Hi, why is the albanian domain inima.al accessible through internet, but not listed in the ripe database? there are some european TLDs, where I couldn't find accessible websites in the ripe database. is there a reason for this or an error? regards and thanks for your help, elvis samson

2 1

RE: Problems with Albanian Domains
by Wilfried Woeber, UniVie/ACOnet 26 Jul '01

26 Jul '01

>why is the albanian domain inima.al accessible through internet, but not >listed in the ripe database? That is most probably due to the fact the RIPE DB is *not* an authoritative registry for (forward) domain names. While some TLD administrations indeed did use the RIPE-DB for some years to maintain a list of allocated/delegated domains, there was a major push during 2000 to remove (close to) all forward domain entries from the RIPE-DB. The RIEP-DB is still authortitative for the reverse Domains for address space that was distributed by way of the RIPE NCC. >there are some european TLDs, where I couldn't >find accessible websites in the ripe database. is there a reason for this >or an error? All TLD Administartors are welcome to register an object for the TLD itself - including a pointer to the whois server that in turn can answer queries. This mechanism is called "referral" and it works for some, but not for all, european TLDs. For an example how this looks like in reality, do a whois-query for e.g. $ whois -h whois.ripe.net -T domain unige.ch While this mechanism is available as an offer, neither the RIPE NCC nor the DB-WG have a mandate to urge TLD administrators to use that faciliy. >regards and thanks for your help, >elvis samson Just in case you want to follow up on Albanian domains, I'd suggest you get in touch with <Francesco.Gennai(a)iat.cnr.it> . This gentleman is listed as a contact in the SOA record for the TLD "AL". ______________________________________________________________________ bash$ nslookup Default Server: wsww.xx.xxxxxx.xx.at Address: 131.130.x.xxx > set q=soa > al. Server: wsww.xx.xxxxxx.xx.at Address: 131.130.x.xxx al origin = itgbox.iat.cnr.it mail addr = Francesco\.Gennai.iat.cnr.it [ ... ] ______________________________________________________________________ Best regards, -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0