[ppml] Policy Proposal 2006-3: Capturing Originations in Templates

[Scott Leibrand]

I support this policy under the condition that ARIN takes the origin AS 
information provided and populates/updates the ARIN RR with that information 
(possibly in addition to making it available by whois or other means).

My reading of the policy below indicates that use of the data to populate 
the ARIN RR would be an allowed use of the data (at the discretion of ARIN 
staff), but would not be required.  While I would prefer that the policy 
specifically direct ARIN to populate the RR, I would also support the policy 
as written (unless ARIN interprets the policy to not allow them to update 
their RR with the data).

-Scott

----- Original Message ----- 
From: "Member Services" <memsvcs at arin.net>
To: <ppml at arin.net>
Sent: Friday, February 17, 2006 11:32 AM
Subject: [ppml] Policy Proposal 2006-3: Capturing Originations in Templates


> On February 16, 2006, the ARIN Advisory Council concluded its review of
> 'Capturing Originations in Templates' and accepted it as a formal policy
> proposal for discussion by the community. This proposal is designated
> Policy Proposal 2006-3: Capturing Originations in Templates. The
> proposal text is below and can be found at:
>
> http://www.arin.net/policy/proposals/2006_3.html
>
> All persons in the community are encouraged to discuss Policy Proposal
> 2006-3 in the weeks leading to the ARIN Public Policy Meeting in
> Montreal scheduled for April 10-11, 2006. Both the discussion on the
> Public Policy Mailing List and at the Public Policy Meeting will be used
> to determine the community consensus regarding this policy proposal.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> ARIN's Policy Proposal Archive can be found at:
> http://www.arin.net/policy/proposals/proposal_archive.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ### * ###
>
>
> Policy Proposal 2006-3: 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 NRPM 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
>