[arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised

[George Bonser]

Opposed

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of ARIN
> Sent: Tuesday, February 15, 2011 2:14 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of
> Unaffiliated Address Blocks - revised
> 
> The proposal originator submitted revised text.
> 
> "Changes from Previous Version:
> Version 2 of this proposal removed section 13.2 so that it could be
> considered separately, in a new policy proposal submission.  As a
> result, the remaining sections were renumbered to use an abstract
> system
> of "13.x" and "13.y", with the intent that actual sub-section numbers
> would be assigned later in the policy development process."
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address
> Blocks
> 
> Proposal Originator: Benson Schliesser
> 
> Proposal Version: 2
> 
> Date: 15 Feb 2011
> 
> Proposal type:  New
> 
> Policy term:  Permanent
> 
> Policy statement:
> 
> Add the following to the NRPM:
> 
> 13.  Unaffiliated Address Blocks
> 
> 13.x. No Volunteer Services
> 
> Except in the specific circumstances described by this policy, ARIN
> will
> not provide any services for any organization and/or address block.
> This includes without limitation all directory services,  reverse
> mapping services, and future services that may be provided to the
> community.
> 
> 13.x.1.  Requested Services
> 
> In the event that an organization explicitly requests registry
services
> from ARIN for one or more specified address blocks, ARIN may provide
> the
> requested services, subsequent to execution of a  service contract,
for
> those address blocks.  This includes without limitation all directory
> services, reverse mapping services, and future services that may be
> provided to the community.
> 
> All address blocks that are assigned or allocated by ARIN under a
valid
> RSA, as well as specific  address blocks that are included under a
> Legacy RSA with the legitimate validated address  holder, are deemed
to
> have services requested for them.
> 
> An organization requesting registry services for one or more specified
> address blocks, that also holds additional address blocks not
specified
> in their request, is not obligated to receive registry services for
> those additional address blocks and those blocks are not deemed to
have
> services requested for them.
> 
> 13.x.2. Directory Placeholders
> 
> For any address blocks, for which there are not fully executed ARIN
> service contracts, ARIN will create generic placeholder entries in the
> ARIN Whois directory.  These placeholder entries will not specify
> organizational details, but will indicate that the entry represents a
> non-member resource.
> 
> When applicable, each non-member resource placeholder will include a
> reference and/or RWhois referral to the authoritative directory
service
> for that block, or the directory service operated by the IANA, or by
> another organization in the event that IANA has delegated their
> directory service responsibility to that organization.  This does not
> apply to placeholders that represent an unassigned and unallocated
> address block delegated to ARIN by the IANA.
> 
> 13.y.  Permitted Updates to Directory Services for Unaffiliated
Address
> Blocks
> 
> Any organization that legitimately holds an address block, as defined
> by
> section 13.2 of this policy, may request the removal or modification
of
> existing directory placeholders representing that address block.
> 
> Valid requests for modification of placeholder entries are limited to
> references and/or RWhois referrals to authoritative directory
services,
> such as directory services operated by or on behalf of the IANA,
> another
> address registry, or the address holder.  In the event that such a
> request is received, ARIN may choose to either remove the placeholder
> entry or update it per the request.
> 
> 
> Rationale:
> 
> Policy Background:
> 
> This policy attempts to clarify the relationship that ARIN has with
> legacy address holders.
> 
> Specifically, this policy recognizes that absent an agreement such as
> the RSA or LRSA there is no formal relationship with legacy address
> holders.  At present, however, ARIN continues to provide services to
> these organizations.  This is done without compensation and
potentially
> in opposition to the legacy address holders' wishes.  As a result of
> this behavior ARIN has created an illusion of implied authority that
> exposes ARIN to unacceptable levels of liability, is hindering the
> development of an open address market (driving it "underground"), and
> is
> putting the operational stability of the Internet at risk.  As new
> services such as RPKI are contemplated this situation becomes even
more
> critical.
> 
> This policy would require positive affirmation from any legacy address
> holder that wishes to receive registry services, moving to an "opt-in"
> approach.  In the event that a legacy address holder does not opt-in
to
> receive registry services, ARIN is limited to providing no more than a
> pointer (such as a RWhois referral) to an authoritative directory
> service for that holder's legacy address blocks.  Pointers to other
> providers of directory services for addresses managed by those
> other providers continue to be permitted.
> 
> Policy Structure:
> 
> This policy introduces a new section to the NRPM, numbered section 13.
> Within this new section, there are two new sub-sections described in
> this proposal.
> 
> Sub-section 13.x introduces policy that limits ARIN to providing
> services on an opt-in basis.  It does make clear in 13.x.1 that
> services
> provided as part of a RSA or LRSA are automatically considered opted-
> in.
> With 13.x.2 it allows ARIN to create placeholders in the Whois
database
> for blocks managed by other RIRs as well as for blocks managed (but
> unassigned/unallocated) by ARIN.
> 
> Sub-section 13.y introduces policy enabling legitimate address holders
> to request a very limited update to any Whois placeholders that might
> exist for their legacy address block, so that the Whois will refer
> queries to the authoritative directory service.  It is expected that
> ARIN will charge a fee for this update, but not require an ongoing
> services agreement.  ARIN is given the option of deleting placeholders
> instead.
> 
> Changes from Previous Version:
> 
> Version 2 of this proposal removed section 13.2 so that it could be
> considered separately, in a new policy proposal submission.  As a
> result, the remaining sections were renumbered to use an abstract
> system
> of "13.x" and "13.y", with the intent that actual sub-section numbers
> would be assigned later in the policy development process.
> 
> Discussion:
> 
> This proposal should not be interpreted as a "punishment" of legacy
> address holders or as an attempt to encourage execution of the LRSA.
> Rather, the intent of this proposal is to make it clear that ARIN will
> only provide services for organizations that wish to receive them.
Put
> another way: this proposal would prohibit ARIN from forcing any
> organization to be listed in the ARIN Whois database without their
> consent.
> 
> While it is not anticipated by this proposal's text, alternative forms
> of "request" are not prohibited by this policy proposal.  Indeed,
while
> the RSA and LRSA are recognized as current forms of request for
> services, the ARIN community may choose to develop additional
> mechanisms.
> 
> Prior to implementing this policy, ARIN should attempt to contact the
> address holders that would have services removed as a result of this
> policy.  Specifically, ARIN should make them aware of the loss of
> services, explain the potential impact of losing reverse mapping DNS
> services, etc. If an affected address holder cannot be reached by
ARIN,
> or refuses to communicate with ARIN on this topic, then ARIN may
> consider their contact attempt to be satisfied.
> 
> Timetable for implementation:  Immediately
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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.