[rpd] Regarding definition of need and operation practice.

Sun Dec 6 09:41:20 UTC 2015

Sorry to all for replying to my own post. However, it has been made clear to me that I should clarify one thing..

My answer(s) to Lu in another region(s) were appropriate to the policies in those regions. Attempting to apply
them to other regions (such as AfriNIC) is wholly inappropriate.

It is clearly up to the AfriNIC community through the RPD process to develop the policies that are used by
AfriNIC to govern the address space. It is clearly up to the AfriNIC CEO and Board to interpret those policies
and implement them according to that interpretation.

There is no requirement for any level of parity between AfriNIC policies and any other region and there may
well be good reason to have different policies in the AfriNIC region.

Owen

> On Dec 6, 2015, at 01:21 , Owen DeLong <owen at delong.com> wrote:
> 
> I read your whole email. However, I do not trust you and I am not sure that I believe you.
> 
> Need is not defined in RFCs, so your statement there is inaccurate to begin with. The definition of need has evolved
> over time. Originally, it was whatever you could convince Jon was a valid need. Later, it became a little more defined,
> but still very lax. It was not until the late 1980s when we started to see commercial ISPs and broader uses of the
> internet that stricter definitions of need. Eventually, as RIRs were developed/deployed, it came to be that the definition
> of need for a given region was determined by each specific RIR’s public policy process.
> 
> However, your question had very little to do with the definition of need and was an obtuse question about moving
> addresses around while (presumably, but purely by implication) maintaining a consistent topology and organizational
> relationship.
> 
> Almost universally, the definition of need is having a host which requires an address. Need for a given size prefix
> is determined by having a number of such hosts which add up to a defined fraction of the number of addresses
> in said prefix over a defined period of time.
> 
> The fraction, period of time, etc. vary from RIR to RIR and also differ in most RIRs between IPv4 and IPv6.
> 
> In fact, most RIRs (perhaps all) do not count hosts in considering IPv6 prefix sizes, but rather count the number
> of subnets and/or the number of physical locations (where different RIRs also have different definitions for
> what constitutes a “site” or “physical” or “geographical” location).
> 
> Owen
> 
>> On Dec 6, 2015, at 01:09 , h.lu at anytimechinese.com <mailto:h.lu at anytimechinese.com> wrote:
>> 
>> Hi
>> 
>> Read my *whole* Email before replying. I clear state the reason and do not speculate my action while I have already explained.
>> 
>> On 6 Dec 2015, at 5:56 AM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>> 
>>> It seems Lu is asking this in each region. Looks like some form of RIR policy shopping to me.
>>> 
>>> Owen
>>> 
>>>> On Dec 4, 2015, at 23:21 , Lu Heng <h.lu at anytimechinese.com <mailto:h.lu at anytimechinese.com>> wrote:
>>>> 
>>>> Hi
>>>> 
>>>> I have an policy question regarding the "need".
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> First one:
>>>> 
>>>> 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?
>>>> 
>>>> Second one:
>>>> 
>>>> 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?
>>>> 
>>>> 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?
>>>> 
>>>> What should be the right interpretation of the policy?
>>>> 
>>>> (Below are some additional information, you may not need to read below before reply)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 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:
>>>> 
>>>> http://lists.arin.net/pipermail/arin-ppml/2015-December/subject.html <http://lists.arin.net/pipermail/arin-ppml/2015-December/subject.html>
>>>> 
>>>> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-December/subject.html <https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-December/subject.html>
>>>> 
>>>> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/12/ <http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/12/>
>>>> 
>>>> Some current feedback I have quoted here, to save your time, general conceus as I interpreted across every region is
>>>> 
>>>> " 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."
>>>> 
>>>> "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."
>>>> 
>>>> "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."
>>>> 
>>>> "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."
>>>> 
>>>> "> Example 1:
>>>> >
>>>> > No, there is no need to notify ARIN simply because change of location.( provided other fact stay the same)
>>>> >
>>>> > Example 2.
>>>> >
>>>> > 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)
>>>> 
>>>> 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...
>>>> 
>>>> 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."
>>>> 
>>>> "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.
>>>> 
>>>> 2nd: I would say no.  The changing of network infrastructure should NOT invalidate the original request which is approved. "
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> -- 
>>>> --
>>>> Kind regards.
>>>> Lu
>>>> _______________________________________________
>>>> RPD mailing list
>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
>>> 
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20151206/9e384f9e/attachment.html>