[address-policy-wg] An interesting policy question

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 at space.net> wrote:

> Hi,
>
> On Thu, Dec 03, 2015 at 06:21:27PM +0100, h.lu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20151203/48398917/attachment.html>