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@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net