From pierre at baume.org Fri Mar 1 11:51:03 2002 From: pierre at baume.org (Pierre Baume) Date: Fri, 1 Mar 2002 11:51:03 +0100 (CET) Subject: AS numbers an IP space salvage. In-Reply-To: <0b6601c1c070$72b502a0$2e04bf3e@eu.frd.uu.net> Message-ID: Dear all, During last RIPE meeting, I don't remember seeing statistics about how many AS numbers or what volume of IP space are being reclaimed from LIRs. Maybe it would be a good idea to include such numbers in the next Registration Services Report... Pierre. From sabrina at ripe.net Fri Mar 1 12:30:53 2002 From: sabrina at ripe.net (Sabrina Wilmot) Date: Fri, 01 Mar 2002 12:30:53 +0100 Subject: Do not remember this In-Reply-To: Message from "Stephen Burley" of "Thu, 28 Feb 2002 12:11:57 GMT." <0a4d01c1c051$1e23a120$2e04bf3e@eu.frd.uu.net> Message-ID: <200203011131.g21BVAv24744@birch.ripe.net> Some time ago the RIPE NCC introduced a system through which LIRs could inform the RIPE NCC of changes to their LIR contacts by updating their role object. Adding the attribute [notify: hm-dbm-msgs at ripe.net] within their role object meant that whenever this role object was updated the RIPE NCC would get a RIPE database notification message and update the internal record for your Local Internet Registry contacts based on the tech-c or admin-c changes made within the role object. This system was introduced because at that time the only way LIRs were able to inform the RIPE NCC of changes to their Local Internet Registry contacts was through the mailbox. Nowadays LIRs can notify the RIPE NCC of changes through the mailbox which is ticketised and thus all emails are archived. Using the 'notify' system within a role object for LIR contact changes proved to be very time consuming, impractical and above all not very reliable for several reasons: - The same role object was sometimes updated 3 times a week: adding a contact one day, removing it the next day and adding it again 12 hours later. The intention of changing LIR contacts so frequently is questionable. - Role objects were referring to other role objects with or without the notify attribute pointing to the RIPE NCC. Verification of the requested changes was difficult. - Some LIRs did not realise that if they removed a contact from their role object, this contact would no longer be able to submit request forms to the RIPE NCC. Implications of changes to the role object were often not realised by the LIRs and produced misunderstandings. Information about this purely operational change to the procedure of changing LIR contacts was only sent to those LIRs who had a notify attribute pointing to in their role object(s). Apologies for the lack of explanation in that message. Using the mailbox proved to be a much more consistent, reliable and efficient way of changing confidential contact information. Regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o "Stephen Burley" writes: * Hi * I am a little concerned with the email we recieved today (copied below * in part). This was sent to the community and enforced without any reason why * or justification or even a dicussion as the the change in working practice. * As the NCC work for the benefit of the RIPE community i would have thought * this sort of change in working practice would have to be agreed with the * community before the announcment went out. I may have missed the discussion * on the list and if so i am sorry but i still would think it manners to * explain why. I for one found this functionality very useful. * * Regards, * Stephen Burley * UUNET EMEA Hostmaster * SB855-ripe * * * [PLEASE FORWARD THIS TO YOUR LOCAL INTERNET REGISTRY CONTACT] * * Dear Colleague, * * This email is to inform you that the RIPE NCC no longer updates * its internal record for your Local Internet Registry contacts * based on the tech-c or admin-c changes you make within your role * object. Therefore we ask you to remove the line * 'notify: hm-dbm-msgs at ripe.net' from your role object: * * * From stephenb at uk.uu.net Mon Mar 4 13:02:28 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 4 Mar 2002 12:02:28 -0000 Subject: Do not remember this References: <200203011131.g21BVAv24744@birch.ripe.net> Message-ID: <0dbe01c1c374$751ea5d0$2e04bf3e@eu.frd.uu.net> Thankyou for your explanation. I see the same old problem with this process as with the usages reports when requesting more space. That problem is the NCC are trying to do too much and not handing enough responsability to us the LIR usrers/managers. Looking at it objectivly we the mangers of the LIR's should be the ones who know who is a VPC (valid point of contact) within the LIR so it seems pointless that the NCC have to manage the list of VPC for your LIR. What i see as the best solution is to create an automated system which we can manage so you have a valid list of our VPC's, instead of adding yet another ticketed system which you the NCC have to spend time and money (our money) on upkeeping. Besides which it would be much faster. Moving it to another mail ticketing is not removing the problem just giving a record of the problems but putting the responsability back in our hands removes the problem for you and improves the service all round. > > Some time ago the RIPE NCC introduced a system through which LIRs could inform > the RIPE NCC of changes to their LIR contacts by updating their role object. > > Adding the attribute [notify: hm-dbm-msgs at ripe.net] within their role object > meant that whenever this role object was updated the RIPE NCC would get a RIPE > database notification message and update the internal record for your Local > Internet Registry contacts based on the tech-c or admin-c changes made > within the role object. > > This system was introduced because at that time the only way LIRs were able to > inform the RIPE NCC of changes to their Local Internet Registry contacts was > through the mailbox. > > Nowadays LIRs can notify the RIPE NCC of changes through the > mailbox which is ticketised and thus all emails are > archived. > > Using the 'notify' system within a role object for LIR contact changes proved > to be very time consuming, impractical and above all not very reliable for > several reasons: > > - The same role object was sometimes updated 3 times a week: adding a contact > one day, removing it the next day and adding it again 12 hours later. The > intention of changing LIR contacts so frequently is questionable. > > - Role objects were referring to other role objects with or without the notify > attribute pointing to the RIPE NCC. Verification of the requested changes was > difficult. > > - Some LIRs did not realise that if they removed a contact from their role > object, this contact would no longer be able to submit request forms to the > RIPE NCC. Implications of changes to the role object were often not realised > by the LIRs and produced misunderstandings. > > > Information about this purely operational change to the procedure of changing > LIR contacts was only sent to those LIRs who had a notify attribute pointing > to in their role object(s). Apologies for the lack of > explanation in that message. > > Using the mailbox proved to be a much more consistent, > reliable and efficient way of changing confidential contact information. > > > Regards, > > Sabrina Wilmot > > -- > > o------------------------------------------o > | Sabrina Wilmot sabrina at ripe.net | > | Registration Services Operations Manager | > | | > | RIPE NCC tel +31 20 535 4444 | > | www.ripe.net fax +31 20 535 4445 | > o------------------------------------------o > > "Stephen Burley" writes: > * Hi > * I am a little concerned with the email we recieved today (copied below > * in part). This was sent to the community and enforced without any reason why > * or justification or even a dicussion as the the change in working practice. > * As the NCC work for the benefit of the RIPE community i would have thought > * this sort of change in working practice would have to be agreed with the > * community before the announcment went out. I may have missed the discussion > * on the list and if so i am sorry but i still would think it manners to > * explain why. I for one found this functionality very useful. > * > * Regards, > * Stephen Burley > * UUNET EMEA Hostmaster > * SB855-ripe > * > * > * [PLEASE FORWARD THIS TO YOUR LOCAL INTERNET REGISTRY CONTACT] > * > * Dear Colleague, > * > * This email is to inform you that the RIPE NCC no longer updates > * its internal record for your Local Internet Registry contacts > * based on the tech-c or admin-c changes you make within your role > * object. Therefore we ask you to remove the line > * 'notify: hm-dbm-msgs at ripe.net' from your role object: > * > * > * > > From alfredo at intelideas.com Mon Mar 4 16:52:06 2002 From: alfredo at intelideas.com (Alfredo Sola) Date: Mon, 04 Mar 2002 16:52:06 +0100 Subject: Do not remember this References: <200203011131.g21BVAv24744@birch.ripe.net> <0dbe01c1c374$751ea5d0$2e04bf3e@eu.frd.uu.net> Message-ID: <3C839826.E4D2A1FC@intelideas.com> Hi, > as with the usages reports when requesting more space. That problem is the > NCC are trying to do too much and not handing enough responsability to us > the LIR usrers/managers. Looking at it objectivly we the mangers of the > LIR's should be the ones who know who is a VPC (valid point of contact) That is true for your company and many more, but not for all. Take into account that the NCC needs to handle equally cases where everything is properly done and crystal clear and cases where inadequate or misguided management has taken place. Personally speaking, I tend to feel that we, LIR managers, should be allowed to do as much of our job as possible. However, this message is to say that I see at least one reason why Ripe do as they do. -- Alfredo Sola Director tecnico From stephenb at uk.uu.net Mon Mar 4 17:23:11 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 4 Mar 2002 16:23:11 -0000 Subject: Do not remember this References: <200203011131.g21BVAv24744@birch.ripe.net> <0dbe01c1c374$751ea5d0$2e04bf3e@eu.frd.uu.net> <3C839826.E4D2A1FC@intelideas.com> Message-ID: <102001c1c398$e0a660d0$2e04bf3e@eu.frd.uu.net> > > That is true for your company and many more, but not for all. Take into > account that the NCC needs to handle equally cases where everything is > properly done and crystal clear and cases where inadequate or misguided > management has taken place. > > Personally speaking, I tend to feel that we, LIR managers, should be > allowed to do as much of our job as possible. However, this message is > to say that I see at least one reason why Ripe do as they do. > Ok i take your point but then there should atleast be the choice, self managment of the list of VPC's or NCC managment of the list. > -- > Alfredo Sola > Director tecnico From bon at ripn.net Wed Mar 6 11:38:16 2002 From: bon at ripn.net (bon at ripn.net) Date: Wed, 6 Mar 2002 13:38:16 +0300 (MSK) Subject: Do not remember this In-Reply-To: <0dbe01c1c374$751ea5d0$2e04bf3e@eu.frd.uu.net> Message-ID: On Mon, 4 Mar 2002, Stephen Burley wrote: Hi, there we'do support this suggestion, managers of the LIRs should have opportunity to update regid info without contacting NCC, however inner database surely must be managed by NCC staff themself. Trying to resolve this contradiction it would be reasonable to discuss *regid* database object. I mean short/public version of regid file (regid, descr, lir-contact and smth. else), it may be protected by LIR and NCC maintainers, NCC will act accordingly having received update notification from database while LIR'll send (very occasionally) serious updates to lir-help box. Oleg > > Thankyou for your explanation. I see the same old problem with this process > as with the usages reports when requesting more space. That problem is the > NCC are trying to do too much and not handing enough responsability to us > the LIR usrers/managers. Looking at it objectivly we the mangers of the > LIR's should be the ones who know who is a VPC (valid point of contact) > within the LIR so it seems pointless that the NCC have to manage the list of > VPC for your LIR. What i see as the best solution is to create an automated > system which we can manage so you have a valid list of our VPC's, instead of > adding yet another ticketed system which you the NCC have to spend time and > money (our money) on upkeeping. Besides which it would be much faster. > Moving it to another mail ticketing is not removing the problem just giving > a record of the problems but putting the responsability back in our hands > removes the problem for you and improves the service all round. > > > > Some time ago the RIPE NCC introduced a system through which LIRs could > inform > > the RIPE NCC of changes to their LIR contacts by updating their role > object. > > > > Adding the attribute [notify: hm-dbm-msgs at ripe.net] within their role > object > > meant that whenever this role object was updated the RIPE NCC would get a > RIPE > > database notification message and update the internal record for your > Local > > Internet Registry contacts based on the tech-c or admin-c changes made > > within the role object. > > > > This system was introduced because at that time the only way LIRs were > able to > > inform the RIPE NCC of changes to their Local Internet Registry contacts > was > > through the mailbox. > > > > Nowadays LIRs can notify the RIPE NCC of changes through the > > mailbox which is ticketised and thus all emails are > > archived. > > > > Using the 'notify' system within a role object for LIR contact changes > proved > > to be very time consuming, impractical and above all not very reliable for > > several reasons: > > > > - The same role object was sometimes updated 3 times a week: adding a > contact > > one day, removing it the next day and adding it again 12 hours later. The > > intention of changing LIR contacts so frequently is questionable. > > > > - Role objects were referring to other role objects with or without the > notify > > attribute pointing to the RIPE NCC. Verification of the requested changes > was > > difficult. > > > > - Some LIRs did not realise that if they removed a contact from their role > > object, this contact would no longer be able to submit request forms to > the > > RIPE NCC. Implications of changes to the role object were often not > realised > > by the LIRs and produced misunderstandings. > > > > > > Information about this purely operational change to the procedure of > changing > > LIR contacts was only sent to those LIRs who had a notify attribute > pointing > > to in their role object(s). Apologies for the lack > of > > explanation in that message. > > > > Using the mailbox proved to be a much more consistent, > > reliable and efficient way of changing confidential contact information. > > > > > > Regards, > > > > Sabrina Wilmot > > > > -- > > > > o------------------------------------------o > > | Sabrina Wilmot sabrina at ripe.net | > > | Registration Services Operations Manager | > > | | > > | RIPE NCC tel +31 20 535 4444 | > > | www.ripe.net fax +31 20 535 4445 | > > o------------------------------------------o > > > > "Stephen Burley" writes: > > * Hi > > * I am a little concerned with the email we recieved today (copied > below > > * in part). This was sent to the community and enforced without any > reason why > > * or justification or even a dicussion as the the change in working > practice. > > * As the NCC work for the benefit of the RIPE community i would have > thought > > * this sort of change in working practice would have to be agreed with > the > > * community before the announcment went out. I may have missed the > discussion > > * on the list and if so i am sorry but i still would think it manners to > > * explain why. I for one found this functionality very useful. > > * > > * Regards, > > * Stephen Burley > > * UUNET EMEA Hostmaster > > * SB855-ripe > > * > > * > > * [PLEASE FORWARD THIS TO YOUR LOCAL INTERNET REGISTRY CONTACT] > > * > > * Dear Colleague, > > * > > * This email is to inform you that the RIPE NCC no longer updates > > * its internal record for your Local Internet Registry contacts > > * based on the tech-c or admin-c changes you make within your role > > * object. Therefore we ask you to remove the line > > * 'notify: hm-dbm-msgs at ripe.net' from your role object: > > * > > * > > * > > > > > With respect, --- RIPN Registry center ----- From marck at rinet.ru Wed Mar 6 13:49:25 2002 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed, 6 Mar 2002 15:49:25 +0300 (MSK) Subject: Do not remember this In-Reply-To: Message-ID: <20020306154543.Q67935-100000@woozle.rinet.ru> Colleagues, On Wed, 6 Mar 2002 bon at ripn.net wrote: > we'do support this suggestion, managers of the LIRs should have > opportunity to update regid info without contacting NCC, however > inner database surely must be managed by NCC staff themself. > Trying to resolve this contradiction it would be reasonable to discuss > *regid* database object. I mean short/public version of regid file > (regid, descr, lir-contact and smth. else), it may be protected > by LIR and NCC maintainers, NCC will act accordingly having received > update notification from database while LIR'll send (very occasionally) > serious updates to lir-help box. We've got very interesting point here. I'm afraid this, earlier or later, leads us to the main point which RIPE NCC wants (or at least seems to want) to avoid: public and private parts of the Database. Although it would be very useful to hide some valuable info from anyone except the maintainer, the process of both defining such data and managing it should be made very clear and, of course, agreed by the community. Perhaps now is the time to widely discuss it? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From hph at online.no Wed Mar 6 20:18:47 2002 From: hph at online.no (Hans Petter Holen) Date: Wed, 6 Mar 2002 20:18:47 +0100 Subject: Do not remember this References: <20020306154543.Q67935-100000@woozle.rinet.ru> Message-ID: <00a301c1c543$be492570$8000a8c0@cq> I agree with the point that we should try to automate as much as possible and move the updating of the LIR contact info from manual hostmaster work to some ineractive tool to be used by the LIR management. I was in the beginning very much in favour of the feature now removed where I could update my LIR contact information by updating my role object. I have however changed my mind on this and do see the need for a RIPE NCC Internal list with a list of the staff I have autorized to act on our behalf which may include more persons than I want to advertize to the whole world. (Maybe I just want to list our NOC as the only tech-c responsible without attaching any names to it. So my suggestion to this would be for the RIPE NCC to develop some Interactive web based tool where LIRs can view and update RIPE NCC internal contact file perhaps modelled after the APNIC solution with a secure web site for this. -hph From joao at ripe.net Thu Mar 7 03:37:27 2002 From: joao at ripe.net (Joao Luis Silva Damas) Date: Thu, 7 Mar 2002 03:37:27 +0100 Subject: Do not remember this In-Reply-To: <00a301c1c543$be492570$8000a8c0@cq> References: <20020306154543.Q67935-100000@woozle.rinet.ru> <00a301c1c543$be492570$8000a8c0@cq> Message-ID: Dear all, At 20:18 +0100 6/3/02, Hans Petter Holen wrote: > >So my suggestion to this would be for the RIPE NCC to develop some >Interactive web based tool where LIRs can view and update RIPE NCC internal >contact file perhaps modelled after the APNIC solution with a secure web >site for this. This is indeed what we are intending to do: provide the RIPE NCC membership with ways of accessing and modifying their own data using currently avaiable technologies such as a secure web site and any other appropriate means that LIRs may find interesting and are feasible to deploy taking into consideration security, privacy and efficiency, to name a few. I hope to be able to present our current thoughts on the matter during the next RIPE meeting. We would like to start by providing facilities to update contact information as this is a clear and present source of workload for both the LIRs and the RIPE NCC hostmasters. Further developments include implementations recommendations of the May 17 taskforce and facilities built on the internal and external databases of the RIPE NCC. I would also like to add that as preparation for the roll-out of such a service we have recently started adapting our internal databases to allow the display and modification of information in a safe way. Best regards, Joao Damas RIPE NCC -- From ula at ripn.net Thu Mar 7 10:39:49 2002 From: ula at ripn.net (Larisa A. Yurkina) Date: Thu, 7 Mar 2002 12:39:49 +0300 (MSK) Subject: Do not remember this In-Reply-To: Message-ID: On Thu, 7 Mar 2002, Joao Luis Silva Damas wrote: Hi everybody, > Dear all, > > At 20:18 +0100 6/3/02, Hans Petter Holen wrote: > > > >So my suggestion to this would be for the RIPE NCC to develop some > >Interactive web based tool where LIRs can view and update RIPE NCC internal > >contact file perhaps modelled after the APNIC solution with a secure web > >site for this. > > This is indeed what we are intending to do: provide the RIPE NCC > membership with ways of accessing and modifying their own data using > currently avaiable technologies such as a secure web site and any > other appropriate means that LIRs may find interesting and are > feasible to deploy taking into consideration security, privacy and > efficiency, to name a few. > i think a secure web site is a very good idea. But, let's look at first, which inform is really secret in the regid file. I only find one: bill-scheme. Everything else could be published very well. Or perhaps someone could find more? > I hope to be able to present our current thoughts on the matter > during the next RIPE meeting. We would like to start by providing > facilities to update contact information as this is a clear and > present source of workload for both the LIRs and the RIPE NCC > hostmasters. Further developments include implementations > recommendations of the May 17 taskforce and facilities built on the > internal and external databases of the RIPE NCC. > > I would also like to add that as preparation for the roll-out of such > a service we have recently started adapting our internal databases to > allow the display and modification of information in a safe way. > > Best regards, > Joao Damas > RIPE NCC > -- > With respect, Larisa Yurkina --- RIPN Registry center ----- From carsten at ripe.net Thu Mar 7 19:34:34 2002 From: carsten at ripe.net (Carsten Schiefner) Date: Thu, 07 Mar 2002 19:34:34 +0100 Subject: Do not remember this References: Message-ID: <3C87B2BA.FD811ACC@ripe.net> Dear Larisa, "Larisa A. Yurkina" wrote: > i think a secure web site is a very good idea. But, let's look at > first, which inform is really secret in the regid file. I only find > one: bill-scheme. Everything else could be published very well. > Or perhaps someone could find more? I believe that not every LIR is willing to reveal the names, phone numbers, email addresses etc. to head hunters, for example. Cheers, Carsten From ula at ripn.net Mon Mar 11 11:58:31 2002 From: ula at ripn.net (Larisa A. Yurkina) Date: Mon, 11 Mar 2002 13:58:31 +0300 (MSK) Subject: Do not remember this In-Reply-To: <3C87B2BA.FD811ACC@ripe.net> Message-ID: On Thu, 7 Mar 2002, Carsten Schiefner wrote: Dear Carsten, > Dear Larisa, > > "Larisa A. Yurkina" wrote: > > i think a secure web site is a very good idea. But, let's look at > > first, which inform is really secret in the regid file. I only find > > one: bill-scheme. Everything else could be published very well. > > Or perhaps someone could find more? > > I believe that not every LIR is willing to reveal the names, phone > numbers, email addresses etc. to head hunters, for example. each person listed in the registry file has nic-hdl in the ripe database, with his or her name, address etc. I think, the list only includes persons authorized to act as lir contacts. If they do act, they are known by their nic-hdls. If they do not act, why list them? Some additional object containing lir data in the ripe db could only make head hunters's life easier, but not very much. Thank you. > > Cheers, > > Carsten > > With respect, Larisa Yurkina --- RIPN Registry center ----- From stephenb at uk.uu.net Mon Mar 11 12:47:50 2002 From: stephenb at uk.uu.net (Stephen Burley) Date: Mon, 11 Mar 2002 11:47:50 -0000 Subject: Quick question Message-ID: <183201c1c8f2$925947d0$2e04bf3e@eu.frd.uu.net> Hi The auto dbm system seems to be very slow again is there any particular reason for this? Is someone constnatly trawling the DB? Just wondering? Regards, Stephen Burley UUNET EMEA Hostmaster From andrei at ripe.net Mon Mar 11 17:31:47 2002 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 11 Mar 2002 17:31:47 +0100 Subject: Quick question References: <183201c1c8f2$925947d0$2e04bf3e@eu.frd.uu.net> Message-ID: <3C8CDBF3.4050701@ripe.net> Dear Stephen, Stephen Burley wrote: > Hi > The auto dbm system seems to be very slow again is there any particular > reason for this? Is someone constnatly trawling the DB? Just wondering? > > Regards, > Stephen Burley > UUNET EMEA Hostmaster > In fact we experienced some problems with processing updates, but that happened 2 hours after you reported this. Could you please send some more detailed information about delayed updates to ripe-dbm at ripe.net? Regarding the problem with updates I mentioned above, you may experience 1-2 hour delay for updates sent after 14:00 UTC. Now the service seems to be back to normal. Sorry for the inconvenience, Regards, Andrei Robachevsky DB Group Manager RIPE NCC From Tanja.Heimes at ecrc.de Thu Mar 14 11:42:45 2002 From: Tanja.Heimes at ecrc.de (Tanja Heimes) Date: Thu, 14 Mar 2002 11:42:45 +0100 Subject: more authority for mnt-lower in the allocation objects Message-ID: <3C907EA5.9D1EB314@ecrc.de> Hi Lir-WG, this is a hostmasters argument upon my question why I am not able to change the contacts and mnt-routes in my own allocation by myself. I am interested if somebody else is sharing my opinion. Hostmasters argument: "It is not possible for you to update an allocation object because RIPE NCC is the maintainer of these objects, which makes sense. :)" This is my opinion: Yes, it makes sence that RIPE NCC is the maintainer of a LIRs allocation. But in my opinion it makes NO sence that Cable and Wireles (and all other LIRs) as mnt-lower do not have the authority to change their own administrative and technical contacts in the allocation. There must be an restricted authority for a mnt-lower to change things like that by their own. I think especially about following attributes: (marked with +++) inetnum: 62.208.0.0 - 62.208.255.255 netname: DE-ECRC-970502 descr: ECRC GmbH country: DE +++++admin-c: EN65-RIPE +++++tech-c: EN65-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: CW-EUROPE-GSOC +++++mnt-routes: CW-EUROPE-GSOC changed: hostmaster at ripe.net 20010814 source: RIPE In my opiniom it makes no sence that for a very simple change in the allocation, that does actually not affect the allocation itself we have to send requests to the hostmasters and wait sometimes weeks for their handling. I think that persons that stand behind the respective reg-id should have this authority. Best regards, Tanja Heimes -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From av at nethead.de Thu Mar 14 12:10:37 2002 From: av at nethead.de (Arnd Vehling) Date: Thu, 14 Mar 2002 12:10:37 +0100 Subject: more authority for mnt-lower in the allocation objects References: <3C907EA5.9D1EB314@ecrc.de> Message-ID: <3C90852D.17A780D3@nethead.de> Hi, Tanja Heimes wrote: [..] > This is my opinion: > Yes, it makes sence that RIPE NCC is the maintainer of a LIRs > allocation. > But in my opinion it makes NO sence that Cable and Wireles (and all > other LIRs) as mnt-lower > do not have the authority to change their own administrative and > technical contacts in the allocation. IMO this is correct. The LIR should be able to modify this information without needing to write to hostmaster at ripe.net (which may take some time depending on how busy the hostmaster team is). admin-c, tech-c, mnt-lower and mnt-routes within an allocation should be changeable by the LIR itself. I know this is difficult to accomplish while "mnt-by:" points to an ripe-maintainer. But as far as i know RIPE has a second database where all allocations are stored for cross-checlking. Therefore we could take an approach where the allocation may only be created by RIPE but may be updated by the according LIR. This can simply be accomplished by removing the RIPE-Maintainer from the object after creation and change it to the according maintainer of the LIR. regards, Arnd Vehling -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212 From Karsten.Koepp at lambdanet.net Thu Mar 14 14:37:36 2002 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 14 Mar 2002 14:37:36 +0100 Subject: more authority for mnt-lower in the allocation objects Message-ID: <39F27E3F569FD4119EF200508BAF85B90268D49E@CCGNT30> Hi I fully support Tanja's and Arnd's proposal. Several people (myself as well) had already requested some improvements on the mnt-routes problem, because it is a frequent problem for network operators. The proposed change should be very easy for inetnums with existing mnt-lower object, such a change was already done to include mnt-routes. But I imagine manual updates would be necessary for inet-nums with "mnt-by: RIPE-NCC-HM-MNT". Dear hostmasters, can we see figures on how many allocation objects exist of either sort? Regards Karsten Koepp > -----Original Message----- > From: Arnd Vehling [mailto:av at nethead.de] > Sent: Thursday, March 14, 2002 12:11 PM > To: Tanja Heimes > Cc: lir-wg at ripe.net > Subject: Re: more authority for mnt-lower in the allocation objects > > > Hi, > > Tanja Heimes wrote: > [..] > > This is my opinion: > > Yes, it makes sence that RIPE NCC is the maintainer of a LIRs > > allocation. > > But in my opinion it makes NO sence that Cable and Wireles (and all > > other LIRs) as mnt-lower > > do not have the authority to change their own administrative and > > technical contacts in the allocation. > > IMO this is correct. The LIR should be able to modify this information > without needing to write to hostmaster at ripe.net (which may take some > time depending on how busy the hostmaster team is). > > admin-c, tech-c, mnt-lower and mnt-routes within an > allocation should be > changeable by the LIR itself. > > I know this is difficult to accomplish while "mnt-by:" points to > an ripe-maintainer. But as far as i know RIPE has a second database > where all allocations are stored for cross-checlking. > Therefore we could > take an approach where the allocation may only be created by RIPE but > may be updated by the according LIR. This can simply be > accomplished by > removing the RIPE-Maintainer from the object after creation > and change it > to the according maintainer of the LIR. > > regards, > > Arnd Vehling > -- > > NetHead Network Design and Security > Arnd Vehling av at nethead.De > Gummersbacherstr. 27 Phone: +49 221 8809210 > 50679 Cologne, Germany Fax : +49 221 8809212 > From bon at ripn.net Thu Mar 14 15:23:27 2002 From: bon at ripn.net (bon at ripn.net) Date: Thu, 14 Mar 2002 17:23:27 +0300 (MSK) Subject: more authority for mnt-lower in the allocation objects In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90268D49E@CCGNT30> Message-ID: On Thu, 14 Mar 2002, Koepp, Karsten wrote: > > Hi > > I fully support Tanja's and Arnd's proposal. > Several people (myself as well) had already requested some improvements > on the mnt-routes problem, because it is a frequent problem for network > operators. agree > > The proposed change should be very easy for inetnums with existing > mnt-lower object, such a change was already done to include mnt-routes. > But I imagine manual updates would be necessary for inet-nums with > "mnt-by: RIPE-NCC-HM-MNT". > why ? do you think NCC couldn't allow updating allocations by adding LIR's maintainer ? in case of problems with billing NCC will simply remove (or comment) LIR's mnt-by, and probably mnt-by: RIPE-NCC-HM-MNT could get status of mandatory,unchagable attribute for allocation inetnum objects. > Dear hostmasters, can we see figures on how many allocation objects exist > of either sort? > > Regards > Karsten Koepp > > > -----Original Message----- > > From: Arnd Vehling [mailto:av at nethead.de] > > Sent: Thursday, March 14, 2002 12:11 PM > > To: Tanja Heimes > > Cc: lir-wg at ripe.net > > Subject: Re: more authority for mnt-lower in the allocation objects > > > > > > Hi, > > > > Tanja Heimes wrote: > > [..] > > > This is my opinion: > > > Yes, it makes sence that RIPE NCC is the maintainer of a LIRs > > > allocation. > > > But in my opinion it makes NO sence that Cable and Wireles (and all > > > other LIRs) as mnt-lower > > > do not have the authority to change their own administrative and > > > technical contacts in the allocation. > > > > IMO this is correct. The LIR should be able to modify this information > > without needing to write to hostmaster at ripe.net (which may take some > > time depending on how busy the hostmaster team is). > > > > admin-c, tech-c, mnt-lower and mnt-routes within an > > allocation should be > > changeable by the LIR itself. > > > > I know this is difficult to accomplish while "mnt-by:" points to > > an ripe-maintainer. But as far as i know RIPE has a second database > > where all allocations are stored for cross-checlking. > > Therefore we could > > take an approach where the allocation may only be created by RIPE but > > may be updated by the according LIR. This can simply be > > accomplished by > > removing the RIPE-Maintainer from the object after creation > > and change it > > to the according maintainer of the LIR. > > > > regards, > > > > Arnd Vehling > > -- > > > > NetHead Network Design and Security > > Arnd Vehling av at nethead.De > > Gummersbacherstr. 27 Phone: +49 221 8809210 > > 50679 Cologne, Germany Fax : +49 221 8809212 > > > With respect, --- RIPN Registry center ----- From leo at ripe.net Thu Mar 14 16:49:37 2002 From: leo at ripe.net (leo vegoda) Date: Thu, 14 Mar 2002 16:49:37 +0100 Subject: more authority for mnt-lower in the allocation objects In-Reply-To: <3C907EA5.9D1EB314@ecrc.de> References: <3C907EA5.9D1EB314@ecrc.de> Message-ID: <20020314154936.GA14735@ripe.net> Tanya, The RIPE NCC maintains all the allocations it makes as it is responsible for them. We expect most LIRs will want to maintain all their assignments for the same reason. We agree that it is desirable for LIRs to be able to control the contact information in their allocation inetnum objects as well as the mainatiners used for hierarchical authorisation. As Joao wrote a few days ago, we want to provide the RIPE NCC membership with ways of accessing and modifying their own data using currently avaiable technologies such as a secure web site. These systems are being developed at the moment. As Karsten points out, there is no easy way to add mnt-routes attributes to inetnum objects for allocations where the LIR's maintainer is not already referenced as a mnt-lower. Of course, where LIRs already have role objects referenced they can update the contacts in the role and have no need to contact RIPE NCC. The new systems we are developing are one way we intend to reduce the workload carried out by the Registration Services department and to help provide a speedier service to our customers. Regards, -- leo vegoda RIPE NCC From Tanja.Heimes at ecrc.de Thu Mar 14 17:13:02 2002 From: Tanja.Heimes at ecrc.de (Tanja Heimes) Date: Thu, 14 Mar 2002 17:13:02 +0100 Subject: more authority for mnt-lower in the allocation objects References: Message-ID: <3C90CC0E.CBD18204@ecrc.de> Hi, am sure that once I have seen an allocation object where both mnt-by have been set - the RIPE NCCs one and the LIRs one. It may be that this has been a mistake in that object but would'nt this solve the problem? For more security only people that know the LIRs password and are a reg-id contact are able to make changements in the allocation. May be in the reg-id there could be set an "alloc-c" that has the authority for this specific updates in the allocation objects contrary to the other contacts that will not have this authority. Tanja bon at ripn.net wrote: > > On Thu, 14 Mar 2002, Koepp, Karsten wrote: > > > > > Hi > > > > I fully support Tanja's and Arnd's proposal. > > Several people (myself as well) had already requested some improvements > > on the mnt-routes problem, because it is a frequent problem for network > > operators. > > agree > > > > > The proposed change should be very easy for inetnums with existing > > mnt-lower object, such a change was already done to include mnt-routes. > > But I imagine manual updates would be necessary for inet-nums with > > "mnt-by: RIPE-NCC-HM-MNT". > > > > why ? do you think NCC couldn't allow updating allocations by > adding LIR's maintainer ? in case of problems with billing NCC will > simply remove (or comment) LIR's mnt-by, > and probably mnt-by: RIPE-NCC-HM-MNT could get status of mandatory,unchagable > attribute for allocation inetnum objects. > > > Dear hostmasters, can we see figures on how many allocation objects exist > > of either sort? > > > > Regards > > Karsten Koepp > > > > > -----Original Message----- > > > From: Arnd Vehling [mailto:av at nethead.de] > > > Sent: Thursday, March 14, 2002 12:11 PM > > > To: Tanja Heimes > > > Cc: lir-wg at ripe.net > > > Subject: Re: more authority for mnt-lower in the allocation objects > > > > > > > > > Hi, > > > > > > Tanja Heimes wrote: > > > [..] > > > > This is my opinion: > > > > Yes, it makes sence that RIPE NCC is the maintainer of a LIRs > > > > allocation. > > > > But in my opinion it makes NO sence that Cable and Wireles (and all > > > > other LIRs) as mnt-lower > > > > do not have the authority to change their own administrative and > > > > technical contacts in the allocation. > > > > > > IMO this is correct. The LIR should be able to modify this information > > > without needing to write to hostmaster at ripe.net (which may take some > > > time depending on how busy the hostmaster team is). > > > > > > admin-c, tech-c, mnt-lower and mnt-routes within an > > > allocation should be > > > changeable by the LIR itself. > > > > > > I know this is difficult to accomplish while "mnt-by:" points to > > > an ripe-maintainer. But as far as i know RIPE has a second database > > > where all allocations are stored for cross-checlking. > > > Therefore we could > > > take an approach where the allocation may only be created by RIPE but > > > may be updated by the according LIR. This can simply be > > > accomplished by > > > removing the RIPE-Maintainer from the object after creation > > > and change it > > > to the according maintainer of the LIR. > > > > > > regards, > > > > > > Arnd Vehling > > > -- > > > > > > NetHead Network Design and Security > > > Arnd Vehling av at nethead.De > > > Gummersbacherstr. 27 Phone: +49 221 8809210 > > > 50679 Cologne, Germany Fax : +49 221 8809212 > > > > > > > With respect, > --- > RIPN Registry center > ----- -- Tanja Heimes / IP Administrator E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From Tanja.Heimes at ecrc.de Thu Mar 14 17:21:35 2002 From: Tanja.Heimes at ecrc.de (Tanja Heimes) Date: Thu, 14 Mar 2002 17:21:35 +0100 Subject: more authority for mnt-lower in the allocation objects References: <3C907EA5.9D1EB314@ecrc.de> <20020314154936.GA14735@ripe.net> Message-ID: <3C90CE0F.A5B8DA25@ecrc.de> Hi Leo, good that RIPE is aware of this problem. in concern: Of course, where LIRs already have role objects referenced they > can update the contacts in the role and have no need to contact > RIPE NCC. In our case we have a old role object that is not in use anymore EN65-RIPE and I want to change it to the new one. For that in this situation I have to contact the hostmasters. The same I have to do with all other allocations of aquired ISPs. In much of them I am already a reg-id contact in our maintainer is stated in the objetcs. In all this allocations I have to change to contacts/roles. An update of the contacts/roles in this cases is not relevant but an completely exchange to a new one. Tanja leo vegoda wrote: > > Tanya, > > The RIPE NCC maintains all the allocations it makes as it is > responsible for them. We expect most LIRs will want to maintain > all their assignments for the same reason. > > We agree that it is desirable for LIRs to be able to control the > contact information in their allocation inetnum objects as well > as the mainatiners used for hierarchical authorisation. As Joao > wrote a few days ago, we want to provide the RIPE NCC membership > with ways of accessing and modifying their own data using currently > avaiable technologies such as a secure web site. These systems are > being developed at the moment. > > As Karsten points out, there is no easy way to add mnt-routes > attributes to inetnum objects for allocations where the LIR's > maintainer is not already referenced as a mnt-lower. > > Of course, where LIRs already have role objects referenced they > can update the contacts in the role and have no need to contact > RIPE NCC. > > The new systems we are developing are one way we intend to reduce > the workload carried out by the Registration Services department > and to help provide a speedier service to our customers. > > Regards, > > -- > leo vegoda > RIPE NCC -- Tanja Heimes / IP Administrator E-Mail Tanja.Heimes at de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de From av at nethead.de Fri Mar 15 08:48:53 2002 From: av at nethead.de (Arnd Vehling) Date: Fri, 15 Mar 2002 08:48:53 +0100 Subject: more authority for mnt-lower in the allocation objects References: <3C907EA5.9D1EB314@ecrc.de> <20020314154936.GA14735@ripe.net> Message-ID: <3C91A765.3C02182F@nethead.de> Hello, leo vegoda wrote: > The RIPE NCC maintains all the allocations it makes as it is > responsible for them. You maintain a copy of the allocations within a seperate second db as far as i know?! You can always make cross checks t confirm the allocations are valid. For the RIPE it should be sufficient to be able to create and delete an inetnum object with status = ALLOCATED (i.e. an allocation). The LIRS should be able to change the mentioned attributes like mnt-by, mnt-lower, mnt-routes. The changes to the ripe-software for this are minimal. Therefore i dont see why it shouldnt be possible to commit such a change. best regards, Arnd Vehling -- NetHead Network Design and Security Arnd Vehling av at nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212 From sabrina at ripe.net Fri Mar 15 18:20:49 2002 From: sabrina at ripe.net (Sabrina Wilmot) Date: Fri, 15 Mar 2002 18:20:49 +0100 Subject: more authority for mnt-lower in the allocation objects Message-ID: <200203151721.g2FHL7E21487@birch.ripe.net> For security and consistency reasons the RIPE NCC maintains the inetnum objects describing allocations with all their information. Requests for changes should be submitted to the mailbox. This procedure will continue until the development of accessing and modifying the LIRs own data using currently avaiable technologies such as a secure web site is finished. An LIR might experience delays in the handling of its request when necessary information is not provided to the RIPE NCC. If the reason for changing contact/maintainer information is that an LIR acquires other ISPs/LIRs then there are more RIPE NCC procedures to follow then just requesting a change of contacts in the allocation objects. Kind regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o From av at nethead.de Sat Mar 16 10:24:17 2002 From: av at nethead.de (Arnd Vehling) Date: Sat, 16 Mar 2002 10:24:17 +0100 Subject: more authority for mnt-lower in the allocation objects References: <200203151721.g2FHL7E21487@birch.ripe.net> Message-ID: <3C930F41.491CE1E3@nethead.de> Sabrina Wilmot wrote: > > For security and consistency reasons the RIPE NCC maintains the inetnum > objects describing allocations with all their information. Requests for > changes should be submitted to the mailbox. This procedure > will continue until the development of accessing and modifying the LIRs own > data using currently avaiable technologies such as a secure web site is > finished. Sabrina, instead of just stating current ripe-procedures that we all already know about, and which "we" requested that the may be changed, can you add something constructive to the discussion? best regards, Arnd Vehling