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?<br>
<br><div class="gmail_quote">On Thu, Jun 14, 2012 at 9:36 AM, Chris Engel <span dir="ltr"><<a href="mailto:cengel@conxeo.com" target="_blank">cengel@conxeo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br></div>
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.<br>
</blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote><div><br></div><div>Agreed. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>

 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?</blockquote>
<div><br></div><div>So here's a stab at what I think should happen:</div><div><br></div><div> - 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.</div>
<div> - 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.</div>
<div> - 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-Scott (speaking only for myself)</div></div>