Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)

[Sascha Lenz slz@localhost]

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@localhost         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================