[ppml] 2002-7--- A New idea---
forrest at almighty.c64.org
Wed Feb 19 17:37:10 EST 2003
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 convoluted circles.
> >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 to further
> >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 IP address
> >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 maintain an
> >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 the contact
> >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 does not
> >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 responsive
> >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 these policy
> >Michael Dillon
More information about the ARIN-PPML