[ncc-services-wg] Feature request

Max Tulyev wrote:

>>Well, you are not supposed to sell/rent addresses, with the exception of
>>covering the administrative overhead. Which should be close to NIL if you
>>do not want to take care of that block (LIR-wise). So a simple approach
>>would be to hand out the addresses only after a reasonable once-off fee for
>>obtaining them has been paid.
> 
> 
> Heh... /22 PI is scored like 4 (FOUR) PA /20 block usually got by LIR at the 
> beginning (but, of course, once).

I presume that is either the "non-aggregation penalty", or the penalty for
the additional overhead at the RIR (as they have to be involved in each
assignment transaction), or for both.

> So I don't think it is "close to NIL".

I tried to say that the _administrative overhead_ would be close to NIL
if you do not want to help in maintaining the registry data.

Otoh, given that fee structure it might be cheaper (for a certain block-size
or larger) to establish a separate extra small LIR to get big PI blocks (which
PA-blocks essentially are). With the benefit that the resposibility is clearly
set.

> Often it is too expensive, especially in eastern Europe, especially to 
> non-profit organization. So it is good to split payment for a chunks, not 
> bill them once.
> 
> Anyway, is there the deny to bill PI/AS on regular basis (not once)? Where?

No, and I didn't think I said that?

>>Which agreements? As long as you provide connectivity to them, this is an
>>ISP operational issue. If they don't pay for those services they get
>>locked/cut. Then the holder of PI is free (by definition) to find another
>>provider. end story.
>
> If I am their service provider (btw, then they got PA) - I can cut their 
> service. And if not?

If you are not, then your options are different, of course, and probably
the motivation to provide the service, or not. And if you try to run it as
a national or regional service, then it sounds very much like the concept
of the "last resort registry" which was abandoned many years ago, as it was
considered counterproductive to the aggregation goal.

>>Boring, yes, but I thought you want to see an on-going flow of money ;-)
>>What for? Where's the user friendlyness?
> 
> 
> So RIPE gives me a policy how to deal with my clients? ;)

No, RIPE gives you a set of guidelines how to handle address space requests,
and how much and when you have to pay to the RIR for the services you receive
from the RIR.

> If yes, please show me the documents. If not - let me do that, and be 
> LIR-friendly ;)

Don't be offended, but it starts to smell like a request for a free, or at
least cheaper, ride than the rest of the gang:
- when you assign PI on a regular basis for entities that are not your
  service customers, then that probably hurts the rest of the community
  by lack of aggregation,
- when you argue in favour of keeping the money coming in regularly (more
  than to cover the cost of your _administrative overhead_ plus the penalty
  for your size category), but you don't want to be responsible any longer
  and/or be involved with registry data maintainance foe me this starts to
  smell like selling or renting out address space,

>>There should be a local legal envirnment available to enforce (resonable)
>>contracts.
> 
> 
> Yes. But, unfortunally, contracts sometimes violates, so I ask about technical 
> resources to have users to be correct.

- and you implictely ask for the whole community to spend money on providing
  technical resources to help you in managing the contracts with your customers.


Again, you are more than welcome to come forward with a proposal (see ripe-350),
and if the community can agree on the usefulness of your requirement(s) or proposal
then we should be able to help.

Btw, I started to think about a potential *technical* approach to achieve what you
seem to request: because you might have a _slightly_ better point with regard to AS
numbers than for PI address space management. But I need a bit more time to make up
my own *technical* mind.

But don't hold your breath, come forward with a set of requirements, at least.
Ideas regarding implementation and expected impact on logistics and DB operations
would of course be even better.

Regards,
Wilfried.