* Rob Evans
Overall I think this is a good thing,
+1
but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is?
If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented?
I think not, that would not be consistent. Maybe it's just an oversight by the proposal's author to not have removed that particular paragraph?
The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves.
I say the latter. The current de-facto routing limit of /24 isn't something borne out of our address policies, it's a limit the routing community has come up with all on its own. So if we're putting in /24 in the policy we're not really «clamping» anything, rather just documenting today's operational reality (which could possibly change, in turn making policy outdated). Besides, it's only ALLOCATED PA and SUB-ALLOCATED PA inetnums that are have a minimum size of >= /24 anyway. inetnums with status ASSIGNED PI¹ can be /29, ASSIGNED PA², as well as route objects³ can be any length up to and including /32. Sky isn't falling yet though. :-) [1] http://www.ripe.net/ripe/docs/ripe-555#longest-prefix-tables [2] whois -T inetnum -x 185.47.43.255/32 [3] whois -T route -x 185.47.43.255/32 In the end I think the operators is perfectly capable of figuring out what's the minimum size route advertisement they're willing to accept without RIPE address policy instructing them (or pretending to, anyway). Perhaps the ability to recycle infrastructure PI assignments as PA could even be considered a small incentive for some operators to migrate some of their infrastructure to IPv6, thus freeing up precious IPv4 resources that can be then assigned to revenue-generating customers - alongside an IPv6 assignment of course... :-) Tore