Hi! As I register a lot of PI/AS, there is a bit problem I often face to. My clients wants to have control on their objects I registered for them (i.e. have their mnt-by). But there is an agreement between us, and sometimes (due to payment problems, violating the agreement, spam, etc.) I need to suspend or even remove objects. Having my mntner inside users' objects is often not acceptable because of users wants to change objects by themself (and do that quickly and transparently). Also there is administrative reason ("Why we can't change our objects, why there is alien mntner?"). How I can shut down objects I registered as LIR, but don't maintain? Is there some special feature? Thank you. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
Hi!
As I register a lot of PI/AS, there is a bit problem I often face to.
My clients wants to have control on their objects I registered for them (i.e. have their mnt-by).
But there is an agreement between us, and sometimes (due to payment problems, violating the agreement, spam, etc.) I need to suspend or even remove objects.
...which means that you want to/have to keep responsibility to maintain the data in the repository, right?
Having my mntner inside users' objects is often not acceptable because of users wants to change objects by themself (and do that quickly and transparently). Also there is administrative reason ("Why we can't change our objects, why there is alien mntner?").
I don't understand this assertion, as long as there is a contractual relationship with your LIR, there is no "alien maintainer". Please keep in mind that an LIR is NOT required to provide PI assignment services. So if those "customers" don't like your set of rules, they are free to find another LIR which offers what they want. What you definitely _can_ do is add an _additional_ maintainer for your user. Then having any credential as listed in _any_ of the maintainers allows access. Evaluation of the auth: tags is done according to a LOGICAL OR policy.
How I can shut down objects I registered as LIR, but don't maintain?
Not at all. The maintainer mechanism was engineered to do exactly what you want to do: keep control.
Is there some special feature?
Not to my knowledge. I think I suggested that before - in case you deploy the multiple maintainer approch, you probably should enable the notification mechanism(s) [in your maintainer] to each time get an alert when your customer happens to change registration data. And you may want to include an explicit provision in your contract that prevents your customer from removing the link to _your_ maintainer object.
Thank you.
I presume the NCC (ripe-dbm) would be in a postion to help you enforce those provisions, just in case your customers might atttempt resource hijacking. Anything missing? If you think we need additional tools or hooks, please try to propose requirements and/or implementation ideas to the DB-WG list. Preferably before the up-coming meeting in October. (Pls. see the recently announced PDP, ripe-350) Wilfried (DB-WG Chair)
On Fri, Sep 16, 2005 at 03:30:12PM +0100, Wilfried Woeber, UniVie/ACOnet wrote:
Max Tulyev wrote:
Hi!
As I register a lot of PI/AS, there is a bit problem I often face to.
My clients wants to have control on their objects I registered for them (i.e. have their mnt-by).
But there is an agreement between us, and sometimes (due to payment problems, violating the agreement, spam, etc.) I need to suspend or even remove objects.
...which means that you want to/have to keep responsibility to maintain the data in the repository, right?
Having my mntner inside users' objects is often not acceptable because of users wants to change objects by themself (and do that quickly and transparently). Also there is administrative reason ("Why we can't change our objects, why there is alien mntner?").
I don't understand this assertion, as long as there is a contractual relationship with your LIR, there is no "alien maintainer". Please keep in mind that an LIR is NOT required to provide PI assignment services. So if those "customers" don't like your set of rules, they are free to find another LIR which offers what they want.
What you definitely _can_ do is add an _additional_ maintainer for your user. Then having any credential as listed in _any_ of the maintainers allows access. Evaluation of the auth: tags is done according to a LOGICAL OR policy.
How I can shut down objects I registered as LIR, but don't maintain?
Not at all. The maintainer mechanism was engineered to do exactly what you want to do: keep control.
Is there some special feature?
Not to my knowledge. I think I suggested that before - in case you deploy the multiple maintainer approch, you probably should enable the notification mechanism(s) [in your maintainer] to each time get an alert when your customer happens to change registration data.
And you may want to include an explicit provision in your contract that prevents your customer from removing the link to _your_ maintainer object.
Thank you.
I presume the NCC (ripe-dbm) would be in a postion to help you enforce those provisions, just in case your customers might atttempt resource hijacking.
Anything missing? If you think we need additional tools or hooks, please try to propose requirements and/or implementation ideas to the DB-WG list. Preferably before the up-coming meeting in October. (Pls. see the recently announced PDP, ripe-350)
Wilfried (DB-WG Chair)
To be honest, I don't think it is resonable for the ISP to remove the inetnum's from the RIPE db, as the customer 'owns' the resources. So the ISP can drop the routing, they can drop any route-records they have, but I don't think they can really drop the PI space inetnum objects. But please correct me if I am wrong. Regards, Andre Koopal MCI
To be honest, I don't think it is resonable for the ISP to remove the inetnum's from the RIPE db, as the customer 'owns' the resources. So the ISP can drop the routing, they can drop any route-records they have, but I don't think they can really drop the PI space inetnum objects.
But please correct me if I am wrong.
Correct only if I provide connectivity to my user. In that case, there is PA space, not PI. And of course, it can't be applied for ASNs. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On १६-०९-२००५, at ३:४७ अपराह्न, Andre Koopal wrote:
To be honest, I don't think it is resonable for the ISP to remove the inetnum's from the RIPE db, as the customer 'owns' the resources.
OK, let's say the ISP/LIR does the PI application etc for the customer and agrees with the customer that he/she will be charged x amount per year for the facility (seeing as ISP/LIR membership size and membership fee depends on number of allocations within LIR membership so LIR quite rightly wants to recoup some of this cost). So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it. Please correct me if I am wrong. :-) Regards Denesh
Denesh Bhabuta wrote:
On १६-०९-२००५, at ३:४७ अपराह्न, Andre Koopal wrote:
To be honest, I don't think it is resonable for the ISP to remove the inetnum's from the RIPE db, as the customer 'owns' the resources.
OK, let's say the ISP/LIR does the PI application etc for the customer and agrees with the customer that he/she will be charged x amount per year for the facility (seeing as ISP/LIR membership size and membership fee depends on number of allocations
More precisely: on the size (amount of addresses, not number of transactions) _and_ the age of the allocation/assignment. The formula is available somewhere. I have to admit that I don't know _exactly_ how PI assignments do contribute to the determination of an LIR's size category. E.g. the few PI transactions we have made to support our customers are insignificant - compared to the PA space we have to manage. That might be different for other LIRs, although I doubt it, unless the PI mechanism is misused (from an aggregation point of view).
within LIR membership so LIR quite rightly wants to recoup some of this cost).
So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it.
Please correct me if I am wrong. :-)
That's a different story, and we can start to discuss this in itself. Remember, an LIR is not required to offer that service. So unless you see some sort of advantage offering it, you would probably not do it in the 1st place, right?
Regards Denesh
Wilfried.
OK, let's say the ISP/LIR does the PI application etc for the customer and agrees with the customer that he/she will be charged x amount per year for the facility (seeing as ISP/LIR membership size and membership fee depends on number of allocations
More precisely: on the size (amount of addresses, not number of transactions) _and_ the age of the allocation/assignment. The formula is available somewhere.
The formula is available http://www.ripe.net/ripe/docs/billing2005.html
Remember, an LIR is not required to offer that service. So unless you see some sort of advantage offering it, you would probably not do it in the 1st place, right?
Is money an advantage to offer service? People asks, we do. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Fri, Sep 16, 2005 at 04:42:37PM +0100, Denesh Bhabuta wrote:
So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it.
I think it's more reasonable to charge PI and/or ASNs by means of a one time charge when the customer requests them. It seems unfair to me to have the customer enter a long term contract for resources he is free to take away to another party, but that's just my 2 cents.
Hi, On Fri, Sep 16, 2005 at 04:42:37PM +0100, Denesh Bhabuta wrote:
So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it.
ripe-330, appendix I has the following to say regarding PI space: ----------- quote ------------- Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. ----------- quote ------------- so, as of today, the LIR is only charged for the very year where a PI network or AS number is assigned (and previous years didn't charge PI/ASn at all). Regarding the future, this is something for the RIPE General Meeting to decide (not the "RIPE meeting", which is open for everyone, but the RIPE AGM, which decides things like billing, and is open for RIPE members only). Unless the AGM decides to change this rule, it's going to stay the same for the next year. Personally, I think this approach makes sense. PI and AS numbers *do* cause work at the NCC, so a LIR that assigns lots of them should pay more. OTOH, the PI/AS holder might just go away afterwards, so charging the "correct" LIR for many years after the assignment is going to be administratively difficult (and likely unfair, in many cases). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Dear all, Just a confirmation of what Gert just mentioned below. In addition I wanted to point out that the new draft Charging Scheme 2006 is available and will score PI IPv4 and AS number in an identical manner. Below the link to the draft Charging Scheme 2006 on which the RIPE NCC General Meeting will vote in October. http://www.ripe.net/ripe/draft-documents/gm-october2005/charging-scheme-2006... Regards, Jochem de Ruig RIPE NCC At 06:35 PM 9/18/2005 +0200, Gert Doering wrote:
Hi,
On Fri, Sep 16, 2005 at 04:42:37PM +0100, Denesh Bhabuta wrote:
So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it.
ripe-330, appendix I has the following to say regarding PI space:
----------- quote ------------- Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. ----------- quote -------------
so, as of today, the LIR is only charged for the very year where a PI network or AS number is assigned (and previous years didn't charge PI/ASn at all).
Regarding the future, this is something for the RIPE General Meeting to decide (not the "RIPE meeting", which is open for everyone, but the RIPE AGM, which decides things like billing, and is open for RIPE members only). Unless the AGM decides to change this rule, it's going to stay the same for the next year.
Personally, I think this approach makes sense. PI and AS numbers *do* cause work at the NCC, so a LIR that assigns lots of them should pay more. OTOH, the PI/AS holder might just go away afterwards, so charging the "correct" LIR for many years after the assignment is going to be administratively difficult (and likely unfair, in many cases).
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi all! Yes. But it is about RIPE bills me, but not I bills my clients. I really don't want to lease or rent addresses, but to make several (or even regular) small payments instead of one big is useful in practice very often. BTW, same problems is PA assignment are not maintained by me.
Dear all,
Just a confirmation of what Gert just mentioned below. In addition I wanted to point out that the new draft Charging Scheme 2006 is available and will score PI IPv4 and AS number in an identical manner.
Below the link to the draft Charging Scheme 2006 on which the RIPE NCC General Meeting will vote in October.
http://www.ripe.net/ripe/draft-documents/gm-october2005/charging-scheme-200 6.html
Regards,
Jochem de Ruig RIPE NCC
At 06:35 PM 9/18/2005 +0200, Gert Doering wrote:
Hi,
On Fri, Sep 16, 2005 at 04:42:37PM +0100, Denesh Bhabuta wrote:
So, if LIR no longer has any control over the PI space via any sort of MNT, why should PI space still reside within LIR membership 'account' and continue contributing to membership size? Either ISP/ LIR should be able to remove PI Space from their membership or not be indirectly charged for it.
ripe-330, appendix I has the following to say regarding PI space:
----------- quote ------------- Note: For AS Numbers and PI IPv4 allocations, only the allocations from the past 12 months dating back from the 30 September 2004 are taken into account as these resources are allocated or assigned on behalf of third parties. ----------- quote -------------
so, as of today, the LIR is only charged for the very year where a PI network or AS number is assigned (and previous years didn't charge PI/ASn at all).
Regarding the future, this is something for the RIPE General Meeting to decide (not the "RIPE meeting", which is open for everyone, but the RIPE AGM, which decides things like billing, and is open for RIPE members only). Unless the AGM decides to change this rule, it's going to stay the same for the next year.
Personally, I think this approach makes sense. PI and AS numbers *do* cause work at the NCC, so a LIR that assigns lots of them should pay more. OTOH, the PI/AS holder might just go away afterwards, so charging the "correct" LIR for many years after the assignment is going to be administratively difficult (and likely unfair, in many cases).
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
participants (7)
-
Andre Koopal -
Denesh Bhabuta -
Gert Doering -
Jochem de Ruig -
MarcoH -
Max Tulyev -
Wilfried Woeber, UniVie/ACOnet