Hi Leo,

Several people raised concerns that new LIRs may not have sufficient experience to make good decisions with a /21 AW. This is a valid concern but I do not believe a series of incremental AW raises would provide the most effective support to new LIRs. Instead, I have modified the proposal so that new LIRs would get a /21 AW six months after receiving their first allocation. They would need to send in requests as now until then. This should ensure that the LIRs most in need of support receive it, while reducing the administrative overhead for the vast majority of LIRs.

Sounds like a very good solution/proposal to me. Thanks! Sander

On Thu, Dec 14, 2006 at 10:33:13AM +0000, Nick Hilliard wrote:

[..] Could I suggest an alternative based on experience in dealing with new LIRs on the ground? Many new LIRs are smaller operations with relatively small address space usage, and simply wouldn't get to send in a huge number of assignment requests within the first 6 months. Because of this, they're just not going to get the hang of RIPE's address space administrative requirements. Would it not therefore be more sensible to automatically increase the AW after either a set number of well-formed assignment requests were sent into RIPE?

Nick

Having sent in a set number of well-formed assignment requests sounds a lot more logical as condition for getting the AW raised than "having been an lir for 6 months" does. This ensures that small LIRs really get enough contact and - on the other hand - that big lirs will get their AW increased after only a short time. And all new LIRs have the same contact experiences with RIPE NCC when they get their AW raised - which is what we are aiming for, I'd guess. Juergen. -- Juergen Kammer {Net,Dns,Host}master eurodata eurodata GmbH & Co. KG Tel. +49 681 8808761 Fax: +49 681 8808780 Grossblittersdorfer Str. 257-259 Email: j.kammer@eurodata.de D-66119 Saarbruecken S/MIME certs: http://pki.eurodata.de

On Thu, Dec 14, 2006 at 06:55:36AM -0800, Leo Vegoda wrote:

On Dec 14, 2006, at 2:33 AM, Nick Hilliard wrote:

[...]

...

Could I suggest an alternative based on experience in dealing with new LIRs on the ground? Many new LIRs are smaller operations with relatively small address space usage, and simply wouldn't get to send in a huge number of assignment requests within the first 6 months.

This I agree with.

...

Because of this, they're just not going to get the hang of RIPE's address space administrative requirements.

This I don't.

The RIPE NCC has found that less than 5% of requests need anything more than a comment from them because the person making the request met all of the administrative and policy requirements. LIRs seem to gain this experience pretty fast and they can't make truly large mistakes because the slow start policy restricts the size of LIRs' first few allocations. New LIRs don't really have very much space to waste, so there is relatively little risk.

...

Would it not therefore be more sensible to automatically increase the AW after either a set number of well-formed assignment requests were sent into RIPE?

That's basically what happens now: evidence based AW raises. It makes AW growth a slow process that involves LIRs sending in huge numbers of request forms that don't really need any input from the RIPE NCC staff.

Looking at slide 10 of Filiz's recent presentation at the Region Meeting in Manama, Bahrain, we can see that PA Requests account for about 60% of the requests handled:

http://www.ripe.net/meetings/regional/manama-2006/presentations/ stats_policyupdate.pdf

- or -

http://tinyurl.com/yjushp

Relaxing this policy lowers the administrative burden for the vast majority of LIRs while the RIPE NCC retains the ability to select the size of an LIR's allocation, so limiting the damage they can do. The RIPE NCC also has an explicit mandate to audit LIRs (ripe-170), and were this proposal accepted, they would be able to expand this role, providing additional, targeted support for those few LIRs that need it.

Hi Leo,all, If the hostmasters are spending to much time on doing simple requests then they might not just show initiative enough to raise the assignment window when a LIR behaves 'good'. Having said that, I can still support that the first step in the AW is from 0 to a /21 in one go. I however do have problems with doing it automaticly after half a year. I still think it is good that a LIR is helped (not controlled, helped) by having the first requests go through the hostmaster team. Now if you take that into account, a big ISP that for example opens a new LIR for a new country will be annoyed the first half year, while for a startup company that is really still starting up and not doing requests yet, half a year might be to short. So I really think that raising the AW to the /21 should be hostmaster initiated. If they don't do it quickly enough, that is an internal problem that should be handled with for example training. A suggestion might be to do an audit every 3 months on all LIR's that still have an AW of 0. Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - Int ITSD Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands VNET: 711 6990 tel : +31 (0)20 711 6990 fax : +31 (0)20 711 2519 Verizon and MCI are now operating as Verizon Business ! This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated.

Hay, Andy Davidson schrieb:

On 13 Dec 2006, at 16:16, Leo Vegoda wrote:

...

Several people raised concerns that new LIRs may not have sufficient experience to make good decisions with a /21 AW.

To appease those worriers, the policy could say that the AW growth from 0 to /21 is only permitted if the LIR has at least one admin-c who has been to RIPE LIR training ?

hm, i don't really see why making the policy more complex is helping. My point from my former post(s) keep standing... just pass the proposal so we can focus on the other more important ones :-) As long as we don't start with per-LIR-contact AWs instead of per-LIR AWs, i rather prefer it simple than complicated. Because it doesn't make that much sense at all to have an AW per LIR if there are many different LIR contacts processing the requests anyways. Some LIRs might do internal trainings or send their staff to LIR trainings, but not all. ==> I still support the request, actually rather the original draft than the updated one, but i'm fine with a 6month slow-start mechanism. Just don't think it makes much sense but might prevent at least some mistakes by new LIRs, yes. Mistakes by new LIR staff in any other LIR with a high AW are still not accounted for though. But do we want RIPE to look at a LIRs work that much? I guess not. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================

On 12/14/06, Andy Davidson <andy@nosignal.org> wrote: Just an incentive to encourage people to at least learn how to assign 'properly'. Why can't the incentive be that the LIR won't be able to get more address space? That seems to work well in other regions. ---Cathy

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sounds reasonable. Although It's possible to adapt to the rules and regulations without attending the course. It's a damn good idea to be there. If not for the sake, of meeting representatives from other ISP:s, and sharing ideas. And offcourse getting answers for our everyday woes and worries directly from the RIPE-NCC. I strongly recommend everyone who has not yet attended to give it a good thought. Best regards. - --Dennis Lundström GippNET AB On Dec 14, 2006, at 17:44 , Andy Davidson wrote:

On 13 Dec 2006, at 16:16, Leo Vegoda wrote:

...

Several people raised concerns that new LIRs may not have sufficient experience to make good decisions with a /21 AW.

To appease those worriers, the policy could say that the AW growth from 0 to /21 is only permitted if the LIR has at least one admin-c who has been to RIPE LIR training ?

Cheers Andy

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFFgmrmsqJZaeZjsn8RAiUoAKCNs5Bt+XXXfRQ0z5y8ehGC0AVzdQCglkNt kZXrSr3ipHvAcen5Ab8N8zo= =5KEv -----END PGP SIGNATURE-----

Hi, On Wed, Dec 13, 2006 at 08:16:09AM -0800, Leo Vegoda wrote:

Several people raised concerns that new LIRs may not have sufficient experience to make good decisions with a /21 AW. This is a valid concern but I do not believe a series of incremental AW raises would provide the most effective support to new LIRs. Instead, I have modified the proposal so that new LIRs would get a /21 AW six months after receiving their first allocation. They would need to send in requests as now until then. This should ensure that the LIRs most in need of support receive it, while reducing the administrative overhead for the vast majority of LIRs.

I like this more than the previous one, but still some questions remain: - what about the AW for existing LIRs? Will it be auto-raised to /21 as well? - what about the AW size *after* the initial raise? Can it be reduced to less than a /21 - and if yes, under which conditions, and at what time will it grow back? Sounds like nitpicking, but if I have learnt one thing in the last years, it is "make the policy clear!" :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Tue, Dec 19, 2006 at 12:12:07PM +0100, Leo Vegoda wrote:

...

I like this more than the previous one, but still some questions remain:

- what about the AW for existing LIRs? Will it be auto-raised to /21 as well?

I think this would be part of the implementation. If the LIR had an IPv4 allocation for at least six months and their AW was under /21 then their AW would be raised to /21 - unless it has been reduced by the RIPE NCC because of misuse.

Thanks for clarification. (Yay! A /21 for me, after having worked towards a /23 for years, and never needed anything beyond that anyway). [..]

Ah, perhaps I should have made it more clear in the updated text. This proposal does not change the current policy text, which states:

"The AW may also be lowered after or during an audit if invalid assignments are noted."

Thanks for clarification. So the proposal really is only about a one-off increase after 6 months (or the equivalent for existing LIRs), and it will not affect the normal AW handling anywhere else. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi Dmitry, On Dec 19, 2006, at 12:18 PM, Dmitry Kiselev wrote: [...]

Some minor questions: why /21? It is just current minimum allocation size? If yes, what about changes which possible in future?

Good question. I looked at the policy in other regions[0] and saw that there was quite a spread. For instance, APNIC's current policy[1] is very similar policy to RIPE's. In contrast, ARIN's current policy[2] requires small to large ISPs to seek ARIN's approval before making reassignments of a /19. That goes up to /18 for extra-large ISPs. ISPs in North America seem to cope fairly well with more freedom than is currently available in the RIPE region. However, 0 to /19 is a big leap. I thought that /21 was a good balance between providing LIRs with more freedom while limiting the amount of damage to a relatively small size. If the proposal is accepted and doesn't cause any significant harm then increasing the first AW from /21 to a shorter prefix may be appropriate in the future. Regards, -- Leo Vegoda IANA Numbers Liaison [0] http://www.nro.net/documents/nro41.html#2-5-1 [1] http://www.apnic.net/docs/policy/add-manage-policy.html#10.1 [2] http://www.arin.net/policy/nrpm.html#four235

Dear Colleagues,

Hm... Is there statistics which shows subnet size requested per user for last year? Something like (actual numbers is just an example!):

Size Requests in 2006

4-32 addresses 5,000 10% 33-64 addresses 8,000 12% ... 256-511 addresses 50,000 44% ... 2048-4095 addresses 1,300 6% 4096-8191 addresses 750 3% ...

In my opinion AW can be auto-rised to almost match most "popular" assignments sizes. All further risings(lowers) can be done upon LIR request. If stats does not show clear peak - AW size can be aligned to nearest bigest value.

We have prepared statistics showing the size of all approvals that the RIPE NCC has made in 2006: Size Number of approvals 1 - 1 [/32]: 3 0.1% 2 - 2 [/31]: 3 0.1% 3 - 4 [/30]: 60 1.0% 5 - 8 [/29]: 359 6.2% 9 - 16 [/28]: 308 5.3% 17 - 32 [/27]: 220 3.8% 33 - 64 [/26]: 217 3.7% 65 - 128 [/25]: 274 4.7% 129 - 256 [/24]: 1394 23.9% 257 - 512 [/23]: 789 13.6% 513 - 1024 [/22]: 705 12.1% 1025 - 2048 [/21]: 596 10.2% 2049 - 4096 [/20]: 371 6.4% 4097 - 8192 [/19]: 191 3.3% 8193 - 16384 [/18]: 125 2.1% 16385 - 32768 [/17]: 63 1.1% 32769 - 65536 [/16]: 62 1.1% 65537 - 131072 [/15]: 37 0.6% 131073 - 262144 [/14]: 19 0.3% 262145 - 524288 [/13]: 16 0.3% 524289 - 1048576 [/12]: 5 0.1% 1048577 - 2097152 [/11]: 4 0.1% Total number of PA approvals: 5821 Total number of /21 and smaller: 4928 84.6% We hope these statistics are useful, please let us know if you need more information. Best regards, Alex Le Heux RIPE NCC IP Resource Analyst

On Dec 20, 2006, at 8:11 PM, Leo Vegoda wrote: [...]

...

In my opinion AW can be auto-rised to almost match most "popular" assignments sizes. All further risings(lowers) can be done upon LIR request. If stats does not show clear peak - AW size can be aligned to nearest bigest value.

I am not sure I understand what you are proposing. Are you suggesting that all assignment approvals should trigger an AW raise? That is, if my LIR has an AW of /23 and I receive approval to make a /22 assignment I should automatically have my AW set at /22.

I've not seen a response, but I'd like to outline why I think that a rapid series of raises is a bad idea. My concern is that AW raises should not be seen as a reward but as an extra responsibility. A rapid series of raises is likely to appear like an evidence based reward. However, a time-based change from 0 to /21 is clearly not an evidence based change and is much more likely to be viewed as a new responsibility. Emphasizing the LIR's ongoing responsibilities rather than their previous wise decisions is likely to lead to better results for everyone, I think. Regards, -- Leo Vegoda IANA Numbers Liaison