Hi Max, as defined in RIPE-482, "a charge of EUR 50 for each independent Internet number resource". Each inetnum is a independent resource, even if your End User will receive /20+/22+/23+/24. If you wish to change this in 2011 Charging Scheme, you have to do it more clearly. I support your proposal. Monday, July 19, 2010, 6:13:35 PM, you wrote: MT> Recently RIPE NCC has assigned a PI network for my client. It is 1536 MT> IPs (/22+/23), and it was assigned as two completely different inetnums MT> (with one same netname). MT> I have asked how it will be billed, and got an answer - as two separate MT> objects. I understand, in future it will be harder and harder to get a MT> non-splitted networks, and splitted networks will be more frequent. MT> But how I can predict it in my agreements with customers? I don't know MT> how much pieces will be splitted the next network to. MT> When I said it will be twice more expensive than expected, customer was MT> unhappy and said there is an agreement already signed, with the exact MT> price in it. MT> I think, one request shold be billed as one object, isn't it? -- Sergey

* Max Tulyev wrote:

Recently RIPE NCC has assigned a PI network for my client. It is 1536 IPs (/22+/23), and it was assigned as two completely different inetnums (with one same netname).

inetnums does not need to follow CIDR. So ask RIPE NCC to merge both inetnum objects to a single (continuous) one.

Hi,

Recently RIPE NCC has assigned a PI network for my client. It is 1536 IPs (/22+/23), and it was assigned as two completely different inetnums (with one same netname).

I have asked how it will be billed, and got an answer - as two separate objects. I understand, in future it will be harder and harder to get a non-splitted networks, and splitted networks will be more frequent.

But how I can predict it in my agreements with customers? I don't know how much pieces will be splitted the next network to.

When I said it will be twice more expensive than expected, customer was unhappy and said there is an agreement already signed, with the exact price in it.

I think, one request shold be billed as one object, isn't it?

maybe, but as you basically said yourself - there won't be any more IPv4 to assign soon anyways, that's just the first signs now that you won't get continous blocks in some cases. Solution (and yes i do mean that): Just start to assign IPv6 PI or PA blocks to your customers. No problem there. P.S.: Of course it's a bad thing if you don't know what to pay upfront. I understand your problem here, i wouldn't have thought about that either actually. But now where we know the issue, you can just tell that to your next customer BEFORE he signs the contract that IPv6 is one block at a fixed price and IPv4 price may vary depending on availibility :-) P.P.S.: Or probably our friendly NCC staff can come up with a temporary workaround about this we can all agree upon quickly? I don't think it's worth the time to start a new PDP to once again change the policy over the wording, IPv4 is over before the PDP gets anywhere. But i'm not even sure this was unintended :-) From my point of view it somehow gives another reason to use IPv6, so it's somewhat a good thing. -- ===================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = =====================================================================