[ppml] 2002-7--- A New idea---

[Forrest]

It appears that APNIC assigns small blocks of portable IP addresses to 
multihomed organizations.  

http://www.apnic.net/info/faq/multihoming_faq.html

Forrest

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? 
> 
> Later,
> Jim
> 
> 
> 
> 
> >-----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.
> >S
> >-----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 
> >assignments?
> >
> >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 
> >public. 
> >
> >ARIN will ensure that existence information is updated in this 
> >directory 
> >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 
> >encourage 
> >organizations to mirror the entire directory for use in their 
> >firewalls, 
> >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 
> >practice.
> >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 
> >items.
> >
> >----
> >Michael Dillon
> >
>