Angela Dall'Ara wrote on 06/05/2025 12:50:
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too prescriptive about operational details. As a general comment about policy creation, policy should aim towards stating principles about what-should-be-done, and for the most part should leave the details of how-to-do-it to the procedure manual. There's a bunch of reasons for this, not least being able to deal with procedural abuse, bearing in mind that the implementation time for plugging policy holes is measured in double-digit months or years. Zooming out, the policy is: - first ASN: on request - subsequent ASNs: stated need Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number (ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the LIR or End User can provide documented justification for the unique external routing policy for the ASN application. The uniqueness of the routing policy includes the announced prefixes. The LIRs or End Users must demonstrate fulfillment of the criteria for which the application was approved within six months of the ASN being assigned.
The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. Autonomous System Numbers may not be sub-assigned. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." NB: prohibition on sub-assignment now made explicit.
Nick