[ppml] Revised 2007-17 Legacy outreach and partial reclamation

[Michael K. Smith - Adhost]

Hello Owen:

I apologize for not getting back to you sooner.

<snip>
> 
> > Hello All:
> >
> > I oppose this policy as written.  I have put comments in line below,
> > but in summary, the incentives to Legacy holders seem largely
> > ephemeral in comparison to the disincentives and, as such, I don't
> > think this policy will be well received by the Legacy community.  It
> > should be noted that I am not a Legacy address holder.
> >
> As I understand it, you object because you believe the policy by
> itself would not be effective.  Would you agree it could be effective
> if the BoT were to adopt additional incentives as recommended
> in the Rationale section?  Those incentives were removed from the
> policy text to address the technicality that fees, fee waivers and the
> like are not policy matters and cannot be addressed in the policy
> process.
> 

Absolutely.  My personal opinion is that the *only* way to get the Legacy holders to come into the fold is through incentives.  Why would a Legacy holder ever choose to come under the ARIN umbrella otherwise?

<snip>
> >
> >>> 4.6.2 No penalty for returning or aggregating
> >>> ARIN shall seek to make the return of address space as convenient
> >>> and risk-free to the returning organization as possible. An
> >>> organization with several non-contiguous blocks seeking to
> >>> aggregate and return space at the same time should be accommodated
> >>> if possible. If it is possible to expand one block, for example,
> >>> to facilitate the return of other blocks, ARIN should do that
> >>> where possible.
> >>>
> > Here's where we get ephemeral.  What does "as convenient and risk-
> > free...as possible" actually mean?
> >
> It means that any resource holder seeking to return resources to ARIN
> should be able to do so without fear that ARIN will seek to do some
> harm to the organization returning the address space.  For example,
> returning address space will not force you to renumber (other than
> to stop using the addresses you are returning).  It should not trigger
> an additional audit of your retained resources.  Etcetera.  In general,
> this is intended as a guideline statement to staff that the public
> interest is best served if people have no reason to be afraid of
> returning
> unused address space.

So I like the second set of examples better than the first.  Would it be better to have no example at all so that it read:

ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as possible.

> 
> >>> 4.6.3 Return should not force renumbering
> >>> An organization shall be allowed to return a partial block of
> >>> any size to ARIN. For any return greater than a /24, ARIN shall
> >>> not require that the non-returned portion of the block be
> renumbered
> >>> unless the returning organization wishes to do so.
> >
> > I'm not sure I understand the intent of this one.  Is this to say
> > ARIN will not require the owner to renumber within the remaining
> > block, or renumber out of the block into a new, non-Legacy block at
> > some future date?
> >
> This is intended to cover a situation where, for example, someone has
> a /16
> and needs a /18 of that space.  Instead of returning the /16 and
> getting a
> completely different /18, this policy would require ARIN staff to
> allow the
> holder to return any /18 and /17 from the /16 while still keeping the /
> 18 of
> the holder's choosing.  Under current policy, theoretically, the
> holder could
> be required to return the entire /16.  Although that is not current
> staff practice
> in most such cases, it is how current policy is written.
> 
Something like "ARIN will allow for the return of partial blocks of space from within the originally assigned  block without any further encumbrances". 

> >>>
> >>> 4.6.4 Incentives
> >>> The Board of Trustees should consider creating incentives for
> >>> organizations to return addresses under this policy.
> >
> > Should?  That doesn't really say much to my mind.  I think a "must"
> > or "will" would be in order to make this palatable.
> >
> Again, because of the limitations of the policy process, should is the
> strongest language that can be applied in this context.  I have a high
> degree of confidence that if this policy is adopted, the board will
> consider creating incentives.  Even if they do not, I don't see any
> way in which this policy is harmful, and, the membership certainly
> can through the member meeting process create a forcing function
> for the board to consider incentives if this policy is adopted.
> Fee issues are outside the purview of the policy process, so, this
> was the best compromise I could strike.
> 

It just seems to take all the teeth out of it, whereas the requirement further down are all very concrete.  I'd love to hear from Legacy holders about how they read it.

<snip>
> >
> > I'm assuming one or more of the bullets below would be rolled up
> > under 4.6.4?
> >
> The bullets below can't be policy.  That is why they were removed from
> the
> policy in this rewrite.  Fees are set by the BoT and are not part of
> the public
> policy process.
> 
<snip>

It might be better to remove it entirely so that it doesn't set unreasonable expectations.  Then, a separate discussion about incentives could be had within the community and submitted as comments/suggestions to the BoT.

Regards,

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 475 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080225/26418c40/attachment.sig>