First proposal - all who need space get it (fwd)

This was proposal number one for OPERATIONAL changes to ARIN's functional
allocation policies. Note that this gets us to an objective,
neutrally-verified criteria that allows, IMHO, all organizations with a
legitimate use for PI space to have it.

I am expanding the discussion list to NANOG and the ARIN Members mailing
lists. Please post comments PUBLICALLY, or if you feel you cannot do so
without "cloaking" yourself, through someone else (who you trust to strip
the attribution).

FIRST PROPOSAL:

1) The allocation policy of ARIN should be changed to reflect that any
  organization which can demonstrate that it can constructively use
  PI space should be able to receive it.
  
  "Constructively demonstrate" is stated to mean:

  a) The organization is multi-homed, possesses an ASN, and
    two or more independant T1-or-above rate connections to
    more than one backbone or other carrier (ie: to an exchange,
    to a NSP, to other ISPs). Documentation in the form of a
    signed connectivity agreement for a period of at least one
    year, or connectivity provable via existing network tools
    (ie: treno) is sufficient to satisfy this requirement.

  b) The ASN is visible at industry-accepted peering points and
    shows multiple paths available (ie: "nitrous.digex.net")

  c) The organization is EITHER:
    1) Engaged in the business of selling connectivity
      to the general public, or can otherwise document
      a REASONABLE expectation that at least 75% of the
      /19 will be fully utilized at some point in the
      future during the expected lifetime of the IPv4
      space (defined as 10 years). The firm must be able
      to prove this without resorting to a claim of
      confidentiality; in other words, you must be able
      to show that you're in the business of doing this
      from your public, visible, documentable actions.
        OR
    2) The firm contains enough employees, staff members,
      and EXTERNALLY ADDRESSABLE infrastructure equipment
      within its boundaries to qualify for efficient use
      of a /19 on its own (ie: more than 5,000 staff
      members).

2) To receive MORE space, regardless of the size of the organization,
  the requestor must document that more than <X>% of the existing
  space allocated to it is either;
  a) In use internally;
    OR
  b) Delegated to actively visible customers who actually use
    said IP address space.

  An IP address shall be deemed to be "constuctively used" if any of
  the following apply to it at the /32 level:
  a) It responds to a PING or other network packet addressed
    to it when queried.
  b) It is properly referenced in both forward and reverse DNS
    files, and the hostname is traceable and billable to a
    customer who has ongoing revenue associated with same. (ie:
    an ISDN connectivity provider sells a class of service which
    has a /29 associated with it; they generate hostnames for
    all 8 addresses, and the customer is routed behind those
    addresses).
  c) It is a member of a operational DCHP or other dynamic pool,
    and is properly referenced in both forward and reverse DNS
    maps.
  d) It is delegated to a dedicated circuit or other routed business
    customer, and is part of a block of no more than 64 addresses
    assigned to that customer.
  Network broadcast addresses (defined as "all ones" host
  components) are excluded from these requirements, as are
  "all zeros", since some equipment demands that the "zeros"
  address remain).
  
  The value for "X%" shall be set by discussion within the AC and
  ratified by vote.

  All organizations must prove up use in all blocks delegated to or
  through them in order to receive any further delegation of space.

  I recommend that the value of "X" be set somewhere between 50 and
  70%. This provides for some "slop", particularly in dedicated
  circuit customer situations (which are going to have some slop).
  However, it also prevents the practice of assigning a /24 to a
  customer who has five computers in their office - a practice which
  is extremely common!

3) A delegate producing documentation for classes of service (a - c)
  above may not claim privilege for these classes of information,
  as such is discernable from an external connection.

4) A delegate producing documentation for classes of service (d) may
  claim privilege as to the identities of the organizations involved,
  and may redact that information from their submissions, however,
  the actual allocations themselves must be documented.

5) All submitted documentation and prove-up performed under these
  policies are public information and subject to challenge by any
  member of the Internet community.