Hi again Filiz,
So the proposal is to remove some heavy "bureaucracy" (because if it was not heavy, we would not need a change, right?) which at the same time is (according to the 2nd paragraph) as easy as basically "keeping a straight face while justifying the assignment of 1 single IP"?
You are comparing apples to oranges here (allocations to assignments). The "easy" part is to document "need" enough to get an *allocation* from the NCC. "Need" for allocations comes from one thing only: Intent to make assignments. If you can document an intent to make a valid assignment for one (1) IPv4 address, you have a valid need for an allocation. Following the implementation of the last /8 policy, there is only one size allocation the NCC can delegate to its members (/22). Thus, by submitting a ripe-583 form documenting an intended assignment of 1 IPv4 address (or a /32 if you prefer), you have also automatically qualified for your initial and final /22 allocation. Anyone can do that, it is not heavy bureaucracy at all. The "heavy bureaucracy" part comes when an LIR is about to make a real assignment to an End User. The NCC isn't involved at all in this process (unless the assignment is larger than the AW). For example, say you have a meeting with a new customer who spends a few hours explaining how their network looks like, is subnetted, and how it all works and so on and so on, and you both agree that a /21 looks like a good fit for them. The bureaucracy kicks into play when you finish the meeting by telling them "now you have to just repeat everything you've just told me, translate it into English, and type it into this ripe-583 form so that I can archive it in case I am selected by the NCC for an LIR Audit". Who benefits from the time the customer (or the LIR, on the customer's behalf) spends doing this paperwork? As far as I can tell, nobody.
Accordingly, I cannot support removing need justification from "allocation" requesters.
As described above, this is not being removed. Since an assignment must be sized at least 1 address (or larger), a check-box requiring the requesting LIR to confirm assignments will be made from the allocation is functionally identical to today's current practise.
I am fine, I repeat I am fine, removing it from assignments and sub-allocations (consensus hint???)
That's really what this proposal is all about! :-)
proposal says: 2. Allows for long-term business planning. Under the proposed policy, the need-based time period will be raised from the current one/two years (allocation/assignments) to essentially infinity. ----- I do not see this as a supporting argument to the proposal itself. I think it is just irrelevant. No one has any idea what their network will be like in 100 years. Anything that can be rational will be based in the next one/two years which the current text is reflecting already.
Try substituting "essentially infinity" with "more than two years", which is really what is meant here. If the customer in the example above signs a three-year contract with my LIR and expects a gradual growth in address consumption over the contract period, I would like to be able to make an assignment that is expected to last them for their entire contract period, instead of re-doing the need bureaucracy once or twice during the contract period, avoid having to ask them to renumber into the larger assignments they got half-way through, etc.
proposal says: 3. Makes the policy easier to read and understand. ------ This is nothing to do with the content of the proposal.
I'll limit myself to one example here, although I could go on for quite some time. These two quotes are taken straight from ripe-592, our current policy document: 1) The RIPE NCC's minimum allocation size is /21. 2) The size of the allocation made under this policy will be exactly one /22. 2013-03 changes them to: 1) The RIPE NCC's minimum allocation size is /22. 2) The size of the allocation made will be exactly one /22. I hope I do not need to elaborate on why I feel this is one valid example of how 2013-03 makes the policy easier to read and understand.
proposal says: 5/6. LIR Audits becomes less time-consuming and Reduction of RIPE NCC workload. ------ These are procedural NCC issues, I've already commented regarding reducing bureaucracy with the NCC, without doing a main curriery in the policy before. These two are not real address policy management related, they are "consequences" of the proposal, rather than positive or negative Rationales
It's positive consequence, yes. That is what this point in the rationale is trying to convey. (The word "Rationale" comes from the policy proposal template (ripe-500) by the way, not from the proposal itself. While I'm not a native speaker, I do think it's being used appropriately.)
... By removing the need-based requirements, the playing field becomes level and fair for everyone involved, and will become impossible to get ahead by cheating. ------
I do not agree with the content of this statement. By removing the need-based requirements, the playing field becomes level for everyone, but this does not bring "fairness" at all. It only makes it less painful for those who dare or wishes to play unfair, in my opinion. I cannot support any proposal suggesting this in principle.
Perhaps the use of the word "fair" was not ideal here, as this is a rather subjective term. I believe that accomplishing "fairness" in our current state of scarcity is near impossible, 2013-03 or no 2013-03. Absent something we can objectively call a fair playing field, however, I think a level playing field is better than what we have today.
proposal says: 8. Makes IPv4 and IPv6 policies more similar in practise …. By removing the need principle from the IPv4 policy, it will become more similar to the IPv6 policy in practise, in the sense that need justification will not be mandated for the vast majority of delegations. -----
I am having trouble parsing this sentence, but the question stands; Why is this a good thing to stand as a Rationale, especially that currently IPv4 and IPv6 are separate pool of resources with separate set of problems?
While IPv4 and IPv6 are not the same, they are still quite similar. "96 more bits, no magic." Having similar polices makes it easier to relate to them both. Best regards, Tore Anderson