[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
scottleibrand at gmail.com
Sat Jul 15 13:42:42 EDT 2017
On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <bill at herrin.us> wrote:
> On Sat, Jul 15, 2017 at 8:52 AM, John Curran <jcurran at arin.net> wrote:
>> Such a separation doesn’t preclude the community from adopting policy
>> references the present or future state of routing (note, for example, the
>> use of
>> “multihoming” criteria in several portions of the NRPM), but folks are
>> that in Internet number resource policy we should only be specifying how
>> ARIN registry is to be administered, not how things are to be routed,
>> since the
>> latter is up to each ISP.
> Hi John,
> In the interests of clarifying your remarks:
> ARIN does not set or even recommend routing policy. Participants in the
> ARIN policy process routinely consider industry routing practices, IETF
> recommendations, etc. when suggesting ARIN address management policy and
> ARIN routinely enacts such policy.
That is true, but I think John is making a stronger point, which I'll make
here: It's perfectly fine for ARIN policy to be contingent on (applied
differently depending on) how a particular block is (going to be) routed.
So if we think it's the right thing to do, we could require in the NRPM
that all blocks in the global routing system be SWIP'ed. But we *can't*
enforce such a requirement by saying, for example, that ISPs can't accept a
block until it's SWIP'ed. We can only issue guidelines on what should be
SWIP'ed and make ARIN services (like allocation of additional blocks)
contingent on whether such a policy is followed. If an enforced
SWIP-before-routing rule is desired by the ISPs that participate in the
global routing system, then they'll have to do so voluntarily by refusing
to accept the announcement of non-SWIP'ed blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML