[address-policy-wg] PA policy

I thing he understand "end user" as a residential customer user.

But a residential customer user is not recieving the PA space, is the 
ISP of the customer who recieve it.

LIR is not ISP. You can be a LIR and not an ISP and vice versa.


El 07/07/2015 a las 14:55, Nick Hilliard escribió:
> On 07/07/2015 13:31, Kennedy, James wrote:
>> At the risk of sounding naïve, I have a question regarding the
>> legitimate usage of PA address space. That is, what *type* of network or
>> End User can it be assigned to.
>>
>> "LIRs are allocated Provider Aggregatable (PA) address space. They
>> sub-allocate and assign this to *downstream networks*."
>> https://www.ripe.net/publications/docs/ripe-643#7
>>
>> To me this reads networks or End Users assigned PA space must receive
>> transit from the LIR holding the parent allocation.
>>
>> Or can the LIR assign PA blocks to customers/companies that don't
>> receive transit, or any other technical network service for that matter,
>> from the LIR?
>
> There are two separate things going on here.
>
> 1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was
> accepted.
>
> 2. if an end user receives a PA block from LIR1 and then attempts to route
> it out through a different network who operates LIR2, that's an issue for
> the end user, LIR1 and LIR2 to resolve.  The RIPE NCC is not the routing
> police and has no policy basis to intervene.
>
> Situation #2 is relatively common and becoming more so.
>
>  From an end user point of view, it's a pretty damned stupid thing to do
> because if the end user terminates their business relationship with LIR1,
> then they terminate any rights to use the address space they received from
> LIR1.  This puts the them in the situation where their business continuity
> depends on a contractual relationship with a single supplier.  Not clever.
>
>  From the point of view of LIR1, some LIRs run with this as a business model
> in order to prevent customers moving away.
>
>  From the point of view of LIR2, this often ends up causing problems between
> them, the end user and LIR1.
>
> Nick
>