Hi WG.
In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services.
However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW.
I propose that the API keys mechanism is extended to Syncupdates and the RESTful API.
The already existing default maintainer concept could be leveraged to accomplish this (similar to how NWI-8 was implemented). That is, using Syncupdates or the RESTful API with API keys will simply authenticate the client as the LIR's default maintainer.
Authorisation should remain handled by in-band mnt-* object attributes, as is currently the case.
It would be an acceptable limitation that API keys for database maintenance are unavailable for LIRs without a default maintainer.
Assuming the WG agrees that this is a good idea, I request an NWI.
Tore
Dear RIPE Database Working Group,
On behalf of the RIPE NCC Academy team, I would like to let you know that we have launched the updated RIPE Database e-learning course. Here are some of the major changes:
- We modularised the content. You can now learn a new topic whenever you have 15 minutes to spare.
- The modules are more interactive, and include practical exercises and scenarios.
- The Training Database has been upgraded to the latest version of the RIPE Database software.
The RIPE NCC Academy, our free, open e-learning platform has been revamped. It has received a visual upgrade. You can visit it at:
https://academy.ripe.net <https://academy.ripe.net/>
Kind regards,
Evelien Schilder
E-Learning Developer
RIPE NCC
Hello RIPE support ,
In the past few years, our organization has gone through a privatization program by the government of Kuwait. Kuwait Stock Exchange has been changed now to Boursa Kuwait our old domain was kuwaitse.com is now boursakuwait.com.kw.
The MNT ID and email is still pointing to old inaccessible domain ID,
Anyway, the phone number & address are still the same, and the contact person still with Boursakuwait looped in this mail with his new email id 'ybaniyan(a)boursakuwait.com.kw'.
Do you have any idea how to change these records? I have contacted the local registrar LR: Fast Telco and they said this must be done through the RIPE and they are not authorized to change these registration parameters.
We will adhere to provide all the supporting official documents and memos that RIPE might asking for this change.
LIR : Fast Telecommunications Company W.L.L.
P.O.Box 287
15453 Dasman
KUWAIT
phone: +96522256666
fax: +96522401925
e-mail: ripeadmin (at) fasttelco (dot) net
Areas serviced: KW
195.137.174.0/24 AS# 49104 Domain : BoursaKuwait.com.kw<https://dnslytics.com/bgp/as49104>
% Abuse contact for '195.137.174.0 - 195.137.174.255' is 'abuse(a)fasttelco.net'
inetnum: 195.137.174.0 - 195.137.174.255
netname: Kuwait-Stock-Exchange
country: KW
org: ORG-KSE1-RIPE
admin-c: YA443-RIPE
tech-c: YA443-RIPE
status: ASSIGNED PI
mnt-by: RIPE-NCC-END-MNT
mnt-by: MNT-Kuwait-Stock-Exchange
mnt-routes: MNT-Kuwait-Stock-Exchange
mnt-domains: MNT-Kuwait-Stock-Exchange
created: 2005-09-20T07:36:57Z
last-modified: 2016-04-14T08:28:19Z
source: RIPE # Filtered
sponsoring-org: ORG-FTC1-RIPE
organisation: ORG-KSE1-RIPE
org-name: Kuwait Stock Exchange
org-type: OTHER
address: P.O. Box 22235 - Safat - Kuwait
abuse-c: AR25180-RIPE
mnt-ref: MNT-Kuwait-Stock-Exchange
mnt-by: MNT-Kuwait-Stock-Exchange
created: 2005-09-19T11:59:15Z
last-modified: 2014-11-17T21:01:58Z
source: RIPE # Filtered
person: Yousef Abbas
address: Kuwait City
phone: +965 22992576
nic-hdl: YA443-RIPE
created: 2009-07-27T06:57:06Z
last-modified: 2016-04-06T19:52:01Z
mnt-by: RIPE-NCC-LOCKED-MNT
source: RIPE
% Information related to '195.137.174.0/24AS49104'
route: 195.137.174.0/24
descr: Kuwait Stock Exchange
origin: AS49104
mnt-by: MNT-Kuwait-Stock-Exchange
created: 2009-04-16T10:13:58Z
last-modified: 2009-04-16T10:13:58Z
source: RIPE
Regards,
Mohamed Eldemiri
Network Administrator
[cid:image001.png@01D5E970.A74CE0E0]
Address:
Mubarak Al Kabeer Street, Kuwait City, Kuwait
P.O.Box:
22235, Safat, 13083 Kuwait
Telephone:
+(965) 2299-2595
Mobile:
+(965) 55266079
Fax:
+(965) 2244-0476
www.boursakuwait.com.kw
Disclaimer: This e-mail message and any files attached to it are intended only for the recipients named above. The information in this e-mail is confidential and may be legally privileged. If you are not the intended recipient or have received this e-mail by error, you must not use or disseminate the information and must promptly notify the sender and delete this e-mail immediately. Unless otherwise explicitly provided in the body of this e-mail, neither this e-mail nor any attachment hereto is intended to operate as a commitment of whatever type or to include an electronic signature of whatever form under any applicable law. Opinions, conclusions and other information in this email that do not relate to the official business of Boursa Kuwait. Shall be understood as neither given nor endorsed by Boursa Kuwait. Although this email and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that it is virus free. Boursa Kuwait accepts no responsibility for any loss or damage arising in any way from the use of this email.
Colleagues
I said at Ripe 79 that I would review the open NWIs. So lets start with NWI-1. This has been open and virtually static since 2016. The original summary is here:https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html
The situation has changed since then with the "abuse-c:" attribute now allowed in resource objects. The main point I was making (as one of the authors of this NWI) is that there is no easy way for a resource holder to view all the abuse contact details for any of their resources. Hierarchical queries for abuse contacts only search 'up' the hierarchy. There is no easy way for the resource holder to search 'down' through the hierarchies to find all/any abuse contact details. These can now be added at any point in a hierarchy and forgotten about. But they are still active and may present the wrong information when people query for these details.
The question now is "Do we need a search/query option or RIPEstat widget that will present an overview of all abuse contacts from a resource allocation down the hierarchy, or even for all of an organisation's resources?"
cheers
denis
co-chair DB-WG
