- db-wg - mailman.ripe.net

NWI-4 - role of status: field in multivalued status context
by Job Snijders 27 Jun '16

27 Jun '16

Dear Working Group, (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) NWI-4 --------- The RIPE NCC was tasked with the following action point: AP70.2 [RIPE NCC] Come up with a proposal for the status: field to fix the requirement that certain objects may need multivalued status. Some believe that the main underlying issue here is that it is currently not possible to create an assignment that is the same size as an allocation in the RIPE Database. And resource holders are of course supposed to create an assignment for the address space in an allocation that is in use, by address policy. The main reason for this limitation is that the INET(6)NUM attribute is a primary key. There is a work-around for this problem. Instead of creating an assignment of the same size it's possible to create two smaller assignments instead. In our (red: RIPE NCC) experience this work-around has always been accepted. Still if the allocation is used as a whole, having a single assignment for the whole block is a more accurate reflection of reality, and it reduces the amount of objects to maintain. ---------- The AP70.2 action point refers to a suggest solution, following earlier discussion. But the chairs believe it would be good to bring this back to a clear problem statement first, and then suggest different solutions and their respective benefits and/or problems. Furthermore address-policy wg policies mention the different statuses and what the different statusses reflect. Therefore we'll need to inform the address policy working group as well. If you agree or disagree with this problem statement, please indicate your opinion on this mailinglist. Refinements to the text are welcome too. Kind regards, Job

3 3

NWI-1 - staying on top of abuse contact changes
by Job Snijders 27 Jun '16

27 Jun '16

Dear WG, This is our first Numbered Work Item! We are now in phase 1. (You can review https://www.ripe.net/ripe/mail/archives/db-wg/2016-April/005190.html to ensure you have an overview of the next steps.) The following preliminary problem statement has been put forth by Denis & Piotr: "The resource holder could be unaware of changes made to the abuse contact details for his/her resources. This could happen as a result of any addition, change or deletion of any part of the abuse contact details put in his/her ORGANISATION object ("abuse-c: attribute, referenced ROLE object, "abuse-mailbox:" attribute)." I ask the working group whether they agree with this problem statement, they can identify with the problem, whether the statement needs amendments. Kind regards, Job

3 3

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