November 2015 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

WG Chairs Selection
by Piotr Strzyzewski 16 Nov '16

16 Nov '16

Dear DB-WG Members As agreed during DB-WG session at RIPE69 Meeting in London on 06.11.2014, the WG Chair Selection procedure is executed at yearly intervals. This means that it is about time to run it for the very first time. This is the call for interested parties. Interested parties have 2 weeks to make their interest known on this mailing list. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. After two weeks the chairs will declare consensus. Since there is a limit of 3 co-chairs, if at the end of the discussion phase there will be more than 3 proposed co-chairs then a call will be made for any of the candidates to withdraw. If there still will be more than 3 candidates then names will be put into a hat and the first three names drawn from the hat will take on the role of chairs for the next 12 months. All three of present co-chairs expressed their interest in being co-chairs for another term. All the best, Job, Nigel & Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

9 11

Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working group, There is an open action point on us regarding the use of the RIPE-NCC-RPSL-MNT maintainer: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004626.html > I'd like to ask RIPE NCC to provide the group with an implementation > plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from > being used to authenticate updates to an object after the object has > been created. We also ask that the RIPE NCC look into cleaning up > existing references to RIPE-NCC-RPSL-MNT and tell us their plan. Note that there is an ongoing an important parallel discussion about the authorisation of out-of-region IRR objects in general. But this is specifically about the use of 'RIPE-NCC-RPSL-MNT' on "mnt-by:". As long as we do have RIPE-NCC-RPSL-MNT, there are things we can improve and we want to propose the following to working group: 1) implement a business rule to prevent that this maintainer is used as 'mnt-by' Submitting an object that includes 'mnt-by: RIPE-NCC-RPSL-MNT' would result in a hard error, with a message like: "The RIPE-NCC-RPSL-MNT is used to authorise the creation of out-of-region aut-num and route(6) objects, but may not be used as 'mnt-by'" This is fairly trivial to implement, provided of course that the working group agrees to this. 2) remove the maintainer from existing objects There are roughly 2000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' only, and about 10000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' and at least one other maintainer. In the first case we propose to lock the object, i.e. set 'mnt-by: RIPE-NCC-LOCKED-MNT', and send out a custom notification to any contacts on the object explaining that the object has been locked to prevent a hijack of the object, and that ripe-dbm(a)ripe.net can be contacted to unlock the object. In the second case we propose to leave the remaining maintainer and send out a custom notification informing contacts on the object that the "RIPE-NCC-RPSL-MNT" has been removed to prevent a hijack of the object, and listing which maintainer(s) remain. Technically this is not difficult either, but it can result in a lot of questions. Therefore we prefer to do this in batches to make sure that we can process possible follow up requests to ripe-dbm(a)ripe.net properly. For reference we used a similar approach when dealing with locking the old MD5 passwords earlier this year. Provided that the working group agrees with this, we expect this can be done in the space of a few weeks after the business rule is implemented. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14

Implementation proposal descr line
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working groups, Following discussion in this group it was decided that the RIPE NCC should stop enforcing that the first "descr:" attribute of resource objects reflects the name of the organisation, for resources that it alloced or assigned. This practice has been place for a long time, but now that all such objects have a reference to an organisation object and the RIPE NCC ensures that this reflects the resource requests, this is no longer needed. Furthermore it was decided that the RIPE NCC should clean up existing organisation names in "descr:" attributes in order to: (1) avoid confusion about where the organisation name should be found; (2) avoid that the names here are different from the name of the actual organisation; (3) make it very clear which attributes are verified by RIPE NCC, and which attributes are not. Hereby the RIPE NCC would like to propose an implementation plan for these changes. We invite the working group to review and discuss if needed. As soon as the working group co-chairs formally call consensus, we can proceed to implement shortly. Implementation proposal: ======================== = Change "descr:" to an 'optional multiple' attribute We believe that the working group concluded that it would be appropriate to make "descr:" optional. The reason is that when the organisation name is cleaned up, there may be no description lines left. The working group considered whether the attribute should be 'single optional', but there seemed to be no strong preference for this, and it would have a bigger impact. Therefore we propose to go for the easier option of making it 'optional multiple'. Technically this change is not hard to do on the server side, but can impact users of the database because there may be no "descr:" attribute, and this can affect parsers. Because this can have an impact on automated systems the RIPE NCC will announce this change ncc-announce(a)ripe.net, and use a longer week staging period in the Release Candidate environment allowing users to test and update their systems. Dependent on formal consensus call we may be able to combine this with the upcoming release for deprecating "changed:" phase 3, to avoid delays. = Clean up existing "descr:" attributes where RIPE NCC enforced the organisation name The RIPE NCC will remove the "descr:" attributes that it has been enforcing. = Add "descr:" to allocation object editor in LIR Portal So that LIRs can edit this themselves. = Stop setting the "descr:" on new allocations or assignments done by the RIPE NCC We will leave "descr:" blank. It can be edited by the LIR or end-user later.

8 14

Re: [db-wg] [members-discuss] ripe objects as single text field
by Alex Band 02 Feb '16

02 Feb '16

Hello everyone, I would just like to clarify a couple of things on the redesigned user interface, based on the feedback we have received so far. First of all, these are the URLs to all of the different parts of the RIPE Database web ui, as it seems some people are getting a bit lost: Query: https://apps.db.ripe.net/search/query.html Create using single text field: https://apps.db.ripe.net/db-web-ui/ Create/Update using multiline text area: https://apps.db.ripe.net/syncupdates/simple-rpsl.html In addition, the TEST database user interface now has its own dedicated URL, instead of having to select it with a radio button: https://apps-test.db.ripe.net/ The option to edit an existing object in a single text area is functionality that was used very infrequently according to our statistics. We decided to leave it out of the first phase of the redesign, as most people use email or scripting to update the RIPE Database in a single text area. If there is a lot of demand, we'll implement that option as well for the web interface as well. Please keep in mind that it not impossible to edit an existing object in a single text area, it is simply a two-step process. You can copy and paste the object you queried into Syncupdates and go from there. This update method will allow you to use your SSO account to authenticate as well, if it is associated with your maintainer. Lastly, I realise "Syncupdates" is not the most descriptive name ever. We will make sure that we have a look at the wording of the different menu items to avoid confusion. Kind regards, Alex Band Product Manager RIPE NCC > On 25 Nov 2015, at 11:28, Andy Betts <A.Betts(a)node4.co.uk> wrote: > > Yep, I just discovered that feature had been removed (or really well hidden) this morning. > > Please bring it back. > > Regards > Andy > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of David Wilkinson > Sent: 24 November 2015 17:06 > To: Tapio Haapala; members-discuss(a)ripe.net > Subject: Re: [members-discuss] ripe objects as single text field > > Hi Tapio, > > Looks like they have removed it. I can't see away to use the single text update either. (Unless both of us are blind) > > That is quite annoying as to update some records it was easier to edit via the single text area than adding each attribute one by one. > > Regards > > David > > > -----Original Message----- > From: members-discuss [mailto:members-discuss-bounces@ripe.net] On Behalf Of Tapio Haapala > Sent: 24 November 2015 16:42 > To: members-discuss(a)ripe.net<mailto:members-discuss@ripe.net> > Subject: [members-discuss] ripe objects as single text field > > Signed PGP part > I was just adding domain objects to DB. Suddenly that ui ask me to login again. After that I did not find way to add objects via single text fied. > Can someone check that do they really remove one of most used feature at whole portal or is it just me who is blind or dumb? > > -- > F-Solutions Oy > > Tapio Haapala > > PL7, 90571 Oulu > GSM 0400 998371 > Skype burner- > IRC Burner@ircnet<mailto:Burner@ircnet> > > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/ > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/ > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. > > ________________________________ > This email has been scanned inbound by Node4's Email Security System. > ________________________________ > This email message has been delivered safely and archived online by Mimecast. > ________________________________ > > *************************************************************************************************************************************************** > Node4 Limited is registered in England No: 04759927 and has its registered office at Millennium Way, Pride Park, Derby, DE24 8HZ > The information contained in this email is confidential and is intended for the exclusive use of the email addressee shown. > If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. > If you have received this mail in error, please notify our mail manager at abuse(a)node4.co.uk and delete it from your system. > Opinions expressed in this email are those of the individual not the company, unless specifically indicated to that effect. > > > > This email has been scanned by Node4's Email Security System. > > This email message has been delivered safely and archived online by Mimecast. > **************************************************************************************************************************************************** > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/ > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses.

7 9

anyone using the RIPE Databse MUST now have an SSO account?
by ripedenis＠yahoo.co.uk 02 Dec '15

02 Dec '15

Hi guys When was it discussed, agreed or announced that Webupdates will no longer allow objects to be created or updated with a password? As Webupdates is the only way to access an unfiltered version of your own MNTNER object, it is no longer possible to even retrieve a version of your own MNTNER without signing up for an SSO account. I did not realise this has become mandatory. So has it been agreed that SSO is the only authorisation method allowed to access the RIPE Database? Did I miss the announcement that passwords and PGP are being deprecated? cheersdenis

6 6

revisiting rpsl-related set of rcf documents?
by Wilfried Woeber 26 Nov '15

26 Nov '15

Following up on the discussion here, during the DB-WG session in Bucharest, where changes to different aspects of using the RIPE registry database - including a reference to discussions relating to cross-RIR authorisation - I'd like to ask the following question to the community: Is it about time to revisit the set of RFCs and either get them updated to properly reflect the (more) current reality, or consciously have them declared historic and overtaken by events? What's your point of view? Thanks, Wilfried

6 7

RIPE TEST DATABASE REST INTERFACE PROBLEM
by PRANEETH, MANASVI 25 Nov '15

25 Nov '15

Hi, I have created a maintainer EIPAM-MNT for testing the ripe rest in Test system. But looks like the query/update function is not working through rest Interface. Can you confirm whether the RIPE REST is working for TEST database. [cid:image001.png@01D125DE.B2187610] Request sent: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <whois-resources> <objects> <object type="INET6NUM"> <source id="TEST"/> <attributes> <attribute name="inet6num" value="2001:1be0:1000:1e::/64"/> <attribute name="netname" value="EIPAMGUYATT"/> <attribute name="descr" value="EIPAMGUYATT"/> <attribute name="country" value="US"/> <attribute name="admin-c" value="EP1-TEST"/> <attribute name="tech-c" value="EP1-TEST"/> <attribute name="status" value="ASSIGNED"/> <attribute name="mnt-by" value="EIPAM-MNT"/> <attribute name="mnt-lower" value="TEST-DBM-MNT"/> <attribute name="source" value="TEST"/> </attributes> </object> </objects> </whois-resources> Response received: Errormessage part: <errormessages> <errormessage severity="Error" text="Authorisation for [%s] %s failed using "%s:" no valid maintainer found "> <args value="inet6num"/> <args value="2001:1be0:1000:1e::/64"/> <args value="mnt-by"/> <args value=""/> </errormessage> <errormessage severity="Error" text="The maintainer '%s' was not found in the database"> <args value="EIPAM-MNT"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="tech-c" value="EP1-TEST"/> <args value="EP1-TEST"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="mnt-by" value="EIPAM-MNT"/> <args value="EIPAM-MNT"/> </errormessage> <errormessage severity="Error" text="Unknown object referenced %s"> <attribute name="admin-c" value="EP1-TEST"/> <args value="EP1-TEST"/> </errormessage> <errormessage severity="Info" text="To create the first person/mntner pair of objects for an organisation see https://apps.db.ripe.net/startup/"/<https://apps.db.ripe.net/startup/%22/>> </errormessages> Thanks, Manasvi praneeth Nannapaneni INSTAR-EIPAM Development/office:(636) 544-5448/mp418b(a)att.com<mailto:(636)%20544-5448/mp418b@att.com>

2 2

Database release 1.83 deployed to RC environment
by Alex Band 24 Nov '15

24 Nov '15

Dear colleagues, We are happy to announce the deployment of RIPE Database software release 1.83 to the Release Candidate (RC) environment, which has gone live on Friday 30 October. This release is still focussed on seamlessly integrating RIPE NCC Access (SSO) into the webupdates user interface. In addition, several other changes have been made, such as: - Webupdates will show full object details by default - Partial route object creation has been greatly improved, indicating which maintainer needs to complete the authorisation - When deleting a person object, you will be prompted to also delete the associated maintainer if it has no other dependencies - When trying to delete an object that is still referenced, you will get a list of blocking objects - Auto-complete of person, role and organisation attributes is now available throughout the interface - The TEST database now has its own URL instead of having to be selected with a radio button Please let us know if you have any questions or comments. Kind regards, Alex Band Product Manager RIPE NCC

3 4

RIPE 72 minutes
by Nigel Titley 19 Nov '15

19 Nov '15

Folks Here is the first cut at the minutes. Comments (and particularly complaints about missing/additional action points) to me All the best Nigel

1 0

RIPE 71 DB-WG agenda V4
by Piotr Strzyzewski 19 Nov '15

19 Nov '15

Dear DB-WG Members This is the 4th draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, 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 Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 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. Database Updates (Tim Bruijnzeels, RIPE NCC) [~30 min] . operations . new functionality . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects . personalised authentication C. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] D. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] E. Afrinic IRR (Michel Odou) [~10 min] Afrinic IRR homing project update (Tim Bruijnzeels, RIPE NCC) [~10 min] F. ROUTE object authorisation update (Job Snijders) [~5 min] G. Control over associating objects for number blocks (William Sylvester) [~5 min] X. Heads up about recent discussions at db-wg mailing list 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

Bootstraping a new private whois instance
by CUBIC, SCOTT 18 Nov '15

18 Nov '15

Hi all, I'm new to the db-wg, and I'm just beginning to explore the code from https://github.com/RIPE-NCC/whois.git. I'd like to use the code to run a private whois server to integrate with our Infoblox IPAM system. I've cloned the repository and followed the instructions posted at https://github.com/RIPE-NCC/whois/wiki/Installation-instructions . The instructions, however, don't include any details on 'priming' the whois database - using the SQL from the whois-commons/target/classes/<database>_schema.sql files, I get all my databases and tables created, but there is no data in the tables. I'm assuming that I need to have at least a 'mntner' in the WHOIS_LOCAL/mntner table, and I added a single entry manually with an object_id of 0, but I still can't seem to use any update method (synchupdates, REST, etc.) to add new information to the database. Would it be possible to get a push in the right direction for manually populating the WHOIS database with enough stuff (user IDs, passwords, etc.) to begin using the APIs to modify the database? Regards, Scott Cubic cubic(a)att.com<mailto:cubic@att.com>

2 1

Control over associating objects for number blocks
by William Sylvester 18 Nov '15

18 Nov '15

Dear Database Working Group Members, At the last RIPE meeting we discussed the topic of orphaned objects, and it seems that this term was confusing to some. This is an attempt to clarify the problem and hopefully find a solution forward. This continues to be a problem where number block holders are getting “locked” out of being able to manage their routing objects and in-addr records. Today, we continue to have a problem where a block holder does not have an ability to manage the objects that operationally impact their number blocks. Examples include a routing or reverse dns object that exist in the database but are not currently maintained by an active number block maintainer. This is typically the case where a number block holder (usually legacy) may have contracted services through a third party. Time goes by, the business relationship ends but the third party never removed their associated records (in-addrs, routing objects, etc). The number block holder now seeks to update the block (either directly or through a new service provider) and is unable to add these resource records to their number block. The database can help fix this problem through allowing the appropriate control for a number block holder to maintain their own information. In many cases the last resort is to contact RIPE NCC to make the change to an object the number block holder should have had online access to manage directly in the first place. This proposal intends to enable number block holders to have a greater ability to manage their own resources. I propose that the maintainer of a number block shall have full control over the association of contacts, routing, and reverse dns entries related to the number block held. The number block holder should not be able to delete an object they do not have maintainer status for, but they should be able to remove the association from their number block. The number block maintainer shall have an ability to delete the relationship between a related object and the number block through the LIR Portal, Webupdates, and related systems. Open items to discuss; 1) What is the best method to enable a number block holder to manage and control objects associated with their blocks in Ripe DB? 2) Should any objects be excluded from this control? 3) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester(a)addrex.net<mailto:william.sylvester@addrex.net>

5 12

Solving the issue of rogue ROUTE objects in the RIPE Database
by denis 14 Nov '15

14 Nov '15

Hi All I raised an idea before the last RIPE Meeting but it did not generate a lot of interest at that time. I brought it up again yesterday on the Anti Abuse WG list and it seemed to get quite a bit of support. So I will bring it back to the DB WG as it is a DB issue. I have CC'ed both AA WG and Routing WG for information. But it may be useful to keep the discussion now on the DB WG list. I don't claim this will solve all the problems of the universe, but it does satisfy an immediate goal to have all ROUTE objects in the RIPE Database created with the knowledge and approval of the related resource holders. And I believe it could be implemented in a relatively short space of time giving immediate benefits. cheers denis STEP 1 Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation. The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database. STEP 2 For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications. Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object. STEP 3 On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database. STEP 4 This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received, delete the ROUTE object from the RIPE Database. We can be a bit more generous on the timing for this step and even send multiple reminder notifications to be sure. (Possible) STEP 5 If a delete request is sent to the RIPE Database for a ROUTE object related to out of region address space without the proper authorisation, send a notification to the contacts for the authoritative address space holder. If an appropriate response is received back, delete the ROUTE object. This would simulate the reclaim functionality for RIPE address space holders. AUT-NUM copies Another byproduct of implementing this is that we no longer need to hold copies of AUT-NUM objects in the RIPE Database. The out of region ASN auth requirement is satisfied by the appropriate response to the notification. So all 'foreign' AUT-NUM objects could be immediately deleted. (Or after allowing time for these ASN holders to make sure their routing policy is actually up to date in the authoritative AUT-NUM object.)

10 25

RIPE 71 DB-WG agenda V3
by Piotr Strzyzewski 13 Nov '15

13 Nov '15

Dear DB-WG Members This is the 3rd draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, 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 Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 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. DB Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~10 min] (proposed, test, deployment) . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~10 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] Afrinic IRR (Michel Odou) [~10 min] H. ROUTE object authorisation update (Job Snijders) [~5 min] I. Control over associating objects for number blocks (William Sylvester) [~5 min] X. Heads up about recent discussions at db-wg mailing list 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] Solving the issue of rogue ROUTE objects in
by Sascha Luck [ml] 06 Nov '15

06 Nov '15

the RIPE Database Reply-To: In-Reply-To: <563CC2EB.2040509(a)inex.ie> X-Operating-System: FreeBSD 10.1-RELEASE On Fri, Nov 06, 2015 at 03:10:35PM +0000, Nick Hilliard wrote: >On 06/11/2015 14:00, Sascha Luck [ml] wrote: >personal information is not exported for route: objects, >therefore this does not apply: That's the point Nick, for "verification" of out-of-area contacts, this information would *have* to be exported. In this scheme from other RIRs to the NCC but it would, if the others implemented similar schemes, also be exported from the NCC to other RIRs. rgds, Sascha Luck > >> remarks: **************************** remarks: * >> THIS OBJECT IS MODIFIED remarks: * Please note that all >> data that is generally regarded as personal remarks: * >> data has been removed from this object. remarks: * To >> view the original object, please query the RIPE Database at: >> remarks: * http://www.ripe.net/whois remarks: >> **************************** > >Nick >

1 0

RIPE 71 DB-WG agenda V2
by Piotr Strzyzewski 05 Nov '15

05 Nov '15

Dear DB-WG Members This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE71 at the JW Marriott Bucharest Grand Hotel in Bucharest, Romania. The DB-WG Meeting is scheduled as usual for Thursday, Nov 19th, starting at 14:00 local time, after the lunch break. The length of our timeslot is 90 minutes. For the overall RIPE 71 meeting plan please refer to its most up-to-date version at https://ripe71.ripe.net/programme/meeting-plan/ Although the agenda is fully packed right now, 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 Bucharest. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 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. DB Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New and revised DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~10 min] (proposed, test, deployment) . "changed:" deprecation . Implementation proposal descr line . restrict usage of RIPE-NCC-RPSL-MNT . other aspects D. Personalised authentication update (Tim Bruijnzeels, RIPE NCC) [~20 min] E. Updated Database documentation (Alex Band, RIPE NCC) [~10 min] F. Routing policies vs. reality in BGP (Tomas Hlavacek) [~15 min] G. Afrinic IRR homing project update (Job Snijders/Tim Bruijnzeels, RIPE NCC) [~10 min] H. ROUTE object authorisation update (Job Snijders) [~5 min] I. Control over associating objects for number blocks (William Sylvester) [~5 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] Database release 1.83 deployed to RC environment
by Alexander Stranzky 02 Nov '15

02 Nov '15

Am 02.11.15 um 12:00 schrieb db-wg-request(a)ripe.net: > Dear colleagues, > > We are happy to announce the deployment of RIPE Database software release 1.83 to the Release Candidate (RC) environment, which has gone live on Friday 30 October. > > - When deleting a person object, you will be prompted to also delete the associated maintainer if it has no other dependencies Does this affect REST API calls in any way? > - When trying to delete an object that is still referenced, you will get a list of blocking objects How does the REST API implement that? Does it send the objects along the error message(s) or can either part be omitted? Best regards, Alexander Stranzky -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181-1898119 * Fax: +49 6181-1898117 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

2 1