- ncc-services-wg - mailman.ripe.net

Country index gone?
by Hank Nussbacher 14 Sep '09

14 Sep '09

On: http://www.ripe.net/membership/ there is a link to list of members: http://www.ripe.net/membership/indices/ but I am getting: Not Found The requested URL /membership/indices/ was not found on this server. Thanks, Hank

2 1

LIR Portal Downtime: Incident Report
by Tim Bruijnzeels 09 Sep '09

09 Sep '09

Dear Colleagues, LIR Portal service has now been restored. The LIR Portal, along with several other RIPE NCC online services, was unavailable from 06:30 - 08:30 (UTC), 9 September 2009. The outage was caused by a faulty switch. We have performed emergency patching to fix the problem for now. A replacement switch will be installed this afternoon between 15:00 - 16:00 (UTC). A five-minute interruption to service is expected when we make this change. We apologise for the inconvience this may have caused for you. We are currently working on a project to migrate the LIR Portal to a new architecture, with improved redundancy, which, when implemented, will reduce the likelihood of such events. Regards, Tim Bruijnzeels LIR Portal Service Manager RIPE NCC

1 0

Unplanned LIR Portal Downtime
by Tim Bruijnzeels 09 Sep '09

09 Sep '09

Dear Colleagues, We regret to inform you that the LIR Portal service has been unavailable since this morning, 06:30 (UTC), 9 September 2009. We are currently working to fix the problem. The cause of the outage is not yet known, though it is not related to service outage that occurred yesterday. We will provide further details once the issue has been resolved. Regards, Tim Bruijnzeels Service Manager LIR Portal RIPE NCC

1 0

Unplanned LIR Portal Downtime: Incident Report
by Tim Bruijnzeels 08 Sep '09

08 Sep '09

Dear Colleagues, This is an incident report regarding an LIR Portal service outage that occurred last night and earlier today. The outage started at 21:15 (UTC), Monday, 7 September, and services were restored at 08:15 (UTC) this morning. The outage was caused by a configuration error of the Apache web server. The RIPE NCC has strict upgrade procedures that our staff follow to prevent this, but they do leave some room for human error, and this outage was the result of such an error. To minimise the chance of this happening again, we plan to include automated monitoring of our Apache configuration syntax to our monitoring system. A separate issue was responsible for the longer than usual time it took to recognise and fix the problem. Our monitoring system is set up to send text messages to a 24/7 engineer in case of outages such as this. From our logs, we can see that the system did indeed try to send an SMS about the outage yesterday at 21:15 (UTC), but was unable to connect to our mobile service provider. To minimise the chance of this happening again, we will reconfigure our monitoring system to fall back to another provider in case a message can not be sent out. I hope that you find this explanation of the cause of the outage and the steps we are taking to prevent it from happening again useful. Regards, Tim Bruijnzeels Service Manager LIR Portal RIPE NCC

1 0

LIR portal unreachable
by Daniel Suchy 08 Sep '09

08 Sep '09

Hello, since yesterday night I'm observing problems with LIR portal connection. Planned maintenance or unplanned outage was not announced on obvious places. Connection to TCP port 443 (https) is closed by server immediately, browser reports that the network link was interrupted while negotiating a connection. Connection to TCP port 80 works (there's redirect to https). I verified this from several networks (AS) / browses. Someone could check on this problem. In addition, monitoring should be improoved I think, checks should be extended not only to monitor state of TCP port (open/closed), but also check application status (for example, nagios is able to monitor this). With regards, Daniel

1 0

PI/ASN contracts
by Max Tulyev 06 Sep '09

06 Sep '09

Hi All, I have some misunderstanding with contractual relationship procedure is going on. By 20th of September, I should provide information about my clients signed contracts with our company. These all objects will appear in our billing scheme in 2010. If someone didn't sign it before this date, but will - for example, on October, 1st - what should I do with these clients? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 2

Deprecation of rev-srv attribute
by Denis Walker 27 Aug '09

27 Aug '09

Dear Colleagues, In April 2009, the RIPE NCC announced the timeline for the deprecation of the "rev-srv:" attribute. This announcement can be found online at: http://www.ripe.net/ripe/maillists/archives/db-wg/2009/msg00032.html At the RIPE 58 Meeting it was agreed that the final stage would be to convert any remaining "rev-srv:" attributes into "remarks:" attributes. This final stage will be implemented by the RIPE NCC on Wednesday, 2 September. There are approximately 100,000 remaining "rev-srv:" attributes. There was some discussion on the RIPE Database Working Group mailing list about whether these attributes should be removed completely instead of converted into remarks as most of the data concerned is likely to be out of date and of little use to anyone. However, as no consensus was reached on this discussion, we will continue with the current conversion to remarks. If you have any general comments or questions about this, please reply to the mailing list. For more specific comments or questions, please contact <ripe-dbm(a)ripe.net>. Regards, Denis Walker Business Analyst RIPE NCC

1 0

Re: Complaint: Overly complicated when requesting PI space
by Sander Steffann 16 Jul '09

16 Jul '09

Hello Mark, > If you ask me it should be allowed to use PI space for clients (and > give > clients the option to use/maintain more than a /30 (IPv4)). PI policy explicitly states that PI space can not be re-assigned or further assigned to other parties. See http://www.ripe.net/ripe/docs/ripe-471.html#9 . Any organisation that needs address space for its customers must use PA space. The definition of an LIR is that it assigns address space to its customers. PI space is (per definition) only to be used by the company that requested it itself. > It is also in my > opinion not to RIPE (community or the NCC) to ask that information. > The > should ask for general usage, how much would be used for clients for > example. How many clients a company has shouldn't be important to > get PI. In this case it doesn't matter. That the company needs address space for *any* customers indicates that PI space is not appropriate and PA space should be used. The company uses address space for customers and therefore must become an LIR. I think it is now time to stop this discussion, at least on the address policy mailing list. This discussion is not leading to a viable policy proposal. Thanks, Sander Steffann APWG co-chair

1 0

Complaint: Overly complicated when requesting PI space
by Jeroen Wunnink 16 Jul '09

16 Jul '09

Hello Members, I'd like to state a complaint toward overly complicated issues with requesting PI space as a LIR for a customer. Situation: I have a customer who's purchased a router and wants his own IP space+AS number to start multihoming. Since he's pretty new to routing and policies of RIPE and managing the database to keep things going, we as LIR offered him to do this for him at the startup phase. Currently he'll be hosting several services from within our PA ranges and will start growing his new resources in the PI space he wants. After filling in the request forms, his AS got approved pending the PI /24 range assignment. And that's been a process that's currently becoming something ridiculous. Initially I got some return questions on how the subnets would be sliced up, what would be used for management of the routers, if IP's are being assigned statically or dynamically, how much IP's a customer would use and if PA space is being returned. Questions (except for the 'how much IP's will a customer use') I can understand and all answered. Then in a follow-up I got asked what the montly growth is, who's administratively responsible for the IP's and how they're going to be used on the servers. Then in a next follow up I got pointed to using PA space either from us or a different provider or that the customer should become LIR himself since we as LIR cannot sub-allocate PI space. (something that's not intended in the first place at all, we just administer it on a contract base until he understands procedures) And then after explaining that we will only help the customer on contract base and not sub-allocate anything, another follow-up comes that no customer can use more then 1 or 2 IP's and once again a question on how many servers are involved here. And that's where I'm at now. I've been trying to request PI space for our customer since last friday, and in my opinion there's too much meddling into internal business by RIPE here and this is taking a ridiculous amount of time and communication. As a LIR we hand out IP space responsibly to our customers, for a good technical and administrative reason we have a customer who wants his own PI assignment and I'm asking him questions about his business that lean towards a company secret. In my opinion RIPE has absolutely no business in asking how many customers and/or servers someone has and stating that a customer can not use >2 IP's in that PI space (what if someone has *gasp* 3 SSL websites ?, I cannot imagine that happening.., ever). Also neither we or our customer has a crystal ball to see in the future, so sure I can tell the amount of customer growth I'll be expecting or HOPING to see, but come on. I know IPv4 space must be handed out responsibly, but this is seriously going too far, especially for a LIR. Supposedly I cannot give a routing-reason for requesting PI space, but part of that IS important on why I'm requesting it. It's really not desirable for us AND for my customer to chop out a part of my PA space and announce in smaller chunks from his own AS on the same exchange points we're on and this customer is NOT at the stage yet to become a full LIR himself. -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer(a)easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl

8 10

IPv6 Deployment Monitoring Survey: Deadline Extended!
by Paul Rendek 06 Jul '09

06 Jul '09

[Apologies for duplicates] Dear Colleagues, The deadline for responding to the IPv6 Deployment Monitoring Survey has been extended to Friday, 10 July 2009. This survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region, and all members of the RIPE community are encouraged to participate. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org Please note that all data will be kept confidential at all times, and will only be disclosed on an aggregated level. For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to <info(a)gnksconsult.com>. Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0