RE: Software change requests for Ripe V3 code

["Lu, Ping" PLu@localhost]

Comments follwed.

> -----Original Message-----
> From: George Michaelson [
	    
	    
]
> Sent: Thursday, October 04, 2001 8:27 AM
> 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@localhost
mnt-by:       RIPE-NCC-MNT
changed:      plu@localhost 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@localhost    |  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@localhost