Hi APWG, It should be noted that the below message is an "in-between poll" to seek guidance for the next formal version. As Gert aptly pointed out to me, technically I now started a "random discussion". :-)
Anyhow, please help us address the adversary argument. Kind regards, Job On Tue, Aug 11, 2015 at 11:15:36AM +0200, Job Snijders wrote: > 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
