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

Reminder: LIR Portal ticketing system outage on 6 June
by Razvan Oprea 06 Jun '07

06 Jun '07

Dear Colleagues, This is a reminder for the maintenance work being carried out tonight. The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to <ops(a)ripe.net>. Regards, Razvan Oprea Senior Systems Engineer RIPE NCC

1 0

LIR Portal ticketing system outage on 6 June
by Razvan Oprea 04 Jun '07

04 Jun '07

Dear Colleagues, The RIPE NCC will perform planned maintenance work on Wednesday, 6 June 2007 between 17:00 and 19:00 (UTC). During this period the RIPE NCC ticketing system will not be working, meaning that any changes in the status of open tickets will not be reflected in the LIR Portal. Any pending mails will be processed after the maintenance work has been completed. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to <ops(a)ripe.net>. Regards, Razvan Oprea Senior Systems Engineer RIPE NCC

1 0

Verio renamed NTTCOM in RIPE Database
by Katie Petrusha 30 May '07

30 May '07

Dear Colleagues, On 31 March 2007, the Verio routing registry database was renamed NTTCOM. This change of name has been incorporated in the RIPE Database server which mirrors a number of public databases including the NTTCOM routing registry. More information about the NTTCOM routing registry is available at: http://www.us.ntt.net/about/policy/rr.cfm The list of databases mirrored by the RIPE Database server is available at: http://www.ripe.net/db/mirrored.html -- Katie Petrusha RIPE Database administration RIPE NCC

1 0

RIPE NCC Network Maintenance Wednesday 23 May 1700 - 1900 UTC/GMT - COMPLETED
by Mark Guz 24 May '07

24 May '07

Dear Colleagues, The above mentioned maintenance was performed successfully and within the specified maintenance window. If you have any questions about this, please e-mail ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Dept RIPE NCC

1 0

RIPE NCC Network Maintenance Wednesday 23 May 1700 - 1900 UTC/GMT - COMPLETED
by Mark Guz 24 May '07

24 May '07

Dear Colleagues, The above mentioned maintenance was preformed successfully and within the specified maintenance window. If you have any questions about this, please e-mail ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Dept RIPE NCC

1 0

RIPE NCC Network Maintenance Wednesday 23 May 1700 - 1900 UTC/GMT
by Mark Guz 21 May '07

21 May '07

Dear Colleagues, Between 17:00 and 19:00 (UTC) on Wednesday, 23 May 2007, the RIPE NCC will carry out planned maintenance work on our core network infrastructure. During this period all RIPE NCC services will suffer intermittent interruptions We apologise for any inconvenience that this may cause. If you have any questions about this, please e-mail ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Dept RIPE NCC

1 0

Re: [enum-wg] DNSMON for enum zones
by Ondřej Surý 11 May '07

11 May '07

Ccing to ncc-services-wg. Short summary: Discussion started on enum-wg whether DNSMON service should be extended to ENUM registry operators as well. Patrik summarized discussion so far in several points in mail I am replying at. You can find start of the thread at: http://www.ripe.net/ripe/maillists/archives/enum-wg/2007/msg00024.html Patrik Fältström píše v Čt 10. 05. 2007 v 15:08 +0300: > I see a number of different questions being discussed here, and I > think we should try to separate them: > > 1. RIPE NCC is running DNS for e164.arpa > 2. RIPE NCC should "protect their skin" and monitor the e164.arpa > zone, so they can show their service is up to current standards Shouldn't RIPE NCC do the same for all its delegations. I would broaden scope of this point to monitoring reverse delegations as well. > 3. Registry operators run DNS for zones delegated from e164.arpa, and > the delegation itself should be of some quality for ENUM to work -- > who has responsible for this? I think that responsibility lies in registry operators hands, but NCC should do monitoring and step-in if quality is too low. I don't have idea right now what "step-in" and "quality is too low" definition is. > 4. Registry operators have interest in being monitored, should they > be monitored, or (via opt-in) on request? You probably already know my opinion on that point :-), but together with previous points it gets more complicated. If answer to 2 and 3 is YES, then I think that they should be monitored and on opt-in request they could receive results/warnings/etc. Without opt-in it would be only from RIPE NCC internal needs. > 5. If there is a need for monitoring of DNS operation, is RIPE-NCC to > do that monitoring (they already do in the case of dnsmon)? Let's put another POV in play. If DNSMON was outsourced to let's say commercial service, who will ensure quality of such monitoring? I don't think that niche in this market is so big, that it will self-regulate, because of competition. Then there would be need to _monitor_ monitoring to ensure 2 and 3. Ondrej -- Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------

1 0

New E-Learning Module: Using PGP and X509 to Protect MNTNER Objects
by Rumy Kanis 03 May '07

03 May '07

Dear Colleagues, We are pleased to announce the launch of the latest module on the RIPE NCC E-Learning Centre: - Using PGP Keys and X509 Certificates in MNTNER objects This module explains the steps required to use a PGP Key and/or X509 Certificate to protect objects in the RIPE Database. The module provides step-by-step guidelines for: - Creating a KEY-CERT object - Adding the KEY-CERT object to an existing MNTNER object as a method of authentication - Updating an object protected by that MNTNER using the PGP key or X509 certificate The RIPE NCC E-Learning Centre is a free of charge service available to everyone, and can be found at https://e-learning.ripe.net. If you have any questions, please feel free to contact us at: e-learning(a)ripe.net Happy Learning, Rumy Kanis Training Services Manager

1 0

RIPE Database update problem
by Denis Walker 26 Apr '07

26 Apr '07

[Apologies for duplicate e-mails] Dear Colleagues, >From 21:30 (UTC) on 24 April 2007 until 10:20 (UTC) on 26 April 2007, e-mail updates sent by users to the RIPE Database update service were not processed by the RIPE Database. This problem has now been resolved. ALL the updates submitted have now been processed. No updates were lost. We apologise for this problem with the RIPE Database update service. This was caused by some network adjustments affecting our firewall and mail servers. It had no effect on updates submitted using syncupdates or webupdates, or changes made using the LIR Portal interface. Any changes made by the RIPE NCC Registration Services Department on behalf of RIPE NCC members were also unaffected. We would like to thank all our users for their patience while we fixed this problem. Regards Denis Walker Database Group RIPE NCC

1 0

Cleanup of unreferenced person objects
by Denis Walker 23 Apr '07

23 Apr '07

Hi There has been some useful feedback already on this proposal. Perhaps I need to clarify some points and suggest some changes to the proposal. We have always wanted to keep the database as clean as possible. So whilst half a million extra person objects has no effect on the operation, we prefer them not to be there if they are serving no useful purpose. We have also been looking more closely at Data Protection issues recently. We have a number of points to discus with the Data Protection Task Force. But the bottom line is, we have to define the purpose(s) of the RIPE Database. We are only allowed to keep personal data in the database if it fits the defined purpose. Although we are only at the stage of drafting these definitions, it is difficult to see how unreferenced person objects could fit any definition that we finally agree on. As for e-mails, I have discussed the numbers with our IT operations guys. They are confident we can handle the worst case scenario with our mail servers. So I suggest we process the deletions with the normal notification procedure where e-mails are sent to any "notify:" addresses in the person objects and to the maintainers if maintained. We will use a modified notification text for this purpose. It will refer to a web page that explains why these person objects are being deleted. Regarding the issue of temporary unreferenced person objects. For example when someone is moving to a new company and de-references their person object from the old companies data and intends to reference it with the new companies data. The proposal allows for a (minimum) one month waiting period before deletion. It could be up to two months, depending on when it is de-referenced. If there is a feeling that this needs to be a longer period it can be extended. I hope this addresses the issues so far raised. Regards Denis Walker Database Group RIPE NCC

1 0