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

McBurnett, Jim jmcburnett at msmgmt.com
Wed Feb 19 16:37:04 EST 2003

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 mailing list