This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] RE: Complaint: Overly complicated when requesting PI space
- Previous message (by thread): [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space
- Next message (by thread): [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Remco van Mook
remco.vanmook at eu.equinix.com
Fri Jul 17 13:54:20 CEST 2009
Hi Mark, It is heartening to see that your drive to conservation of IPv4 space alone is pushing you to put all this effort in to get PI space. I¹m sure we can suggest a policy change approved that would set the standard initial allocation to /21 but allow for smaller allocations up to /24 if specifically requested by the new LIR. Best, Remco On 17-07-09 13:48, "Stream Service || Mark Scholten" <mark at streamservice.nl> wrote: > Hello Sander, > > Thank you for the clear reply. If I combine this with other things on the > mailing list in the last 3 weeks I agree with you that it is better to > request a /21 range (you get it when you become a LIR) compared to a /24 > (PI) if you just need a /24. This is clearly the best way to conserve IPv4 > address space. > > With kind regards, > > Mark Scholten > > -----Original Message----- > From: Sander Steffann [mailto:sander at steffann.nl] > Sent: donderdag 16 juli 2009 22:01 > To: Stream Service || Mark Scholten > Cc: address-policy-wg at ripe.net > Subject: Re: Complaint: Overly complicated when requesting PI space > > Hello Mark, > >> > If you ask me it should be allowed to use PI space for clients (and >> > give >> > clients the option to use/maintain more than a /30 (IPv4)). > > PI policy explicitly states that PI space can not be re-assigned or > further assigned to other parties. See > http://www.ripe.net/ripe/docs/ripe-471.html#9 > . Any organisation that needs address space for its customers must use > PA space. The definition of an LIR is that it assigns address space to > its customers. PI space is (per definition) only to be used by the > company that requested it itself. > >> > It is also in my >> > opinion not to RIPE (community or the NCC) to ask that information. >> > The >> > should ask for general usage, how much would be used for clients for >> > example. How many clients a company has shouldn't be important to >> > get PI. > > In this case it doesn't matter. That the company needs address space > for *any* customers indicates that PI space is not appropriate and PA > space should be used. The company uses address space for customers and > therefore must become an LIR. > > I think it is now time to stop this discussion, at least on the > address policy mailing list. This discussion is not leading to a > viable policy proposal. > > Thanks, > Sander Steffann > APWG co-chair > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20090717/6b0b5bbf/attachment.html>
- Previous message (by thread): [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space
- Next message (by thread): [address-policy-wg] RE: Complaint: Overly complicated when requesting PI space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]