Hi Janos,
I think you refer to the following statement from the LIR handbook: "The RIPE NCC will directly reverse delegate to zones smaller than /24 which are Provider Independent (PI) and do not originate from an LIR's PA allocation. If this applies or questions arise, please contact: ripe-dbm@ripe.net"
Yes, exactly. Also see: http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegat...
However, I think this is not an administrative question (i.e. the question is not whether the NCC allows it or not).
In case of PI, the "surrounding" address space is also managed by the RIPE NCC, so they do have the possibility to set up a scheme similar to the one specified in BCP20/RFC2317.
In case of a transfer out of an LIR allocation, the "surrounding" space is allocated to the "selling" LIR, so they are the ones who _can_ set up the reverse delegation.
Alternatively, the transfer policy could require that in such a case the "surrounding" /24 has to be delegated to the RIPE NCC, who will manage this address space in a neutral way for an indefinite period of time. This would, however, have an impact on RIPE NCC operations, and I do not think I would support such a proposal.
Maybe I am being dense, but I am really struggling to understand your concern. After all the surrounding address space is already delegated to the RIPE NCC's name servers, which then sub-delegate based on the domain objects the resource holder inserts into the database. So I don't see how this proposal would have an impact on RIPE NCC operations in this regard (beyond the one-time job of permitting classless delegation for PA space in the same way as for PI). Let me try to explain my understanding of things by example... 185.47.43.0/24 is part of an ALLOCATED PA delegation from the RIPE NCC to my LIR. When it comes to reverse DNS, the allocation chain goes like this, starting from the root: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) [The NS records for "40.47.185.in-addr.arpa." happens to be there because I've inserted the corresponding object into the RIPE database and it's based on those objects the RIPE NCC generates the "185.in-addr.arpa" zone.] Let's now assume that you and I agree that 185.47.43.128/25 should be transferred to your LIR. I would then expect that the delegation chain would part ways in the 185.in-addr.arpa sone, like so for my /25: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 0-127.43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) ..and like so for your /25: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 128-255.43.47.185.in-addr.arpa. NS ns*.iszt.hu (yours) [As before, we would of course both need to insert appropriate domain objects into the RIPE database for the final delegation to our own authoritative name servers to show up in the 185.in-addr.arpa zone.] Even though I would be the "selling" LIR here, I do not understand why I would be required to play a part in delegating reverse DNS for the /25 you "bought" for an infinite period of time (or any period of time at all for that matter). What am I missing here? Tore