Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] wrote:

Hi Jeroen!

...

Only problem here is that in the non rwhois databases there is no defacto 'referal' method. At least as far as I know of except for a 'remarks:' field. If somebody can hint me where to find it I would be pleased.

Interesting line of thought!

In fact there _is_ a referral mechanism - for domain lookups, but not for address lookups. Depending on what the result of this discussion is, we could investigate the merits of a referral mechanism for inet6nums, too.

[Maybe this should go into db-wg?] The domain name referral mechanism works using the 'refer' tag. This could be used for inet6nums too, albeit as it isn't defined for inet6num's the whois db won't accept it. Most clients probably won't care much. Marco d'Itri's whois client also handles The refer tag is documented in amongst others http://www.ripe.net/ripe/docs/databaseref-manual.html An (minimal) example of inet6num in this style could look like. 8<------------------------ inet6num: fec0:8114:1000::/40 netname: EXAMPLE-DLG-ONE descr: Example /48 delegation space to endusers. refer: RIPE whois.example.net 43 country: NL remarks: More specific information can be found by quering whois.example.net mnt-by: MNT-EXAMPLE changed: jeroen@unfix.org 20030115 source: EXAMPLE ------------------------>8 Lines 4 and 6 depict the referral, line 6 is simply there to allow humans to know of ther referral too, though it could be left out as line 4 is obvious enough. Line 6 can ofcourse easily be autogenerated in the server side. The "refer" should actually be "longer refer" in that only the subdelegations of the inet6num are referred and not the inet6num documented itself. This way the documentation is always available in RIPE (which should be up 99%) and the more detailed versions should go in the referred server. One thing is that the domain 'refer' attribute does the refer on the RIPE server. Thus the object is fetched from the referred server bij whois.ripe.net which actually could/will cause some extra load on the whois.ripe.net machine. Marco pointed out to me that the 6bone database (whois.6bone.net) has a special piece of code that when a person/maintainer object etc is not found in the local database it outputs a: % referto: whois -h whois.ripe.net -p 43 -s RIPE -T person,role NO17-RIPE Eg as found in http://www.viagenie.qc.ca/cgi-bin/whois.pl?SURFNET The whois-client then connects to the specified server and request the data from there. It would probably be better if these referals are done client side for the inet6num case too. Problem with this is that it isn't an attribute and thus there is no way to control it when filling in your inet6num, unless there comes a exception etc... in which case a correctly specified refer attribute would be better.

Nevertheless I'd strongly suggest to keep the (minimal) required documentation of resources in the central database, instead of going down the route of rwhois (or the like).

IMHO the </48 should be completely documented in the RIPE db, but suballocations of that should be documented in a local (referred) whois. The records to which the referal points could sub-document their delegation again in another whois if wanted. eg: fec0:8114:1000::/40 -> whois.ripe.net, with a "longer refer" to whois.example.net fec0:8114:1000::/48 -> whois.example.net (The regional ISP) fec0:8114:1000::/56 -> whois.example.org (The enduser organisation) Which makes it quite flexible, but ofcourse people shouldn't refer to much otherwise this will become DNS. Greets, Jeroen