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/ncc-services-wg@ripe.net/
[ncc-services-wg] Feature request
- Previous message (by thread): [ncc-services-wg] Feature request
- Next message (by thread): [ncc-services-wg] Feature request
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Max Tulyev
president at ukraine.su
Sun Sep 18 10:33:07 CEST 2005
> > 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. Yes, my administrative overhead in fact is an hour or two of working with the request and user (I really afraid to scare hostmasters by sending forms I got from users ;) ). But scoring LIR gets for such requests is really the money. So I have to get it from my customers. > 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. No. It isn't cheaper. LIR costs near 3000EUR (PI assignments here costs from a box of beer ;) up to 1000 EUR), and there is quarterly (yearly) payments. LIR needs to be administrated. LIR needs A LOT of paperwork (thanks to community, in Russia there is special agreement, but in other ex-USSR countries don't). > > Anyway, is there the deny to bill PI/AS on regular basis (not once)? > > Where? > No, and I didn't think I said that? No. But as I understood, you try to say that PI/AS billing on regular (or chunked) basis is bad. So I want to understand is there just your point of view or there is some documents about it. > 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. Other goal is consumption ;) If small ISP really needs /24 assignment, but they have to be LIR and get /20 allocation - is it good? > 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, I assign PI to these who needs it. So their presence hurts community, not me ;) Again, think about consumption. > - 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, Even if it is one payment chunked for example on 12 monthly payments? > - 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. Not only me. There is a question really. And as contract violations is a rare case, may be it doesn't need any technical improvements into the RIPE DB. Maybe letter to hostmaster will be enough? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO)
- Previous message (by thread): [ncc-services-wg] Feature request
- Next message (by thread): [ncc-services-wg] Feature request
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]