[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?
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
>
More information about the ARIN-PPML
mailing list