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

[John Springer]

Opposed.

On Tue, 15 Feb 2011, ARIN wrote:

> 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.
>
>