This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] Fwd: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4
- Previous message (by thread): [routing-wg] Weekly Routing Table Report
- Next message (by thread): [routing-wg] Promote the use of IRC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Rob Evans
rhe at nosc.ja.net
Tue Aug 11 11:50:26 CEST 2015
Hi, As the routing WG, folk here might want to consider and comment on this policy proposal in APWG. Cheers, Rob ----- Forwarded message from Job Snijders <job at instituut.net> ----- Date: Tue, 11 Aug 2015 11:15:36 +0200 From: Job Snijders <job at instituut.net> To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4 X-Spam-Score: -0.2 (/) Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job ----- End forwarded message -----
- Previous message (by thread): [routing-wg] Weekly Routing Table Report
- Next message (by thread): [routing-wg] Promote the use of IRC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]