[address-policy-wg] 2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4

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