- db-wg - mailman.ripe.net

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

14 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 03 May '16

03 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 22 Apr '16

22 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