From makc.the.great at gmail.com Mon Dec 4 09:08:00 2006 From: makc.the.great at gmail.com (Makc The Great) Date: Mon, 4 Dec 2006 10:08:00 +0200 Subject: [address-policy-wg] Allocation vs assignment question Message-ID: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> Hello all, I have posted similar question at https://www.ripe.net/ripe/maillists/archives/db-help/2006/msg00040.html but I think that was not appropriate list, and I'm still not sure which is. My question is am I correct in assuming that all "assigned" IPs are on same physical network that all other IPs in their "sub-allocation" range? For example, here inetnum: 217.77.240.0 - 217.77.255.255 org: ORG-SW1-RIPE netname: DE-SAP-20001221 descr: SAP-AG Walldorf descr: ENTERPRISE country: DE status: ALLOCATED PA inetnum: 217.77.254.28 - 217.77.254.28 netname: SAP-JCrewGroupInc-US-i8 descr: J. Crew Group Inc. descr: US 770 Broadway, 14th Floor descr: Remote connection to SAP country: US status: ASSIGNED PA inetnum: 217.77.254.30 - 217.77.254.30 netname: SAP-AlumaFormDixieElectrical-US-i8 descr: Aluma-Form/Dixie Electrical descr: US 3625 Old Getwell Road descr: Remote connection to SAP country: US status: ASSIGNED PA are 217.77.254.28 and 217.77.254.30 still on german network, or are they physically located in US and connected to germany over some sort of intercontinental cable? Thanks, Max. From gert at space.net Mon Dec 4 09:38:51 2006 From: gert at space.net (Gert Doering) Date: Mon, 4 Dec 2006 09:38:51 +0100 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> Message-ID: <20061204083851.GK66903@Space.Net> Hi, On Mon, Dec 04, 2006 at 10:08:00AM +0200, Makc The Great wrote: > My question is am I correct in assuming that all "assigned" IPs are on > same physical network that all other IPs in their "sub-allocation" > range? Definitely not. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From makc.the.great at gmail.com Mon Dec 4 12:09:19 2006 From: makc.the.great at gmail.com (Makc The Great) Date: Mon, 4 Dec 2006 13:09:19 +0200 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <20061204083851.GK66903@Space.Net> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> Message-ID: <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> On 12/4/06, Gert Doering wrote: > Hi, > > On Mon, Dec 04, 2006 at 10:08:00AM +0200, Makc The Great wrote: > > My question is am I correct in assuming that all "assigned" IPs are on > > same physical network that all other IPs in their "sub-allocation" > > range? > > Definitely not. > So, if you have IP range A.B.C.* allocated to you, and assigns A.B.C.D to someone else, A.B.C.D may be plugged in any switch on the internet, not necessary yours? From gert at space.net Mon Dec 4 12:19:38 2006 From: gert at space.net (Gert Doering) Date: Mon, 4 Dec 2006 12:19:38 +0100 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> Message-ID: <20061204111938.GN66903@Space.Net> Hi, On Mon, Dec 04, 2006 at 01:09:19PM +0200, Makc The Great wrote: > >On Mon, Dec 04, 2006 at 10:08:00AM +0200, Makc The Great wrote: > >> My question is am I correct in assuming that all "assigned" IPs are on > >> same physical network that all other IPs in their "sub-allocation" > >> range? > > > >Definitely not. > > So, if you have IP range A.B.C.* allocated to you, and assigns A.B.C.D > to someone else, A.B.C.D may be plugged in any switch on the internet, > not necessary yours? That's not what I said (and is a different conclusion from the original question). First, the entry in the RIPE Database does not necessary correlate to a physical "subnet" in the sense of "all these IP addresses are in a single LAN". Most of the time, this is not going to be the case - like "a company getting assigned a network of a given size, and using subnets out of that network for different purposes, like branch offices". Second, of course you need to make sure *routing* for the address ("A.B.C.D") works - so if you plug it in "anywhere", it will not work. Still, A.B.C.D *could* be "anywhere" - depending on the specific layout of the network in question. They could use A.B.C.* for VPN connections, and route the individual addresses via IPSEC tunnels to "anywhere". Summary: you cannot draw any definite conclusion about physical or geographic setup from the RIPE (or any other) database. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From president at ukraine.su Mon Dec 4 14:16:31 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 04 Dec 2006 13:16:31 +0000 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> Message-ID: <45741FAF.1030104@ukraine.su> Hi, In general, yes. Really it can work in some cases.Even without ask for your permission ;) Makc The Great wrote: > On 12/4/06, Gert Doering wrote: >> Hi, >> >> On Mon, Dec 04, 2006 at 10:08:00AM +0200, Makc The Great wrote: >> > My question is am I correct in assuming that all "assigned" IPs are on >> > same physical network that all other IPs in their "sub-allocation" >> > range? >> >> Definitely not. >> > So, if you have IP range A.B.C.* allocated to you, and assigns A.B.C.D > to someone else, A.B.C.D may be plugged in any switch on the internet, > not necessary yours? > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From makc.the.great at gmail.com Mon Dec 4 16:29:33 2006 From: makc.the.great at gmail.com (Makc The Great) Date: Mon, 4 Dec 2006 17:29:33 +0200 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <457404A7.7050504@telia.net> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> <457404A7.7050504@telia.net> Message-ID: <7a2c69bf0612040729j2d0e69cv6faa4054f1a0456b@mail.gmail.com> So, overall consensus here is like this: On 12/4/06, Amar wrote: > > Ergo: There has not to be any connection between > subnets for each assignment. It is done > based on the proven need and not on a > physical connection between the requesters > networks. > Could you please explain then what does "Sub-allocations are intended to aid the goal of routing aggregation" phrase means in english? From amar at telia.net Mon Dec 4 16:56:55 2006 From: amar at telia.net (Amar) Date: Mon, 04 Dec 2006 16:56:55 +0100 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <7a2c69bf0612040729j2d0e69cv6faa4054f1a0456b@mail.gmail.com> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> <457404A7.7050504@telia.net> <7a2c69bf0612040729j2d0e69cv6faa4054f1a0456b@mail.gmail.com> Message-ID: <45744547.4020000@telia.net> Two things first: 1) If I send You a mail off list I see this as a private conversation between two parties. If I would like to make a public statement I would have sent a CC or replied to the list 2) I You decide to continiue the intended private conversation by sending my comments to the list without my consent then do not cut out pieces of the full text I wrote. But because You have already done it: Makc The Great wrote: > So, overall consensus here is like this: I wrote (un-cut by You): Let's say that You have 192.168.0.0/16 allocated to You. You have a global backbone with services all around the world. From that You assign Acme a /24 (eg 192.168.0.0/24) and route that thru Acmes connection in London. One month later Acme comes back an requests for another /24 but this time in New York. You assign Acme 192.168.1.0/24 and route that thru their connection in New York. Now Acme has two network with a /24 on each. They are not on the same subnet but the addresses are assigned to the same organisation. Ergo: There has not to be any connection between subnets for each assignment. It is done based on the proven need and not on a physical connection between the requesters networks. > Could you please explain then what does "Sub-allocations are intended > to aid the goal of routing aggregation" phrase means in english? Your question was made in such way that I belived that You thougt that all assigned addresses had to be on the same physical network. That was what my answer was about. -- amar From makc.the.great at gmail.com Mon Dec 4 18:53:50 2006 From: makc.the.great at gmail.com (Makc The Great) Date: Mon, 4 Dec 2006 19:53:50 +0200 Subject: [address-policy-wg] Allocation vs assignment question In-Reply-To: <45744547.4020000@telia.net> References: <7a2c69bf0612040008q5ae9efccv25725ba61177be9e@mail.gmail.com> <20061204083851.GK66903@Space.Net> <7a2c69bf0612040309t35f101bbsa258ff0affd3224c@mail.gmail.com> <457404A7.7050504@telia.net> <7a2c69bf0612040729j2d0e69cv6faa4054f1a0456b@mail.gmail.com> <45744547.4020000@telia.net> Message-ID: <7a2c69bf0612040953l57f910bbr40a6c83fc50993da@mail.gmail.com> On 12/4/06, Amar wrote: > Two things first: > > 1) If I send You a mail off list I see this as a private > conversation between two parties. If I would like to > make a public statement I would have sent a CC or > replied to the list > > 2) I You decide to continiue the intended private conversation > by sending my comments to the list without my consent then > do not cut out pieces of the full text I wrote. > > But because You have already done it: > > Makc The Great wrote: > > > So, overall consensus here is like this: > > I wrote (un-cut by You): > > Let's say that You have 192.168.0.0/16 allocated > to You. You have a global backbone with services > all around the world. > > From that You assign Acme a /24 (eg 192.168.0.0/24) > and route that thru Acmes connection in London. > > One month later Acme comes back an requests for > another /24 but this time in New York. > > You assign Acme 192.168.1.0/24 and route that > thru their connection in New York. > > Now Acme has two network with a /24 on each. They > are not on the same subnet but the addresses are > assigned to the same organisation. > > Ergo: There has not to be any connection between > subnets for each assignment. It is done > based on the proven need and not on a > physical connection between the requesters > networks. > > > Could you please explain then what does "Sub-allocations are intended > > to aid the goal of routing aggregation" phrase means in english? > > Your question was made in such way that I belived that > You thougt that all assigned addresses had to be on the > same physical network. That was what my answer was > about. > > -- amar > Hey Amar, I thought you have just forgot to include cc to this list, I am sorry, and I took only a part of your e-mail because I thought it sums up everything people wrote in reply to my original message. Perhaps I simply shouldn't put your name on it. Then yes I did believed "that all assigned addresses had to be on the same physical network". And that's why I am asking about "Sub-allocations are intended to aid the goal of routing aggregation" part, and "you" in my "could you please explain" refers to all people on the list. I am sorry for causing this confusion. From shane at time-travellers.org Tue Dec 12 12:07:27 2006 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 12 Dec 2006 12:07:27 +0100 Subject: [address-policy-wg] Map of the Internet Message-ID: <20061212110727.GA22029@borg.c-l-i.net> All, You've probably already seen it, but I thought it was cool enough to spam the list: http://xkcd.com/c195.html -- Shane From Michael.Dillon at btradianz.com Wed Dec 13 14:16:49 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 13 Dec 2006 13:16:49 +0000 Subject: [address-policy-wg] Map of the Internet In-Reply-To: <20061212110727.GA22029@borg.c-l-i.net> Message-ID: > You've probably already seen it, but I thought it was cool enough to > spam the list: > > http://xkcd.com/c195.html Somebody should tell the artist that no blocks were ever SOLD DIRECTLY TO CORPORATIONS AND GOVERNMENTS. Also, considering the number of pixels in that image, you could really drill down to much more detail if you would use color coding for regions, multicast, and pre-CIDR blocks. --Michael Dillon From filiz at ripe.net Wed Dec 13 16:50:03 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 13 Dec 2006 16:50:03 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) Message-ID: <20061213155003.732DC2F592@herring.ripe.net> PDP Number: 2006-07 First Raise in IPv4 Assignment Window Size Dear Colleagues The text of the policy proposal 2006-07 has changed. We have published the new version today, as a result the discussion period for this proposal will end on 17 January 2007. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From leo.vegoda at icann.org Wed Dec 13 17:16:09 2006 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 13 Dec 2006 08:16:09 -0800 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061213155003.732DC2F592@herring.ripe.net> References: <20061213155003.732DC2F592@herring.ripe.net> Message-ID: <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> On 13 Dec 2006, at 7:50am, Filiz Yilmaz wrote: [...] > The text of the policy proposal 2006-07 has changed. > > We have published the new version today, as a result the discussion > period for this proposal will end on 17 January 2007. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-07.html I have updated the proposal after reviewing the feedback received on the list and at the Address Policy WG session at RIPE 53. 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'd also like to repeat that the statistics show that 95% of requests for approval to make an assignment are approved straight away or a with a very brief exchange of mail. Some of that extra mail is unrelated to the request and is about billing issues, or just "Thank you" comments. http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2006/ msg00556.html I hope this modification addresses the concerns of the people worried about giving LIRs 'Too Much Too Young". Regards, -- Leo Vegoda IANA Numbers Liaison From s.steffann at computel.nl Thu Dec 14 01:23:50 2006 From: s.steffann at computel.nl (Sander Steffann) Date: Thu, 14 Dec 2006 01:23:50 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> Message-ID: <001501c71f16$216fb8e0$64c8a8c0@balefirehome> 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 From nick at inex.ie Thu Dec 14 11:33:13 2006 From: nick at inex.ie (Nick Hilliard) Date: Thu, 14 Dec 2006 10:33:13 +0000 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <001501c71f16$216fb8e0$64c8a8c0@balefirehome> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <001501c71f16$216fb8e0$64c8a8c0@balefirehome> Message-ID: <1166092393.91583.5.camel@pancake.netability.ie> > > 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. 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 -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From j.kammer at eurodata.de Thu Dec 14 13:13:09 2006 From: j.kammer at eurodata.de (Juergen Kammer) Date: Thu, 14 Dec 2006 13:13:09 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <1166092393.91583.5.camel@pancake.netability.ie> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <001501c71f16$216fb8e0$64c8a8c0@balefirehome> <1166092393.91583.5.camel@pancake.netability.ie> Message-ID: <20061214121309.GE14936@raasay.eurodata.de> 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 at eurodata.de D-66119 Saarbruecken S/MIME certs: http://pki.eurodata.de From leo.vegoda at icann.org Thu Dec 14 15:55:36 2006 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 14 Dec 2006 06:55:36 -0800 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <1166092393.91583.5.camel@pancake.netability.ie> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <001501c71f16$216fb8e0$64c8a8c0@balefirehome> <1166092393.91583.5.camel@pancake.netability.ie> Message-ID: 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. Regards, -- Leo Vegoda IANA Numbers Liaison From andy at nosignal.org Thu Dec 14 17:44:54 2006 From: andy at nosignal.org (Andy Davidson) Date: Thu, 14 Dec 2006 16:44:54 +0000 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> Message-ID: <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> 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 From slz at baycix.de Thu Dec 14 18:23:21 2006 From: slz at baycix.de (Sascha Lenz) Date: Thu, 14 Dec 2006 18:23:21 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> Message-ID: <45818889.5020803@baycix.de> 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 at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From andy at nosignal.org Fri Dec 15 00:09:12 2006 From: andy at nosignal.org (Andy Davidson) Date: Thu, 14 Dec 2006 23:09:12 +0000 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <45818889.5020803@baycix.de> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> <45818889.5020803@baycix.de> Message-ID: <19F5D56D-9476-4349-BD34-44BC5A20DD8C@nosignal.org> Hi, On 14 Dec 2006, at 17:23, Sascha Lenz wrote: > 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 :-) Just an incentive to encourage people to at least learn how to assign 'properly'. From packetgrrl at gmail.com Fri Dec 15 01:50:04 2006 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 14 Dec 2006 17:50:04 -0700 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <19F5D56D-9476-4349-BD34-44BC5A20DD8C@nosignal.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> <45818889.5020803@baycix.de> <19F5D56D-9476-4349-BD34-44BC5A20DD8C@nosignal.org> Message-ID: On 12/14/06, Andy Davidson 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From EricS at t-com.net Fri Dec 15 10:04:39 2006 From: EricS at t-com.net (Erics) Date: Fri, 15 Dec 2006 10:04:39 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) Message-ID: <6E6739BC95294242979BDAA042E4871B01995DFF@S4DE9JSAAHY.nord.t-com.de> Hi, incentive and AW is a very bad combination. The AW should reflex the LIRs address requirement, and it must not be an incentive ! Hi Ingrid ;-) All in all I support the proposal to raise the AW automatically from 0 to /21 within six month. kind regards Eric Schmidt Deutsche Telekom AG T-Com Headquarters Network Information Center -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at gippnet.com Fri Dec 15 10:45:12 2006 From: dennis at gippnet.com (=?ISO-8859-1?Q?Dennis_Lundstr=F6m?=) Date: Fri, 15 Dec 2006 10:45:12 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <45818889.5020803@baycix.de> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> <45818889.5020803@baycix.de> Message-ID: <3891BF3E-D63A-4C33-8980-89D001317715@gippnet.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I totally agree there. We need to keep it simple. From my own experience, I say most of us do other things daily that just work with assigning ip-addresses. A complex and byrocratic policy could have the opposite effect, at least from a management point of view. While auditing performance per employee, this might stir up bad blood If we are spending more time adapting to policy than doing the actual work :-) For those worried about AW size, my suggestion is to take an active roll. If you have new staff, that is not experienced enough. Contacting RIPE-NCC, and asking for a lower AW is always a good option. Best regards. - --Dennis Lundstr?m GippNET AB On Dec 14, 2006, at 18:23 , Sascha Lenz wrote: > 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 at baycix.de = > = Network > Operations = > = BayCIX GmbH, Landshut * PGP public Key on demand > * = > ====================================================================== > == > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFFgm6rsqJZaeZjsn8RAly2AJ9ea6QoI7791iMXh1b/DsNAT/TNigCeNB4v 9HevRALQyvJwC6K0WK+lmUs= =oH4B -----END PGP SIGNATURE----- From dennis at gippnet.com Fri Dec 15 10:29:06 2006 From: dennis at gippnet.com (=?ISO-8859-1?Q?Dennis_Lundstr=F6m?=) Date: Fri, 15 Dec 2006 10:29:06 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> Message-ID: -----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----- From tiberiu.ungureanu at ines.ro Fri Dec 15 23:07:10 2006 From: tiberiu.ungureanu at ines.ro (Tiberiu Ungureanu) Date: Fri, 15 Dec 2006 16:07:10 -0600 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <21F273E3-D754-4093-A2A6-3680852952DD@nosignal.org> Message-ID: <1166220430.3994.62.camel@t-desk.ky.opentransfer.com> On Thu, 2006-12-14 at 16:44 +0000, 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 ? Look. There is e-learning in LIR portal. People can learn without going to RIPE trainings. We should keep the policy as simple as possible. I personally go to trainings because a) I have a question to ask, and i'd rather ask it to a person than to an email address b) I work better if i know the face i'm emailing to. c) (be honest) it's a good way to avoid work and get free coffee (and food) for that. If there's a Training course close to the CO of the new org, techs will be there. You don't need to force them to come. Just advertise free coffee, no need to work. d) All the training courses I attended ended with ISP-TECHS-DRINKING-CABAL, and of course this ended with good new peering agreements. It is true there are new things that you can learn at LIR-TRAININGs but there aren't many that aren't already explained in e-learning. Plus... New orgs don't get much space to start with. I *think* they currently get an initial assignment of /21. If they make bad assignments, they will get their asses kicked next time when they request IP space. And if they never request new ip space... there's no way to keep them assign the space they got with or without the AW of /21. On the other hand, I also support the "Per-Contact-Person-AW" proposal. From andre.koopal at nld.mci.com Fri Dec 15 14:10:01 2006 From: andre.koopal at nld.mci.com (Andre Koopal) Date: Fri, 15 Dec 2006 14:10:01 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <001501c71f16$216fb8e0$64c8a8c0@balefirehome> <1166092393.91583.5.camel@pancake.netability.ie> Message-ID: <20061215131001.GQ968@asoserve0.ams.ops.eu.uu.net> 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. From gert at space.net Tue Dec 19 12:02:37 2006 From: gert at space.net (Gert Doering) Date: Tue, 19 Dec 2006 12:02:37 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> Message-ID: <20061219110237.GN66903@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From leo.vegoda at icann.org Tue Dec 19 12:12:07 2006 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 19 Dec 2006 12:12:07 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061219110237.GN66903@Space.Net> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> Message-ID: <650F6A0F-4B65-47FA-B2B7-68A7517D1CDB@icann.org> Hi Gert, On Dec 19, 2006, at 12:02 PM, Gert Doering 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. > - 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? 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." Regards, -- Leo Vegoda IANA Numbers Liaison From gert at space.net Tue Dec 19 12:32:10 2006 From: gert at space.net (Gert Doering) Date: Tue, 19 Dec 2006 12:32:10 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <650F6A0F-4B65-47FA-B2B7-68A7517D1CDB@icann.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <650F6A0F-4B65-47FA-B2B7-68A7517D1CDB@icann.org> Message-ID: <20061219113210.GS66903@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From dmitry at volia.net Tue Dec 19 12:18:27 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Tue, 19 Dec 2006 13:18:27 +0200 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061219110237.GN66903@Space.Net> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> Message-ID: <20061219111827.GB1101@f17.dmitry.net> Hello! On Tue, Dec 19, 2006 at 12:02:37PM +0100, Gert Doering 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? Some minor questions: why /21? It is just current minimum allocation size? If yes, what about changes which possible in future? -- Dmitry Kiselev From leo.vegoda at icann.org Tue Dec 19 13:19:27 2006 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 19 Dec 2006 13:19:27 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061219111827.GB1101@f17.dmitry.net> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <20061219111827.GB1101@f17.dmitry.net> Message-ID: <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> 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 From dmitry at volia.net Tue Dec 19 13:44:21 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Tue, 19 Dec 2006 14:44:21 +0200 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <20061219111827.GB1101@f17.dmitry.net> <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> Message-ID: <20061219124421.GC1101@f17.dmitry.net> Hello, Leo! On Tue, Dec 19, 2006 at 01:19:27PM +0100, Leo Vegoda 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. 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. -- Dmitry Kiselev From alexlh at ripe.net Wed Dec 20 16:40:39 2006 From: alexlh at ripe.net (Alex le Heux) Date: Wed, 20 Dec 2006 16:40:39 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061219124421.GC1101@f17.dmitry.net> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <20061219111827.GB1101@f17.dmitry.net> <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> <20061219124421.GC1101@f17.dmitry.net> Message-ID: <20061220154039.GK3665@ripe.net> 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 From leo.vegoda at icann.org Wed Dec 20 20:11:40 2006 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Dec 2006 20:11:40 +0100 Subject: [address-policy-wg] 2006-07 Discussion Period extended until 17 January 2007 (First Raise in IPv4 Assignment Window Size) In-Reply-To: <20061219124421.GC1101@f17.dmitry.net> References: <20061213155003.732DC2F592@herring.ripe.net> <45B2A769-E32D-4382-A622-0416DBCDD9EF@icann.org> <20061219110237.GN66903@Space.Net> <20061219111827.GB1101@f17.dmitry.net> <5BCCA4C3-12F2-4462-B67E-CA51BA2E07E5@icann.org> <20061219124421.GC1101@f17.dmitry.net> Message-ID: <995C8425-6E0F-411D-BFE9-CC0D756338B7@icann.org> Hi Dmitry, On Dec 19, 2006, at 1:44 PM, Dmitry Kiselev 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. Thanks, -- Leo Vegoda IANA Numbers Liaison From ncc at ripe.net Thu Dec 28 11:43:37 2006 From: ncc at ripe.net (Dominic Spratley - Registration Services Manager) Date: Thu, 28 Dec 2006 11:43:37 +0100 Subject: [address-policy-wg] 32-bit AS Number Requests Message-ID: <45939FD9.4080406@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce that from 1 January 2007 we will accept requests for 4-byte (32-bit) AS Numbers. The request form and supporting notes are available in the RIPE Document Store at: http://www.ripe.net/ripe/docs/asnrequestform.html http://www.ripe.net/ripe/docs/asnsupport.html Assignments will come from the following range: 3.0 - 3.1023 ASN32 objects will appear in the RIPE Database from 1 January 2007. Their format is different from the current 16-bit ASNs. The new format is described in these documents: http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-02.txt http://www.ietf.org/internet-drafts/draft-uijterwaal-rpsl-4byteas-ext-01.txt The introduction of 32-bit AS Numbers may have an effect on tools that query the RIPE Database or those based on RPSL. Kind Regards, Dominic Spratley Registration Services Manager RIPE NCC From ncc at ripe.net Thu Dec 28 11:43:37 2006 From: ncc at ripe.net (Dominic Spratley - Registration Services Manager) Date: Thu, 28 Dec 2006 11:43:37 +0100 Subject: [address-policy-wg] [ncc-announce] 32-bit AS Number Requests Message-ID: <45939FD9.4080406@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce that from 1 January 2007 we will accept requests for 4-byte (32-bit) AS Numbers. The request form and supporting notes are available in the RIPE Document Store at: http://www.ripe.net/ripe/docs/asnrequestform.html http://www.ripe.net/ripe/docs/asnsupport.html Assignments will come from the following range: 3.0 - 3.1023 ASN32 objects will appear in the RIPE Database from 1 January 2007. Their format is different from the current 16-bit ASNs. The new format is described in these documents: http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-02.txt http://www.ietf.org/internet-drafts/draft-uijterwaal-rpsl-4byteas-ext-01.txt The introduction of 32-bit AS Numbers may have an effect on tools that query the RIPE Database or those based on RPSL. Kind Regards, Dominic Spratley Registration Services Manager RIPE NCC