[address-policy-wg] [policy-announce] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Cleanup)

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