- db-wg - mailman.ripe.net

Deployed 1.87.4 with two fixes for business rules
by Tim Bruijnzeels 22 Jun '16

22 Jun '16

Dear working group, We deployed version 1.87.4 to production earlier this week with two fixes for business rules that impacted a number of users: 1) It was not possible to set "mnt-lower:" on INET6NUM objects with status "ALLOCATED-BY-RIR". This restriction existed when object editors were used, but was ignored at that time because object editors used a different authorisation method. The restriction has now been removed. 2) The fix in 1.87.3 allowed "netname:" to be changed on objects with status "ASSIGNED PI", but unfortunately not for other "ASSIGNED" objects. We have made sure that the restriction only applies to INET(6)NUM objects for allocations done by the RIPE NCC. To summarise the following business rules apply to objects that are 'co-maintained', i.e. allocations, assignments or legacy space that is registered with RIPE NCC: = Allocations INETNUM objects with "status:" ALLOCATED PA, ALLOCATED PI or ALLOCATED UNSPECIFIED, and INET6NUM objects with "status:" ALLOCATED-BY-RIR Restricted attributes: netname, org, sponsoring-org, status, mnt-by (you can only change your default maintainer through the LIR Portal) = Assignments INET(6)NUM objects with at least one RIPE-NCC-XYZ-MNT and "status:" ASSIGNED PI, or ASSIGNED ANYCAST Restricted attributes: org, sponsoring-org, status, mnt-by (you cannot add or remove RIPE-NCC-XYZ-MNT) and mnt-lower = Legacy space registered with RIPE NCC INETNUM objects at least one RIPE-NCC-X-MNT and "status:" LEGACY Restricted attributes: org, sponsoring-org, status, mnt-by (you cannot add or remove RIPE-NCC-XYZ-MNT) In addition to this, all objects described above can only be deleted by RIPE NCC. I hope this makes it clear how we apply business to these objects. If you have any questions or comments, please let us know. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

Organisation Names in "descr:" cleaned up and no longer enforced
by Tim Bruijnzeels 08 Jun '16

08 Jun '16

Dear working group, As we just announced on the ncc-announce mailing list, we have completed the clean up of "descr:". Resource holders who configured "notify:" were alerted about this cleanup. We updated the RIPE Database to version 1.87.3 in order to make "descr:" on allocations editable by LIRs. Please let us know if you find any issues. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

3 2

Faked entries in the RIPE db
by Dickinson, Ian 02 Jun '16

02 Jun '16

There appears to be abuse happening in the RIPE db - presumably to allow other online activity to be done with abuse indirection to an innocent bystander (e.g. my employer) - all over the last day or two... The specific items I noticed are all inet6num maintained by BSKYB-BROADBAND44-MNT, along with BSKYB-BROADBAND44-MNT itself, and ORG-BBH4-RIPE and ACRO772-RIPE This was due to the fake objects referring to our real role/person objects. It appears that there are many other faked entries under 2a07:7ec0::/29 - pretending to be Deutsche Telekom or Time Warner Cable for example. Either that LIR is a bad actor, or their maintainer credentials have been 0wned. This needs to be killed off. Cheers, -- Ian Dickinson Network Architect Sky Network Services ian.dickinson(a)sky.uk Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

3 4

Progress on Number Work Items - June 2016
by Tim Bruijnzeels 01 Jun '16

01 Jun '16

Dear working group, As discussed during the Database Working Group session at RIPE 72, we have now published the new process, as well as an overview of the ongoing Numbered Work Items (NWIs) here: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items For the impatient, we currently have the following five NWIs, all in state "Problem Definition": NWI-1 Staying on top of abuse contact changes NWI-2 Displaying history for database objects where available NWI-3 AFRINIC IRR homing NWI-4 Role of status: field in multivalued status context NWI-5 Out of region ROUTE(6) / AUT-NUM objects Please let us know if you have any questions or comments. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

2 1

Deployed 1.87.1 to RC - supporting business rules that allow phasing out object editors
by Tim Bruijnzeels 27 May '16

27 May '16

Dear working group, We deployed release 1.87.1* to RC today. This new Database release introduces several business rules that allow us to phase out object editors for LIRs in the near future. As announced by Alex Band to the services working group on 21 April: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2016-April/002999.h… Since this release does not introduce any other functional changes, we believe that a one week RC test period should be enough. And we propose to deploy this release to production next Wednesday 11 May, unless of course issues are found or concerns are raised. The new business rules ensure that once an LIR maintainer is added to "mnt-by:" of an LIR ORGANISATION object and/or INET(6)NUM objects for LIR allocations, attributes that are maintained by RIPE NCC remain maintainable by RIPE NCC only. For organisation objects the following attributes will not be modifiable by the LIR: "organisation:"**, "org-name:", "org-type:", "address:" ***, "phone:" ***, "fax-no:" ***, "email:" ***, "mnt-by:" **** For inet(6)num objects the following attributes will not be modifiable by the LIR: "inetnum:"**, "netname:", "org:", "sponsoring-org:" (on assignments, included here for completeness), "status:", "mnt-by:" **** Please note that these changes only come into real effect after we deploy changes to the LIR Portal that allow LIRs to select a maintainer to use. We are working hard on this at this moment, but we are not sure whether we can have these changes ready before the RIPE Meeting, or that we will have to wait a bit longer. Of course we will communicate how this changes the way that LIRs can maintain their objects before that time. Please let us know if you find any issues or have any concerns or questions, Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group *: Note that we caught a small issue internally before we planned to deploy 1.87, hence the version currently deployed is 1.87.1. **: primary key, so not modifiable - included here to make it clear that these objects are created by RIPE NCC ***: These fields will remain modifiable through the LIR Portal only for now, since they are stored both in the RIPE NCC internal member database and the RIPE Database ****: During the first phase of this effort the LIR can only choose one MNTNER to use, through the LIR Portal

2 2

Re: [db-wg] Geolocation in the RIPE Database
by Wilfried Woeber 25 May '16

25 May '16

On 2016-05-25 20:25, Job Snijders wrote: > Hi wilfried, > > Would you be willing to work with the chairs to formulate a problem statement and follow the NWI process? Sure :-) I guess it would be reasonably easy, along the following lines: - functionality was introduced to "test the waters" - it never became obvious how to maintain it or which party would actually be allowed or mandated to manage the entries - whatever rudimentary functionality there was/is, it is not helping the "victims", ie. the end users - geo-location is better (but not nearly good![1]) maintained by entities like maxmind - geo-location is pretty far out from the mandate of the Resource Registry - there was never a common understanding, how to deal with assignments within an LIR with global or at least continental or regional coverage - we never had any sense of applicable granularity of longitude/latitude or national boundaries - we never got useful feedback on the usefulness or "consumer processes" for this particular dataset - all of that related to the 1st entry in this list :-) Wilfried [1] the RIPE Meeting Network here in Copenhagen is still considered to be located in Romania, with all the ill-advised side effects... > Job > > Original Message > From: Wilfried Woeber > Sent: woensdag 25 mei 2016 20:08 > To: Tim Bruijnzeels; Database WG > Subject: Re: [db-wg] Geolocation in the RIPE Database > > > Hi Tim, DB-WG community! > > On 2016-05-25 19:51, Tim Bruijnzeels wrote: >> Dear working group, >> >> We have an update with regards to the following action point: >> AP69.3 [RIPE NCC] To examine and report on possible solutions to improving geolocation >> data in the RIPE DB (Ongoing but if no progress by RIPE 72 then kill it) >> >> Following a decision by the RIPE NCC Executive Board not to support resource expenditure >> in the area of geolocation services, the RIPE NCC has no plans to examine this further. > > I can easily relate to this decision and can easily "accept" it. > > But as a consequence, I'd like to propose to *discontinue* all geo-location > related functionality in the Resource Registry as soon as possible. > > Regards, > Wilfried > >> A write-up is published on our website: >> https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… >> >> Kind regards, >> >> Tim Bruijnzeels >> >> Assistant Manager Software Engineering >> RIPE NCC Database Group > > >

1 0

Geolocation in the RIPE Database
by Tim Bruijnzeels 25 May '16

25 May '16

Dear working group, We have an update with regards to the following action point: AP69.3 [RIPE NCC] To examine and report on possible solutions to improving geolocation data in the RIPE DB (Ongoing but if no progress by RIPE 72 then kill it) Following a decision by the RIPE NCC Executive Board not to support resource expenditure in the area of geolocation services, the RIPE NCC has no plans to examine this further. A write-up is published on our website: https://www.ripe.net/manage-ips-and-asns/db/tools/geolocation-in-the-ripe-d… Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

3 2

proposal for a review of the RIPE Database data model
by ripedenis＠yahoo.co.uk 24 May '16

24 May '16

HI All Piotr asked me if I would have time to write a short problem statement about the data model for consideration as an NWI. For once I will try to make it brief(er). Current model developed in late 90s as a further development of the previous RIPE Database design from much earlier. Nothing fundamental has changed in the last 15 years. It makes virtually no use of inheritance which has led to massive amounts of duplicated data, with all the problems of managing and interpreting that data. It was designed in a day when it was more normal to manage data by sending and receiving emails. Although I welcome the improvements to Webupdates, this feature is still something bolted on to the side and not fundamental to the design. There is no concept of 'user accounts' beyond SSO (another feature bolted on) so it is not possible to manage your data online and set permissions or do any configuration. The database contains two basic types of data: 1/ Operational data as determined by the purpose of the database 2/ Organisational and security data for the management of the operational data Far too much of the security and organisational management data is public. How I secure my data and who, within my organisation, has permission to do what is non of your business. That information is confidential to my organisation. With user accounts that can all be kept confidential. The lack of business rules and constraints in the early days of the database allowed massive misuse of the original design. Especially in the area of PERSON, ROLE and MNTNER objects. A lot of the relationships between these objects and others is totally screwed up now making management, security and interpretation of the data far more complex than it needs to be. Over the last 12 months I have pointed out so many examples on the mailing list of how things are over complicated, or cannot be changed, or features that cannot be implemented because of the constraints of this data model. The most recent example being a very good suggestion by someone to customise the notification message and define a simple rule set for sending them out as part of a bulk update. This cannot be done by the database software based on this data model. It has to be done externally by the NCC staff by analysing the data involved in the bulk update, building the customised notification messages and sending them out with an email client. What I am suggesting is a serious review of the data model and the database design to identify areas that could be improved in an organised, backwards compatible, step by step process. It is also important to stress what I am not suggesting as this topic seems to carry as much negative propaganda as the UK's foolish, brexit campaign. I am not suggesting a team of engineers hide in a dark room for a year then launch a completely re-designed data model on the community and force you all to change all your tools used to engage with the database overnight. That is not how software is developed these days. Small steps, backwards compatible, testing, reviews, run in parallel, slowly moving forwards. That is how software is developed these days. On this basis I put this forward for consideration as an NWI. cheers denis

2 1

RIPE 72 DB-WG agenda V2
by Piotr Strzyzewski 24 May '16

24 May '16

Dear DB-WG Members This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE72 at the Tivoli Hotel & Congress Center in Copenhagen, Denmark. The DB-WG Meeting is scheduled as usual for Thursday, May 26th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 72 meeting plan please refer to its most up-to-date version at https://ripe72.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. RIPE DB development process: Numbered Work Items (Job Snijders) [~5 min] C. Follow-up from GAC Public Safety Working Group in ICANN (Hans Petter Holen) [~10 min] D. DB Operational Update New and revised DB-Software functionality (proposed, test, deployment) Recent DB issues (Tim Bruijnzeels, RIPE NCC) [~15 min] . setting abuse-c for remaining organisation with resources allocated or assigned by the RIPE NCC . cleaning-up Organisation Names in "descr:" . ripe objects as single text field . restrict usage of RIPE-NCC-RPSL-MNT . increase daily db dump frequency . clean-up of "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06 . locking unmaintained PERSON and ROLE objects in the RIPE Database . other aspects E. Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~5 min] F. Recent work on the UI improvements + Phasing out the LIR Portal object editors (Alex Band, RIPE NCC) [~20 min] G. Follow-up from AA-WG: 2016-01 (Piotr Strzyżewski) [~5 min] H. NWI-1: staying on top of abuse contact changes (Piotr Strzyżewski) [~5 min] I. ROUTE objects for non RIPE resources (Job Snijders) [~15 min] Y. Input from other Working Groups and/or Task Forces Z. AOB -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

RIPE Policy Proposal 2016-03 Affects Database Status for Allocations from IPv4 Pool
by Marco Schmidt 17 May '16

17 May '16

Dear colleagues, A new RIPE Policy proposal, 2016-03, "Locking Down the Final /8 Policy" is available for discussion on the Address Policy Working Group mailing list. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These allocations will receive a separate status with several restrictions. As this proposal introduces a new status for these INETNUM objects, we would like to notify the Database Working Group and invite you to discuss the proposal on the Address Policy Working Group mailing list. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 June 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE 72 DB-WG agenda V1
by Piotr Strzyzewski 13 May '16

13 May '16

Dear DB-WG Members This is the 1st draft of an agenda for the DB-WG Meeting at RIPE72 at the Tivoli Hotel & Congress Center in Copenhagen, Denmark. The DB-WG Meeting is scheduled as usual for Thursday, May 26th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 72 meeting plan please refer to its most up-to-date version at https://ripe72.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. RIPE DB development process: Numbered Work Items (Job Snijders) [~5 min] C. Follow-up from GAC Public Safety Working Group in ICANN (Hans Petter Holen) [~10 min] D. DB Operational Update New and revised DB-Software functionality (proposed, test, deployment) Recent DB issues (Tim Bruijnzeels, RIPE NCC) [~15 min] . setting abuse-c for remaining organisation with resources allocated or assigned by the RIPE NCC . cleaning-up Organisation Names in "descr:" . ripe objects as single text field . restrict usage of RIPE-NCC-RPSL-MNT . increase daily db dump frequency . clean-up of "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06 . locking unmaintained PERSON and ROLE objects in the RIPE Database . other aspects E. Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~5 min] F. Recent work on the UI improvements + Phasing out the LIR Portal object editors (Alex Band, RIPE NCC) [~20 min] G. Follow-up from AA-WG: 2016-01 (Piotr Strzyżewski) [~5 min] H. NWI-1: staying on top of abuse contact changes (Denis Walker/Piotr Strzyżewski) [~5 min] I. ROUTE objects for non RIPE resources (Denis Walker/Piotr Strzyżewski) [~15 min] Y. Input from other Working Groups and/or Task Forces Z. AOB -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by Tim Bruijnzeels 12 May '16

12 May '16

Hi Akil, working group, If we perform the clean-up that was proposed your organisation name will be removed from "descr:" in your resource objects. But note that this *only* applies to 'top-level' objects: i.e. allocations or assignments you received from the RIPE NCC - not e.g. assignments done under a PA allocation. And we only perform the clean-up if the "descr:" exactly matches the organisation name - that RIPE NCC was enforcing. You can already update the "descr:" for assignments (PI and ASN) you received. If you change the "descr:" to something other than the organisation name they will not be touched. Until now it has not been possible to update "descr:" for allocation objects. So if we would run the clean-up today that would mean that all allocation objects end up with no "descr:" attributes. You would however still be able to find your objects, because they have a reference to your organisation object (and your organisation object has your organisation name). We are currently working on deprecating the object editors, so you will be able to edit the "descr:" attribute for allocations within a few weeks from now. After this work is done, you will be able to update your "descr:" of allocation objects as well. As mentioned earlier the clean-up was reverted and has been postponed. We can run it again on 9 May, but only if the working group co-chairs call consensus. We can also postpone the clean-up until after the object editors are deprecated and people have had a chance to update the "descr:" on their allocation objects. We can also cancel the clean-up if the working group feels this is better. Kind regards, Tim > On 28 Apr 2016, at 16:07, AKIL EVLAT <AKIL.EVLAT(a)kktcell.com> wrote: > > > Hi, > > Since you have no longer got descr available at your end. How would we refer to our IP block at your end? > > Regards, > > > AKIL EVLAT > KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST > Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 > Lefkoşa / KKTC > T: > E: akil.evlat(a)turkcell.com.tr > > > -----Original Message----- > From: AKIL EVLAT > Sent: Friday, April 22, 2016 10:50 AM > To: 'Tim Bruijnzeels' <tim(a)ripe.net>; ncc-announce(a)ripe.net; 'db-wg(a)ripe.net' <db-wg(a)ripe.net> > Cc: BARIS KIZILDERE (BARIS.KIZILDERE(a)kktcell.com) <BARIS.KIZILDERE(a)kktcell.com>; TO-CO-PN <TO-CO-PN(a)kktcell.com> > Subject: RE: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:" > > Hi, > > From what i understand no changes are going to be made that effects users and no actions have to be taken by the users. > > But as KKTCELL we would like to know what will the name/abbreviaton change to. What will be the new abbreviations? > > Are any of the users going to be effected in any way? Or is there such a risk? > > Kind Regards, > > AKIL EVLAT > KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 Lefkoşa / KKTC > T: +90 533 850 0175 > E: akil.evlat(a)kktcell.com > > -----Original Message----- > From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels > Sent: Tuesday, April 19, 2016 5:17 PM > To: ncc-announce(a)ripe.net > Subject: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:" > > Dear colleagues, > > We want to let you know about a clean-up that we have been planning with the RIPE Database Working Group (WG) and explain why this is being done. As this is currently being discussed on the WG mailing list, there is still time to comment if you wish. > > Background > ---------------- > > For a long time, there has been a requirement that the first "descr:" attribute of resource objects that were allocated/assigned by the RIPE NCC must match the name of the organisation that holds the resource. However, these resource objects have also had a reference to the organisation object of the holder of these resources for quite some time, and the RIPE NCC ensures that this organisation object matches what we have in the RIPE Registry. This means that we have been using two parallel approaches to achieve the same goal. > > Since we began using organisation objects, requiring the organisation name in the “descr:” attribute has become redundant. It creates the potential for a mismatch between the name recorded here and the name on the actual organisation object. It also leads to confusion about where the correct name of the organisation can be found, along with a number of other issues. > > This has been discussed at length on the RIPE Database WG mailing list and during WG sessions at RIPE 70, 71 and 72. Consensus was reached that going forward: > - Organisation names should no longer be enforced in "descr:" attributes > - LIRs should be allowed to modify the "descr:” attribute[1] and will be responsible for maintaining this (it will not be verified by the RIPE NCC) > - The RIPE NCC should clean up existing cases where the organisation name is enforced > - "descr:” should become an *optional* attribute > > Last Week’s Reverted Clean-up > ------------------------------------------ > > The WG decided that a clean-up was needed to remove any confusion about where the organisation name should be found. Because there are 93,105 objects that need to be updated, it is not practical to send notifications to all of these resource holders individually. As this change was expected to have little operational impact, it was decided that this should be done as a silent update. However, while the WG was informed of our intention to run the clean-up, it was an oversight on our part not to send a notification to the wider RIPE community. > > We proceeded with our implementation of these changes in the RIPE Database and deployed release 1.86 to production on 21 March. We then communicated our intent to run the clean-up on 11 April to the Database WG[2]. When we ran the update last week, a community member alerted us to a problem and the clean-up was reverted the following day after it was completed[3]. > > There is now a discussion about how or whether to continue with this clean-up on the RIPE Database WG mailing list[4]. If the WG determines that we should proceed with this, we have a tentative date set for 9 May 2016. We invite you to discuss this further on the mailing list at <db-wg(a)ripe.net> if you have any opinions or concerns that you would like to share. > > We will also be reviewing our processes to ensure we give adequate notification for such changes in the future. > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC Database Group > > [1] "descr:" is currently not editable in the Allocation Object Editor, but will become editable by LIRs in the near future. > [2] https://www.ripe.net/ripe/mail/archives/db-wg/2016-March/005136.html > [3] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005172.html > [4] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005173.html > > > [http://www.kktcell.com/e-fatura/Disclaimer_Banner.jpg]<http://www.kktcell.com> > > Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.KUZEY KIBRIS TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve KUZEY KIBRIS TURKCELLin goruslerini yansitmayabilir > > Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. > > ________________________________ > > This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted.KUZEY KIBRIS TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of KUZEY KIBRIS TURKCELL. > > This e-mail has been scanned for all known computer viruses.

11 21

Re: [db-wg] db-wg Digest, Vol 57, Issue 1
by Øystein Gåsdal 02 May '16

02 May '16

Hello again. I spoke too soon. I still get errors when I try to make NIC-handles looking like this: ALE1574-ADMIN AK1576-ADM Etc. That shouldn't happen, right? Thanks again. - Øystein -----Opprinnelig melding----- Fra: db-wg [mailto:db-wg-bounces@ripe.net] På vegne av db-wg-request(a)ripe.net Sendt: søndag 1. mai 2016 12.00 Til: db-wg(a)ripe.net Emne: db-wg Digest, Vol 57, Issue 1 Send db-wg mailing list submissions to db-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/db-wg or, via email, send a message with subject or body 'help' to db-wg-request(a)ripe.net You can reach the person managing the list at db-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of db-wg digest..." Today's Topics: 1. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (Anand Buddhdev) 2. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (denis) ---------------------------------------------------------------------- Message: 1 Date: Sat, 30 Apr 2016 16:58:01 +0200 From: Anand Buddhdev <anandb(a)ripe.net> To: "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <5724C7F9.8020403(a)ripe.net> Content-Type: text/plain; charset=utf-8 On 30/04/16 14:02, ?ystein G?sdal wrote: Hi ?ystein, > Hello, and thank you for your answer. > But I think I need to be spoonfed about this? Denis has already provided a good answe. But let me help more with an example. > So according to the rules, the NIC-handle can be something like this: > > ALE-ADMIN-C ? No, you may not have 2 dashes in the NIC handle. You can only have a NIC handle of the form: XXX or XXX-YYY The first part (XXX) has to start with 2-4 letters, and optionally up to 6 digits. The -YYY part is optional, but if present, must be a dash, followed by up to 9 letters. Here are some valid examples: ALE ALE-RIPE ALE1234 AL345-RIPE ALE90-KOMMUNE But the following are NOT allowed: ALE-ADMIN-C AL023 ALESUND Regards, Anand ------------------------------ Message: 2 Date: Sat, 30 Apr 2016 23:25:59 +0200 From: denis <ripedenis(a)yahoo.co.uk> To: Anand Buddhdev <anandb(a)ripe.net>, "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <572522E7.7030800(a)yahoo.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Hi Anand, ?ystein On 30/04/2016 16:58, Anand Buddhdev wrote: > On 30/04/16 14:02, ?ystein G?sdal wrote: > > Hi ?ystein, > >> Hello, and thank you for your answer. >> But I think I need to be spoonfed about this? > > Denis has already provided a good answe. But let me help more with an > example. > >> So according to the rules, the NIC-handle can be something like this: >> >> ALE-ADMIN-C ? > > No, you may not have 2 dashes in the NIC handle. You can only have a > NIC handle of the form: > > XXX > > or > > XXX-YYY > > The first part (XXX) has to start with 2-4 letters, and optionally up > to > 6 digits. The -YYY part is optional, but if present, must be a dash, > followed by up to 9 letters. Here are some valid examples: > > ALE > ALE-RIPE > ALE1234 > AL345-RIPE > ALE90-KOMMUNE Almost :) But after the '-' you can only use a source name, like 'RIPE, 'APNIC', etc. so ALE90-KOMMUNE is not allowed cheers denis > > But the following are NOT allowed: > > ALE-ADMIN-C > AL023 > ALESUND > > > Regards, > Anand > End of db-wg Digest, Vol 57, Issue 1 ************************************

3 3

Re: [db-wg] db-wg Digest, Vol 57, Issue 1
by Øystein Gåsdal 02 May '16

02 May '16

I thank you all for good answers. I think I know what to do now. - Øystein -----Opprinnelig melding----- Fra: db-wg [mailto:db-wg-bounces@ripe.net] På vegne av db-wg-request(a)ripe.net Sendt: søndag 1. mai 2016 12.00 Til: db-wg(a)ripe.net Emne: db-wg Digest, Vol 57, Issue 1 Send db-wg mailing list submissions to db-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/db-wg or, via email, send a message with subject or body 'help' to db-wg-request(a)ripe.net You can reach the person managing the list at db-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of db-wg digest..." Today's Topics: 1. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (Anand Buddhdev) 2. Re: Is it possible to choose your own NIC Handle when creating ROLE objects? (denis) ---------------------------------------------------------------------- Message: 1 Date: Sat, 30 Apr 2016 16:58:01 +0200 From: Anand Buddhdev <anandb(a)ripe.net> To: "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <5724C7F9.8020403(a)ripe.net> Content-Type: text/plain; charset=utf-8 On 30/04/16 14:02, ?ystein G?sdal wrote: Hi ?ystein, > Hello, and thank you for your answer. > But I think I need to be spoonfed about this? Denis has already provided a good answe. But let me help more with an example. > So according to the rules, the NIC-handle can be something like this: > > ALE-ADMIN-C ? No, you may not have 2 dashes in the NIC handle. You can only have a NIC handle of the form: XXX or XXX-YYY The first part (XXX) has to start with 2-4 letters, and optionally up to 6 digits. The -YYY part is optional, but if present, must be a dash, followed by up to 9 letters. Here are some valid examples: ALE ALE-RIPE ALE1234 AL345-RIPE ALE90-KOMMUNE But the following are NOT allowed: ALE-ADMIN-C AL023 ALESUND Regards, Anand ------------------------------ Message: 2 Date: Sat, 30 Apr 2016 23:25:59 +0200 From: denis <ripedenis(a)yahoo.co.uk> To: Anand Buddhdev <anandb(a)ripe.net>, "'db-wg(a)ripe.net'" <db-wg(a)ripe.net> Subject: Re: [db-wg] Is it possible to choose your own NIC Handle when creating ROLE objects? Message-ID: <572522E7.7030800(a)yahoo.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Hi Anand, ?ystein On 30/04/2016 16:58, Anand Buddhdev wrote: > On 30/04/16 14:02, ?ystein G?sdal wrote: > > Hi ?ystein, > >> Hello, and thank you for your answer. >> But I think I need to be spoonfed about this? > > Denis has already provided a good answe. But let me help more with an > example. > >> So according to the rules, the NIC-handle can be something like this: >> >> ALE-ADMIN-C ? > > No, you may not have 2 dashes in the NIC handle. You can only have a > NIC handle of the form: > > XXX > > or > > XXX-YYY > > The first part (XXX) has to start with 2-4 letters, and optionally up > to > 6 digits. The -YYY part is optional, but if present, must be a dash, > followed by up to 9 letters. Here are some valid examples: > > ALE > ALE-RIPE > ALE1234 > AL345-RIPE > ALE90-KOMMUNE Almost :) But after the '-' you can only use a source name, like 'RIPE, 'APNIC', etc. so ALE90-KOMMUNE is not allowed cheers denis > > But the following are NOT allowed: > > ALE-ADMIN-C > AL023 > ALESUND > > > Regards, > Anand > End of db-wg Digest, Vol 57, Issue 1 ************************************

1 0

Is it possible to choose your own NIC Handle when creating ROLE objects?
by Øystein Gåsdal 02 May '16

02 May '16

Hi I'm trying to create some ROLE objects, but encounter an error: nic-hdl: Syntax error I was told from support that in ROLE and PERSON object, I must use AUTO-1 as NIC handle. This information is not correct for the PERSON object, since I choose my own NIC handle when I created my own PERSON object. So is there a way around this for the ROLE object, too? Thanks. - Øystein

2 1

RIPE DB development process: Numbered Work Items
by Job Snijders 26 Apr '16

26 Apr '16

Dear team, Reflecting back upon the last 18 months, the chairs feel that we as a group can do better to make it easier to track and discuss ideas in a structurered way. Therefore, we propose a process/vehicle which we call "Numbered Work Items (NWI)". The goal of this proces is to make it simpler to learn the current status of a proposal, and in which court the ball lays. kickstart: To kickstart the proces, any db-wg participant can email the chairs with a snippet of text (a rough problem statement) and formally ask the chairs to make it a work item. The chairs then can say "yes" and assign a number, or "no". If a number was assigned, the work item will be routed through three phases. phase 1: problem definition In this phase as group we'll work on formulating an exact problem definition: text goes back and forth in the working group, example cases of the problem are provided. In a 2 or 3 weeks timeframe the chairs declare consensus on the problem statement of NWI. phase 1 output: clearly defined problem statement, or a conclusion we cannot agree upon a problem statement definition. If the latter is true, the NWI cannot proceed to phase 2. phase 2: solution definition solution finding: people can propose solutions to a work item's problem statement. Solutions can come from RIPE NCC staff, or any working group member. RIPE NCC may offer an implementation analysis on proposed solutions or aspects of solutions. For the NWI to move to phase 3, RIPE NCC has to provide the group with a summary of their understanding of the solution, and the chairs declare consensus on the group's acceptance of this summary. phase 3: development & deployment phase RIPE NCC writes the code, sets timelines what happens when, documents the transitions/migration plan if applicable. finish: when the change has been deployed in the production environment. Every month, someone will email the group with an overview of all open Work Items, a brief summary of the NWI, the phase they are in and possibly in who's court the ball is and the next action. Kind regards, Job

6 5

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by AKIL EVLAT 25 Apr '16

25 Apr '16

Hi, From what i understand no changes are going to be made that effects users and no actions have to be taken by the users. But as KKTCELL we would like to know what will the name/abbreviaton change to. What will be the new abbreviations? Are any of the users going to be effected in any way? Or is there such a risk? Kind Regards, AKIL EVLAT KUZEY KIBRIS TURKCELL | KKTCELL TECHNICAL OPERATIONS | PACKET NETWORK SPECIALIST Bedreddin Demirel Cad. Salih Mecit Sok. No:1 PO 883 Lefkoşa / KKTC T: +90 533 850 0175 E: akil.evlat(a)kktcell.com -----Original Message----- From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Tuesday, April 19, 2016 5:17 PM To: ncc-announce(a)ripe.net Subject: [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:" Dear colleagues, We want to let you know about a clean-up that we have been planning with the RIPE Database Working Group (WG) and explain why this is being done. As this is currently being discussed on the WG mailing list, there is still time to comment if you wish. Background ---------------- For a long time, there has been a requirement that the first "descr:" attribute of resource objects that were allocated/assigned by the RIPE NCC must match the name of the organisation that holds the resource. However, these resource objects have also had a reference to the organisation object of the holder of these resources for quite some time, and the RIPE NCC ensures that this organisation object matches what we have in the RIPE Registry. This means that we have been using two parallel approaches to achieve the same goal. Since we began using organisation objects, requiring the organisation name in the “descr:” attribute has become redundant. It creates the potential for a mismatch between the name recorded here and the name on the actual organisation object. It also leads to confusion about where the correct name of the organisation can be found, along with a number of other issues. This has been discussed at length on the RIPE Database WG mailing list and during WG sessions at RIPE 70, 71 and 72. Consensus was reached that going forward: - Organisation names should no longer be enforced in "descr:" attributes - LIRs should be allowed to modify the "descr:” attribute[1] and will be responsible for maintaining this (it will not be verified by the RIPE NCC) - The RIPE NCC should clean up existing cases where the organisation name is enforced - "descr:” should become an *optional* attribute Last Week’s Reverted Clean-up ------------------------------------------ The WG decided that a clean-up was needed to remove any confusion about where the organisation name should be found. Because there are 93,105 objects that need to be updated, it is not practical to send notifications to all of these resource holders individually. As this change was expected to have little operational impact, it was decided that this should be done as a silent update. However, while the WG was informed of our intention to run the clean-up, it was an oversight on our part not to send a notification to the wider RIPE community. We proceeded with our implementation of these changes in the RIPE Database and deployed release 1.86 to production on 21 March. We then communicated our intent to run the clean-up on 11 April to the Database WG[2]. When we ran the update last week, a community member alerted us to a problem and the clean-up was reverted the following day after it was completed[3]. There is now a discussion about how or whether to continue with this clean-up on the RIPE Database WG mailing list[4]. If the WG determines that we should proceed with this, we have a tentative date set for 9 May 2016. We invite you to discuss this further on the mailing list at <db-wg(a)ripe.net> if you have any opinions or concerns that you would like to share. We will also be reviewing our processes to ensure we give adequate notification for such changes in the future. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group [1] "descr:" is currently not editable in the Allocation Object Editor, but will become editable by LIRs in the near future. [2] https://www.ripe.net/ripe/mail/archives/db-wg/2016-March/005136.html [3] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005172.html [4] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005173.html [http://www.kktcell.com/e-fatura/Disclaimer_Banner.jpg]<http://www.kktcell.com> Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir.KUZEY KIBRIS TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve KUZEY KIBRIS TURKCELLin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. ________________________________ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted.KUZEY KIBRIS TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of KUZEY KIBRIS TURKCELL. This e-mail has been scanned for all known computer viruses.

4 5

Phasing out the LIR Portal object editors
by Alex Band 21 Apr '16

21 Apr '16

Dear colleagues, Over the last year the RIPE NCC has been making a considerable amount of incremental changes to the RIPE Database user interface. Especially the implementation of streamlined authentication using RIPE NCC Access has put us in a position where we can further improve the user experience in other areas. As the next step in this process, we intend to phase out the so-called LIR Portal object editors. Currently, the object editors are necessary to allow you to make changes to particular attributes of RIPE Database objects that are maintained by the RIPE NCC. For example, you can use them to change the tech-c and admin-c in the inetnum object for the allocation that you hold. This system has always been the cause of much confusion. User data that you expect to be able to change in the RIPE Database can only be changed through the LIR Portal, whereas other information can be edited in the RIPE Database itself. Our plan is to bring all of this to the place where it belongs and where users expect it, the RIPE Database. The way we intend to do this involves a couple of steps. The first step is to use business rules to determine which attributes you can change, and which ones can only be changed by the RIPE NCC. For example, in an inetnum for an allocation only the RIPE NCC can change the range, but you can change the admin-c and tech-c. The second step is setting the authorisation for the attributes that you control. The RIPE NCC already has a maintainer on the allocation, RIPE-NCC-HM-MNT. In the system we envision, we would allow you to select an additional maintainer, to authorise changes over the attributes that you are authoritative for. You will be able to select this maintainer in the LIR Portal. We will place this maintainer on all existing and new objects that have joint responsibility: allocations for IP resources and the Organisation object. It is important to note that none of these changes have a fundamental impact on the RIPE Database itself. We are only making changes to the business rules and the way you determine authorisation. We look forward to your feedback! Kind regards, Alex Band Product Manager RIPE NCC

2 1

Re: [db-wg] Locking unmaintained PERSON and ROLE objects in the RIPE Database
by Athina Fragkouli 20 Apr '16

20 Apr '16

Dear Denis, all, The RIPE NCC is by default the "data controller" of the personal data in the Database (i.e. it has liability by law) but in practice it has no control over all these personal data. The Data Protection Task Force, representing the RIPE community, decided that this responsibility should be contractually (via the RIPE Database Terms and Conditions) transferred to those that have actual control over the personal data. In the RIPE Database, these persons are identified by the maintainer object (referenced by the “mnt-by:” attribute in any data object). The Data Protection Task Force decided that this attribute should be made mandatory for all objects. This attribute would be used to indicate who is really responsible for specific personal data in the RIPE Database. Additionally, the Data Protection Task Force decided that the RIPE NCC should remove all unreferenced personal data from the RIPE Database. Although the RIPE NCC allowed some time for the community members to add a mandatory "mnt-by:" to their so-far unmaintained personal data, there were still unmaintained personal data in the RIPE Database. The RIPE NCC was alerted by third parties that this data could be hijacked in order to facilitate illegal activities. It was the RIPE NCC's responsibility to inform the RIPE community of this security risk and initiate a community discussion on possible ways to handle it. At the same time, the RIPE NCC could anticipate that if we were merely exposed the security risk without taking any measures to prevent it, we would alert malicious people and the hijacking attempts would increase. Therefore, we considered that locking the objects, until the community could discuss a proper way forward, would be an adequate measure to prevent possible hijacking cases in the meantime, without creating a disproportionate burden for legitimate holders. This action was in line with the RIPE NCC's obligations by law. If people would like to have their locked personal data removed from the RIPE Database, they can submit a request to the RIPE NCC. Kind regards, Athina Fragkouli Head of Legal RIPE NCC References: RIPE Database Terms and Conditions https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms DPTF report https://www.ripe.net/participate/ripe/tf/dp/report-of-the-ripe-data-protect… Data Protection report https://www.ripe.net/about-us/legal/ripe-ncc-data-protection-report Procedure for the Removal of Personal Contact Details from the RIPE Database https://www.ripe.net/manage-ips-and-asns/db/support/documentation/removal-o…

2 1

Re: [db-wg] [ncc-announce] [news] RIPE Database: Cleaning-up Organisation Names in "descr:"
by Marcin Kuczera 19 Apr '16

19 Apr '16

On 2016-04-19 16:17, Tim Bruijnzeels wrote: > Dear colleagues, > > We want to let you know about a clean-up that we have been planning with the RIPE Database Working Group (WG) and explain why this is being done. As this is currently being discussed on the WG mailing list, there is still time to comment if you wish. I strongly support this. Normally there is ORG: in object, that refers to correct owner name. Company names in example in Poland are sometimes complicaded, some forms of company contain all founders names so this is very very long and as DESCR is often used by i.e. SpeedTest - such companies were angry that description displayed was i.e. "BestInternet and partners SVEN, OLAF, ANNA and ELSA" instead of just "BestInternet". So, in my opinion it is good step Marcin > > Background > ---------------- > > For a long time, there has been a requirement that the first "descr:" attribute of resource objects that were allocated/assigned by the RIPE NCC must match the name of the organisation that holds the resource. However, these resource objects have also had a reference to the organisation object of the holder of these resources for quite some time, and the RIPE NCC ensures that this organisation object matches what we have in the RIPE Registry. This means that we have been using two parallel approaches to achieve the same goal. > > Since we began using organisation objects, requiring the organisation name in the “descr:” attribute has become redundant. It creates the potential for a mismatch between the name recorded here and the name on the actual organisation object. It also leads to confusion about where the correct name of the organisation can be found, along with a number of other issues. > > This has been discussed at length on the RIPE Database WG mailing list and during WG sessions at RIPE 70, 71 and 72. Consensus was reached that going forward: > - Organisation names should no longer be enforced in "descr:" attributes > - LIRs should be allowed to modify the "descr:” attribute[1] and will be responsible for maintaining this (it will not be verified by the RIPE NCC) > - The RIPE NCC should clean up existing cases where the organisation name is enforced > - "descr:” should become an *optional* attribute > > Last Week’s Reverted Clean-up > ------------------------------------------ > > The WG decided that a clean-up was needed to remove any confusion about where the organisation name should be found. Because there are 93,105 objects that need to be updated, it is not practical to send notifications to all of these resource holders individually. As this change was expected to have little operational impact, it was decided that this should be done as a silent update. However, while the WG was informed of our intention to run the clean-up, it was an oversight on our part not to send a notification to the wider RIPE community. > > We proceeded with our implementation of these changes in the RIPE Database and deployed release 1.86 to production on 21 March. We then communicated our intent to run the clean-up on 11 April to the Database WG[2]. When we ran the update last week, a community member alerted us to a problem and the clean-up was reverted the following day after it was completed[3]. > > There is now a discussion about how or whether to continue with this clean-up on the RIPE Database WG mailing list[4]. If the WG determines that we should proceed with this, we have a tentative date set for 9 May 2016. We invite you to discuss this further on the mailing list at <db-wg(a)ripe.net> if you have any opinions or concerns that you would like to share. > > We will also be reviewing our processes to ensure we give adequate notification for such changes in the future. > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC Database Group > > [1] "descr:" is currently not editable in the Allocation Object Editor, but will become editable by LIRs in the near future. > [2] https://www.ripe.net/ripe/mail/archives/db-wg/2016-March/005136.html > [3] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005172.html > [4] https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005173.html -- Marcin Kuczera / Specjalista d/s telekomunikacji, Wiceprezes Zarządu +48 32 440 80 71/ marcin.kuczera(a)leon.pl <mailto:marcin.kuczera@leon.pl> Leon Sp. z o.o. ul. Kilińskiego 33d, 44-200 Rybnik http://www.leon.pl/ INTERNET | TELEWIZJA | TELEFON KRS 0000223101 Sąd Rejonowy w Gliwicach Kapitał zakładowy 282.500 zł NIP: 6332068698

1 0

db 1.86 and descr objects
by Peter Hessler 19 Apr '16

19 Apr '16

Hi all New member of the DB-WG here. Some of our objects were affected by the change to the "descr" object. FWIW, I fully support the change to the object type and removing required attributes. HOWEVER, I am EXTREMELY UPSET that my objects were edited without my consent or even a warning. 11 April, clean-up existing "descr:" attributes where the RIPE NCC enforced organisation names In our objects, we wanted to keep our org name in the descr attribute. Having our objects unilaterately changed by RIPE NCC as a "clean up", is frankly not acceptable. And worse, it only affected some of our objects, not all of them as I would have expected. IMHO, the worst part is the "last-modified" field was not updated, nor was a "your object has changed" email generated. Many people use the descr field for things, as an example: the "name" attribute at bgp.he.net. When browsing through the ASes in Germany, I noticed many companies that were likely hit by this (they showed a partial or complete address in the "name" field, instead of the name of the company), including one of the largest ISPs in Germany. I was unable to find a discussion of the _clean-up_ in the WG archives. Why was it decided not to inform the affected members, or even all members via the announce mailing list? Is that a standard policy? -- Left to themselves, things tend to go from bad to worse.

7 9

Release 1.86 deployed to RC
by Thiago da Cruz Pereira 13 Apr '16

13 Apr '16

Dear working group, We have deployed release 1.86 to the Release Candidate environment. With this release we will: = Make "descr:" tribute optional for all object types as discussed in the Database WG. = Prevent RIPE-NCC-RPSL-MNT to be used as mnt-by We encourage all users of the database to test their tools. Kind regards, Thiago da Cruz Software Engineer - RIPE NCC Database Team

2 3

Call for agenda items, DB-WG and planned Routing-DB meeting during RIPE72, Copenhagen, Denmark
by Piotr Strzyzewski 12 Apr '16

12 Apr '16

Dear DB-WG participants It is now only a bit more than a month to the next RIPE Meeting. This is about time to ask you for agenda items. This time we are reaching out to you for agenda items for _two_ sessions during the RIPE72 meeting in Copenhagen, Denmark, 23-27 May 2016: - the usual Database Working Group, - the _planned_ joint Routing-DB session. The DB-WG session is currently scheduled as it was the last time, for Thursday (May 26th), starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. Please be aware that the date and time provided could change as the meeting itself still has the draft plan. The planned joint Routing-DB does not have time and date set up yet. As it was announced by Rob Evans at the Routing-WG mailing list, it purpose is to see if we can actually make some progress around the topic of non-authoritative routing registry information in the RIPE DB. Please submit your items or topic suggestions directly to the WG chairs or to the list for public discussion. The draft agenda will be published soon. Looking forward to see you all in Copenhagen. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

3 2

Locking unmaintained PERSON and ROLE objects in the RIPE Database
by ipmaster＠bt.com 08 Apr '16

08 Apr '16

reg id: uk.bt Dear Trudy Prins, Can you tell me what will happen at present with our current PA assignments to our end customers when we try to register them on the RIPE NCC database against an unmaintained person object. Will it fail, or will it pass and we just get a warning? Or, is the process now as stated in your proposal set out in your email ? Regards Myrna Goedluck BTnet IP Master Team Tel: 0800 085 0223 Option 3 +44 (0)331 666 2729[X] Email: IPMASTER(a)BT.COM British Telecommunications plc Registered Office: 81 Newgate Street London EC1A 7AJ Registered in England no.1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the British Telecommunications plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

2 1

New on RIPE Labs: Improved Syncupdates in the RIPE Database
by Mirjam Kuehne 06 Apr '16

06 Apr '16

Dear colleagues, Over the last couple of months we've been putting a lot of focus on improving the usability of the RIPE Database web interface. We started with tightly integrating our Single Sign-On system, RIPE NCC Access, into webupdates. We added better validation, auto-complete, "diffs", integrated abuse-contact creation, updates in a text-area and many more tweaks and improvements to enhance the user experience. The last big part of the RIPE Database web interface that was left untouched is Syncupdates. Until now... Please find more details on RIPE Labs: https://labs.ripe.net/Members/AlexBand/improving-syncupdates-in-the-ripe-da… Kind regards, Mirjam Kuehne RIPE NCC

1 0