From ncc at ripe.net Thu Sep 1 16:35:24 2005 From: ncc at ripe.net (Paul Rendek) Date: Thu, 01 Sep 2005 16:35:24 +0200 Subject: [ncc-services-wg] RIPE Policy Development Process Message-ID: <5.2.1.1.2.20050901162916.027803b8@mailhost.ripe.net> Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC From contact at ripe.net Thu Sep 1 16:40:46 2005 From: contact at ripe.net (Membership Liaison Officer) Date: Thu, 01 Sep 2005 16:40:46 +0200 Subject: [ncc-services-wg] Final Reminder: RIPE NCC Regional Meeting, Moscow, 15 - 16 September 2005 Message-ID: <5.2.1.1.2.20050901163826.03390800@mailhost.ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, This is a final reminder that registration will soon close for the second RIPE NCC Regional Meeting in Moscow. The meeting will be held 15 - 16 September 2005 at the Moscow Marriott Grand Hotel in Moscow, Russia. The deadline for registering is Friday, 9 September 2005. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. MEETING VENUE Marriott Grand Hotel 26/1 Tverskaya Street Moscow, 125009 Russian Federation Phone: +7 095 9370000 Fax: +7 095 9370001 More information about the meeting venue can be found at: http://www.ripe.net/meetings/regional/moscow-2005/meeting-venue.html REGISTRATION Registration for the RIPE NCC Regional Meeting is now open. Registration will close on Friday, 9 September 2005. To register, please see: https://lirportal.ripe.net/lirportal/meeting/registration/meeting.html?id=6 AGENDA The agenda for the RIPE NCC Regional Meeting is available at: http://www.ripe.net/meetings/regional/moscow-2005/agenda.html We have reserved space in the agenda for presentations from the local community on current issues affecting the region. If there is a particular presentation or topic you would like included in the agenda, please send your suggestion to: TRAINING SEMINARS The RIPE NCC Regional Meeting will feature training seminars on IP request procedures, DNSSEC and the Routing Registry. More information about these training seminars is available at: http://www.ripe.net/meetings/regional/moscow-2005/agenda.html APPOINTMENTS AVAILABLE WITH RIPE NCC IP RESOURCE ANALYSTS RIPE NCC IP Resource Analysts will be available for consultation during the RIPE NCC Regional Meeting. For more information, and to make an appointment, please see: http://www.ripe.net/meetings/regional/moscow-2005/ip-resource-analysts.html VISA INFORMATION If you will need a visa to attend this meeting, please read the information available at: http://www.ripe.net/meetings/regional/moscow-2005/visa.html MORE INFORMATION More information about the RIPE NCC Regional Meeting in Moscow is available from: http://www.ripe.net/meetings/regional/moscow-2005/index.html If you have any further questions, please send an e-mail to: Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC www.ripe.net From ncc at ripe.net Thu Sep 8 17:51:58 2005 From: ncc at ripe.net (Paul Rendek) Date: Thu, 08 Sep 2005 17:51:58 +0200 Subject: [ncc-services-wg] RIPE NCC Member Update - Issue 8 Message-ID: <5.2.1.1.2.20050908174117.02fef150@mailhost.ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce the release of the latest edition of the RIPE NCC Member Update. You can find the latest edition of the Member Update at: http://www.ripe.net/membership/newsletter/2005/newsletter8.pdf This edition of the Member Update includes sections on: - A guest article on the report from the Working Group on Internet Governance (WGIG) - The RIPE NCC Membership Survey 2005 - Changes to RIPE NCC Online Payments - New instances of the RIPE NCC operated K-root server - Previous and upcoming RIPE Meetings - RIPE NCC Training Courses and conference calendar If you have any questions, suggestions or comments about the RIPE NCC Member Update, please contact us by e-mail at: Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From president at ukraine.su Fri Sep 16 14:41:03 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 16 Sep 2005 16:41:03 +0400 Subject: [ncc-services-wg] Feature request Message-ID: <200509161641.03993.president@ukraine.su> 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 at FIDO) From woeber at cc.univie.ac.at Fri Sep 16 16:30:12 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 16 Sep 2005 15:30:12 +0100 Subject: [ncc-services-wg] Feature request In-Reply-To: <200509161641.03993.president@ukraine.su> References: <200509161641.03993.president@ukraine.su> Message-ID: <432AD6F4.7040504@cc.univie.ac.at> 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) From president at ukraine.su Fri Sep 16 17:09:24 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 16 Sep 2005 19:09:24 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: <200509161909.24336.president@ukraine.su> > 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 at FIDO) From president at ukraine.su Fri Sep 16 17:13:03 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 16 Sep 2005 19:13:03 +0400 Subject: [ncc-services-wg] Feature request Message-ID: <200509161913.03689.president@ukraine.su> > > 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? Not right. User is keeping responsibility to maintain the data, so their mnt-by is in the objects. My aim is (at least) to bill user, and it can be done different ways (once, yearly, quarterly, by crediting user for sometime, whatever). And I need the mechanism to let that user have to pay ;) (and not to violate agreements by other ways) and remove objects if it doesn't - but NOT to keep information up to date in RIPE DB. > 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. Ok, but if I want to be more user friendly than others? Or if I bored with making updates of my users' objects? > 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. From the beginning I said about "bad guys". If user really one - he just sends an update to remove my mntner - and I loose control on object completly. > 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. But notification comes a bit later, isn't it? ;) > And you may want to include an explicit provision in your contract that > prevents your customer from removing the link to _your_ maintainer object. If all users always do what is written in the contract - there was no deal about all of that at all. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From andre.koopal at nld.mci.com Fri Sep 16 16:47:33 2005 From: andre.koopal at nld.mci.com (Andre Koopal) Date: Fri, 16 Sep 2005 16:47:33 +0200 Subject: [ncc-services-wg] Feature request In-Reply-To: <432AD6F4.7040504@cc.univie.ac.at> References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> Message-ID: <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> 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 From denesh at cyberstrider.net Fri Sep 16 17:42:37 2005 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Fri, 16 Sep 2005 16:42:37 +0100 Subject: [ncc-services-wg] Feature request In-Reply-To: <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: 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 From woeber at cc.univie.ac.at Fri Sep 16 18:12:59 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 16 Sep 2005 17:12:59 +0100 Subject: [ncc-services-wg] Feature request In-Reply-To: References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: <432AEF0B.10303@cc.univie.ac.at> 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. From president at ukraine.su Fri Sep 16 18:27:40 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 16 Sep 2005 20:27:40 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <432AE9A1.9040007@cc.univie.ac.at> References: <200509161913.03689.president@ukraine.su> <432AE9A1.9040007@cc.univie.ac.at> Message-ID: <200509162027.40894.president@ukraine.su> > 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). So I don't think it is "close to NIL". 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? > 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? > 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? ;) If yes, please show me the documents. If not - let me do that, and be LIR-friendly ;) > 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. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Fri Sep 16 18:33:26 2005 From: president at ukraine.su (Max Tulyev) Date: Fri, 16 Sep 2005 20:33:26 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <432AEF0B.10303@cc.univie.ac.at> References: <200509161641.03993.president@ukraine.su> <432AEF0B.10303@cc.univie.ac.at> Message-ID: <200509162033.26602.president@ukraine.su> > > 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 at FIDO) From woeber at cc.univie.ac.at Fri Sep 16 20:28:09 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 16 Sep 2005 19:28:09 +0100 Subject: [ncc-services-wg] Feature request In-Reply-To: <200509162027.40894.president@ukraine.su> References: <200509161913.03689.president@ukraine.su> <432AE9A1.9040007@cc.univie.ac.at> <200509162027.40894.president@ukraine.su> Message-ID: <432B0EB9.9090505@cc.univie.ac.at> 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. From marcoh at marcoh.net Sat Sep 17 18:23:38 2005 From: marcoh at marcoh.net (MarcoH) Date: Sat, 17 Sep 2005 18:23:38 +0200 Subject: [ncc-services-wg] Feature request In-Reply-To: References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: <20050917162338.GA3944@marcoh.net> 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. From president at ukraine.su Sun Sep 18 10:33:07 2005 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Sep 2005 12:33:07 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <432B0EB9.9090505@cc.univie.ac.at> References: <200509161913.03689.president@ukraine.su> <200509162027.40894.president@ukraine.su> <432B0EB9.9090505@cc.univie.ac.at> Message-ID: <200509181233.07053.president@ukraine.su> > > 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) From gert at space.net Sun Sep 18 18:22:51 2005 From: gert at space.net (Gert Doering) Date: Sun, 18 Sep 2005 18:22:51 +0200 Subject: [ncc-services-wg] Feature request In-Reply-To: <200509162027.40894.president@ukraine.su> References: <200509161913.03689.president@ukraine.su> <432AE9A1.9040007@cc.univie.ac.at> <200509162027.40894.president@ukraine.su> Message-ID: <20050918162251.GW5931@Space.Net> Hi, On Fri, Sep 16, 2005 at 08:27:40PM +0400, Max Tulyev wrote: > If I am their service provider (btw, then they got PA) - I can cut their > service. And if not? The whole point about "PI" networks is that they are owned by the *end customer*, and not by the provider. As soon as you (as LIR) have requested&received it for your customer, it belongs to your customer. End of story. No way to take it back (as long as all facts stated in the request are still valid). > > 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? ;) Don't assign PI space if do not want your customers to be able to just take it away if they are unhappy with you. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Sun Sep 18 18:35:50 2005 From: gert at space.net (Gert Doering) Date: Sun, 18 Sep 2005 18:35:50 +0200 Subject: [ncc-services-wg] Feature request In-Reply-To: References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: <20050918163550.GX5931@Space.Net> 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 at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jochem at ripe.net Mon Sep 19 09:22:28 2005 From: jochem at ripe.net (Jochem de Ruig) Date: Mon, 19 Sep 2005 09:22:28 +0200 Subject: [ncc-services-wg] Feature request In-Reply-To: <20050918163550.GX5931@Space.Net> References: <200509161641.03993.president@ukraine.su> <432AD6F4.7040504@cc.univie.ac.at> <20050916144725.GP11143@asoserve0.ams.ops.eu.uu.net> Message-ID: <5.2.1.1.2.20050919090807.02cea7f0@mailhost.ripe.net> 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.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 at Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 From president at ukraine.su Mon Sep 19 18:04:42 2005 From: president at ukraine.su (Max Tulyev) Date: Mon, 19 Sep 2005 20:04:42 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <5.2.1.1.2.20050919090807.02cea7f0@mailhost.ripe.net> References: <5.2.1.1.2.20050919090807.02cea7f0@mailhost.ripe.net> Message-ID: <200509192004.42758.president@ukraine.su> 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 at 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 at FIDO) From president at ukraine.su Mon Sep 19 18:12:21 2005 From: president at ukraine.su (Max Tulyev) Date: Mon, 19 Sep 2005 20:12:21 +0400 Subject: [ncc-services-wg] Feature request In-Reply-To: <58629038-D950-4762-B6B2-A28050680480@ripe.net> References: <200509161641.03993.president@ukraine.su> <200509161904.43138.president@ukraine.su> <58629038-D950-4762-B6B2-A28050680480@ripe.net> Message-ID: <200509192012.22105.president@ukraine.su> > I think I misunderstood what you wanted when we spoke last week. I > thought you were looking for some kind of added granularity to the > maintainer system. However, reading your request again it looks more > like you want to be able to use the RIPE Database to enforce a > contract between you and your customers. Is that correct? Correct, but not exactly RIPE DB. Just have an ability (for example, through letter to Hostmaster) to have general control on the objects I registered. > Can I ask why you'd want to use the RIPE Database to do this rather > than use an alternative, like a debt collection agency, or an order > from a civil court? That's because it is not working fine here... -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From bijal at sanghani.co.uk Mon Sep 19 17:58:51 2005 From: bijal at sanghani.co.uk (Bijal Sanghani) Date: Mon, 19 Sep 2005 16:58:51 +0100 (BST) Subject: [ncc-services-wg] RIPE51 - NCC Services WG - Agenda Items Message-ID: <11170.217.155.37.21.1127145531.squirrel@www.gradwell.com> Dear Colleagues, We are currently working on the draft agenda for the RIPE NCC Services Working Group for RIPE 51. If anyone would like to make a presentation or raise a topic for discussion please contact either Kurtis or myself and we'll arrange a slot on the agenda. Thanks, -bijal From ops at ripe.net Thu Sep 29 10:30:40 2005 From: ops at ripe.net (RIPE NCC Operations) Date: Thu, 29 Sep 2005 10:30:40 +0200 Subject: [ncc-services-wg] RIPE NCC Service Interruption Message-ID: <200509290830.j8T8UekI004709@birch.ripe.net> [apologies for duplicate mails] Dear Colleagues, >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected disruption to services. Although this may have caused delays to updates to the RIPE Whois Database, these updates have been processed normally. The disruption may have also affected some of these RIPE NCC services: - whois.ripe.net - www.ripe.net - lirportal.ripe.net - ns*.ripe.net - ftp.ripe.net - www.aso.icann.org - www.nro.net - k.root-servers.org (Global node at the AMS-IX) - AS112.ripe.net We apologise for any interruption or delay to services. If you have any questions or concerns regarding this issue, please contact . Regards, RIPE NCC Operations From daniel.karrenberg at ripe.net Fri Sep 30 17:36:40 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 17:36:40 +0200 Subject: [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: <20050930153640.GC479@reifer.karrenberg.net> On 29.09 10:30, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. ... > > The disruption may have also affected some of these RIPE NCC services: > ... > - k.root-servers.org (Global node at the AMS-IX) For the record: According to our monitoring this interruption has not at all affected the K root server. In particular our monitoring has detected no interruption in service and no shifting of traffic to other anycast instances of K. Daniel References: http://k.root-servers.org/stats/ams-ix/index.html http://dnsmon.ripe.net/dns-servmon/server/plot?server=k.root-servers.net&type=drops&tstart=1127887200&tstop=1127901599 From daniel.karrenberg at ripe.net Fri Sep 30 17:36:40 2005 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 30 Sep 2005 17:36:40 +0200 Subject: [ripe.net #121278] [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <200509290830.j8T8UekI004709@birch.ripe.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> Message-ID: <20050930153640.GC479@reifer.karrenberg.net> On 29.09 10:30, RIPE NCC Operations wrote: > [apologies for duplicate mails] > > Dear Colleagues, > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > disruption to services. ... > > The disruption may have also affected some of these RIPE NCC services: > ... > - k.root-servers.org (Global node at the AMS-IX) For the record: According to our monitoring this interruption has not at all affected the K root server. In particular our monitoring has detected no interruption in service and no shifting of traffic to other anycast instances of K. Daniel References: http://k.root-servers.org/stats/ams-ix/index.html http://dnsmon.ripe.net/dns-servmon/server/plot?server=k.root-servers.net&type=drops&tstart=1127887200&tstop=1127901599 From brettcarr at ripe.net Fri Sep 30 22:24:21 2005 From: brettcarr at ripe.net (Brett Carr) Date: Fri, 30 Sep 2005 22:24:21 +0200 (CEST) Subject: [db-wg] Re: [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <20050930153640.GC479@reifer.karrenberg.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> <20050930153640.GC479@reifer.karrenberg.net> Message-ID: On Fri, 30 Sep 2005, Daniel Karrenberg wrote: > > > On 29.09 10:30, RIPE NCC Operations wrote: > > [apologies for duplicate mails] > > > > Dear Colleagues, > > > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > > disruption to services. ... > > > > The disruption may have also affected some of these RIPE NCC services: > > ... > > - k.root-servers.org (Global node at the AMS-IX) > > For the record: > > According to our monitoring this interruption has not at all affected > the K root server. In particular our monitoring has detected no > interruption in service and no shifting of traffic to other anycast > instances of K. Yes indeed the problem briefly affected the website k.root-servers.org but not the global K-root at amsix as they sit behind different routers. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 From brettcarr at ripe.net Fri Sep 30 22:24:21 2005 From: brettcarr at ripe.net (Brett Carr) Date: Fri, 30 Sep 2005 22:24:21 +0200 (CEST) Subject: [ripe.net #121288] [db-wg] [ncc-services-wg] RIPE NCC Service Interruption In-Reply-To: <20050930153640.GC479@reifer.karrenberg.net> References: <200509290830.j8T8UekI004709@birch.ripe.net> <20050930153640.GC479@reifer.karrenberg.net> Message-ID: On Fri, 30 Sep 2005, Daniel Karrenberg wrote: > > > On 29.09 10:30, RIPE NCC Operations wrote: > > [apologies for duplicate mails] > > > > Dear Colleagues, > > > > >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected > > disruption to services. ... > > > > The disruption may have also affected some of these RIPE NCC services: > > ... > > - k.root-servers.org (Global node at the AMS-IX) > > For the record: > > According to our monitoring this interruption has not at all affected > the K root server. In particular our monitoring has detected no > interruption in service and no shifting of traffic to other anycast > instances of K. Yes indeed the problem briefly affected the website k.root-servers.org but not the global K-root at amsix as they sit behind different routers. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8