[ncc-services-wg] Re: [routing-wg]Re: [address-policy-wg] 32-bit AS Number status?

Hello,

The presentation I have mentioned in my previous mail did not discuss  
a proposed change in the RIPE ASN policy. In fact, there has been no  
revisions on the policy document since then and it is still as follows:

----
..
# From 1 January 2009 the RIPE NCC will process applications that  
specifically request 16-bit AS Numbers and assign such AS Numbers as  
requested by the applicant. In the absence of any specific request for  
a 16-bit AS Number, the RIPE NCC will assign a 32-bit only AS Number.

# From 1 January 2010 the RIPE NCC will cease to make any distinction  
between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate  
AS Number assignments from an undifferentiated 32-bit AS Number  
allocation pool.
----

The question that the presentation asked was on how exactly the RIPE  
Community thought the RIPE NCC should be assigning ASN numbers in  
2010, following the two pieces of text above and whether they saw a  
need to change this text. The answer was to continue the way it was  
done during 2009, seeing no need for a change in the policy text or in  
the current procedure of the RIPE NCC. The minutes of this discussion  
was posted to the AP WG mailing list on 13 Aug 2009.

Having said that, you can still make a policy proposal if you think  
that the policy text and so the RIPE NCC procedure must be changed.

As a side note, during this presentation, one other issue about 32 bit  
AS Numbers, relating to the Global ASN policy, was also discussed.  
This resulted in a formal global proposal and it was discussed in all  
regions because it required a change in the global policy. You can see  
the details of this proposal at http://www.ripe.net/ripe/policies/proposals/2009-07.html 
.
RIPE Community reached consensus on this proposal back in September  
2009.

Kind regards,

Filiz Yilmaz
Policy Development Manager
RIPE  NCC

On 30 Jan 2010, at 21:21, Hank Nussbacher wrote:

> On Fri, 29 Jan 2010, Filiz Yilmaz wrote:
>
>> Dear Shane,
>>
>> During RIPE 58, Daniel Karrenberg has made a presentation, titled  
>> "32-bit ASN Take-Up Report, Policy Adjustments Needed?".
>> You can find the presentation at the archives at http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
>>
>> Slide 5 of the presentation relates to your question. The RIPE NCC  
>> proposed that the method of assigning ASNs that was employed in  
>> 2009 should continue after 1 January 2010. This means that all  
>> assignments will be for 32-bit only ASNs by default, unless a 16- 
>> bit ASN is specifically requested. The AP WG agreed with this  
>> proposal.
>
> Does the RIPE NCC consider a slide in a presentation as proper  
> documentation for revised ASN assignment procedures?
>
> -Hank
>
>>
>> You can find the records of this at:
>>
>> http://www.ripe.net/ripe/meetings/ripe-58/meeting-report.php
>> and
>> http://www.ripe.net/ripe/wg/address-policy/r58-minutes.html
>>
>> I hope this helps.
>>
>> Kind regards,
>>
>> Filiz Yilmaz
>> Policy Development Manager
>> RIPE NCC
>>
>>
>> On 28 Jan 2010, at 18:29, Shane Kerr wrote:
>>
>>> All,
>>> I noticed that the proposed updated AS Number policy was sent to the
>>> address-policy-wg recently.
>>> There is a timeline for 32-bit AS Number in both the old and new
>>> versions, which says:
>>> "From 1 January 2010 the RIPE NCC will cease to make any distinction
>>> between 16-bit AS Numbers and 32-bit only AS Numbers, and will  
>>> operate
>>> AS Number assignments from an undifferentiated 32-bit AS Number
>>> allocation pool."
>>> I'm not sure exactly what this means, but I think it is supposed  
>>> to mean
>>> that people get 32-bit AS Numbers now. Did this happen?
>>> If it didn't, why not? Do we need to change "2010" to "2011"? Is  
>>> it ever
>>> going to happen?
>>> If it did, was there any effect? I mean both from humans (angry  
>>> LIRs,
>>> peasants marching on the castle with torches, riots in the  
>>> streets), or
>>> on the Intertubes (ugly routing artifacts, mass reboots of boxes  
>>> with
>>> old firmware, monitoring systems gone wild)?
>>> Just wondering. :)
>>> --
>>> Shane
>>