Comments follwed.

-----Original Message----- From: George Michaelson [mailto:ggm@apnic.net] Sent: Thursday, October 04, 2001 8:27 AM To: db-wg@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@cw.net mnt-by: RIPE-NCC-MNT changed: plu@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@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@cw.net