- lir-wg - mailman.ripe.net

RE: more authority for mnt-lower in the allocation objects
by Koepp, Karsten 14 Mar '02

14 Mar '02

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@nethead.de] > Sent: Thursday, March 14, 2002 12:11 PM > To: Tanja Heimes > Cc: lir-wg(a)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(a)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(a)nethead.De > Gummersbacherstr. 27 Phone: +49 221 8809210 > 50679 Cologne, Germany Fax : +49 221 8809212 >

3 2

Quick question
by Stephen Burley 11 Mar '02

11 Mar '02

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

2 1

Re: Do not remember this
by Sabrina Wilmot 11 Mar '02

11 Mar '02

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(a)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 <hostmaster(a)ripe.net> mailbox. Nowadays LIRs can notify the RIPE NCC of changes through the <lir-help(a)ripe.net> 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 <hm-dbm-msgs(a)ripe.net> in their role object(s). Apologies for the lack of explanation in that message. Using the <lir-help(a)ripe.net> 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(a)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" <stephenb(a)uk.uu.net> 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(a)ripe.net' from your role object: * * *

9 10

Re: AS number revokes
by Sabrina Wilmot 01 Mar '02

01 Mar '02

"Stephen Burley" <stephenb(a)uk.uu.net> writes: * Thankyou. Where is this documented? Hi Stephen, Please have a look at document RIPE-185 "European Internet Registry Policies and Procedures, http://www.ripe.net/ripe/docs/ir-policies-procedures.html#toc75 [..] Technical Details Current assignment guidelines require a network to be multihomed for an AS number to be assigned. When a registry applies for an ASN, it needs to submit the routing policy of the Autonomous System that requires an AS number. ... 7.2.Returning an AS Number If an oranisation has an AS number that is no longer in use, it can be returned to the public pool of AS numbers by sending a message to <hostmaster(a)ripe.net>, it can then be re-assigned to another autonomous system by the RIPE NCC. [..] By sending out messages asking if an AS number is in use (multihomed) or not the RIPE NCC makes sure this policy is applied. As mentioned in my previous message if it turns out that an AS number appears not to be in use after being assigned for almost a year (or more) the LIR should consider to return it. Regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o * > Hi, * > * > "Stephen Burley" <stephenb(a)uk.uu.net> writes: * > * Hi * > * I am a bit concerned about an email we recieved threatening the * > * revokation of an assigned AS number if it did not appear to be used. It * > * concerns me for a number of reasons. * > * * > * 1. Our customer has had problems with other providers and there own * network, * > * which has postponed the intended use of the AS for quite a few month, * all * > * due to things out of their and our control. * > * > This can always happen and we do ask several times for information before * > mentioning the option of returning an assigned AS number which appears not * > to be in use. The first time we ask is 6 months after the assignment. * > * > * 2. If you do revoke it then the customer may suddenly get things fixed * and * > * start using the AS as intended but in the meantime you assign it to * another * > * customer and the problems ensue. If you do not assign it why whould you * ask * > * for it back? * > * > If you do not use it why should you keep it? :) * > Our intention is to make sure AS numbers are used and not wasted. * > * > We send several reminders asking about the status and this process is * > taking a couple of months. If you are not able to start using the AS * > number after a long time we ask you to return it. To date the RIPE NCC * > Hostmasters could always find an agreement with the LIRs to return AS * > numbers that appeared not to be in use. * > * > We do reassign returned AS numbers *not* straight away but after a certain * > time period ("sleeping time") and ... * > * > * 3. Just because an AS does not appear in the looking glass does not * mean * > * that its not being used in situation which does not mean it does not * need to * > * be announced at any looking glass. * > * > ... we do not only use the Looiking Glass to find the number of peers. We * look * > back in time at least on several days using 'asiuse' - publicly know as * the * > RIS Database, from New Projects. * > * > * Please could you clarify this situation? * > * * > * Regards * > * Stephen Burley * > * UUNET EMEA Hostmaster * > * SB855-RIPE * > * * > * > * > Regards, * > * > Sabrina Wilmot * > * > -- * > * > o------------------------------------------o * > | Sabrina Wilmot sabrina(a)ripe.net | * > | Registration Services Operations Manager | * > | | * > | RIPE NCC tel +31 20 535 4444 | * > | www.ripe.net fax +31 20 535 4445 | * > o------------------------------------------o * > * > *

5 4

Fwd: Do not remember this
by Katri 28 Feb '02

28 Feb '02

Hello! I partly agree with Stephen. I actually didn´t find the notify to hm-dbm-msgs(a)ripe.net really useful, but it´s not the point. I would also like to know why it was decided by RIPE NCC without first announcing it at the mailinglist. Are you planning other changes that we might want to know about? Regards Katri Tele2/Swipnet IP Registry Local Internet Registry __________________________________________________________ Tele2/SWIPnet Tel: 08 5626 40 08 Box 62 Fax: 08 5626 42 10 164 94 Kista Email: ip(a)swip.net SWIP-RIPE SWIPNET-LIR-MNT __________________________________________________________ >Delivered-To: lists-lir-wg-out(a)lists.ripe.net >From: "Stephen Burley" <stephenb(a)uk.uu.net> >To: <lir-wg(a)ripe.net> >Subject: Do not remember this >Date: Thu, 28 Feb 2002 12:11:57 -0000 >X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >Sender: owner-lir-wg(a)ripe.net >X-Loop-Detect: RIPE NCC > >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(a)ripe.net' from your role object:

1 0

Do not remember this
by Stephen Burley 28 Feb '02

28 Feb '02

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(a)ripe.net' from your role object:

1 0

Re: AS number revokes
by Sabrina Wilmot 28 Feb '02

28 Feb '02

Hi, "Stephen Burley" <stephenb(a)uk.uu.net> writes: * Hi * I am a bit concerned about an email we recieved threatening the * revokation of an assigned AS number if it did not appear to be used. It * concerns me for a number of reasons. * * 1. Our customer has had problems with other providers and there own network, * which has postponed the intended use of the AS for quite a few month, all * due to things out of their and our control. This can always happen and we do ask several times for information before mentioning the option of returning an assigned AS number which appears not to be in use. The first time we ask is 6 months after the assignment. * 2. If you do revoke it then the customer may suddenly get things fixed and * start using the AS as intended but in the meantime you assign it to another * customer and the problems ensue. If you do not assign it why whould you ask * for it back? If you do not use it why should you keep it? :) Our intention is to make sure AS numbers are used and not wasted. We send several reminders asking about the status and this process is taking a couple of months. If you are not able to start using the AS number after a long time we ask you to return it. To date the RIPE NCC Hostmasters could always find an agreement with the LIRs to return AS numbers that appeared not to be in use. We do reassign returned AS numbers *not* straight away but after a certain time period ("sleeping time") and ... * 3. Just because an AS does not appear in the looking glass does not mean * that its not being used in situation which does not mean it does not need to * be announced at any looking glass. ... we do not only use the Looiking Glass to find the number of peers. We look back in time at least on several days using 'asiuse' - publicly know as the RIS Database, from New Projects. * Please could you clarify this situation? * * Regards * Stephen Burley * UUNET EMEA Hostmaster * SB855-RIPE * Regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

2 1

AS number revokes
by Stephen Burley 27 Feb '02

27 Feb '02

Hi I am a bit concerned about an email we recieved threatening the revokation of an assigned AS number if it did not appear to be used. It concerns me for a number of reasons. 1. Our customer has had problems with other providers and there own network, which has postponed the intended use of the AS for quite a few month, all due to things out of their and our control. 2. If you do revoke it then the customer may suddenly get things fixed and start using the AS as intended but in the meantime you assign it to another customer and the problems ensue. If you do not assign it why whould you ask for it back? 3. Just because an AS does not appear in the looking glass does not mean that its not being used in situation which does not mean it does not need to be announced at any looking glass. Please could you clarify this situation? Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

2 2

New Time Schedule for new IPv4 Policy Document
by Mirjam Kuehne 19 Feb '02

19 Feb '02

Dear Colleagues, As announced earlier the comment/suggestion period for the latest review of the "IPv4 Address Policies in the RIPE NCC Service Region" document has pasted. We are happy to announce that useful feedback was received and we are currently revising the document accordingly. Unfortunately, the deadline for publishing the revised draft set for 7 February 2002 has not been reached. As a result this will slightly change the time schedule published for the revision process. The RIPE NCC will publish the revised draft of the document to the ripe-185bis(a)ripe.net list by 1 March 2002 for the next revision period. Regards, Mirjam Kuehne RIPE NCC

1 0

AW: RIPE-230
by Koepp, Karsten 18 Feb '02

18 Feb '02

Hi Alan, I have not seen anybody answering. The changes in RIPE-230 have been discussed last year on this list. I objected to the initial allocation criterion as well, but was nearly alone and I admit, had no better proposal. Nowadays when becoming a LIR, you have to multi-home one of your upstream's PA space before you reach the /22 limit, or you request PI from RIPE (I have not done this, but this would be my proposal). <SNIP> > So: > De-aggregating our /20 is not an option. Some providers filter. No, that's the only solution I can see. Nobody is filtering on allocation boundaries, because partition is the only way to multi-home. RIPE-230 aims at *conservation* of IP space. Aggregation will suffer. You should request additional ASNs and assign (or have assigned) multiples of /24 to each of your PoPs/networks. Does this help? Karsten > > Taking the same set of suppliers, de-aggregating to them and > having our > upstream announce our aggregated block is not an option because of our > footprint and our desire to be open in terms of suppliers. > > So to go forward we need to: > > 1. Register as an LIR at a country level (as we, as a single LIR > do not qualify for multiple PA assignments under current assignment > policy, even though this would be administratively easier for us) > > *OR* > > 2. leased line connectivity (and no, not a tunnel across multiple > AS's!!) between each country which simply introduces another > POF, another > cost overhead and increases the possibility of blackholing > parts of your > AS if an inter-country link fails. (remembering that our > advantage is we > have all these carriers on our doorstep aka ODF) > > Justifying a /22 for immediate use is well, not possible. > Customers won't wait to be provisioned until you have enough > of them to > use a /22 immediately. > > Last year we applied to RIPE for LIR status and it was granted. > If this were still last year I'd do the same at a country level. > > However now RIPE-230 prevents this.... > > > > Possible (to bounce around) solutions are: > > Use other quantitative methods for approving LIR > status, i.e. what resources/capital investment will an LIR > put into to > ensuring their growth over a period. > > aka 'the put your money where your mouth is' metric. > && > Remove 3.2 from RIPE-230. > > *OR* > > Allow a PA allocation of /21 and Remove 3.2 from RIPE-230 > <lowers risk of waste should LIR be slow to reach > expectations, also as > the PA space exists in a LAN/MAN environment moving to /20 > announcement later is trivial, no real migration.> > > *OR* > > Allow LIR to use PI space for locally colocated customers > provided they > are in a situation to pull the plug. (service operator) - > > (possible flamebait, do we want more prefix's with less > un-utilized space > *or* less prefix's with higher un-utilized space in the short term? -- > also migrating enterprise hosting clients from PI to PA later is hell, > I imagine many will take the easy route and not bother until > sufficiently > pressured by RIPE/community.) > > Would appreciate a constructive dialog on how this can be > achieved. > > With Thanks. > Alan. > > > >

3 2