Hi, Leo Vegoda wrote:
On 22 May 2007, at 8:50pm, Sascha Lenz wrote:
[...]
Simple IPv6 PI Assignment policy:
[...]
- A recurring fee of 100EUR/y is charged from the RIPE NCC directely or via the handling LIR
As you noted elsewhere, fee schedule decisions belong to the membership.
yes, i did. This is over-simplified to state my point WHAT a policy needs to look like *in the end*. Some people stressed their point that a vague pointing towards a not-yes-existing contractual relationship isn't going to fly for them as long as they don't know what might be in it, and you obviously don't like vague statements either. So i explicitely say what the outcome should look like - around how many corners that needs to be filed into policies, contracts, memberships etc.... someone from the NCC needs to help me/us with since we are technicians who don't have 100% clue about that. But this is a cruical part of the overall PI policy IMHO.
[...]
- The assignment is at least a /48 from a dedicated supernet-block which clearly identifies it as Provider Independent Prefix - A shorter prefix may be assigned if the end-site provides a network plan and possible contracts with suppliers that hint that a /48 prefix might not contain enough subnets for the planned lifetime of the assignment.
Hint? If prefixes shorter than /48 should not be the default assignment then I think we need more than a "slight or indirect indication or suggestion" that more than a /48 is required. If I just need to hint that I might possibly need more than a /48 over the next 15 years to receive a /44, /40 or /32 then the policy is utterly broken.
Facts: - The PA policy (http://www.ripe.net/ripe/docs/ipv6policy.html#assignment_size) doesn't really say anything specific either, and AFAIK there hasn't been a single End-User Request for </48 yet(?). If the RIPE NCC thinks it can provide input on what they need here or experience like how they deal with </32 PA requests for very large sites, i'm happy to hear them out. Should be similar to what </48 end-user requests should look like. I don't want to make a difference between PI and PA assignment requirements here in the end, that's my plan at least. - It's vague, but it's always stressed that the RIPE NCC hostmasters usually know what they do and have the experience to tell if someone provided the correct amount of information for a given request. Why should that be different for IPv6 PI now? Isn't some kind of contract or bills for equipment like i suggest here enough? That's what i'm usually asked to provide to the NCC if i request some biiiiiiiiiig IPv4 assignment/allocation at least. PROBABLY the PI and PA policy needs something like "utilisation within a 2year term" statement or so similar to the IPv4 assignment policy; that is correct. But i intentionally left that out here since it's not in the PA policy either. (RFC3177 doesn't say anything about a specific timeframe either AFAICR).
If you want a free-for-all then propose a policy that clearly and unambiguously states that there is a free for all. If you want restrictions then propose a policy that clearly and unambiguously states what the qualifying criteria are.
You cannot predict all possible (valid) reasons for a bigger assignment. If you look at a network plan and you see that 16bit subnets is not enough.. fine. IF not, ask them to come back for a subsequent assignment (mind the /44 reservation suggestion) if they really run out of subnets and can show that by means of contracts or equipment bills (similar to IPv4 as mentioned above). (And btw, i think this will rarely happen since i'm not aware of any request </48 for an end-user) It's pretty clear to me, but again, only RIPE NCC Hostmasters might shed light on the real world issues with unusual big requests (IPv4, IPv6 PA) and what they do about it TODAY. I actually want to prevent big assignments to be granted just because some bad network design. But how the hell should we predict what's bad and what not here in writing? Happy to hear suggestions how to prevent this. I personally think that this can only be solved with clue++; at the RIPE NCC Hostmaster level in the end, not by a rigid policy.
Vague language makes things more difficult for requesters because they don't know if they qualify or not and so may be dissuaded from requesting something they need. It also makes things very awkward for the RIPE NCC staff. Without a clear set of criteria they aren't in a position to justify refusing an (apparently) unreasonable request. This is likely to lead to refusing all requests or approving all requests - but probably the latter.
I still trust the RIPE NCC Hostmasters to be reasonable and clueful, but if you think we should start micro-managing via the policies... since it's you, i actually wouldn't object since you have some experience there ;-) But we need some realworld examples from the NCC here to find out what should go into the polic[y|ies] and what not. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================