October 2001 - 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

LIR-PARTITIONED - Final version
by Nurani Nimpuno 23 Oct '01

23 Oct '01

Dear all, Following the announcement 28 Sep 2001 on these lists, please find below the final details of the LIR-PARTITIONED PROPOSAL. This proposal will be implemented by the RIPE NCC in the coming period and presented at the RIPE 41 meeting in January 2002. Comments and suggestions made on this list have been incorporated in the proposal below. +-----------------+ | LIR-PARTITIONED | +-----------------+ Background ----------- This proposal (initially named "LIR-ALLOCATED") was originally discussed at September 1999. James Aldridge later sent out a first proposal to the LIR-WG mailing list, 14 Jan 2000. (See: http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.ht…) The full final proposal (15 Jan 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 Jan 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)." 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-PARTITIONED PA" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PA" or "LIR-PARTITIONED 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" or "LIR-PARTITIONED 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. The implementation of this proposal will not affect IP address allocation policy. This means that it will not affect the responsibility LIRs have for allocations and assignments held by them. Furthermore, it will not change the manner in which the RIPE NCC verifies allocation utilisation. There is an on-going policy discussion addressing this specific issue. Kind regards, Nurani Nimpuno *-----------------------------------* | Nurani Nimpuno <nurani(a)ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *-----------------------------------*

1 0

changed attribute proposal and not only
by Andrei Robachevsky 11 Oct '01

11 Oct '01

Dear Colleagues, Please find enclosed the proposal of modification of the changed attribute that was presented at the RIPE-40 meeting in Prague. However, another proposal (or rather idea) came up in light of recent discussions regarding timestamping and cleanup procedures in the RIPE Database. Let me present you this idea first. As was pointed by the two proposals there is a need to store and display status information about an object in the database, such as last update time, number of references, etc. At the same time in order to be reliable this information should be automatically generated by the database software and be outside users' control. Regarding "changed attribute" proposal people felt that this changes some of the basic principles of the RIPE Database. Recent Ulf's proposal makes things even worse since it requires that modification to an object may be caused by an update of another object. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf's analogy with the Unix FS, they are part of the inode, not the data blocks. So status information (object metadata) may be stored and displayed separately from the object itself by, say, using a flag. Much like we display the contents using cat, but status using ls. And this information will be used for cleanup procedure, reliable timestamping, etc. This will not affect any object template, preserve users' data and add flexibility to the database. Something like this: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon(a)somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %ref-count: 3 Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Reminder: RIPE-181 to RPSL Migration; Phase 3.
by Andrei Robachevsky 09 Oct '01

09 Oct '01

Dear Colleagues, [Apologies for multiple messages] On and from Monday, 15th October, 2001, the RIPE Database will no longer accept updates in RIPE-181 format. Mail robot at <auto-181(a)ripe.net> will be shutdown. The update path for the TEST database will also be changed. We plan to discontinue <test-181(a)ripe.net> service on 11th October, 2001. If you are still sending updates in RIPE-181 format, we advise you to switch to RPSL before 15th October. Please send your objects in RPSL format to <auto-dbm(a)ripe.net>. You may use ripe2rpsl utility to convert your RIPE-181 objects to RPSL format before sending them to the RIPE Database. The utility can be found at ftp://ftp.ripe.net/tools/ripe2rpsl-3.0.2.tar.gz. As part of this final step we will also make some cleanup of the ftp.ripe.net site. - The top directory for the RIPE Database software and flat object files is ftp://ftp.ripe.net/ripe/dbase. - "Short" versions of flat object files [*] will not be supported. [*]Version of a flat object file where attribute names are abbreviated to 2 letter code starting with '*'. The name of the object file also contains the object type in abbreviated form. For example ripe.db.in is the "short" version of the flat file for inetnum objects, while ripe.db.inetnum is the "long " version that is RPSL compliant. For more information please visit http://www.ripe.net/rpsl If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

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

09 Oct '01

Re everybody, following up to some personal talks during the RIPE meeting I propose an automatic cleanup of orphaned person and role objects in the RIPE DB. Motivation ---------- In the light of data privacy issues raised by governmental organizations and in RIPE Database Working Group sessions during RIPE-39 and RIPE-40, as well as following the Great Dangling Person Objects Deletion after de.* ccTLD move-out I propose an automized garbage collection procedure to remove personal data that is unreferenced for a certain amount of time. Proposed Change --------------- An additional attibute ``expire:'' with two values should be added to all person and role objects. The values to this attribute would be a reference counter and a modification timestamp. The reference counter would contain the number of objects still refering to this object, and thus be analog to the link counter of an inode in a UNIX file system. 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. Both values could be combined into a single value, but each value of it's own may be of interest to some people. Combining both values would leave the resulting value useless to human interpretation. A garbage collection process running on a periodic basis should then delete all objects with a reference counter of ``0'' and a modification timestamp of more than e.g. 8000000 seconds (approx. 3 month) ago. The expiration period is to be discussed and agreed upon in the community. An additional switch to the whois client should be added to make the otherwise invisible attribute visible, the DB should consequently not accept ``expire:'' attributes in updates. (The DB could certainly be made more forgiving about this, but since the move to v.3 tightened the syntax we should probably not weaken it again.) Database Objects affected ------------------------- An additional attribute would be added to all person and role objects. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] expire: [generated] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Example ------- inetnum: 10.0.0.0 - 10.0.255.255 netname: XMAS descr: Santa's Workshop Inc. Christmas Toys Manufacturing Facility Northern Nowhere country: NN admin-c: SC12-RIPE tech-c: SWT95-RIPE status: ASSIGNED PA mnt-by: SANTA-SECURITY-MNT changed: jbgood(a)antarctic.nn 19960412 source: RIPE role: Santa Workshop Team address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 3333 fax-no: +12 12 221 4444 e-mail: team(a)antarctic.nn admin-c: SC12-RIPE tech-c: SC12-RIPE tech-c: RD212-RIPE nic-hdl: SWT95-RIPE mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Santa A. Claus address: Santa's Workshop Inc. Jingle Bell Lane 12 1224CH Christmastown Northern Nowhere phone: +12 12 122 2121 +12 12 122 2211 ext. 1221 fax-no: +12 12 221 1212 e-mail: santa(a)antarctic.nn nic-hdl: SC12-RIPE mnt-by: SANTA-SECURITY-MNT expire: 3 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE person: Rudolf R N Reindeer address: Santa's Workshop Inc. Jingle Bell Lane 21 1224CH Christmastown Northern Nowhere phone: +12 12 122 1111 fax-no: +12 12 122 2222 nic-hdl: RD212-RIPE e-mail: rudolf(a)xmas.nn mnt-by: SANTA-SECURITY-MNT expire: 1 849700000 changed: jbgood(a)antarctic.nn 19960412 source: RIPE -- 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 The Database Toothbrush Proposal

4 4

Re: automatic DB cleanup proposal
by Wilfried Woeber, UniVie/ACOnet 09 Oct '01

09 Oct '01

Dear George, >I am worried that there may be *external* referencees to objects, and while >we have no 'contractual' obligation it might not be nice to do this >to people without some engagement but I expect most people would welcome >losing a path to spam. without going into any detail of the proposal itself, I perceive the fact that there are external references (allowed) _without "consent" and without documentation_ a major flaw in the architecture. In fact, there are mechanisms available already (at least in the RIPE DB-SW V2.x and V3.x) that allow us to deal with that requirement: maintainer objects. >As to automatic sweeping, I think there are problems with link counting >which are similar to those we've faced in discussing cross-database linkage >and references. Too many risks of the link count getting out of whack. Fair enough, a very valid concern! But I think the proposal is trying to describe the "user view" and the "abstract behaviour". >I think you could use it as a guide to a sweep, but not as a determinant >without some review and other checks. Eg to trigger more exhaustive checks >to see if there are are references in twisty ways. I agree. >cheers > -George Cheers, and thanks for partcipating in this discussion! Wilfried.

2 1

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