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

[Owen DeLong]

On Jun 14, 2012, at 2:25 PM, Scott Leibrand wrote:

> 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.

I have mixed feelings about this, but I certainly welcome further input from the community on this as it is a new subject not previously discussed.

>  - 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 would absolutely oppose this. Once resources are transferred from 8.3, their status should be no different than if they were returned to ARIN and subsequently issued to another organization in two unrelated transactions.

>  - 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 would absolutely oppose this as well for the same reasons. There is no reason whatsoever to special case these transfers in such a manner and it is not fair to other resource holders or the community in general to do so.

> 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.

I think that the combination of RPKI and the desire to have cooperating ISPs be willing to carry the routes is more than enough motivation here. I do not believe that there is a need to grant further special treatment and I would oppose doing so. This would be one more step towards turning ARIN from consensus driven policy towards merely being an auction house.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120615/da3fa517/attachment.htm>