[ppml] Proposed Policy: Capturing Originations in Templates

Owen DeLong owen at delong.com
Fri Feb 10 05:35:46 EST 2006

I oppose this policy... It represents a duplication of effort.  There are 
a number of routing registries (RADB, ARIN RR, etc.) which can be used to
express such data in far greater detail and a more useful fashion.  Please,
let's not reinvent the wheel with a new inferior solution to an already
solved problem.


--On February 9, 2006 6:36:17 PM -0500 Member Services <memsvcs at arin.net> 

> ARIN received the following proposed policy. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List and being placed on ARIN's
> website.
> The ARIN Advisory Council (AC) will review the proposal and within ten
> working days may decide to:
> 1)  Support the proposal as is,
> 2)  Work with the author to clarify, divide or combine one or more
> policy proposals, or
> 3)  Not support the policy proposal.
> If the AC supports the proposal or reaches an agreement to work with the
> author, then the proposal will be posted as a formal policy proposal to
> the Public Policy Mailing List and it will be presented at the Public
> Policy Meeting. If the AC does not support the proposal, then the author
> may elect to use the petition process to advance the proposal. If the
> author elects not to petition or the petition fails, then the proposed
> policy will be considered closed.
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> 	http://www.arin.net/policy/irpep.html
> Mailing list subscription information can be found at:
> 	http://www.arin.net/mailing_lists/index.html
> Regards,
> Member Services
> American Registry for Internet Numbers (ARIN)
>### * ###
> Policy Proposal Name: Capturing Originations in Templates
> Author: Sandra Murphy
> Proposal type: new
> Policy term: permanent
> Policy statement:
> ARIN will collect an optional field in all IPv4 and IPv6 address block
> transactions (allocation and assignment requests, reallocation and
> reassignment actions, transfer and experimental requests).  This
> additional field will be used to record a list of the ASes that the user
> permits to originate address prefixes within the address block.
> ARIN will produce a collection of the mappings from address blocks to
> ASes permitted to originate that address block, The collection will
> consist of a list where each entry will consist, at a minimum, of
> an address block, a list of AS numbers, and a tag indicating the type of
> delegation of the address block.  This collection will be produced at
> least daily.
> ARIN will make the collected mappings from address blocks to AS numbers
> available for bulk transfer in one or more formats chosen at its own
> discretion, informed by the community's current needs.  This data will
> not be subject to any redistribution restrictions -- it may be
> republished or repackaged it any form.  Should ARIN choose to use WHOIS
> bulk transfer as the bulk form of data access required by this
> paragraph, the address block to AS mappings will not be subject to any
> redistribution restrictions, but the remainder of the WHOIS data will
> remain subject to the terms of the then-current AUP regarding bulk
> access to WHOIS data.
> ARIN may also make the collected or individual mappings from address
> blocks to AS numbers available in other forms, possibly query
> services, chosen at its own discretion, informed by the community's
> current needs.  ARIN may require agreement to an acceptable use policy
> for access to the data in these forms.
> Rationale:
> Origination of prefixes by ASes that have no authority for the
> origination is a recurring problem in the Internet routing system. A
> list of authorized prefix originations would be beneficial to operators in
> 	constructing routing filter lists to counter bogus
> 		originations,
> 	interacting with customers requesting routing of a prefix, and
> 	diagnosing routing problems.
> A list of authorized prefix originations is also the necessary first
> step for any known solution for securing the routing system.
> Prefix originations can be stored in routing registry RPSL route
> objects.  However, the authority for addresses and for ASes belongs to
> the RIRs.  There is presently no mechanism to translate ARIN's authority
> for number resources to an IRR.  Furthermore, operators have been less
> than diligent in creating and maintaining route objects. Capturing the
> prefix origination authorization in number resource registrations with
> ARIN has two main goals:
> 	benefit from the scrutiny with which ARIN verifies initial
> 		requests and authenticates subsequent transactions, and
> 	inherit the operators' self-discipline in completing resource
> 		requests and transactions.
> As an additional benefit, this could take a step toward populating the
> IRR with data known to be accurate.
> The intended use of this data means that both query for individual
> entries and bulk access to a list of the collected entries, without
> restriction on redistribution, is required.  This policy requires that
> the additional data be provided through the usual whois query service
> and some bulk access service that has no restrictions.  It permits ARIN
> to provide the bulk access through the existing bulk whois service if
> the new additional data is not subject to the bulk whois AUP
> restrictions.  The policy does not limit ARIN to providing only those
> two services (whois query and unrestricted bulk access); other
> additional services may be developed at ARIN's discretion.
> It is expected that entries in the list of collected entries will
> include at a minimum the present NetRange and NetType attributes, with a
> new attribute, perhaps named OriginatingASList, for the list of
> permitted originating ASes.
> This policy will presumably be incorporated into NPRM section 3.4.
> Timetable for implementation: Within sixty (60) days of approval.
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060210/f5e2402b/attachment-0001.sig>

More information about the ARIN-PPML mailing list