[dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]

Dear all,

> people on this list might be interested in one aspect of the
> proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>,
> <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.html>,
> when it comes to (sub-)allocations smaller than /24.
> Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem.

_Technically_ speaking, in my opinion BCP20/RFC2317 is an
acceptable solution. It is a trade off: it increases the number of
DNS queries, but it gives a large freedom and independence in managing
the reverse address space.

As I see it, in fact we are talking about three different cases:
1. allocations made by the NCC (5.1)
2. transfers (5.5)
3. possibly sub-allocations (5.4, still under consideration by
    Carsten, the author of the proposal)

In accordance with BCP20, the "maintainer" of the /24 has to set up
and _continue_to_provide_ DNS service in accordance with the RFC for
an indefinite period of time to the "user" of the smaller address
block.

In case 1 above, the NCC can do it without any problems.
In case 3, the sub-allocating LIR has strong ties to the other LIR,
as it is responsible for the address space anyway.

However, in case 2, i.e. in case of transfers, I see a possible problem,
as otherwise a business relationship does not necessarily exist
between the "seller" and the "buyer" of the address space, once the
transfer is approved by the NCC and registered in the database.

I think it would be a good idea to include this obligation to provide
appropriate DNS services for an indefinite time (possibly for a fee)
in the transfer contract itself. Anyway, if someone is asking for
a fee for such a service, this will most probably be a further very good
deterrent to asking for the transfer of such a small address space. :)

Anyway, I think this obligation to provide appropriate DNS services
for an indefinite time is not necessarily specific to address space
smaller than a /24, as any transfer smaller than a /16 out of an
allocation of at least a /16 has a somewhat similar problem.

Best regards,
Janos


> Also, in the interest of keeping the policy discussion focused,
> we might want to strictly focus on the reverse mapping on this list and
> make sure some "sense of the room" as well as all other aspects
> get discussed on address-policy.
>
> -Peter (DNS WG co-chair)
>
> ----- Forwarded message from Tore Anderson <tore at fud.no> -----
>
> From: Tore Anderson <tore at fud.no>
> To: Carsten Schiefner <ripe-wgs.cs at schiefner.de>, Rob Evans <rhe at nosc.ja.net>
> Cc: address-policy-wg at ripe.net
> Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the
>   Minimum Allocation Size for IPv4)
> Date: Thu, 27 Mar 2014 09:34:20 +0100
> In-Reply-To: <5333CABF.1070609 at schiefner.de>
>
> * Carsten Schiefner
>
>> No, not really. I feel this being only loosely coupled at best. My
>> proposal enables the transfer of allocations of *all* sizes and the
>> conversion of PI assignments of *all* sizes into allocations.
>>
>> Whether sub-allocations can be made from *all* these (new)
>> allocations or "just" from those being at least a /24 appears as a
>> separate question to me. Even more so, as the the sub-allocation
>> mechanism has been applied or used very rarely only so far.
>>
>> And having the "one thing at a time" principle in mind: if this
>> impossibility is of concern to the community, then this should maybe
>> be handled by a separate policy (modification) proposal.
>
> Hi Carsten,
>
> I'm just of the opinion that removing one without the other leaves the
> policy in a counter-intuitive state. To me it would appear appropriate
> for a proposal titled «Abandoning the Minimum Allocation Size for IPv4»
> to remove all flavours of the minimum allocation size, including the one
> specific for sub-allocations.
>
> Besides, one of the two stated reasons for having the minimum
> sub-allocation size («[/24] is the smallest prefix length that can be
> reverse delegated») is quite simply false, given RFC 2317, and if we
> also accept the rationale for 2014-01, then we've essentially rejected
> the other reason too («allows for a reasonable number of small
> assignments to be made»).
>
> So I'd ask you to consider removing that paragraph as well before going
> to review phase. Note that since we're still in the discussion phase,
> doing so doesn't have to slow down the progress of the proposal, you can
> go straight to review with updated proposal (modifications at a later
> stage are much more cumbersome).
>
> Just my €.02...your proposal, your call. ;)
>
> Tore
>
>
> ----- End forwarded message -----
>
>