Hi Gert:

Thank you for insight and detailed reply.

(All the discussion below are about an latency policy element *need*, does not imply current Ripe policy in anyway)

On Thu, Dec 3, 2015 at 7:23 PM, Gert Doering <gert@space.net> wrote:

Hi,

On Thu, Dec 03, 2015 at 06:21:27PM +0100, h.lu@anytimechinese.com wrote:
> And if my fellow colleague here has an opinion on this interpretation of "need" as well as the two examples I was given, enlighten me your thought, would really appreciated.

If the customer just moves the same amount of stuff from A to B without
anything changing hands or a reduction in the number of machines/services,
*need* will still be satisfied.

But Andrea has raised a significant point here: if *documentation* is not
updated, the assignment is no longer valid, as that is a strict requirement
(both for direct PI assignments and for PA-through-LIR assignments, it
was not clear from your e-mail which sort you are referring to).

To best of my understanding, "documentation" here means whois database, as long as whois database has been updated with relevant update, no second proof was needed from Ripe NCC for the same assignment, correct me if I was wrong.

Assuming PI, and assuming you are talking about the RIPE NCC making
assignments ("Ripe" can not make assignments, as that's the policy-making
community, read: all of us), I'm fairly sure the e-mail that contains
the actual network that has been assigned clearly contains that requirement,
to always keep the documentation up to date.

I fully understand the difference between the NCC and the community, sorry for the confusion here.

Now, answerung to your second example: if you documented need for 3 locations,
and part of that documentation contained something like "we need to upgrade
the assignment size to a /24 to handle routing requirements, but we really
only have 3 hosts on each site" - and then you move everything to one
location, the original criteria would *not* apply any longer, as a single
/24 would perfectly well serve to number these combined 9 hosts plus the
routing requirements.

Sorry for misunderstanding, my intended example was, to be more detail, a /24 was proofed for any cast in 3 locations for DNS(so one /24 was proofed), during the evaluation process, evidence of existence of infrastructure of 3 locations are all provided, later after approval, management decided that 2 location would be enough for its need to reach customers, so it decided to shinrk amount of location to 2, while the service provided and the customer served was not changed, so the need of a /24 is not changed as well, my questions is, does such action considered "change of purpose of use" and invalid the assignment therefore need approval from NCC for the action before process?

So the bottom line is, what does *need* mean? Does it means the whole package of justification material(so including everything submitted during the evaluation process for the assignment, including but not limit to the upstream's contract, location of the server, etc), or does it means the *service* was provided, LIR can free justify it's own infrastructure(e.g. move server from DC A to DC B to improve speed) to provide same service to the same customer group?

Because if *need* includes whole package of justification material, then by definition, change any thing in that package(for example, location of the server, upstream provider), would request NCC approval for the assignment again therefore effectively requested NCC to manage all the infrastructure adjustment by it's members(assure the LIR do not have assignment window), because the need has changed.

I recently had this policy discussion with some RIR personnels and getting really confused, so that's the reason I come to the community to seek clarification for the understanding this very important piece of history. And I do believe documented clarification and discussion in the list for this important historical element will help future generation understand the policy better(me included).

And thanks again Gert for the time and explanation.

So, individual cases are different (and I fully trust the NCC to understand
the fine nuances, and to apply pain where necessary).

Gert Doering
-- APWG chair
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

--
Kind regards.
Lu