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

[Taylor, Stacy]

Shouldn't we have a minimum /24 assignment, though?
S

-----Original Message-----
From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com]
Sent: Wednesday, February 19, 2003 2:43 PM
To: ppml at arin.net
Subject: RE: [ppml] 2002-7--- A New idea--- 


Everyone let's cut the red tape..
Everyone read the attached FAQ that Forrest sent.
This is the answer..
Jim


>-----Original Message-----
>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 
>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
>> >
>> 
>
>
>