[ppml] 2002-7--- A New idea---
jmcburnett at msmgmt.com
Wed Feb 19 17:42:58 EST 2003
Everyone let's cut the red tape..
Everyone read the attached FAQ that Forrest sent.
This is the answer..
>From: Forrest [mailto:forrest at almighty.c64.org]
>Sent: Wednesday, February 19, 2003 5:37 PM
>To: ppml at arin.net
>Subject: Re: [ppml] 2002-7--- A New idea---
>It appears that APNIC assigns small blocks of portable IP addresses to
>On Wed, 19 Feb 2003, McBurnett, Jim wrote:
>> I have an idea:
>> Does any other RIR have a policy like this?
>> If so, let's cheat and look at their's and see if we can use
>it? Why reinvent the wheel?
>> And why didn't someone else think about this?
>> >-----Original Message-----
>> >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com]
>> >Sent: Wednesday, February 19, 2003 1:20 PM
>> >To: 'Michael.Dillon at radianz.com'; ppml at arin.net
>> >Subject: RE: [ppml] Withdrawal of 2002-7
>> >I agree with Michael. Let's see what the authors of 2002-3
>> >come up with in
>> >their rewrite. Hopefully it will be more succinct.
>> >-----Original Message-----
>> >From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com]
>> >Sent: Wednesday, February 19, 2003 6:39 AM
>> >To: ppml at arin.net
>> >Subject: [ppml] Withdrawal of 2002-7
>> >My take on the discussion of 2002-7 is that it is bad policy
>> >because it
>> >mixes too many issues together. I have nothing against an
>> >omnibus policy
>> >as long as it is well organized so that the individual issues
>> >are clear in
>> >and of themselves. But 2002-7 doesn't do that and as a result the
>> >discussion just keeps going around in twisted and
>> >Therefore, I suggest that ARIN should set aside this policy
>> >proposal and
>> >not give it any further consideration.
>> >Ron Da Silva has made a very good suggestion for separating
>> >the distinct
>> >items and discussing them in separate threads. I would like
>> >suggest that these items be discussed with an intent to turn
>> >them into a
>> >series of separate policy proposals. To refresh your memories, Ron
>> >suggested that we should deal with the following separate issues:
>> >Revocation - under what conditions should ARIN revoke an address
>> >allocation? Should this action extend to include assignments?
>> >Enforcement - what actions should ARIN take to enforce its
>> >allocations and
>> >its policies, if any?
>> >Leasing - what AUP should ARIN impose on anyone receiving an
>> >allocation to
>> >ensure that any "lease terms" are passed on to sub-allocations and
>> >Accuracy of data - what is ARIN's policy regarding the
>> >accuracy of SWIP
>> >and rwhois data? How will ARIN enforce this policy?
>> >Then he suggested an item regarding IETF cooperation that
>> >wasn't clear to
>> >me but which appears to include my following suggestion:
>> >Public Authoritative Directory:
>> >ARIN will publish an authoritative directory for all of the
>> >space which it administers.
>> >This directory will be public and will be published using
>LDAP v3 also
>> >known as referral LDAP.
>> >Only a minimal set of information will be made fully
>public, i.e. one
>> >email address and one phone number per organization along with the
>> >organization's name and city.
>> >Additional contact information, personal names and street
>> >addresses will
>> >be in the directory but will only be accessible to ARIN
>> >members who are in
>> >posession of suitable credentials.
>> >The intent is to facilitate communication while inhibiting
>> >email address
>> >scraping and stalking.
>> >All organizations receiving ARIN allocations must either
>> >accurate record of their sub-allocations and assignment with
>> >ARIN or they
>> >must operate an LDAP v3 server containing such information and
>> >open to the
>> >ARIN will ensure that existence information is updated in this
>> >on a daily basis.
>> >Existence information refers to the fact that an allocation
>> >exists, i.e.
>> >it has been allocated and has not been revoked.
>> >ARIN will also do a twice yearly audit of the accuracy of
>> >information in this database.
>> >When contacts do not respond, the data in the ARIN database will be
>> >replaced with contact info for the next level up in the hierarchy.
>> >In other words, if an ISP gets address space from UUNet and
>> >respond during the audit, then ARIN will record UUNet
>contact info for
>> >this ISP.
>> >The intent is to ensure that there is an identifiable and
>> >contact for all address space that is legitimately in use.
>> >ARIN will provide a mirroring mechanism for this directory and
>> >organizations to mirror the entire directory for use in their
>> >route servers, etc.
>> >ARIN will warn that it is not good engineering practice to
>> >connect this
>> >directory directly to BGP route filters but will not prohibit the
>> >However ARIN will disclaim all responsibility for any
>damage that may
>> >result from such misuse.
>> >Please CHANGE THE SUBJECT if you wish to discuss one of
>> >Michael Dillon
More information about the ARIN-PPML