[arin-ppml] Discussion Petition for Proposal 109 - Standardize IPReassignment Registration Requirements

Fri Jul 23 17:06:52 EDT 2010

I support the petition of proposal 109.
Michael K. Smith, Adhost Internet LLC, Contact in Sig
--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Chris Grundemann
> Sent: Friday, July 23, 2010 10:51 AM
> To: ARIN PPML
> Subject: [arin-ppml] Discussion Petition for Proposal 109 -
Standardize
> IPReassignment Registration Requirements
> 
> This post should act as my formal request to initiate a discussion
> petition of proposal 109 and to request that it be moved to draft
> policy status for discussion at ARIN XXVI.
> 
> > The AC decided not to select Proposal 109 as a draft policy at this
time:
> >
> >  109. Standardize IP Reassignment Registration Requirements
> >
> > Regarding Proposal 109, the AC would really like to see the
sentiments
> > in this proposal re-surface in bite-size pieces. SWIP requirements,
both
> > IPv4 and IPv6, the distinction of residential customers, the
utilization
> > requirements for subsequent allocations, and customer privacy are
all
> > good topics, but agreement in some will be held up by any
disagreements
> > on the others when trying to address them as one.
> 
> Although I understand the sentiments of the AC, I am petitioning this
> proposal as I feel strongly that it meets the basic requirements for
> ARIN Policy and meets the immediate needs of the community. This
> proposal was previously discussed at the open policy hour in Toronto
> and I believe that the best next step is for the final (v4) text to be
> discussed as a draft policy in Atlanta. If the petition is successful
> I will continue to work with the AC in preparation for presenting it
> at the PPM in Atlanta.
> 
> If you support this petition, please send the following:
> 
> I support the petition of proposal 109.
> <Name, Organization, Contact info>
> 
> Either as a response to this thread or directly to petition at arin.net
> if you do not want your information to be broadcast on the PPML.
> 
> --
> 
> Author contact information:
> 
> Chris Grundemann
> cgrundemann at gmail.com
> +1.303.351.1539
> 
> --
> 
> Policy statement (v4):
> 
> ## Definitions ##
> 
> - Add:
> 
> 2.3. Organizational Information
> 
> When required, organization Information must include at a minimum:
> Legal name, street address, city, state, zip code equivalent and at
> least one valid technical and one valid abuse POC. Each POC shall be
> designated by the organization and must include at least a verifiable
> email address and phone number.
> 
> 2.12. Residential Customer
> 
> End-users who are individual persons and not organizations and who
> receive service at a place of residence for personal use only are
> considered residential customers.
> 
> ## IPv4 ##
> 
> - Rename 4.2.3.7. "Reassignment information" to "Registration" and add
text:
> 
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
> 
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
> 
> Each IPv4 assignment containing a /29 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
> 
> - Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5.
> 
> - Renumber section 4.2.3.7.3. to 4.2.3.7.2., rename to "Assignments
> visible within 7 days" and replace text with:
> 
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
> 
> - Renumber and replace 4.2.3.7.6. Residential Customer Privacy with:
> 
> 4.2.3.7.3. Residential Subscribers
> 
> 4.2.3.7.3.1. Residential Market Area
> 
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /29 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
> 
> 4.2.3.7.3.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS directory record for that
> block.
> 
> - Strike section 4.2.6. "Cable Address Space Policy"
> 
> ## IPv6 ##
> 
> - Replace Section 6.5.5. with:
> 
> 6.5.5. Registration
> 
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
> 
> 6.5.5.1. Reassignment information
> 
> Each IPv6 assignment containing a /64 or more addresses shall be
> registered in the WHOIS directory via SWIP or a distributed service
> which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
> 
> 6.5.5.2. Assignments visible within 7 days
> 
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
> 
> 6.5.5.3. Residential Subscribers
> 
> 6.5.5.3.1. Residential Market Area
> 
> ISPs that assign address space to the infrastructure to which their
> customers connect rather than to individual subscribers must register
> assignment information regarding each market area holding such an
> address block. Market area reassignments shall be registered with the
> network name used to identify each market area. Any assignment to
> specific end-users holding /64 and larger blocks still requires
> registration. A >50% utilization rate shall be considered efficient
> for market area reassignments from the ISPs most recent allocation.
> 
> 6.5.5.3.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /64 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
> 
> ## Resource Review ##
> 
> - Move section 12.2. paragraph 2. bullet c. to bullet d. and insert
> the following:
> 
> c. whenever ARIN has reason to believe that an organization is not
> complying with reassignment policies, or
> 
> --
> 
> Rationale:
> 
> #Changes in this version:
> After many conversations both at and following the last public policy
> meeting in Toronto, some revisions have been made. These all address
> specific concerns raised by multiple interested parties:
> 1) Organizational Information - Phone number, street address and abuse
> POC now required.
> 2) Residential Customer - Added "for personal use only" to the
definition.
> 3) Registration  (4.2.3.7 & 6.5.5) - Added "but not limited to" WRT
> assignment histories.
> 4) IPv6 - Requires all /64 and larger blocks to be registered.
> 5) Resource Review - Added this section.
> 
> #Short Rational:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to WHOIS when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all WHOIS entries in policy. This includes
> designating an upstream POC as their own preferred POC (which allows
> for simple reassignments).
> 4) Expands the privileges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
> 5) Specifically define the term "residential customer."
> 6) Allow ARIN to conduct resource reviews based on failure to comply
> with registration / reassignment policies.
> 
> #Expanded Rational:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
> a) The IPv4 section is renamed "registration."
> b) The IPv4 policy is shortened and rewritten for clarity.
> c) The IPv6 policy is totally rewritten in a format that matches the
> IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> d) The IPv6 policy is altered from a /56 minimum needing to be
> registered to a /64. A /64 is a single IPv6 subnet where as a /56
> contains many subnets (that should all be recorded in the WHOIS
> directory if handed out to other organizations).
> 
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
> a) The definition states that legal name and physical address are
> required for client organizations.
> b) The definition states that POCs are required but can be designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
> c) The definition requires that each POC have a valid email address
> and phone number.
> 
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
> a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
> b) It retains the existing residential customer privacy policy for all
> customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
> 
> 4) This policy also extends the >50% utilization rate, currently
> granted only to IPv4 cable operators, to all ISPs with a residential
> footprint.
> * This change offsets the ability to register/swip/rwhois market
> areas. For all other allocation types, efficient utilization is based
> on SWIPs, not on actual utilization. When an organization is able to
> SWIP an entire market area, this must be checked against actual
> utilization. This policy maintains the current line set at >50%.
> **The 50% mark on the most recent allocation is because you can
> quickly distribute most of your address space across your provisioning
> footprint, leaving nothing left for growth while the lease count of
> the provisioned customers catches up to the blocks allocated. (Dan
> Alexander's words)
> 
> 
> 5) Current policy references "residential customers" but there is no
> current definition of residential customers in the NRPM. This has
> reportedly been an on-going problem for ARIN and it's customers.
> 
> 6) Not properly registering reassignment information could be a sign
> of other improper or illicit behavior and should justify a resource
> review (audit) by ARIN when necessary, regardless of when the last
> review took place.
> 
> --
> 
> Thank you,
> ~Chris
> 
> 
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.