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

[McBurnett, Jim]

If we went exactly by the APNIC policy-
they do not stipulate a block size... 
Then maybe we, those of us in ARIN, are too bent around the
axel with US Law and triyng to be TOO exact and TOO strict.

Think of this. 2001-2 justifies a Class C for Multihoming.
Change the below to read:
You can apply for an assigment of any size with a minimum of a /24, as defined bby ARIN 2001-2.
All blocks large than a /24 are subject to standard 25 % and 50 % usage requirements as defined by current ARIN 
policy.


Anyway I consider this to be simple. Let's plagerize (SP?), submit this to voting members and move on..

Jim

APNIC website as noted below..
QUOTE

What size are the assignments?
You can apply for an assignment of any size provided you can demonstrate the need for that space. You must demonstrate that you will use 25 percent of the assignment immediately and 50 percent within one year. Please remember, APNIC cannot guarantee the routability of any assignment it makes and very small assignments may not be globally routable.
Top

Is there a maximum or minimum assignment size?
No. Assignments are based on demonstrated need. However, if you are close to meeting the minimum allocation size (/20), you may find it more economical to become an APNIC member and apply for a portable allocation using the APNIC IPv4 ISP request form.

END QUOTE:


> -----Original Message-----
> From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com]
> Sent: Wednesday, February 19, 2003 5:51 PM
> To: McBurnett, Jim; ppml at arin.net
> Subject: RE: [ppml] 2002-7--- A New idea--- 
> 
> 
> 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
> >> >
> >> 
> >
> >
> >
>