[address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)

Hi Jens,

As we are talking about AS numbers and implicit about BGP .. Lets take the following approach ... 

Ask the NCC to use a max-prefix kind of warning system in the hand-out / provisioning software ..

A 95% warning level at ( arbitrary number 100 AS nr's ). To start asking questions on what the LIR is doing .. A full stop handing out at the 100% of the $arbitrary-number ... And the NCC will have to manually increase the number by another $amount. Same as every ISP does on an Internet Exchange with $peer that trips their max-prefix number .... 

That can be implemented in the backend .. And the majority of the LIR's will never trip the max-resource level .. But the ones that do .. Can be directed to the IPRA's and provide additional insight on what the hell they think they are doing ... And if they are not providing a sufficient use case that satisfies the IPRA, their request to increase the $arbitraty-number won't be increased ... So they can't request additional resources. 

This suggested deployment setup doesn't need to be put in stone in the policy, but as a request to the NCC in the introduction or rationale .. To keep the policy text clear and the NCC can reply to it in their IA ..

Just my 2 cents ... 

Erik Bais. ( now a bit more awake that this morning ) ... 

> Op 16 mei 2015 om 12:26 heeft Opteamax GmbH <ripe at opteamax.de> het volgende geschreven:
> 
> Erik and all,
> 
> I think your idea to exclude 16Bit ASN from the proposal brings us much
> closer to consensus.
> 
> Nevertheless I think we should start discussing about how to "enhance"
> garbage collection, but this should IMHO not be part of discussion on
> _this_ proposal.
> 
> BR Jens
> 
>> On 16.05.2015 09:11, Erik Bais - A2B Internet wrote:
>> Hi Gert,
>> 
>> There are a couple things that I keep reading and hearing in the discussion here.. 
>> 
>> Run-out of 16 bit as's and garbage collection.. 
>> 
>> May I suggest to Job to look into the following to see if that would fit his plan moving forward and is in line with what the community thinks is acceptable. ( personally I don't have a specific preferrence ) 
>> 
>> Exclude the 16 bit AS's from the removal of the multihoming requirement. ( so it stays as it is currently ) and ask the NCC to keep a close look on the number of requested AS's per entity to avoid stockpiling and give them the silent 'right' to question and stop abuse of what we are trying to achieve here.  Also the NCC should include resource garbage collection in the ARC's and if that is not enough, report that to the community during the ripe meeting ncc update. 
>> 
>> The above mentioned suggestion could bring us closer to consensus.. It is not something I have a strong feeling about. It is a suggestion that one can look at. 
>> 
>> Personally I would go for version 1 of the proposal, no limitations and in addition ask the ncc to look close to any abusive behaviour. 
>> 
>> Regards,
>> Erik Bais
>> 
>> Verstuurd vanaf mijn iPad
>> 
>>> Op 15 mei 2015 om 14:34 heeft Gert Doering <gert at space.net> het volgende geschreven:
>>> 
>>> Dear AP WG,
>>> 
>>>> On Mon, Mar 09, 2015 at 04:57:20PM +0100, Marco Schmidt wrote:
>>>> The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for 
>>>> AS Number Assignments" has been extended until 19 May 2015.
>>> 
>>> So - we extended this to wait for the AGM decision on "charging for AS
>>> numbers".  The AGM decided, and the clear majority decide to not introduce
>>> annual charges for AS numbers - my life would be easier otherwise, but
>>> this is what was decided, so respect it and see how we can achive our
>>> goals here :-)
>>> 
>>> Feedback for this proposal so far was, if I simplify a bit
>>> 
>>> - we want to take care not to exhaust 16bit-ASNs
>>> - there is unlimited number of 32bit ASNs
>>>   (but there *also* was feedback about "N. from I. could go out and
>>>   register all 4 billion 32bit ASNs, and exhaust the system"... now what?)
>>> 
>>> - we might want a garbage collection / reclamation mechanism
>>> 
>>> - the current policy text is too complicate, arbitrary numbers are bad
>>> 
>>> but there *is* quite a bit of support for the generic idea of "loosen up
>>> the rules for 32bit ASNs, as the multihoming requirement is often hard
>>> or impossible to demonstrate or check".
>>> 
>>> So, what should we (or, more precise, the proposers) do to get there?
>>> 
>>> Nick, I'm actually looking at you since you threw the most sand into the
>>> gears here...  some specific suggestions how you'd tackle this would 
>>> be welcome.
>>> 
>>> (Technically, I see no other way than to change text and do another round
>>> of IA/review phase with the feedback we've received until now - if, based
>>> on the new background from AGM, everybody who has objected so far is now
>>> accepting this at it stands to go forward - please say so!)
>>> 
>>> Gert Doering
>>>       -- APWG chair
>>> -- 
>>> have you enabled IPv6 on something today...?
>>> 
>>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
>>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>>> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>> 
>> 
>> !DSPAM:637,5556f3e6233401397117280!
> 
> 
> -- 
> Opteamax GmbH - RIPE-Team
> Jens Ott
> 
> Opteamax GmbH
> 
> Simrockstr. 4b
> 53619 Rheinbreitbach
> 
> Tel.:  +49 2224 969500
> Fax:   +49 2224 97691059
> Email: jo at opteamax.de
> 
> HRB: 23144, Amtsgericht Montabaur
> Umsatzsteuer-ID.: DE264133989
>