- db-wg - mailman.ripe.net

Re: automatic DB cleanup proposal
by kieber＠gatel.net 09 Oct '01

09 Oct '01

Somebody @ RIPE NCC, speaking for himself, not for RIPE NCC, writes: > On 2001-10-08 20:02:38 +0200, Ulf Kieber wrote: > > > > The modification timestamp would be updated whenever the object is > > updated or the link counter changes. The analogy in the UNIX file > > system would be sort of a mix of ctime and mtime. > > <snip/> > > > expire: 1 849700000 > > I suggest that this look more like the timestamp in the changed > attribute: > > expire: 1 20011008 > > Human-readable == good. :) Seconded. Daily granularity is good enough, but way more readable. Make is so. > Perhaps this attribute should also be present on maintainer and irt > objects, since they contain contact information as well? Not > necessarily as important, but possible. Then we could put it onto key-cert as well. I'm sort of reluctent to have it placed onto maintainer objects which can not be recreated without interaction with the NCC. I'd at least ask for an extended expiration period. -- Ulf Kieber email: kieber(a)gatel.net Senior Network Engineer voice: +49-69-299896-21 Global Access Telecommunications, Inc. fax : +49-69-299896-40 internet solutions for business www : www.gatel.net

1 0

Re-homing of RAToolSet to RIPE NCC
by Andrei Robachevsky 05 Oct '01

05 Oct '01

Dear Colleagues, [sorry for duplicate messages] Following Cengiz Alaettinoglu's message on this subject on the ratoolset(a)isi.edu mailing list (please find the original message attached below) it is our pleasure to announce that RAToolSet project has moved from ISI to the RIPE NCC. Starting from now the RIPE NCC will take on support and development of these tools. As a part of this move, RAToolSet will be called IRRToolSet. A new web page http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html and a mailing list irrtoolset(a)ripe.net have been established. We have subscribed all of the members of ratoolset(a)isi.edu to this mailing list. The original list will be phased out, but will forward any email to the new address. If you would like to subscribe to the IRRToolSet mailing list, put the line "subscribe irrtoolset" in the body of the message to add your address to the list, and send it to majordomo(a)ripe.net. We rely on your feedback and hope to provide the level of support you received from Cengiz and the ISI team. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

7 11

RE: Software change requests for Ripe V3 code
by Lu, Ping 04 Oct '01

04 Oct '01

Comments follwed. > -----Original Message----- > From: George Michaelson [mailto:ggm@apnic.net] > Sent: Thursday, October 04, 2001 8:27 AM > To: db-wg(a)ripe.net > Subject: Software change requests for Ripe V3 code > > > > I spoke to Joao and Andrei today about some changes APNIC would like > to see in the ripe V3 code, and we all agreed that in the spirit of > code management in an open process, they should be proposed here for > wider community review. > > So I would like to submit the following three proposals for > changes to the > current code. > > > 1) add country: [optional] [single] [ ] > to objects in RPSL schema > > 2) add some -k behaviours to permit generation of DNS zones > > 3) add a cross-correlation attribute to objects > I have no problem with item #1 and #2. However I have some comments about #3. Please see the following comments. > > 1) add country: [optional] [single] [ ] to objects > in RPSL schema > > APNIC currently uses R181 v2 perl to serve whois. We have > existing data which > is tagged by countrycode. We would like to maintain this > information in an RPSL > schema. > > We are manually adding the schema changes to the v3 code, but > we feel it would > serve wider convergeance of schema if this was in the global model. > > > > 2) add some -k behaviours to permit generation of DNS zones > > APNIC depends on locally developed code which reads the v2 > .db files to > generate a radix tree view of domain objects which are of the form > > domain: z.y.x.in-addr.arpa > nserver: foo.bar.baz > nserver: fu.bar > > this radix tree is then walked in /8 /16 and /24 forward order so > we can make zonefiles for the byte aligned boundaries, and the > matching bind named.conf inputs. > > We would like to be able to do this via a single pass, > directly from the > V3 server. WE have already demonstrated we can emit the sorted list of > the domain objects, and so a two pass process can be done, > but it will have > a far higher query load. So, we think this proposal will > generate outcomes > faster, and for less load on the server. > > We also think that this feature would be useful for people > managing other > DNS zones. > > > > 3) add a cross-correlation attribute to objects > > APNIC is investigating higher-level services for its membership based > on correlating data held across multiple servers. TO do this, we need > a cross-correlation key. We have also noticed that the > discrete objects > held by an organization in whois do not have any binding > cross-reference > except in a limited sense between nic-hdl and objects, or > maintainer refs. > I am proposing to implement the "::" delimiter specified in RFC2725 chapter 9.6. === Quote Begin ==== To specify an external repository reference, the object key is preceded by the name of the repository and the delimiter "::". For example a NIC handle may take the form "RIPE::CO19". Currently there is a desire to keep NIC handles unique so the naming convention of appending a dash and the repository name is used. Prepending the repository name provides the unique name space since an object in the RIPE database referencing "CO19" would be interpreted as "RIPE::CO19" by default, but it would still be possible to query or reference "IANA::CO19". There is no possibility of accidentally forgetting to adhere to the conventions when making an addition and the existing objects are accommodated, including cases where name conflicts have already occurred. === Quote End ==== May I suggest that RIPE NCC to implement this first on a limited set of attributes that need to cross-reference object in other source but don't need a foreign-key to ensure the integrity of the back-end database. For example: as-set: AS-TEST descr: TEST-CW-OBJECT members: CW::AS3561, CW::AS-CWTRANSIT tech-c: PL1-RIPE admin-c: PL1-RIPE notify: plu(a)cw.net mnt-by: RIPE-NCC-MNT changed: plu(a)cw.net 20011004 source: RIPE So the "members:" attribute accepts CW::AS3561, CW::AS-CWTRANSIT but it is upto the client-side tool ( RAToolSet comes into mind ) to deal with the infomation. Later RIPE NCC can implement tech-c: CW::PL1-CW mnt-by: CW::CW but this is more involved regarding the database integrity issue. > While we think we can mimic this behaviour by overloading > mnt-by: we would > perfer this is implemented as a new attribute and object, so there is > no risk of side effects (eg mnt-by implies rights to change, > and we don't > want to do that in this context) > I will think this is to address a different type of cross-reference that imply the whole object is in other RR, is it ? > > comments welcome! > > cheers > -George > -- > George Michaelson | APNIC > Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 > Phone: +61 7 3367 0490 | Australia > Fax: +61 7 3367 0482 | http://www.apnic.net > Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

Software change requests for Ripe V3 code
by George Michaelson 04 Oct '01

04 Oct '01

I spoke to Joao and Andrei today about some changes APNIC would like to see in the ripe V3 code, and we all agreed that in the spirit of code management in an open process, they should be proposed here for wider community review. So I would like to submit the following three proposals for changes to the current code. 1) add country: [optional] [single] [ ] to objects in RPSL schema 2) add some -k behaviours to permit generation of DNS zones 3) add a cross-correlation attribute to objects 1) add country: [optional] [single] [ ] to objects in RPSL schema APNIC currently uses R181 v2 perl to serve whois. We have existing data which is tagged by countrycode. We would like to maintain this information in an RPSL schema. We are manually adding the schema changes to the v3 code, but we feel it would serve wider convergeance of schema if this was in the global model. 2) add some -k behaviours to permit generation of DNS zones APNIC depends on locally developed code which reads the v2 .db files to generate a radix tree view of domain objects which are of the form domain: z.y.x.in-addr.arpa nserver: foo.bar.baz nserver: fu.bar this radix tree is then walked in /8 /16 and /24 forward order so we can make zonefiles for the byte aligned boundaries, and the matching bind named.conf inputs. We would like to be able to do this via a single pass, directly from the V3 server. WE have already demonstrated we can emit the sorted list of the domain objects, and so a two pass process can be done, but it will have a far higher query load. So, we think this proposal will generate outcomes faster, and for less load on the server. We also think that this feature would be useful for people managing other DNS zones. 3) add a cross-correlation attribute to objects APNIC is investigating higher-level services for its membership based on correlating data held across multiple servers. TO do this, we need a cross-correlation key. We have also noticed that the discrete objects held by an organization in whois do not have any binding cross-reference except in a limited sense between nic-hdl and objects, or maintainer refs. While we think we can mimic this behaviour by overloading mnt-by: we would perfer this is implemented as a new attribute and object, so there is no risk of side effects (eg mnt-by implies rights to change, and we don't want to do that in this context) comments welcome! cheers -George -- George Michaelson | APNIC Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net

1 0

draft agenda (v3 final?), for DB-WG meeting, RIPE 40, Prague
by Wilfried Woeber, UniVie/ACOnet 03 Oct '01

03 Oct '01

Dear WG list members, attached please find the 3rd (final?) draft: Proposed Agenda for the DB-WG Meeting in Prague, CZ. Item I. was added, a couple of typos were fixed as well... Please note: "the legacy address object migration" is on the draft agenda for the Plenary ("Transfer of Pre/RIR Addess Space") 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 3. Draft Thursday, October 4th, 2001 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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, Andrei R.) 30 min . 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 (summary write-up was sent to DB-WG on Aug 23rd) . review of operational impact (scripts/marketing...) . interworking with "abuse-pointers"? G. What is the Universal Whois Project? 25 min (Mark Kosters, VeriSign Labs) The intended audience would be those who are interested in discussing requirements for domain information lookup but may have direct relevance for information lookups within ip allocations et al. H. Modification of changed: attribute (RIPE NCC, Andrei R.) 15 min . problem statement . proposal . discussion I. "organisation:" Object re-visited 10 min (George Michaelson, APNIC) . background . problem statement . discussion (and proposal?) Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 25-SEP-2001 23:16:18 _________________________________:_____________________________________ 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

LIR-PARTITIONED proposal (originally LIR-ALLOCATED)
by Nurani Nimpuno 01 Oct '01

01 Oct '01

LIR-PARTITIONED PROPOSAL ------------------------ Following James Aldridge's proposal below, here follows an implementation proposal by the RIPE NCC for a new status value in the RIPE Database. Background ----------- This proposal (originally named "LIR-ALLOCATED"was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 January 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 January 2001) by Aldridge can be found at: http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.ht… At the RIPE 38 meeting,(22-26 January 2001), the RIPE NCC accepted the action to implement this proposal. Motivation (as expressed by James Aldridge) -------------------------------------------- "For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s)." Proposed Name ------------- RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use of this added database feature. As "LIR-ALLOCATED" could be misinterpreted as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable term, not involving policy terminology, but merely describing a partition of the LIR's allocation. Database Objects affected ------------------------- Only inetnum objects may have the "LIR-PARTITIONED" status value. Usage ----- The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of lower-level objects representing assignments within the address space specified by the inetnum object with the status "LIR-PARTITIONED PA" OR "LIR-PARTITIONED PI". Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules: - The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file) - The value of "LIR-PARTIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA". - The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI". Additional clarification ------------------------ This proposal addresses the added inetnum status value as proposed by James Aldridge. This is strictly a database feature, allowing LIRs to delegate maintenance within their allocations in the RIPE Database. An implementation of this proposal would not affect IP address allocation policy. It would not change the responsibility LIRs have for allocations and assignments held by them. Furthermore, it would not change the manner in which the RIPE NCC verifies allocation utilisation. Timeline -------- Before RIPE 41, January 2002. ---------------- As explained above, this implementation proposal only relates to the proposal outlined in this mail. We welcome the feedback from the LIR-WG and the DB-WG on the "LIR-PARTITIONED" proposal. However, recent comments on the lir-wg mailing list have indicated a wish among some members of the community for a more extensive change, allowing LIRs to sub-allocate IPv4 address space to subsidiaries or downstream ISPs. Such a change would be a rather significant change in current IPv4 address allocation policy, as it has an impact on the LIR's responsibility for its address space as well as the manner in which the RIPE NCC would verify utilisation. If the general feeling in the community is that the "LIR-PARTITIONED" proposal does not cover the LIRs' need, but a more significant change to current IP allocation policy is necessary, then I propose that this be discussed in detail in the LIR-WG. Kind regards, Nurani Nimpuno *--------------------------------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------*

2 1

Deletion of person objects. Final reminder
by Joao Luis Silva Damas 23 Sep '01

23 Sep '01

Dear all, (apologies for duplicates) Today is the 21st of September. As such, the RIPE NCC will proceed to delete the set of person/role objects detailed in my previous announcements from the RIPE Database. Please see the URL http://www.ripe.net/ripencc/pub-services/db/orphaned.html for information on the details of the objects to be deleted. The following is an outline of the process we will be using: 1. Stop updating the database on Friday, 21, at 18:00 CEST. 2. Remove all person objects according to the criteria: - maintained _only_ by DE domain resellers and not referenced - not maintained and not referenced This will take ~15 hours 3. Next day, on Saturday restart the server with the new database. 4. Resume the updates. As you can see, this process will result in period of a few hours during which UPDATE/ADDITION/DELETION messages sent to the RIPE Database will not be processed immediately, but rather stored for later processing. Queries will be serviced by our hot spare machine. Users will not notice any downtime on that part of the service. The length of the outage is directly related to the number of objects to be deleted (more than 2 million) and the need to use special processes to finalise the process in a reasonable time. Further to this deletion, and in order to avoid replication of the current situation after this deletion process, incoming messages containing person and role objects originating from domain name related activities will NOT be processed. The RIPE NCC will contact any source of such messages in order to clear any possible misunderstandings. Hoping to have informed you well, Joao Luis Silva Damas Chief Technical Officer RIPE NCC

3 2

permissions check
by Frank Bohnsack 20 Sep '01

20 Sep '01

dear community, since RIPE is using rfc-2725 it's sometimes not easy to find out if you have enough permissions to modify an object. often you try to update an object but your request has a typo, a missing password or something else. the request fails and many many people will become aware of your misstake. it would be very usefull if we could check our permissions before and a lot of confusions could have been avoided. current example: we need to create a lot of route objects for customer PI space. on the other hand, i see a security hole in this mechanism, because this would be an easy way to find unprotected objects. what is your opinion, could this be an option ? cheers frank -- Frank Bohnsack email fb(a)de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net

1 0

RIPE Whois Server version 3.0.2
by Shane Kerr 19 Sep '01

19 Sep '01

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.0.2 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release is intended both as a bug fix release, and also to offer much-improved ease of installation and configuration. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.0.2 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.0.2-nocxref.tar.gz A patch for the 3.0.1 "nocxref" version is also available, if you already have that version, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.1-nocxref-3.0.2… If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. -- Shane Kerr RIPE NCC

3 3

on the question of 'right to maintainership'
by Petra Zeidler 17 Sep '01

17 Sep '01

Dear all, I am herewith soliciting opinions and 'current practise' on the question of maintainership of inetnums. We are in the position of having several allocations that are infested with 'historical' PI assignments, i.e. address assignments that have been assigned before the advent of CIDR. My LIR (de.xlink) currently refuses to enter maintainers different from ours to inetnums from our allocation, due to less than happy experiences with different (even also LIR) maintainers in the past (when the user of the 'historical' PI left its new provider and renumbered they lost all interest in the inetnum and it took quite some time to get the object referring to the then long returned address space deleted). Some people seem to think that they have a right to maintainership to objects that are assigned to them; I cannot find any such rule in the LIR procedures, and also it would be a good question where that would stop .. has anybody assigned a PA /29 a right to maintain their own object? and if yes, how are the hostmasters responsible for an allocation supposed to keep their charge in order? After assignment, anything but the size of the range would be fair game, very fun especially in cases where a tech-c decides that the inetnum range is their personal property even though it has not been assigned to them personally (and that is by no means a rare occurrence). Of course both the crook and the misled are the exception, not the rule, but we -do- have maintainers in the first place because of them, and a rule ought to be based on something better than 'you look kind of trustworthy'. What's your position on the problem as such? And if you give third parties maintainership of inetnums in your allocation(s), under what rules do you do so? To any kind of inetnum? To anyone asking who has a maintainer object? And if you do so, do you still assign from that allocation(s)? kind regards, Petra Zeidler -- [A] KPNQwest Germany * Emmy-Noether-Strasse 9 * D-76131 Karlsruhe [T] +49 721 9652 215 [F] +49 721 9652 171 [E] petra.zeidler(a)kpnqwest.com [I] www.kpnqwest.de

2 1

Reminder: Removal of selected sets of contact information from the RIPE Database
by Joao Luis Silva Damas 14 Sep '01

14 Sep '01

Dear all, (apologies for duplicates) This message is a reminder of the ongoing process of removal of unreferenced contact information from the RIPE Database. We have updated the web page http://www.ripe.net/ripencc/pub-services/db/orphaned.html with a more up to date list of maintainer objects relevant to this process. I would like to use the opportunity to clarify an apparently confusing aspect of previous notes: If your person/role object already has a mnt-by attribute that references a maintainer object not contained in the list provided in the above mentioned web page, there is no need to add a reference to RIPE-NCC-PN-NONE-MNT. This maintainer has been created by the RIPE NCC with the sole purpose of facilitating a mechanism for people without maintainer objects to tag their person/role objects to avoid deletion. If you already have a proper maintainer object, DO NOT include RIPE-NCC-PN-NONE-MNT as this would lower your protection level. Best regards, Joao Damas RIPE NCC

3 4

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

03 Sep '01

Dear all, (apologies for duplicates) This is a reminder notice regarding the process of removal of selected sets of contact information from the RIPE Database as initially announced in my mail of 21-8-2001. This phase of the process will affect all person and role objects that are either: - both un-maintained and unreferenced - unreferenced and maintained by maintainers related to registration of domain names in .de For further details about this process, visit the RIPE NCC's web site at http://www.ripe.net/ripencc/pub-services/db/orphaned.html or the "RIPE NCC Annoucements" section at http://www.ripe.net Best regards, Joao Damas Chief Technical Officer RIPE NCC

1 0

RPSL WWW Whois Script ...
by Low, Adam 24 Aug '01

24 Aug '01

Hi, Was the new RPSL web whois script used by RIPE released to the general public ? Cheers, Adam

2 1

summary for CERT/IRT object proposal [3]
by Wilfried Woeber, UniVie/ACOnet 23 Aug '01

23 Aug '01

Dear TF-CSIRT, dear DB-WG community, [ and apologiess to those receiving more than one copy ] I was working with the RIPE NCC recently to finalize the implementation plan for the CERT/IRT Object. We had some interesting discussions (also including Yuri working on IODEF et.al.), and the NCC was checking "our" proposals against some implementation constraints. The result of that process is attached below. I'd ask the CERTs and IRTs in particular, and everyone else being interested, to review the summary. Please try to deploy the stuff "on your desk" and maybe submit your comments. I hope to be able to have a very final and brief discussion, and the technical "go-ahead", in Prague. As I understand from the NCC, we can then expect to see a quick implementation! Regards, and thanks to the NCC for offering very helpful suggestions, and thanks to the IRTs which have been patient for so long! Wilfried. ______________________________________________________________________ inetnum: 193.171.2.0 - 193.171.2.255 netname: ACONET-DEMO-2 descr: ACOnet addresses for demos and transient events country: AT admin-c: WW144 tech-c: UVNA1-RIPE tech-c: WW144 status: ASSIGNED PA remarks: ---------------- remarks: 20000720-20001231: UniVie/PTA ADSL trials - core remarks: ---------------- mnt-by: ACONET-LIR-MNT mnt-irt: ACONET-IRT # use irt object name here changed: panigl(a)cc.univie.ac.at 20010629 source: RIPE irt: ACONET-IRT address: ACOnet Incident Response Team address: c/o Vienna University Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna, Austria phone: +43 1 4277 140 00 fax-no: +43 1 4277 9 140 e-mail: Domain-Admin(a)UniVie.ac.at signature: PGPKEY-<key-id> # IRT team key first (mand.) remark: # member keys next (optional) remark: # messages from the IRT are remark: # signed with this/ese key/s encryption: PGPKEY-<key-id> # use this to encrypt a message remark: # to be sent to the IRT remark: # multiple entries allowed admin-c: WW144 tech-c: WW144 auth: CRYPT-PW bocEHQ0niH52I # checked to authenticate auth: PGPKEY-DBC579D4 # insertion of ref. to this obj. notify: Woeber(a)CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT # use the regular mntner: mech. remark: # to protect the irt object changed: woeber(a)cc.univie.ac.at 20000202 source: RIPE mntner: ACONET-LIR-MNT descr: ACOnet Local-IR admin-c: WW144 tech-c: WW144 upd-to: Domain-Admin(a)UniVie.ac.at mnt-nfy: Domain-Admin(a)UniVie.ac.at auth: MAIL-FROM .*(a)cc\.univie\.ac\.at # a *very* bad example auth: PGPKEY-DBC579D4 notify: Woeber(a)CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT referral-by: RIPE-DBM-MNT changed: woeber(a)cc.univie.ac.at 20000202 source: RIPE Operations: irt: object creation is manual (like mntner:) Semantics/Security: "auth:" mechanisms specified are used for authenticating the reference insertion. For an irt: object, only CRYPT-PW and PGPKEY SHOULD be used! However, this recommendation is not enforced by the DB software. This is considered to be a BCP issue. The 1st entry in the list of signature: SHOULD be the team-key, any additional entries MAY BE secondary team keys and/or team members' keys. This is considered to be a BCP issue. The key-cert objects for the PGP keys will be stored in the public keyring. More generally, only keys supported by the RIPE DB will be allowed. However, as soon as the DB accommodates additional certificate formats, those should be allowed here as well by default. Lookup and use: $whois iplookup Default behaviour, no irt is returned (as expected) because mnt-irt is more a mntner reference, which is never returned automatically. The user will need to perform a second query to retrieve info about the IRT. This will also reduce the abuse of an irt object by people sending reports to whatever e-mail address they see in an output. $whois -c iplookup This query would do a tree-walk, like the referral mechanism, trying to find an entry with an mnt-irt attribute present. The query will display an object containing the reference, but not the irt object itself. Again, people will need to perform a second query to retrieve info about the IRT. The ideas behind this proposal are: - not to alter the default behaviour for object lookups (only contact info is returned, not mntners) - not to modify the behaviour of -l flag. [ed. comment: during the discussion we were thinbking about modifying the behaviour of the -l flag when a -c flag were present.] Questions/Comments: Q: Do we allow any mntner: object in an irt: object's mnt-by: attribute, even those having weak authentication? A: no special provisions in the software. This is considered to be a BCP issue. A: a more useful approach is to deprecate weak authentication mechanisms altogether. Q: Do we want to have/allow a hierarchy similar to mnt-lower: for .e.g. inetnum: and inet6num: objects? A: no Q: should the reference to an irt: object be it's name or it's handle? A: the irt object is very similar to mntner object, so global uniqueness should not be an issue. Q: Do we want something like a trouble: in the role:, or simply use remark or put an (optional) abuse attribute into the irt object? A: probably not. Including uniform info for spam or abuse contacts is a BCP issue. [ed. comment: see discussion on anti-spam list.] Q: do we want to use more descriptive attribute names for signature and encryption? E.g. irt-sig: and encrypt:, or sig-from: and encrypt-to: Q: no clear preference, no decision in WG... so, what? A: stick with signature and encryption Decisions: Do not implement a url: attribute. Can be done with remark: Interaction with (public) key servers is outside the scope of this proposal. Implement irt object for inet[6]num initially. Extending functionality to e.g. AS number objects [ed. comment: and route objects] leads to the interesting question how to extend RPSL. This is similar to the issue of IPv6-extensions to RPSL. Separate project. Suggested object templates: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] encryption: [mandatory] [multiple] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inetnum: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... inet6num: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... _________________________________:_____________________________________ 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

Re: New RIPE-147 needed!
by Sabrina Waschke 23 Aug '01

23 Aug '01

Berislav, Thank you for your comments regarding the AS Number request form. You are correct in that the RIPE-147 document needs updating due to the new RPSL syntax. Over the last couple of months the RIPE NCC has been working hard on writing new documentation, developing training material and updating current documents to adjust to the new database software. RIPE-147 is on our to-do list and you should be able to expect a new version in the near future. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Berislav Todorovic <beri(a)kpnqwest.net> writes: * 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

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