[Comments from Havard] * - how do one request delegation of a subdomain of 193.in-addr.arpa. * Contact hostmaster@ripe.net with a free-form text message, or should we * bother to create a form? Ahh, no extra forms please !!! All we need to know is class C block, and all the servers. I do not think we need another form for that ... Please just contact hostmaster@ripe.net with the needed information. We will be able to parse it ;-) Or maybe the suggestions below ... * - How will the domain administrators for the subdomains of 193.in-addr.arpa * be made aware of a desire to have delegation installed for a subdomain? * There was some talk about doing this semi-automatically with the nic when * a RIPE network registration form was sent in to ripe-dbm@ripe.net or * assign@ripe.net, could this be used here (in addition to other means)? In fact we have the following in mind. For blocks that are not yet delegated, we intend to use the information people supply in the "rev-srv:" field to update the 193.in-addr.arpa domain. For blocks that have been delegated, the people that have been assigned class C nets from such a block should be made aware that reverse registration should be done by either the NCC is the local registry does NOT run the delegated block, or by the local registry. We could look into extending our "rev-srv:" program to notify maintainers of blocks in 193.in-addr.arpa if the information in the database has changed. They could then update their zones if needed. This however does imply that the "rev-srv:" field becomes authoritative for reverse mapping (and not vice versa) [Suggestions from Blasco] * 2a. The names of the reverse nameserver which are delegated by RIPE-NCC * to act as authoritative servers for a 256-class C block are sent * to the RIPE-NCC and registered in the RIPE db using a template * like this: * * inetnum: 193.x.0.0 (where x is the block number) * <administravia> * zone-c: <person> * rev-srv: <first server name> * rev-srv: <second server name> * rev-srv: ns.ripe.net * * as soon as the Local IR receives from RIPE-NCC a new block to * administer. I do not quite like this idea. 193.x.0.0 is a normal class C network number that just could be used (although we recommend not to do so) and I hate having information in the database with "some special meaning you have to know". The other thing would be to just have an extra entry for the complete block in the database (so you would get two answers if you queried a network inside the block), but that I do not like because you are not responsible for individual nets inside the block... If you really want to put it in the database, why not send in an object like: domain: 204.193.in-addr.arpa descr: blah zone-c: <person> nserver: <first server> nserver: <second server> nserver: ns.ripe.net .... It is a domain, so why not pick the right object for it ? * 7. Usually the registration of reverse servers for individual class C nets * or class C subblocks is done by the service provider who is administering * the whole 256-class C block who in turn notifies the RIPE-NCC sending * an updated network template for inclusion in the RIPE db. * However should the RIPE-NCC receive any template for a single class C net * or subblock not from the service provider, they must forward the template * to the authoritative zone-c for the 256-class C block. Totally agree. We will not "overrule" delegations by putting them directly in 193.in-addr.arpa, like we expect hostmaster@nic.ddn.mil to do the same. We will of course forward such requests. I will update the document with regard to the last point, and the other point if we can each agreement on the "how to notify I want a block delegated". An object like above could be used as a request for delegation of a block. -Marten