[arin-ppml] ARIN-prop-171 and ARIN-prop-172 - Legacy Resources

[Scott Leibrand]

Firstly, I'll note that this thread is really more about ARIN-prop-171
than ARIN-prop-172 at this point.  The fact that we can't keep the two
issues separate on PPML is IMO a pretty good argument that we should merge
the two into a single draft policy.  Does anyone think they are really two
separate issues that need to be treated independently?  Is there any reason
we'd want to adopt a definition of legacy resources without adopting
something along the lines of 171, for example?

On Thu, Jun 14, 2012 at 9:36 AM, Chris Engel <cengel at conxeo.com> wrote:

>
> That being said, the membership of ARIN seems to have expressed it's
> interest that ARIN continue it's stewardship role in regards already
> allocated resources and has done so by implementing a policy that sets
> certain minimum requirements/conditions upon transfer of allocated address
> blocks. Presumably the membership does so because it believes that it is in
> the best interest of the community and the operation of the internet as a
> whole to impose such requirements. While that belief is certainly not
> universal among the community (and I'm not a big fan of it myself), there
> appears to have been enough consensus on it that it was enacted into policy.
>

Agreed.


> Unless I'm mistaken, what the policy proposal in question seems to result
> in is the carving out of a special exemption from those requirements for
> entities who acquire  address blocks (via transfer) from legacy address
> holders as opposed to acquiring them (via transfer) from non-legacy address
> holders. I'm failing to see what the rationale for that difference in
> treatment is? What is it that makes those policy requirements useful/fair
> to apply in one case and not useful/fair in the other? It's strikes me that
> sort of inequal application of policies/requirements isn't a great thing
> for the community as a whole.
>

Agreed.

I fully understand why the ORIGIONAL holders of legacy address space were
> treated differently in regards the resources they ALREADY had. Not only was
> there the uncertain legal question of attempting to impose conditions on
> entities ARIN had no contractual relationship with, but more importantly
> there was the consideration of unnecessary disruptiveness in attempting to
> change the conditions under which those entities had been holding those
> resources  for years. In other words, if entity A was widely recognized as
> holding a particular block for years before ARIN, it's alot more
> harmful/disruptive to try to revoke that recognition then it is to allow it
> an exemption to certain requirements imposed upon new registrants. The
> paradigm is not much different then the "Grandfather Clauses" which exist
> in certain laws/regulations. The rationale behind those is to limit the
> harm/disruption of imposing change on what had been upto that point
> relatively stable/well functioning systems whi
>  le still allowing changes to be introduced which are perceived as
> necessary/beneficial to the continuing function of the system as a whole.
>  Grandfather Clause status is rarely transferable from an entity which
> holds it and the reasoning for that would seem to apply here, the
> disruption it is intended to avoid is already imposed by the act of
> transfer itself, no additional harm/disruption is realized by declining to
> allow the transfer of the exemption along with the resource, and indeed if
> the policy requirements are actually well founded and beneficial,
> perpetuating the exemption would impose harm in itself. So again, I fail to
> see why requiring a transferee to justify need (for example) when receiving
> non-legacy space is a good thing and suddenly turns into a bad thing when
> the space is legacy?


So here's a stab at what I think should happen:

 - 8.2 transfers should not require a change in the status of the addresses
being held, except to require that status to be contractually codified (by
the recipient signing an LRSA as a condition of updating ARIN's database).
 In particular, the LRSA doesn't make the addresses it covers subject to
utilization requirements.
 - We may be able to add some sort of grandfather clause to allow fewer
restrictions on the 8.3 transfer of legacy addresses (and a proper
definition of such addresses).  However, I don't believe that such
exceptions should themselves be transitive.  That is to say, the recipient
of an 8.3 transfer needs to sign an RSA and become subject to all of the
policies in the NRPM.
 - I could see an argument for exempting an 8.3 transfer recipient from
needs justification on the initial transfer, but IMO that exemption would
need to be time-limited, to perhaps a year, after which time the recipient
would be subject to all ARIN policies.

I think the underlying motivation here is to encourage holders of legacy
allocations who wish to transfer their space to do so in a way that keep
ARIN's database up-to-date.  In some cases, that may be an easier sell if
some restrictions are relaxed.  The supporters of ARIN-prop-171 may not
agree, but I would argue that a second goal is to encourage such transfers
to occur in such a way that the addresses being transferred are no longer
considered legacy after the transfer is complete.

-Scott (speaking only for myself)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120614/3ed33754/attachment.htm>