<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I read your whole email. However, I do not trust you and I am not sure that I believe you.<div class=""><br class=""></div><div class="">Need is not defined in RFCs, so your statement there is inaccurate to begin with. The definition of need has evolved</div><div class="">over time. Originally, it was whatever you could convince Jon was a valid need. Later, it became a little more defined,</div><div class="">but still very lax. It was not until the late 1980s when we started to see commercial ISPs and broader uses of the</div><div class="">internet that stricter definitions of need. Eventually, as RIRs were developed/deployed, it came to be that the definition</div><div class="">of need for a given region was determined by each specific RIR’s public policy process.</div><div class=""><br class=""></div><div class="">However, your question had very little to do with the definition of need and was an obtuse question about moving</div><div class="">addresses around while (presumably, but purely by implication) maintaining a consistent topology and organizational</div><div class="">relationship.</div><div class=""><br class=""></div><div class="">Almost universally, the definition of need is having a host which requires an address. Need for a given size prefix</div><div class="">is determined by having a number of such hosts which add up to a defined fraction of the number of addresses</div><div class="">in said prefix over a defined period of time.</div><div class=""><br class=""></div><div class="">The fraction, period of time, etc. vary from RIR to RIR and also differ in most RIRs between IPv4 and IPv6.</div><div class=""><br class=""></div><div class="">In fact, most RIRs (perhaps all) do not count hosts in considering IPv6 prefix sizes, but rather count the number</div><div class="">of subnets and/or the number of physical locations (where different RIRs also have different definitions for</div><div class="">what constitutes a “site” or “physical” or “geographical” location).</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 6, 2015, at 01:09 , <a href="mailto:h.lu@anytimechinese.com" class="">h.lu@anytimechinese.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">Hi</div><div class=""><br class=""></div><div class="">Read my *whole* Email before replying. I clear state the reason and do not speculate my action while I have already explained.</div><div class=""><br class="">On 6 Dec 2015, at 5:56 AM, Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=gb2312" class="">It seems Lu is asking this in each region. Looks like some form of RIR policy shopping to me.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div style="" class=""><blockquote type="cite" class=""><div class="">On Dec 4, 2015, at 23:21 , Lu Heng <<a href="mailto:h.lu@anytimechinese.com" class="">h.lu@anytimechinese.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div dir="ltr" class="">Hi<br class=""><br class="">I have an policy question regarding the "need".<br class=""><br class="">We all know when RIR approves are needed for assignment LIR made if it is beyond LIR's assignment window, while the "need" has changed, the assignment become invalid.<br class=""><br class="">The question come to what the definition of need, as a young people here, I am a bit confused, Below I have few examples, please enlighten me if anyone has an thought about it.<br class=""><br class="">First one:<br class=""><br class="">Company A provides 100 customer dedicated server service at location A, RIR 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?<br class=""><br class="">Second one:<br class=""><br class="">Company A provides DNS service, any casted in 3 location using single /24, and has provided evidence of 3 locations to the RIR during the time the company getting valid assignment, then A decided to cut 3 location to 2 location due to operational need, while it still provide service to the same customer group using that single /24, does this invalid original assignment and need to be notified to RIR?<br class=""><br class="">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 also considered as change of purpose of use and need to be notified to RIR?<br class=""><br class="">What should be the right interpretation of the policy?<div class=""><br class=""></div><div class="">(Below are some additional information, you may not need to read below before reply)<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><br class="">Because *need* was an documented RFC element, and shared across the globe, I have asked other community's view here as well, in which you may check at following list:<br class=""><br class=""><a href="http://lists.arin.net/pipermail/arin-ppml/2015-December/subject.html" class="">http://lists.arin.net/pipermail/arin-ppml/2015-December/subject.html</a><br class=""><br class=""><a href="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-December/subject.html" class="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-December/subject.html</a><br class=""><br class=""><a href="http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/12/" class="">http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/12/</a><br class=""><br class="">Some current feedback I have quoted here, to save your time, general conceus as I interpreted across every region is</div><div class=""><br class=""></div><div class="">" no need to notify RIR in both example, however Whois should be updated accordingly to keep the accuracy of the registry, need is defined as the service are provided but not for the whole package of justification material."<br class=""><br class=""><u style="font-style:italic" class="">"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,</u><br class=""><u style="font-style:italic" class="">*need* will still be satisfied."</u><br class=""><br class=""><u style="font-style:italic" class="">"It depends what the conditions were for getting the assignment in the first place. If you were allowed to make an assignment for reason X then you can't just change X. You can change Y and Z, as long as they weren't part of the condition. What those fictional X, Y and Z might be are completely dependent on the actual policy, and for addresses we don't have any needs criteria anymore so this is all hypothetical."</u><br class=""><br class=""><u style="font-style:italic" class="">"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.</u><br class=""><br class=""><u style="font-style:italic" class="">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."</u><br class=""><br class=""><u style="font-style:italic" class="">"> Example 1:</u><br class=""><u style="font-style:italic" class="">></u><br class=""><u style="font-style:italic" class="">> No, there is no need to notify ARIN simply because change of location.( provided other fact stay the same)</u><br class=""><u style="font-style:italic" class="">></u><br class=""><u style="font-style:italic" class="">> Example 2.</u><br class=""><u style="font-style:italic" class="">></u><br class=""><u style="font-style:italic" class="">> In case of 3 location shrinking to 2 location, there is also no need to notify ARIN provided the service stay the same.(in-out region does not relevant here as the number of location is decreased, so even there is an out region location was notified ARIN during application process in the first place)</u><br class=""><br class=""><u style="font-style:italic" class="">Essentially correct, noting that changes in circumstances may cause review of the already-approved resource request if there is reason to believe that original resource request was fraudulent in nature. This is similar to cases where a party requests resources baed on is own need, is approved, and then undergoes a “change in circumstance” such that they wish to now transfer those resources to another party instead...</u><br class=""><br class=""><u style="font-style:italic" class="">Howdy, That's generally correct. One caveat: Internet Service Providers and SWIP. Folks with ISP allocations (not end-user assignments) are expected to maintain accurate SWIP records with ARIN. To the extent that location was reported in the original SWIP records, it would need to be updated. >From what I understand, internal infrastructure generally doesn't get reported with any location details. SWIP is intended mostly to report customer assignments."</u><br class=""><br class=""><u style="font-style:italic" class="">"1st: I would say no. There are no followups after allocation and there should not be due to the many complication issues that can happen.</u><br class=""><br class=""><u style="font-style:italic" class="">2nd: I would say no. The changing of network infrastructure should NOT invalidate the original request which is approved. "</u><br class=""><br class=""><br class="">Please note above are all community views from different region, none of them official, and my quotation are not their full Email so for most acculturate view, please check the list I have posted.<br class=""><br class="">This is an important subject, if *Need* indeed including anything that submitted in the justification process, then meaning any infrastructure adjustment(because that always part of justification) in the continent are needing approval from Afrinic, in another word, Afrinic are effectively managing all internet infrastructure in this continent.<br class=""><br class="">But again, here I am learning from the community's thought on this, Africa does not need to be same as the rest the world, what matters really is what community here thinks.<br class=""><br class="">-- <br class="">--<br class="">Kind regards.<br class="">Lu</div></div></div>
</div><div class=""></div></div>_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo/rpd" class="">https://lists.afrinic.net/mailman/listinfo/rpd</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>