This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] An interesting policy question
- Previous message (by thread): [address-policy-wg] An interesting policy question
- Next message (by thread): [address-policy-wg] An interesting policy question
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lu Heng
h.lu at anytimechinese.com
Fri Dec 4 10:15:09 CET 2015
Hi Thanks Vladislav for the clear answer. And for the list, this is an answer I would like to receive, clear and easy. The example was very simple so I was expecting an simple answer as well. (I got an feeling that anything I say in the list was wrong, I hope it does not become personal again, I am asking a policy question in a policy discussion mailing list and nothing more than that). On Fri, Dec 4, 2015 at 10:10 AM, <poty at iiat.ru> wrote: > Hello, > > > > To answer your question you can look at the obsoleted forms used for > “registering” an assignment. There was no particular points to geographic > locations of a network, so relocation the untouched set of assets to > another place (or even changing them in the margins of the initial request) > did not require a new request/notification. It was the answer to the first > question. > > The second question is more complex. But it seems removing one of the > locations did not change *the need* for the assigned /24, so the answer > to the question should be the same as the previous one. > > > > Regards, > > Vladislav Potapov > > Ru.iiat > > > > *From:* address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] *On > Behalf Of *Lu Heng > *Sent:* Thursday, December 3, 2015 2:27 PM > *To:* address-policy-wg at ripe.net > *Subject:* [address-policy-wg] An interesting policy question > > > > Hi > > > > I have an policy question regarding Ripe policy before adoption of "no > need" policy. > > > > We all know that before the no need policy, when Ripe makes an assignment, > while the "need" has changed, the assignment become invalid. > > > > The question come to what the definition of need. Below I have few > examples, please provide your view: > > > > First one: > > > > Company A provides 100 customer dedicated server service at location A, > Ripe makes an assignment for 100 IP for his infrastructure, if, under > condition that no other factor was changed, Company A moved his > infrastructure to location B, but still providing same service to same > customer, does the company's action need to be notified to RIR? And does > this action considered invalid the original assignment? > > > > Second one: > > > > Company A provides web hosting service, but any casted in 3 location, and > has provided the evidence of 3 location to the RIR during the time the > company getting valid assignment, then A decided to cut 3 location to 2 > location, does this invalid original assignment and need to be notified to > RIR? > > > > So the bottom line is, what is the definition of need, is it defined as > the service you are providing or defined as whole package of any of > original justification material was provided, if was the later, then does > it imply that anything, including location of the infrastructure, upstream > providers etc has changed due to operational need, it will be considered as > change of purpose of use and need to be notified to RIR? > > > > What should be the right interpretation of the policy by then? > > > > -- > > -- > Kind regards. > Lu > -- -- Kind regards. Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20151204/23535547/attachment.html>
- Previous message (by thread): [address-policy-wg] An interesting policy question
- Next message (by thread): [address-policy-wg] An interesting policy question
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]