- db-wg - mailman.ripe.net

Fw: NWI-7 proposal for fixing "abuse-c:" problems
by denis walker 20 Apr '17

20 Apr '17

----- Forwarded Message ----- From: denis walker <dw100uk(a)yahoo.co.uk> To: Havard Eidnes <he(a)uninett.no> Cc: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Sent: Thursday, 20 April 2017, 0:51 Subject: Re: NWI-7 proposal for fixing "abuse-c:" problems Hi Havard Thanks for the response. Let me make a few points here. Firstly I am not trying to justify why such information is required. I asked the question (twice) 'if' this information is required and I got one reply. I am still hoping more people will comment so we can decide if this is required. I put forward this proposal on the assumption that more details are required, based on past discussions, but this may not be the case. Adding "abuse-c:" to resource objects will solve the technical problems in the problem statement. But if that is the solution that we end up adopting then the RIPE NCC MUST provide the tools necessary to manage this hierarchically structured information. After 14 years of working inside this database, analysing what people do with it, 'just' adding "abuse-c:" to resource objects will create a mess within a few years. This is why we created "abuse-c:" in the first place. As you point out the resource holder is ultimately responsible for abuse related to their resources. But many consumers of this abuse contact information don't understand the resource hierarchy or the contractual relationships between the parties. So if we only provide consumers with a single abuse email address and they get no response, they hit a brick wall. This is why I asked the question above. To solve the technical questions we need to know what information consumers need and how best to provide it. cheers denis co-chair DB-WG From: Havard Eidnes <he(a)uninett.no> To: ripedenis(a)yahoo.co.uk Cc: db-wg(a)ripe.net Sent: Wednesday, 19 April 2017, 23:53 Subject: Re: NWI-7 proposal for fixing "abuse-c:" problems Hmm, I'm not entirely happy with this proposal. In brief, I think it overcomplicates matters. It seems to me that this proposal may give rise to creation of "pseudo-organizations" in the RIPE database. I think this will dilute the value of the organization objects, since you can no longer in a reasonable way expect that an organization object in the RIPE database represents a real genuine real-world organization. I agree it's a good idea to provide the default value of the abuse handler via the organization object. What I don't understand is the apparent reluctance to permit per-resource simple overrides of this inheritance, something which could be done by allowing the marking of resource objects with abuse-c pointing to a role object for the abuse handler for the resource. Why insist on an indirection via an organization object for this override? So... I guess I don't understand this justification: > If it is accepted that an email on it's own is not sufficient > information [...] Pointing to an abuse role object via abuse-c provides more than just an e-mail address. > [...] and the clear link to the organisation with responsibility for > handling abuse is also required, then this double indirection is > needed. Can you please expand the justification for why this information is required? Isn't it just as likely that the information provided in such a "must be registered" organization will just be a "pseudo- organization" where the the only thing which causes it to spring into existence is the insistence of the (proposed) RIPE DB data model? Ultimately the responsibility for the use of the resource rests with the organization holding the resource, so that's always a possible recourse should the overriding abuse-c prove to produce non-satisfactory results. Best regards, - Håvard

1 0

NWI-7 proposal for fixing "abuse-c:" problems
by denis walker 19 Apr '17

19 Apr '17

Colleagues Below is a proposal for fixing the problems with "abuse-c:" as shown in the problem statement for NWI-7https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items I look forward to comments. cheers denis co-chair DB-WG Proposal for improving "abuse-c:" Background When abuse contact information was first discussed it was agreed that provision should be made for multiple contact methods, email being just one method. This is why the ROLE object was used to hold the "abuse-mailbox:" attribute. It was decided to reference this abuse ROLE object by an "abuse-c:" attribute in the ORGANISATION object to provide a default option that covered all resources held by an organisation. All resources, including all more specific data, share this contact information in an inherited way. A second reason for setting this up using the ORGANISATION object was to keep a close link between the contact information and the organisation behind those contact details. Without this link, it's just an email address. In that case, unless someone understands the hierarchical nature of resources and the contractual relationships between the parties managing data in the RIPE Database, it's not clear who is behind that email address and responsible for handling abuse. Problem It's clear from the problem statement that some situations cannot be handled with the current arrangement. Mainly because it would require a reference to a second ORGANISATION object from a resource object. This is not possible with the syntax and business rules in the database. There is also a question over the double indirection to get to the abuse contact information, ie resource object -> ORGANISATION object -> ROLE object. If it is accepted that an email on it's own is not sufficient information and the clear link to the organisation with responsibility for handling abuse is also required, then this double indirection is needed. With the right tools it's easy to manage this data. This point is not a technical or operational show stopper. It's more about who needs what information and how do they get it. Proposal I propose introducing a new attribute, "contact-org:" and changing some of the business and syntax rules for the ORGANISATION object. (See below for detailed database changes needed.) For most users where the current default "abuse-c:" mechanism works, nothing will change. For those users who need to specify an alternative abuse contact at some point in a network or for one or more of their allocated/assigned resources it would be a simple process. At the point where the alternative contact details are required add a "contact-org:" attribute referencing a new ORGANISATION object. This new ORGANISATION object will reference the resource holders main ORGANISATION object. If it is the resource holder that is handling the abuse, but from a different department, the new ORGANISATION object can inherit almost everything from their referenced main ORGANISATION object. All that would be needed is a different "abuse-c:" attribute. If it is a separate organisation/person who is handling the abuse, additional information can be entered into the new ORGANISATION object to identify who is behind the abuse contact email address. Query order -For the default situation it remains the same as now, search up the hierarchy to find the "org:" attribute, take the "abuse-c:" from there. -While searching up the hierarchy, if a "contact-org:" is found that references an ORGANISATION object containing an "abuse-c:" attribute, use this. -Where both "org:" and "contact-org:" exist in the same object, "contact-org:" takes precedence. Automation Tools and API calls can be provided to create the necessary extra objects and add attributes where required. To delete the additional abuse contact just remove the "contact-org:" attribute. If the extra objects are not referenced anywhere else it will leave an orphaned 'sub' ORGANISATION object referencing a ROLE object. These pair of objects can be automatically removed by the database garbage process after 90 days. Cleanup A one time cleanup would be needed to replace any "org:" attributes in more specific resource objects with "contact-org:". Also the referenced ORGANISATION objects would need an additional "org:" attribute referencing the resource holders ORGANISATION object. Wider view This mechanism would also work with both "admin-c:" and "tech-c:" attributes. It allows the flexibility to inherit all contact details from the one resource holders ORGANISATION object through to any degree of complexity with any of the contact types. Detailed database changes Make the attributes "address:" and "e-mail:" in the ORGANISATION object optional. Adjust the business rules so that an ORGANISATION object that does not contain an "org:" attribute referencing another ORGANISATION object containing these attributes will be required to have these attributes itself. This keeps things as they are now. Make the "org:" attribute in the ORGANISATION object single instead of multiple. Not sure why it was multiple in the first place. (Quickly checked the split file and it looks like no one uses this attribute in an ORGANISATION object anyway.) Allow an ORGANISATION object to inherit any missing attributes from a referenced ORGANISATION object. Create a new attribute "contact-org:", optional and multiple, in the INET(6)NUM and AUT-NUM objects. This references an ORGANISATION object. Examples Current default situation: The following two objects provide the abuse contact for all the resources held by 'Denis Organisation' including, say, 10.100.0.0/16 organisation: ORG-DO1-RIPE org-name: Denis Organisation org-type: LIR desc: organisation details for Denis Organisation address: Amsterdam phone: 0000000000 e-mail: ripedenis2@yahoo abuse-c: ado18-ripe admin-c: dw-ripe tech-c: dw-ripe mnt-ref: RIPE-NCC-HM-MNT mnt-ref: AARDVARK-MNT mnt-by: RIPE-NCC-HM-MNT mnt-by: AARDVARK-MNT notify: ripedenis2(a)denis.org.uk created: 2017-03-09T13:21:52Z last-modified: 2017-05-20T10:49:27Z source: RIPE role: Abuse Denis Organisation address: NL e-mail: ripedenis2@yahoo abuse-mailbox: abuse(a)denis.org.uk nic-hdl: ADO18-RIPE mnt-by: AARDVARK-MNT created: 2017-05-02T14:19:09Z last-modified: 2017-05-02T14:19:09Z source: RIPE inetnum: 10.100.0.0 - 10.100.255.255 netname: EU-10 country: NL org: ORG-DO1-RIPE admin-c: DW-RIPE tech-c: DW-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: AARDVARK.MNT created: 2017-03-11T11:17:15Z last-modified: 2017-09-23T13:18:26Z source: RIPE Different "abuse-c:" within same organisation - allocation: Suppose 'Denis Organisation' also holds the allocation 10.200.0.0/16 and they want a different department within the same organisation to manage the abuse for this second allocation. They create a second ORGANISATION object (ORG-DOA3-RIPE) with the least amount of data, the rest being inherited from their referenced main ORGANISATION object (ORG-DO1-RIPE). In this new ORGANISATION object they reference the new "abuse-c:" ROLE (aado20-ripe) containing the alternative abuse email address. In the allocation object (10.200.0.0 - 10.200.255.255) they add the new "contact-org:" referencing the new ORGANISATION object (ORG-DOA3-RIPE). If the business situation changes and all abuse is now handled by the default handler, simply remove the "contact-org:" attribute. The additional objects, if unreferenced, will be deleted by the database garbage collector. organisation: ORG-DOA3-RIPE org-name: Denis Organisation Alternative org-type: OTHER org: ORG-DO1-RIPE abuse-c: aado20-ripe mnt-ref: AARDVARK-MNT mnt-by: AARDVARK-MNT created: 2017-03-09T13:21:52Z last-modified: 2017-05-20T10:49:27Z source: RIPE role: Alternative Abuse Denis Organisation address: NL e-mail: ripedenis2@yahoo abuse-mailbox: alternative-abuse(a)denis.org.uk nic-hdl: AADO20-RIPE mnt-by: AARDVARK-MNT created: 2017-05-02T14:19:09Z last-modified: 2017-05-02T14:19:09Z source: RIPE inetnum: 10.200.0.0 - 10.200.255.255 netname: EU-10 country: NL org: ORG-DO1-RIPE contact-org: ORG-DOA3-RIPE admin-c: DW-RIPE tech-c: DW-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: AARDVARK.MNT created: 2017-03-11T11:17:15Z last-modified: 2017-09-23T13:18:26Z source: RIPE Different "abuse-c:" within same organisation - PI: Suppose 'Denis Organisation' also holds the 10.500.0.0/16 as an ASSIGNED PI resource and they want a different department within the same organisation to manage the abuse for this PI resource. The process is exactly the same as above. It is the same for any resource held by the organisation, allocation, PI, ASN. organisation: ORG-DOA3-RIPE org-name: Denis Organisation Alternative org-type: OTHER org: ORG-DO1-RIPE abuse-c: aado20-ripe mnt-ref: AARDVARK-MNT mnt-by: AARDVARK-MNT created: 2017-03-09T13:21:52Z last-modified: 2017-05-20T10:49:27Z source: RIPE role: Alternative Abuse Denis Organisation address: NL e-mail: ripedenis2@yahoo abuse-mailbox: alternative-abuse(a)denis.org.uk nic-hdl: AADO20-RIPE mnt-by: AARDVARK-MNT created: 2017-05-02T14:19:09Z last-modified: 2017-05-02T14:19:09Z source: RIPE inetnum: 10.500.0.0 - 10.500.255.255 netname: EU-10 country: NL org: ORG-DO1-RIPE contact-org: ORG-DOA3-RIPE admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: AARDVARK.MNT created: 2017-03-11T11:17:15Z last-modified: 2017-09-23T13:18:26Z source: RIPE Customer handling their abuse reports: If you assign to a customer who handles their own abuse reports create an ORGANISATION object (ORG-CXO12-RIPE) for the customer, referencing your main ORGANISATION object (ORG-DO1-RIPE). Fill in any details relevant to the customer. Any other details are inherited from your ORGANISATION object. Create the ROLE object (CXA321-RIPE) for the customer's abuse contact details. Add a "contact-org:" attribute to the assignment referencing the customer's ORGANISATION object (ORG-CXO12-RIPE). If the business situation changes and all abuse is now handled by the resource holder, simply remove the "contact-org:" attribute. The additional objects, if unreferenced, will be deleted by the database garbage collector. organisation: ORG-CXO12-RIPE org-name: Customer XYZ Organisation org-type: OTHER org: ORG-DO1-RIPE address: xyz address phone: 0101010101 abuse-c: cxa321-ripe mnt-ref: AARDVARK-MNT mnt-by: AARDVARK-MNT created: 2017-03-09T13:21:52Z last-modified: 2017-05-20T10:49:27Z source: RIPE role: Customer XYZ Abuse address: NL e-mail: info(a)xyz.org.uk abuse-mailbox: abuse(a)xyz.org.uk nic-hdl: CXA321-RIPE mnt-by: AARDVARK-XYZ-MNT created: 2017-05-02T14:19:09Z last-modified: 2017-05-02T14:19:09Z source: RIPE inetnum: 10.100.5.0 - 10.100.5.255 netname: EU-10 country: NL contact-org: ORG-DOA3-RIPE admin-c: DW-RIPE tech-c: DW-RIPE status: ASSIGNED PA mnt-by: AARDVARK.MNT created: 2017-03-11T11:17:15Z last-modified: 2017-09-23T13:18:26Z source: RIPE

2 1

Database release 1.88.1 deployed – bug fix release
by Alex Band 05 Apr '17

05 Apr '17

Dear colleagues, We have identified a bug with the current RIPE Database release which could potentially cause the server to run out ouf memory. We have just deployed version 1.88.1 to resolve this. Please let us know if you have any questions or comments. Kind regards, Alex Band Product Manager RIPE NCC

1 0

Call for Agenda Items DB-WG Meeting - RIPE74 - Budapest, Hungary - 11 May 2017
by William Sylvester 03 Apr '17

03 Apr '17

Dear DB-WG Members This is the call for agenda items for the DB-WG Meeting at RIPE74 at the InterContinental in Budapest, Hungary. Please submit 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<mailto:db-wg-chairs@ripe.net> The DB-WG Meeting is scheduled for Thursday, May 11th, starting at 14:00 local time, after lunch and before the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 74 meeting plan please refer to its most up-to-date version at https://ripe74.ripe.net/programme/meeting-plan/ Looking forward to a successful session in the beautiful city of Budapest. Kind regards, William, Denis, & David

1 1

DMARC issue
by denis walker 23 Mar '17

23 Mar '17

Colleagues The RIPE NCC has applied a mailman work around for DMARC to the DB-WG mailing list. This effectively wraps the sender inside the list address. The only real significance of this is that if you hit Reply the mail goes to the list and not the original sender. So if you want to send a private comment back to the original sender 'off list' you need to either hit Reply All and delete the addresses you don't want or Forward it. cheersdenisco-chair DB-WG

2 2

Re: [db-wg] DMARC issue
by denis walker 23 Mar '17

23 Mar '17

Actually Reply does still work and sends the mail back to the original sender. It does set the Reply-To correctly. I successfully received this post on my yahoo, gmail and xs4all accounts. So from now on no list member's email provider should reject posts to the DB-WG because of DMARC policies. cheersdenisco-chair DB-WG From: denis walker via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Thursday, 23 March 2017, 12:58 Subject: [db-wg] DMARC issue Colleagues The RIPE NCC has applied a mailman work around for DMARC to the DB-WG mailing list. This effectively wraps the sender inside the list address. The only real significance of this is that if you hit Reply the mail goes to the list and not the original sender. So if you want to send a private comment back to the original sender 'off list' you need to either hit Reply All and delete the addresses you don't want or Forward it. cheersdenisco-chair DB-WG

1 0

test message - please ignore
by denis walker 22 Mar '17

22 Mar '17

Apologies for sending this message out but we need to check some issues with the DB-WG mailing list. cheersdenisco-chair DB-WG

1 0

Re: [db-wg] db-wg Digest, Vol 66, Issue 3
by Alexander Stranzky 20 Feb '17

20 Feb '17

> 2. How are updates authenticated? > I'm aware, each object has a "mntner" but how and where is the Maintainer identity part of request to the API? Authentication is done via the maintainer's password. > 3. the Test-DB did not contain any objects related to our company - that's OK. > But could I add them? And how? I guess I may use 'https://apps-test.db.ripe.net/search/lookup.html?source=test&key=TEST-NCC-H…' > Right? There is the test database maintainer (TEST-DBM-MNT) you can use to set up everything using the password "emptypassword". once you have your own maintainer set up, use that one. see also https://github.com/RIPE-NCC/whois/wiki/WHOIS%20REST%20API%20Migration%20Gui… 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 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

2 1

API Documentation
by Andreas Schulze 20 Feb '17

20 Feb '17

Hello, we like to modify RIPE objects using the API under https://rest.db.ripe.net (OK, starting with https://rest-test.db.ripe.net) I found some documentation: - https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API-Update - https://www.ripe.net/manage-ips-and-asns/dns/enum/update-enum-delegation But some points are still unclear to me. 1. Is there any documentation about the database definition, which fields an object must or may have? 2. How are updates authenticated? I'm aware, each object has a "mntner" but how and where is the Maintainer identity part of request to the API? 3. the Test-DB did not contain any objects related to our company - that's OK. But could I add them? And how? I guess I may use 'https://apps-test.db.ripe.net/search/lookup.html?source=test&key=TEST-NCC-H…' Right? Thanks for help and nice weekend! Andreas -- A. Schulze DATEV eG

2 2

changes to the implementation of "abuse-c:" - final problem statement
by denis 08 Feb '17

08 Feb '17

1 0

changes to the implementation of "abuse-c:"
by ripedenis＠yahoo.co.uk 06 Feb '17

06 Feb '17

Colleagues The new co-chairs have prioritized existing and proposed NWIs. Our intent is to reach consensus on open items. We accept that we can't tackle them all at once and we may not address them in numerical order. We would like to start with one that has been discussed for many years, without coming to an acceptable solution, the implementation of the "abuse-c:" attribute. We thoroughly reviewed the working group discussion on the “abuse-c:” attribute, including reviewing Tim's initial draft of a problem statement. We removed the examples to make the problem statement brief and to the point. Anyone concerned with "abuse-c:" has most likely encountered one of these problems and doesn't need quoted examples. We also removed comments on the 'good parts' of the current implementation. That can come back when we discuss pros and cons of possible solutions. Then added in the issue Tobias made about the cleanup. So we end up with the problem statement shown below. Can we agree these are the problems that cause issues with some users? Are there any other problems that anyone has encountered? cheers Denis co-chair DB-WG Problem statement on "abuse-c:" implementation: =============================================== It is currently not possible to specify alternative abuse contacts for different resources in the RIPE Database held by different parts of the same organisation. It is currently not reasonably possible to specify alternative abuse contacts for resources in the RIPE Database assigned to organisations other than the parent organisation. In many circumstances these organisations are customers of the parent organisation. The lower organisation wishes to handle the abuse separate from the parent organisation. After the introduction of "abuse-c", the "abuse-mailbox:" attribute in the PERSON, MNTNER, ORGANISATION and IRT objects was intended to be deprecated. This cleanup was never done and the old data causes confusion to users manually searching the database.

7 11

changes to the implementation of "abuse-c:"
by Alexander Stranzky 17 Jan '17

17 Jan '17

> For a handful of customers that is not difficult, although some still > believe it is over complicated. If you have tens or hundreds of > customers wanting to handle abuse complaints themselves, then it moves > into the 'unreasonable' zone if all this has to be handled manually. For what does the RIPE have a REST API (and programmers that know how to use it)? We have to handle RIPE data for 2K+ customers, without the API that would indeed end in the least possible approach. But there are libraries out there that can be used so we can do abuse handling the intended way (via Org/Role). So maybe we should promote this API (and list client libraries that work with it) way more than today, to tell people that it is not that complicated to get it right. cheers, Alex -- 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 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

2 1

mntner object updates by mail
by Ulf Kieber 02 Jan '17

02 Jan '17

Dear DB WG members, there currently exists a somewhat tricky deadlock situation in updating mntner objects. Envision the following object: mntner: XOO-MNT admin-c: XOO-RIPE upd-to: kieber(a)xoo.net auth: PGPKEY-B490673F # Ulf Kieber auth: PGPKEY-XXXXXXXX # Somebody Else mnt-by: XOO-MNT source: RIPE Now, XOO is a large, distributed organisation and Someone Else eventually starts adding a bunch of auth: SSO # Filtered None of those SSO accounts is certainly mine. How am I going to update this mntner object without removing those SSO accounts? The issue here is: There is no way of retrieving the SSO account information from the mntner object without an SSO auth on it. Proposal: Add a way to retrieve mntner objects from the DB by encrypted mail (public key PGPKEY-B490673F is already in the database). PS: Mail updates may seem arcane to some, but I've done registry mergers of some 20000 object registries pretty fast that way. Regards, -- Ulf Kieber

4 3

Re: [db-wg] mntner object updates by mail
by Alexander Stranzky 02 Jan '17

02 Jan '17

> Mail updates have 2 reasons to exist: > - massive, bulk updates that would otherwise take too long to execute; > - fire & forget, just send in the update and it would get processed > eventually no matter what. > > In the age of REST APIs, neither of the above stands anymore. > Currently mailupdates is kept as a fallback and/or legacy interface. IIRC, there is an update limit for the current REST API (something like 2000 updates per day) > I think what you really want is being able to authenticate via REST > API, so that you would be able to query and update your own objects > without any kind of dummification or accounting process. Maybe even be > able to use an APIKEY over https for a simple way of authentication? the REST API uses the maintainer password via HTTPS. see also https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API for further details. there are also some client libraries for the REST API out there. Best regards, Alex -- 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 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

1 0

Reverse DNS Wizard Improvements
by Alex Band 23 Dec '16

23 Dec '16

Dear colleagues, If you don't want to read all the details below, here is a single screenshot that explains the improvements we just launched: https://labs.ripe.net/Members/AlexBand/reverse-dns-real-time-checks A few weeks ago we announced a new wizard for setting up Reverse DNS. When creating a new DOMAIN object you will be taken to it automatically: https://apps.db.ripe.net/webupdates To refresh your memory, a one-minute demo of the wizard is online: https://youtu.be/7JzapYkca-Y After analysing the usage since the launch, we have identified several improvements we could make to the name server pre-checks. I'm happy to announce these are now live. When entering name servers for your reverse zones, we will now do the following real-time checks: - Syntax checks to ensure no illegal characters are used - Verify if a fully qualified domain name is entered and not an IP address - Test if the name server responds on port 53 using both UDP and TCP - Check if the name server is authoritative for the reverse zone Only if these tests are passed the wizard will allow the user to submit the form, after which the full set of checks is performed by the back-end service. By giving immediate feedback, we drastically reduce the amount of errors users generate and the time required to complete the process successfully. In the error messages, we also link to the documentation for an in-depth explanation and troubleshooting steps. We are confident these improvements will greatly enhance the user experience. If you have any questions or feedback, please do not hesitate to let us know! Kind regards, Alex Band Product Manager RIPE NCC

2 1

Thanks to Nigel
by Niall O'Reilly 20 Dec '16

20 Dec '16

On 20 Dec 2016, at 14:42, Piotr Strzyzewski wrote: > Thank you for this hard work. It was always amazing how fast delivered > and accurate your minutes are. It continually amazed me too. Thanks for a great job, Nigel! Niall

1 0

WG Chairs Selection
by ripedenis＠yahoo.co.uk 20 Dec '16

20 Dec '16

Hi All I would like to clarify one point about my candidacy. Whilst it is no secret that I would love to improve the database design and model, that is a personal view and I accept that it is not well supported within the community. There is a time and place for such proposals and this is not the time. The next group of chairs have a growing list of important issues on the table already and that should be the focus. cheersdenis

11 14

Upgrading servers to address memory issues, intermittent outage in mailupdates
by Tim Bruijnzeels 07 Dec '16

07 Dec '16

Dear working group, Following the outage we experienced on 26 November we determined that a an in-memory cache was the cause. We have disabled this cache, and allocated more memory to the whois application process. We also determined that the whois process and the back-end database need more memory. For this reason we are fast-tracking the deployment of new hardware and extending the memory in the servers that we use. Unfortunately the deployment of two new servers led to a failure to deliver some of the mails sent to auto-dbm(a)ripe.net, the Mailupdates service for Whois, from approximately 12:00 UTC on Tuesday 6th December to 16:30 UTC on Wednesday 7th December. Any failure resulted in a reply with the Subject "Mail delivery failed: returning message to sender". Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

1 0

WG Chairs Selection
by scott donald 06 Dec '16

06 Dec '16

Hi all, I agree with Nigel that some continuity would be good, so Piotr would get my vote. I also think Denis has deep knowledge of the RIPE Database over many years and his experience would be very useful in the 3 person team. I would also say that David's experience at the RIPE NCC dealing with LIR questions on all aspects of RIPE Database functionality gives him a a very useful insight in how to improve it for the future for the users. Kind regards, Scott Donald Comms-care

2 1

as-set fileds
by Shahin Gharghi 05 Dec '16

05 Dec '16

Hello I was working with RIPE DB to export as-set objects. I downloaded as-set database from FTP server. There were a lot of comments and extra unused information in the members field. So it's difficult to work with this object as a third party software. -- Shahin Gharghi

1 0

RIPE WHOIS down?
by Patrick Velder 29 Nov '16

29 Nov '16

Hi there I just tried to use the RIPE WHOIS but it looks like it's currently down: on terminal: > patrick@patrickhome:~$ whois 185.117.xx.0 > connect: Connection refused web whois: > Proxy Error > > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request GET /search/query.html. > > Reason: Error reading from remote server Anyone else? Regards Patrick

4 3

WG Chairs Selection
by Piotr Strzyzewski 25 Nov '16

25 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 this year. 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. As you may know, Job Snijders decided at the RIPE73, last week, to step down. Moreover, Nigel Titley declare that when a new chair is found, he would like to step down as well. This means, that the only reason Nigel is staying on, is not to leave the WG with only one chair. Taking this opportunity, I would like to express my interest in being co-chair for another term. All the best, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

22 43

New wizard for setting up Reverse DNS
by Alex Band 24 Nov '16

24 Nov '16

Dear colleagues, I'm exited to announce that the Software Engineering and Global Information Infrastructure departments have collaborated to provide a wizard for setting up Reverse DNS. The wizard replaces the form for creating RIPE Database objects manually, so when creating a new DOMAIN object you will be taken to it automatically: https://apps.db.ripe.net/webupdates A one-minute demo of the Reverse DNS wizard is online: https://youtu.be/7JzapYkca-Y Requesting reverse delegation for your zones has always been notoriously error prone, causing more user errors and support tickets than the creation of any other RIPE Database object. In order to maximise ease of use and success rate, we implemented the following features: - We present the user with a clear set of guidelines for the configuration of their name servers before starting the wizard - Manually creating reverse zones is no longer necessary, as you can simply fill in a prefix and the wizard will do the rest - Creating DOMAIN objects one by one is no longer necessary, as you can create up to 128 DOMAIN objects in one go - We perform a basic check on the name server before the full set of tests is run, to maximise the chance of success Please keep in mind that this is the first iteration of this functionality. We will now start gathering feedback and will run analytics to see how it can be improved further. For example, the current name server pre-checks are very basic and we can expand them in the future if needed. We are using Zonemaster for these checks and are in the process of migrating the full set of tests to this service. We’d like to thank IIS and AFNIC for their support. In case you are interested in the background story on the Reverse DNS wizard and Zonemaster, there are some presentations from RIPE 73 online: https://ripe73.ripe.net/archives/video/1517/ https://ripe73.ripe.net/archives/video/1511/ Kind regards, Alex Band Product Manager RIPE NCC

1 0

[training] RIPE NCC Training Courses January-March 2017
by Training Services 23 Nov '16

23 Nov '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Barcelona, London, Lebanon, Turin, Hamburg, Moscow, Riga, Turkey, Nicosia, Tashkent, Ljubljana, Oslo. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR and RIPE Database Training Course - DNSSEC Training Course - Measurements Tools Training Course - Basic IPv6 Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Workinggroup Chair Job Description
by Hans Petter Holen 22 Nov '16

22 Nov '16

I see in the ongoing discussion in the chair selection process that there has been some questions regarding the role and commitments of the chair: The "Job Description" can be found in RIPE 542: "Working Group Chair Job Description and Procedures" https://www.ripe.net/publications/docs/ripe-542 As others have stated, it is not necessarily for the chair to be present at every single RIPE meeting. It is however always good to meet in person, at the WG meeting, the WG chairs lunch and informally with other chairs, RIPE NCC staff and myself. While I have enjoyed virtual life for close to 30 years - I do still see the value of meeting in person now and then. -- Sincerely, Hans Petter Holen, RIPE Chair

3 2