[arin-ppml] Revision to 2007-14

[Leo Bicknell]

In a message written on Mon, Oct 06, 2008 at 07:07:01PM -0500, David Farmer wrote:
> This is motherhood and apple pie type stuff, but it needs to be said.  As Leo 
> pointed out in another thread this is covered in RFC 2050, and by reference 
> in NRPM 4.1.7, however I believe this is an important enough concept that it 
> should be explicit in the NRPM some place.
> 
> I guess what I'm trying to say is that ARIN policy shouldn't imply that you can 
> keep your IP allocations until ARIN asks you to return them.  Therefore 
> there needs to be some kind of statement to that effect and in my opinion 
> 4.1.2 comes the closest to that in the NRPM now.  It would be better to have 
> something that says that more directly, but 4.1.2 is better than nothing.  

Your issue raises a procedural question.  Our process allows us to
move forward the current proposal "as is" (there are some nuances
to that, but close enough for this discussion), or we can change
it and hold it back for another loop through the next meeting.

So if you feel strongly enough that this should be included, you have
basically two paths forward:

1) Lobby Owen to modify his proposal, and choose not to support it
   as-is.  This will require all changes to go through another meeting
   cycle.

2) Let this policy go as-is, and then submit an additional policy for
   the next meeting which clarifies the section of interest.  In this
   case we can get the benefits of most of the proposal now, and add
   some additional clarification in the next cycle.

Do you believe this issue is important enough that path #1 is necessary,
or would path #2 make you happy?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081007/e9ead345/attachment.sig>