- db-wg - mailman.ripe.net

draft agenda (v1), for DB-WG meeting, RIPE 43, Rhodes, GR
by Wilfried Woeber, UniVie/ACOnet 26 Aug '02

26 Aug '02

Dear WG list members, attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 43 in Rhodes, GR. As usual, if you have any comments, corrections or additions please get back to me directly. Looking forward to see many of you in Greece, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR 1. Draft Thursday, Sept. 12, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) 10 min . scribe (offer to take notes received from Nigel) Slot 1 . circulate list of participants, agenda bashing . status of minutes [ see http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html ] B. Action Items 15 min . status of actions Slot 1 [ see http://www.ripe.net/ripe/wg/db/db-actions.html ] C. DB update (RIPE NCC, Andrei R.) 15..20 min . operations report Slot 1 . development activities D Web interface for updates (RIPE NCC, Can Bican) 15min(??) Slot 1 E. IRRToolSet Development Brainstorming 20min . how to find out who is using what? Slot 1 . RPSLng interaction F. External Object References 10min [ maybe this should go into item E.?? ] G. "Early Registration Transfer" Project 45 min . review of experience with AS Number transfer probably . proposal for IP Address Space by NCC Slot 2 . develop recommendations to - complete the transfer as quickly as reasonably possible? - limit the work-load impact on the users' end - limit the work-load impact on the NCC's end Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 26-AUG-2002 12:13:25 UTC _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

RE: Proposal for adding external repository reference to import/e xpor t attributes
by Lu, Ping 25 Aug '02

25 Aug '02

Right now, I think we only need to implement the "::" notation in the RFC2725. For this I think RFC2725 is the result of the standard process and there is no need to re-open RPSL WG to repeat that again. However the reason we proposed to implement "::" notation is to address the need for EXTERNAL REFERENCE. For that I think it might be necessary to start the WG discussion on how do we support the EXTERNAL REFERENCE in the near future. Let's just start implementing the "::" notation while we can also start the discussion on the topics of EXTERNAL REFERENCE. I don't know if here is the proper place to start the discussion or we should go somewhere else ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Mark Prior [mailto:mrp@mrp.net] > Sent: Saturday, August 24, 2002 8:08 AM > To: curtis(a)fictitious.org > Cc: Lu, Ping; db-wg(a)ripe.net; irrtoolset(a)ripe.net > Subject: Re: Proposal for adding external repository reference to > import/expor t attributes > > > At 3:10 PM -0400 23/8/02, Curtis Villamizar wrote: > >It is possible to reactivate a WG on the mailing list only, for the > >purpose of updating an existing RFC and not having a meeting. This > >was done with TCPLW for RFC1323. Cengiz would need to > update RPSL (as > >primary author and keeper of the source of that document). > > > >Is the only change needed at this point the :: notation to indicate > >external repository? If so, no change is needed to RFC-2622 > since the > >:: notation is called for in RFC-2725 and it wouldn't be worth > >updating RFC-2622 just for that. > > > >What you really need to do is get Larry Blunk to update the > ISI tools. > > Curtis, > > I wasn't the person suggesting making changes, I was just suggesting > that you needed to follow a procedure in order to make it happen and > couldn't just "fix" it in software. I would suggest if people think > this is a good idea (and I haven't really thought about it) then > perhaps merging it into the RPSLng work would be the way to go. > > Mark. > >

1 0

Re: Proposal for adding external repository reference to import/expor t attributes
by Mark Prior 24 Aug '02

24 Aug '02

At 3:10 PM -0400 23/8/02, Curtis Villamizar wrote: >It is possible to reactivate a WG on the mailing list only, for the >purpose of updating an existing RFC and not having a meeting. This >was done with TCPLW for RFC1323. Cengiz would need to update RPSL (as >primary author and keeper of the source of that document). > >Is the only change needed at this point the :: notation to indicate >external repository? If so, no change is needed to RFC-2622 since the >:: notation is called for in RFC-2725 and it wouldn't be worth >updating RFC-2622 just for that. > >What you really need to do is get Larry Blunk to update the ISI tools. Curtis, I wasn't the person suggesting making changes, I was just suggesting that you needed to follow a procedure in order to make it happen and couldn't just "fix" it in software. I would suggest if people think this is a good idea (and I haven't really thought about it) then perhaps merging it into the RPSLng work would be the way to go. Mark.

1 0

Early Registration Transfer Project
by Joao Luis Silva Damas 21 Aug '02

21 Aug '02

Dear Colleagues, Prior to the formation of the RIPE NCC, all Internet resources were issued by the InterNIC and its predecessors, based in the USA. The RIPE community has decided to transfer registrations of resources used in the RIPE NCC Service Region to the RIPE Whois Database. Initially we will transfer Autonomous System Number registrations. The work will start on 21 August 2002, with the transfer of ASN records. Contacts for all registrations to be transferred will be notified by a separate e-mail detailing the process. A brief report on the results of the transfer process will be made at RIPE 43 in Rhodes. During and after the RIPE 43 meeting there will be the opportunity to discuss any issues that may arise from the transfer of IPv4 registrations. A complete list of ASN registrations being transferred and details of the transfer process are available from our web site at: <http://www.ripe.net/ripencc/pub-services/db/erx.html> In the meantime should you have any further questions please contact us at: <er-transfer(a)ripe.net> Kind regards, Joao Damas RIPE NCC

2 2

call for input: draft agenda DB-WG RIPE#43, Rhodes, GR
by Wilfried Woeber, UniVie/ACOnet 21 Aug '02

21 Aug '02

Dear RIPE DB-WG community! I am pretty close to distributing the 1st draft for the Proposed Agenda, DB-WG meeting, during RIPE#43. It will again feature some of the "traditional" DB-WG items, as well as some items which have already been proposed by the RIPE NCC. If there are any other issues (_within the remit of the WG_) which you want to see on the draft agenda, or if you want to get a report/presentation slot, please come back to me (directly), asap. Thanks, regards, Wilfried (DB-WG chair) _________________________________:_____________________________________ 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

Transferring InterNIC space from ARIN Database to other RIR databases
by Gabriella Paolini 19 Aug '02

19 Aug '02

"Transferring InterNIC space from ARIN Database to other RIR databases". Any news about that? Regards, Gabriella Paolini ------------------------------------------------- GARR - The Italian Academic and Research Network http://www.garr.it m@il: gabriella.paolini(a)garr.it -------------------------------------------------

3 2

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

Phase 4 of the MAIL-FROM deprecation
by Andrei Robachevsky 16 Aug '02

16 Aug '02

Dear Colleagues, As you may know the third phase of phasing out the MAIL-FROM authentication scheme from the RIPE Database resulted in a very high rate of requests to update mntner objects coming to the Database Administration, ripe-dbm (please see my message on this subject http://www.ripe.net/ripe/mail-archives/db-wg/20020701-20021001/msg00021.html). The requests are coming from the owners of the mntner objects that still use only MAIL-FROM authentication scheme and therefore are locked. We still have about 1500 such mntner object whose owners didn't use the opportunity to update their objects during previous phases and now have to apply to ripe-dbm to fix this situation. Taking into account that this puts extra load on ripe-dbm and takes resources from serving the usual types of requests I'd like to propose a change for the phase 4 of the process of phasing out the MAIL-FROM authentication scheme. According to the agreed procedure (http://www.ripe.net/db/MD5-HOWTO.html#b._Migration_timeline) during the phase 4 maintainers with "auth:" attributes using "MAIL-FROM" will have those attributes removed. This is a clean-up step. In addition we would like to do the following: 1. mntners with MAIL-FROM authentication _only_ will be updated in the following way: - a password will be auto generated and all MAIL-FROM "auth:" attributes will be replaced with one auth: MD5-PW $1$<generated_string>; - a mnt-by: attribute will be added referencing a protected mntner RIPE-MAIL-FROM-MNT. This will serve as a tag. 2. A clear text password can be requested by sending an e-mail to ripe-dbm(a)ripe.net with the following in the subject line: MAIL-FROM:<mntner_name> without any spaces. The reply with the passphrase will be sent to contacts listed in "upd-to:" and admin-c's "e-mail:" of the mntner. 3. After that the mntner should be updated to remove the mnt-by: RIPE-MAIL-FROM-MNT attribute and to possibly change the password. 4. After a certain period of time (2 months) the service will be discontinued and decision will be made about the mntners that still haven't been modified (still bear the RIPE-MAIL-FROM-MNT tag). We will extend the deadline of the phase 4 till 15 August to have time to come to an agreement. I kindly ask you to consider this proposal and comment before that day. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 1

New Document available: RIPE-252
by RIPE NCC Document Announcement Service 15 Aug '02

15 Aug '02

Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-252 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 15 August 2002 Format: PS=283252 TXT=134071 Obsoletes: ripe-251 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the functionality of version 3.0 of the RIPE Database that uses the Routing Policy Specification Language (RPSL) to represent all Database objects. It also implements the Routing Policy System Security (RPSS) to provide authorisation mechanisms to enable a higher level of security for Internet Routing Registries (IRR). Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. The Database Reference Manual is available from the WWW at the following URL: http://www.ripe.net/docs/databaseref-manual.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-252.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-252.txt plain text version

1 0

Updating inet6num objects with a legacy status attribute
by leo vegoda 06 Aug '02

06 Aug '02

Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" <http://www.ripe.net/docs/new-value-status.html> The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

Some updates were not processed today
by Andrei Robachevsky 05 Aug '02

05 Aug '02

Dear Colleagues, Unfortunately several (136) update messages were not processed by the RIPE Database today, 5 August 2002. We are reluctant to re-process them as this may override the changes that might have been made afterwards. If you haven't received an acknowledgement to the update you sent to the RIPE Database today, please re-submit it again. We sincerely apologise for the inconvenience this caused. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

New Document available: RIPE-243
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "New Values of the "status:" Attribute for inet6num Objects". Short content description ------------------------- This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "New Values of the "status:" Attribute for inet6num Objects" is available from the WWW at the following URL: http://www.ripe.net/docs/new-value-status.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-243.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-243.txt plain text version Kind Regards, Jeroen Bet Webmaster RIPE NCC

1 0

Actions web page
by Nigel Titley 30 Jul '02

30 Jul '02

Folks, Please note that there is now a separate actions page on the DB WG web site. http://www.ripe.net/ripe/wg/db/db-actions.html Check now and avoid embarrassment at the next WG meeting :-) All the best NIgel

1 0

fwd: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects"
by Wilfried Woeber, UniVie/ACOnet 26 Jul '02

26 Jul '02

Sorry, I forgot to cc: the DB-WG list :-( I guess we should keep this thread in the LIR-WG list for the moment. Apologies for the mix-up, Wilfried. ______________________________________________________________________ From: ACCESS::WOEBER "Wilfried Woeber, UniVie/ACOnet" 26-JUL-2002 11:39:50.52 To: MX%"leo(a)ripe.net" CC: MX%"lir-wg(a)ripe.net",WOEBER Subj: Re: New draft: "New Values of the 'status:' attribute for inet6num Objects" Dear Leo and "Team", >The new draft is available from our web site at: > ><http://www.ripe.net/ripe/draft-documents/new-value-status.html> Looks good! >We would welcome comments on this new draft until Thursday, 1 August >2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Procedural question: How are we going to modify existing objects to conform to this proposal? Right now the template query returns: bash-2.05a$ wripe -t inet6num [ ... ] inet6num: [mandatory] [single] [primary/look-up key] [ ... ] status: [generated] [single] [ ] [ ... ] and it seems to be "optional" for the (new) ALLOCATED-BY-RIR case: bash-2.05a$ wripe -r 2001:0628::/35 [ ... ] inet6num: 2001:0628::/35 netname: AT-ACONET-19990920 descr: ACOnet Sub-TLA block country: AT admin-c: WW144 tech-c: WW144 tech-c: WK42 tech-c: CP8-RIPE notify: Domain-Admin(a)UniVie.ac.at mnt-by: RIPE-NCC-HM-MNT mnt-lower: ACONET-LIR-MNT changed: hostmaster(a)ripe.net 19990920 changed: hostmaster(a)ripe.net 20011019 source: RIPE Is this going to change? E.g. to: status: [mandatory] [single] [ ] The wording used in the draft seems to indicate [optional] [single] [ ]. I think some clarification would be helpful. Thanks, cheers, Wilfried. _________________________________:_____________________________________ 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

New draft: "New Values of the 'status:' attribute for inet6num Objects"
by leo vegoda 25 Jul '02

25 Jul '02

Dear Colleagues, Thank you for the comments we have received on the draft document "New Values of the 'status:' attribute for inet6num Objects". We have revised it to incorporate the suggestions you have made. The meaning of the labels has been made clearer, in line with the comments received. ALLOCATED-BY-RIR - For allocations made by an RIR to an LIR. ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's downstream customer to another downstream organisation. ASSIGNED - For assignments made to End User sites The new draft is available from our web site at: <http://www.ripe.net/ripe/draft-documents/new-value-status.html> We would welcome comments on this new draft until Thursday, 1 August 2002. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

Mntners with only MAIL-FROM auth
by Andrei Robachevsky 25 Jul '02

25 Jul '02

Attention owners of mntner objects using _only_ MAIL-FROM authentication method. Dear Colleagues, We recently sent out a message to all contacts for maintainers that still used MAIL-FROM as the ONLY means of authentication. This method is no longer valid and no updates can be authorised if any of the maintainers checked are in this situation. The message pointed to the proposed procedure on how to fix such situation (http://www.ripe.net/db/mailfrom.html). The RIPE-DBM support team has been overwhelmed with fax requests to update these maintainers. At the moment we are not able to respond to these requests as quickly as we would like to do. We have found it necessary to give a higher priority to other support requests. Therefore the response time for updates to maintainer authentication may be 5 to 10 working days. Please do not send repeat faxes unless we ask for them and do not send e-mails asking for a status update on the changes. This only slows the whole process down. We will reply to each request as soon as we make the change or find that we need additional information. This message will also be sent to all contacts for maintainers that still use MAIL-FROM as the ONLY means of authentication. Please bear with us on this and we apologise for the delay. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Proposal for adding external repository reference to import/expor t attributes
by Lu, Ping 25 Jul '02

25 Jul '02

Hi, All, I think it is time we start to implement the external repository reference specified in RFC2725 section 9.6 === Quote Begin ==== 9.6 Other Objects Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems. 1. There is no hierarchy that can be exploited to direct queries to alternate registries. At some point the query strategy of searching all known registries becomes impractical. 2. There is no hierarchy on which authorizations of additions can be based. The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. 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 ==== Some background: As an ISP we constantly are in the need to find other ISP's routing policy from other registry. Currently we have to do either the following actions: 1. Move the object into our registry. 2. Duplicate the object in our registry. Solution 1 is appropriate if other ISPs own the object but sometimes they have no authority over the object or they don't want to move the object at all (usually a peering ISP). Solution 2 have several problems: 1. The owner of the original object most likely will object to have duplicate in our registry. 2. If the owner has no objection, the duplicate object will gradually become out-of-sync. 3. It is almost impossible to avoid name collision. For example "AS-CUSTOMER" is a very popular as-set name, if there is an "AS-CUSTOMER" in our registry already then we have to add ASN to the name to become "ASN:AS-CUSTOMER". Then not only we have to duplicate the as-set object we also have to duplicate aut-num, person-role and all the associated objects as well ( quite a mess really ). 4. How do I know it is an original or duplicate ? Now the proposal: To implement "::" delimiter to support external repository reference. In a limited scope just to add "::" delimiter to the non-database-integrity-impacting attributes. The first to consider is "import/export" attribute. For example: import: from AS12345 accept RIPE::AS12345:AS-CUSTOMER export: to AS12345 announce AS3561:AS-CUSTOMER This won't affect the database beckend too much. Then the ISP can use their own tools or IRRToolSet to build configuration using the information from the external registry directly. Your opinion is well appreciated. Thanks. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

Re: Final Minutes for DB WG at RIPE 41
by Lu, Ping 23 Jul '02

23 Jul '02

Hi, All, Sorry for the confusion, I am reposting my e-mail regarding "SRC::OBJECT" (response to item 3) again. Originally I proposed to implement "::" delimiter in "member:" attribute but this will probably impact the database integrity so it is simpler to start with "import:" and "export:" attributes. I think it is better to put the proposal in its own thread so people don't have to dig it out in its current form (sorry about that). I will reformat my proposal again in another email soon. Thanks. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Lu, Ping [mailto:plu@cw.net] > Sent: Thursday, October 04, 2001 4:19 PM > To: 'George Michaelson' > Cc: db-wg(a)ripe.net > Subject: RE: Software change requests for Ripe V3 code > > > 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

RE: Final Minutes for DB WG at RIPE 41
by Lu, Ping 23 Jul '02

23 Jul '02

Hi, Nigel, About {AP-41.8 C&W] > [AP-41.2 C&W] To send their proposal to allow referencing external > objects in the DB to the mailing list for discussion. > Ongoing, no action yet We made a proposal to allow "import: from SRC::ASN:AS-SET" for using data from other source of registry data. I haven't seen any formal response from RIPE NCC yet. This shouldn't affect the database referential integrity but will make RR closer to a distributed structure. Maybe the status is now "Complete, pending response from RIPE NCC" ? Agreed ? About {AP-41.8 C&W] > [AP-41.8 C&W] To formulate their proposals on the list for discussion. > Complete. No response from C&W. I think Andrei already responded to my email on this issue (check his e-mail on 3/11/2002 to the DB-WG). Basically we all agree to use "ADD + dummy object" action to filter out non-RPSL object in the NRTM stream. And I believe RIPE NCC already have a prototype for testing. Thus I considered this item closed. Agreed ? Thanks. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Nigel Titley [mailto:nigel@packetexchange.net] > Sent: Thursday, July 18, 2002 11:39 AM > To: db-wg(a)ripe.net > Subject: Final Minutes for DB WG at RIPE 41 > > > Folks, > > As I have had no comments following the posting of the > minutes in draft > form to this list and to the Ripe web site, I am publishing > the minutes > in final form (see below) > > Best regards > > Nigel > > > Minutes for the > Database Working Group Meeting > > RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL > > > > Thursday, May 2nd, 2002 09:00-12:30 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > A. Administrative stuff (WW, chair) > . scribe (offer from Nigel received) > . circulate list of participants > . agenda bashing > . status of minutes > Minutes have been circulated to the list in both draft and final > form and are posted to the web site. > > > B. Action Items > . status of actions > > [AP-41.1 WW] To send list of proposed updates to IRRToolSet to > mailing list for WG members to vote on. Deadline 3 weeks. > Ongoing, no action yet > > [AP-41.2 C&W] To send their proposal to allow > referencing external > objects in the DB to the mailing list for discussion. > Ongoing, no action yet > > [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. > Ongoing, some work done. > > [AP-41.4 ALL] Create IRT object and tag inetnum for all > appropriate > objects. > Ongoing, some objects created > > [AP-41.5 WW] To put together a group to put together a > short guidance > document to guide reference document writers. This team to > include Ruediger. > Ongoing, no action yet, nothing from Ruediger. > > [AP-41.6 RIPE-NCC] Put up a mailing list for the above > purpose and > advertise to the db-wg list. > Ongoing, no action yet > > [AP-41.7 RIPE-NCC] To investigate soluton for mirroring > "stickiness". > Complete, a solution is now available. > > [AP-41.8 C&W] To formulate their proposals on the list > for discussion. > Complete. No response from C&W. > > [AP-41.9 RIPE-NCC] To document the mirroring protocol and the > operational requirements of using it. > Ongoing. Some work done. > > [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners > Ongoing. See presentation below. > > [AP-41.11 RIPE-NCC] Look at implementing MD5 password > authentication > Complete. > > [AP-41.12 RIPE-NCC] Look at general password > authentication methods > Ongoing. No action yet. > > C. DB update (RIPE NCC, Andrei R.) > Usual DB update. Presentation available on the www.ripe.net > web site. > . Operational update > 70% of queries are for IP addresses, 10% are domain references. > The rest are various, including person. > System is scaling well and average response time is less than > 1s, despite a doubling of load over the past year. > 50% of messages to ripe-dbm are spam. It is suggested that > a simple spam filter (To: or Cc: ripe-dbm) may reduce this. > Ticketing system to be introduced in the next few weeks. > > . Database developments > MD5-PW scheme introduced, based on md5-crypt. Available on test > database, soon to move into production. > MAIL-FROM now to be deprecated. Notification to go out > soon. 4 weeks > later updates will be rejected (except for maintainer object > updates). 4 weeks later submission will be rejected. Finally > 4 weeks later the MAIL-FROM attribute will be removed from all > maintainer objects. There is a suggestion that the same thing > should be done with NONE. The meeting formally approved > the MAIL-FROM > timeline. The process to start before the end of May. > > IRT object has been available since Jan 2002. Two IRT objects > have been created. Creation procedure still needs some > development. > > DB Consistency and Statistics project > 113 reports displaying 34000 inconsistences were produced. > Please act on these and fix data. > [AP-42.1 ALL] To check own data and correct inconsistencies if > possible. > > SYNCUPDATES prototype > Available in test as a syntax checker only so far. > > RRCC full prototype is ready > > IRRToolset is being managed. Update requests are very welcome. > > APNIC will be using the RIPE database code. The procedural > changes needed will be rolled into the main database code. > > DB Documentation > Structure and parts of several chapters are ready. Should be > consistent with LIR training. > > > D. Complex authentication scenarios (Alex G. SWITCH) > . Background > There are some scenarios which require multiple signatures. This > has revealed a small bug in the database which has been worked > around. > It is better to sign a clear text update rather than using mime > encapsulation. In the event of multiple signatures > being required > the clear text should be signed by the first > maintainer, then the > entire email signed again by the second maintainer. > [AP-42.2 RIPE-NCC] To send instructions on multiple credentials > to the DB working group mailing list. > > > E. Discussion on "hiding" credentials (RIPE NCC, N.N.) > . "shadow password" concept > The idea is to not include the encrypted credential in the whois > response. This prevents "brute force" attacks. However, > this breaks > with DB tradition of returning all attributes of all > objects when > requested and means that the DB can be the primary repository of > the data. > > A proposal for a two level authentication scheme was received > with full access for the DBA, but no password access from the > general public. It was pointed out that this was a > wider issue than > just the RIPE community, but was also being discussed > in the RPSLng > working groups. It was also pointed out that packages > are available > which can attack digested passwords. > The very valid point was raised that those who have > problems with > weak authentication methods, should use strong ones (eg PGP). > Objects to this were that Windows users had problems > with PGP and > its "complex" interface. > [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow > passwords and multiple level authentication schemes. > [AP-42.3 Larry Blunk] To investigate the problems of > multiple hashed > passwords and the possibilies of embedding an ID within > the hash and > to submit a proposal to the working group. > A proposal came from Janos to embed such information in > the remarks > field. > > F. IRT Object creation process > The technical implementation is in place. Procedures > need some work. > Two IRT objects are registered so far. > Objects need some authentication, to give them some cedibility. > A "trusted introducer" currently provides > authentication and labelling > when an object is created. This may need updating. > There is a meeting > on the 23 - 24th May in Copenhagen on Computer Security IRT > coordination. Attend if appropriate. > > G. Org object? > This has been discussed in the past. Were people still > interested > in creating this object? APNIC and ARIN also carry > these objects. > This might be used in the registration of inet-nums. > The role object > partially answers this need, but cannot be used for an > admin-contact. > An org object could also be used to make a LIR object > more visible > and allow remote updating. The question also arises as > to whether > the owners of PI space could create org objects. > > H. Migration of objects between registries > This is affecting legacy address space which pre-dates > RIRs. This > is currently in the ARIN database. It is proposed to > migrate this data > to the appropriate geographic RIR database. A great > deal of inter-RIR > liasison has already taken place. A number of > approaches are possible, > ranging from moving the data completely, using the > referral mechanism, > carrying all data in all databases etc. > The thing that mustn't happen is to delete more up to > to date data in > the non-authoritative database in favour of old data in the > authoritative database. > It has been suggested that the "delegated" attribute be used to > implement. This would only be used for inet-num and > as-set objects. > The issue was raised that one of the top level domain > servers is in > the 192.0.0.0/8 block, and deletion of the route > objects for this would > be disastrous. The response to this is that there was > no intention > to move route objects, just inet-num objects. > > I. Input from other WGs > No other input > > J. AOB: > No other business. > > >

4 3

RE: Final Minutes for DB WG at RIPE 41
by Lu, Ping 22 Jul '02

22 Jul '02

>From RFC2725 (maybe this is not part of RPSL ?): ================================================================== 9.6 Other Objects Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems. 1. There is no hierarchy that can be exploited to direct queries to alternate registries. At some point the query strategy of searching all known registries becomes impractical. 2. There is no hierarchy on which authorizations of additions can be based. The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. 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. ================================================================== There is a need to address the "external repository reference" problem for a long time. It is in the RFC already and just no implementation to support the solution yet. Now I think is the time to take this issue seriously (at least for "import:" and "export:" :) Best Regards. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Mark Prior [mailto:mrp@mrp.net] > Sent: Saturday, July 20, 2002 6:38 AM > To: Lu, Ping; 'Nigel Titley'; db-wg(a)ripe.net > Subject: RE: Final Minutes for DB WG at RIPE 41 > > > At 2:33 PM -0400 19/7/02, Lu, Ping wrote: > >Hi, Nigel, > > > >About {AP-41.8 C&W] > >> [AP-41.2 C&W] To send their proposal to allow > referencing external > >> objects in the DB to the mailing list for discussion. > >> Ongoing, no action yet > >We made a proposal to allow "import: from SRC::ASN:AS-SET" > for using data > >from other source of registry data. I haven't seen any > formal response from > >RIPE NCC yet. This shouldn't affect the database referential > integrity but > >will make RR closer to a distributed structure. Maybe the > status is now > >"Complete, pending response from RIPE NCC" ? Agreed ? > > That would require a change to the RPSL standard and I haven't seen > any internet drafts suggesting such a change. > > Mark. >

1 0

Final Minutes for DB WG at RIPE 41
by Nigel Titley 19 Jul '02

19 Jul '02

Folks, As I have had no comments following the posting of the minutes in draft form to this list and to the Ripe web site, I am publishing the minutes in final form (see below) Best regards Nigel Minutes for the Database Working Group Meeting RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL Thursday, May 2nd, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer from Nigel received) . circulate list of participants . agenda bashing . status of minutes Minutes have been circulated to the list in both draft and final form and are posted to the web site. B. Action Items . status of actions [AP-41.1 WW] To send list of proposed updates to IRRToolSet to mailing list for WG members to vote on. Deadline 3 weeks. Ongoing, no action yet [AP-41.2 C&W] To send their proposal to allow referencing external objects in the DB to the mailing list for discussion. Ongoing, no action yet [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. Ongoing, some work done. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. Ongoing, some objects created [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. Ongoing, no action yet, nothing from Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. Ongoing, no action yet [AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness". Complete, a solution is now available. [AP-41.8 C&W] To formulate their proposals on the list for discussion. Complete. No response from C&W. [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. Ongoing. Some work done. [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners Ongoing. See presentation below. [AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication Complete. [AP-41.12 RIPE-NCC] Look at general password authentication methods Ongoing. No action yet. C. DB update (RIPE NCC, Andrei R.) Usual DB update. Presentation available on the www.ripe.net web site. . Operational update 70% of queries are for IP addresses, 10% are domain references. The rest are various, including person. System is scaling well and average response time is less than 1s, despite a doubling of load over the past year. 50% of messages to ripe-dbm are spam. It is suggested that a simple spam filter (To: or Cc: ripe-dbm) may reduce this. Ticketing system to be introduced in the next few weeks. . Database developments MD5-PW scheme introduced, based on md5-crypt. Available on test database, soon to move into production. MAIL-FROM now to be deprecated. Notification to go out soon. 4 weeks later updates will be rejected (except for maintainer object updates). 4 weeks later submission will be rejected. Finally 4 weeks later the MAIL-FROM attribute will be removed from all maintainer objects. There is a suggestion that the same thing should be done with NONE. The meeting formally approved the MAIL-FROM timeline. The process to start before the end of May. IRT object has been available since Jan 2002. Two IRT objects have been created. Creation procedure still needs some development. DB Consistency and Statistics project 113 reports displaying 34000 inconsistences were produced. Please act on these and fix data. [AP-42.1 ALL] To check own data and correct inconsistencies if possible. SYNCUPDATES prototype Available in test as a syntax checker only so far. RRCC full prototype is ready IRRToolset is being managed. Update requests are very welcome. APNIC will be using the RIPE database code. The procedural changes needed will be rolled into the main database code. DB Documentation Structure and parts of several chapters are ready. Should be consistent with LIR training. D. Complex authentication scenarios (Alex G. SWITCH) . Background There are some scenarios which require multiple signatures. This has revealed a small bug in the database which has been worked around. It is better to sign a clear text update rather than using mime encapsulation. In the event of multiple signatures being required the clear text should be signed by the first maintainer, then the entire email signed again by the second maintainer. [AP-42.2 RIPE-NCC] To send instructions on multiple credentials to the DB working group mailing list. E. Discussion on "hiding" credentials (RIPE NCC, N.N.) . "shadow password" concept The idea is to not include the encrypted credential in the whois response. This prevents "brute force" attacks. However, this breaks with DB tradition of returning all attributes of all objects when requested and means that the DB can be the primary repository of the data. A proposal for a two level authentication scheme was received with full access for the DBA, but no password access from the general public. It was pointed out that this was a wider issue than just the RIPE community, but was also being discussed in the RPSLng working groups. It was also pointed out that packages are available which can attack digested passwords. The very valid point was raised that those who have problems with weak authentication methods, should use strong ones (eg PGP). Objects to this were that Windows users had problems with PGP and its "complex" interface. [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow passwords and multiple level authentication schemes. [AP-42.3 Larry Blunk] To investigate the problems of multiple hashed passwords and the possibilies of embedding an ID within the hash and to submit a proposal to the working group. A proposal came from Janos to embed such information in the remarks field. F. IRT Object creation process The technical implementation is in place. Procedures need some work. Two IRT objects are registered so far. Objects need some authentication, to give them some cedibility. A "trusted introducer" currently provides authentication and labelling when an object is created. This may need updating. There is a meeting on the 23 - 24th May in Copenhagen on Computer Security IRT coordination. Attend if appropriate. G. Org object? This has been discussed in the past. Were people still interested in creating this object? APNIC and ARIN also carry these objects. This might be used in the registration of inet-nums. The role object partially answers this need, but cannot be used for an admin-contact. An org object could also be used to make a LIR object more visible and allow remote updating. The question also arises as to whether the owners of PI space could create org objects. H. Migration of objects between registries This is affecting legacy address space which pre-dates RIRs. This is currently in the ARIN database. It is proposed to migrate this data to the appropriate geographic RIR database. A great deal of inter-RIR liasison has already taken place. A number of approaches are possible, ranging from moving the data completely, using the referral mechanism, carrying all data in all databases etc. The thing that mustn't happen is to delete more up to to date data in the non-authoritative database in favour of old data in the authoritative database. It has been suggested that the "delegated" attribute be used to implement. This would only be used for inet-num and as-set objects. The issue was raised that one of the top level domain servers is in the 192.0.0.0/8 block, and deletion of the route objects for this would be disastrous. The response to this is that there was no intention to move route objects, just inet-num objects. I. Input from other WGs No other input J. AOB: No other business.

1 0

configuring ripe-dbase-3.1.0
by Sun Guonian 19 Jul '02

19 Jul '02

Dear Madam/Sir, I want to upgrade our whois server from ripe-dbase-2.3 to the new version ripe-dbase-3.1.0. in the last version(2.3), I can modify two files, conf/ripedb.config and lib/syntax.pl, to add new objects/attributes to offer chinese information to our clients. But in the new version, I can't find the proper mothed to do it. would you mind to help me to solve this problem ? Thanks very much ! Best regards, Sun Guonian China Internet Network Information Center (CNNIC)

2 1

Draft document "New Values of the 'status:' attribute for inet6num Objects" is available
by Andrei Robachevsky 17 Jul '02

17 Jul '02

Dear Colleagues, [apologies for duplicate messages] The draft document "New Values of the 'status:' attribute for inet6num Objects" is available on the RIPE NCC website at: http://www.ripe.net/ripencc/draft-documents/ This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. The deadline for comments and suggestions is Wednesday, 24th July. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. On Thursday, 25th July, subject to any additional comments, the described Database functionality will be put in to practice. Please send your comments and suggestions to <lir-wg(a)ripe.net>. Regards, Andrei Robachevsky RIPE NCC

1 0

RE: [lir-wg] Discussion Summary: Status field for inet6num object s
by Guy Davies 08 Jul '02

08 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would prefer RIR-LIR-ALLOCATED, LIR-SUB-ALLOCATED and LIR-USER-ASSIGNED (or similar) if we must keep ALLOCATED and ASSIGNED in the descriptions. I don't think that it is immediately clear from the proposals below whether LIR-ALLOCATED is allocated by an LIR or to an LIR. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net; db-wg(a)ripe.net; > sig-db(a)apnic.net; > policy-db(a)apnic.net; apnic-talk(a)apnic.net > Subject: Re: [lir-wg] Discussion Summary: Status field for inet6num > objects > > > Hi, > > On Mon, Jul 01, 2002 at 06:21:24PM +0200, leo vegoda wrote: > > The RIPE NCC needs to implement a new status attribute for the > > inet6num object to reflect the new policy agreed by the RIPE, > > ARIN and APNIC communities. > > > > The RIPE NCC suggested the following new status attributes for > > the inet6num objects: > > > > - RIR-ALLOCATED > > (For allocations made by an RIR to an LIR) > > > > - LIR-ALLOCATED > > (For allocations made by an LIR or an LIR's downstream > > customer > > to another downstream organisation) > > > > - ASSIGNED > > (For assignments made to End User sites) > > I haven't seen any replies to this so far. > > I want to express that I like this proposal. It doesn't introduce > any new and yet-undefined terms, but makes clear what the status of > a given network is. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 45809 (45931) > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPSmLLo3dwu/Ss2PCEQIJdQCeOKDqqTLKCuB+o3pWMj/XJ41QJMQAnROW EWRBiRI4rPpF9DRbhrxYcK0S =Rab7 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

5 4