On 19/09/2014 10:31, Martin Pels wrote:
You are correct in that having received a small IPv6 PA assigment from another LIR may not be enough for deploying IPv6 to end-customers. But I could argue that having this PA assignment actually deployed in your network is more meaningful than having requested your own PA allocation without doing anything with it (which would satisfy the policy as it is now).
From a syntax point of view, the wording is contradictory. The summary states that there is a requirement for an "inet6num object registered in
There is nothing in the proposal about deployment of either PI or PA space, so it's not clear why you're making this argument. The proposal as it stands is window dressing because it requires only tickbox-style compliance. This is completely pointless. Organisations will either deploy ipv6 or they won't, and this decision will be made on business merit rather than because a RIPE NCC IPRA delayed a /22 allocation because of a policy violation. the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC". The policy itself does not state this; just that the /22 allocation can be made if the LIR has "already received a valid globally routeable unicast IPv6 address block". These two things are not the same. If you intend something to be in the policy, then put it into the policy. The policy is what ends up in RIPE-* documents; the summary is not a part of this.
From an implementation point of view, it may be worth asking the RIPE NCC if they intend to demand that the assignee of the inet6num is an exact text match of the legal name of the LIR. Most organisations are pretty sloppy about this, and this is a likely source of future confusion because getting PA or other RIR assignment/allocation details changed in order to qualify for the /22 could turn out to be surprisingly troublesome.
FWIW, the RIPE NCC has done the community a favour by implicitly pointing this out: "Delay and extra workload is only expected if the provided IPv6 range is not clearly registered to the requesting RIPE NCC member." In other words, be careful what you ask for because you might get it. Also, the RIPE NCC has clarified that IPv6 assignments to different companies within the same company group do not qualify for this proposal.
From what I understand, this was one of the original complaints about the existing policy, and it will not be fixed with this proposal.
overall: - I don't support this policy because window dressing is not a good basis for making ip addressing policy. - even if I did support it, a) the policy doesn't say what you think it says and b) it doesn't handle some of the problems of the current policy. I would kindly suggest either dropping the ipv6 requirement completely from the last /8 policy, or if you feel strongly that it should stay, rewording this proposal to make it say what you intend. Nick