- db-wg - mailman.ripe.net

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by David Hilario 21 Apr '17

21 Apr '17

Hi Denis, On Thursday, April 20, 2017, 7:34:50 PM GMT+8, denis walker via db-wg <db-wg(a)ripe.net> wrote: > I think you misunderstood the point about email being (in)sufficient information. I agree almost all abuse reports come via email. My >point was, what happens if the complainant gets no response to the email complaint? If the email address is all the information they >have, then they hit a brick wall. They don't know what organisation, company, individual sits behind that email address. But again, if this >is the way we move forward then we have to put our business analyst and software engineering hats on and solve the problem by >providing better information to consumers of this data. To be fair, no one can actually tell who should be contacted as the "abuse" can be of so many kinds, the definition of abuse itself never even reached any firm definition I believe. Who should be contacted, in a somewhat relevant order: The registration information in the Assignment itself? The registration information in any intermediate layer found between an assignment and an allocation? The LIR that issued the Assignment? The sponsoring LIR, in case of PI? The AS announcing the space? The sponsoring LIR of the AS number announcing the space? The peering AS numbers? The RIPE NCC? The other RIRs?**end of RIPE Database scope of information**For other RIRs, repeat all of the above and add NIRs for some of them just to get extra complexity for everyone... Their local LEAs? >From either policy, Database or real life point of view, all the above are valid contacts and can be relevant in reporting abuse depending on its nature. So other than allowing/enabling an easy way for RIPE Database users that want clear ways of getting abuse report and to get that registered and displayed on queries, I don't believe it is in the power of anyone to guess where the abuse report should go. When a user does not understand hierarchical delegation queries the Database, they also probably have no clue of route announcements, sponsoring LIRs, RIR system and so on, the educational part will be quite big then. I do believe that that educational information part can be made available in a simple language so that the ones who really care, can learn and crawl through the complex hierarchy and policies and the others will just give up or contact someone they know to do it for them. Keep in mind as well that no DB data input policy or rules will ever make the "abuser" care about any reports they might receive, this discussion is only for the people who care about receiving reports, it would help a bit for the ones reporting when getting in touch with good networks and will have no effects ion reporting to "abusers" on bad networks. On the proposed solution with contact-org, one of the main complaints was the need to create an org Object per abuse-email, it is not alleviating that issue. Let's not make the life of good network harder, it should be simple to manage these contact details, have an abuse-mailbox: added to inetnum could be a simple solution, LIR portal gives you an overview of all your registered objects primary keys and the abuse email linked to them. If you want to change that, click edit/restore default/add and change the email, the first time that you replace the default value a small pop-up informing you that an abuse-mailbox: will be added to the object to replace the default abuse-c: value, done. No need to learn a new Org object hierarchy or how to make mass updates to the RIPE Database to change the abuse email for your cloud services and keep the "old" abuse email for your ISP services. People who would prefer to do this via email/sync/webupdate, can still do it as well, no problem, it isn't breaking any systems. Does anyone know if PI holders have access to an LIR portal like system? Cheers David Co-chair DB-WG From: Sebastian Wiesinger via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Thursday, 20 April 2017, 11:47 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems * denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > 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. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > 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. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

2 1

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by denis walker 20 Apr '17

20 Apr '17

Hi Sebastian Thanks for the comments. This proposal is just an idea that would preserve some of the benefits of the "abuse-c:" design, but I am not going to push hard for it. However, let me at least clear up some of the points you made. (Sorry for it all being top posted but yahoo doesn't allow for inline comments.) We already have "sponsoring-org:", so a "contact-org:" would be fine. Indirection and inheritance can sometimes involve complexity at the raw data level, but all of that complexity can be hidden behind simple to use tools. So I don't think that in itself is a show stopper. "Instead just adding an "abuse-c:" field to an object is easily understandable."I agree this is easily understandable. But it breaks one of the principles of the "abuse-c:" design...the "abuse-c:" attribute only exists in one place, the ORGANISATION object. Now it will be in four object types...ORGANISATION, INETNUM, INET6NUM, AUT-NUM. Before we implemented "abuse-c:" the "abuse-mailbox:" attribute was allowed in five object types...PERSON, ROLE, MNTNER, ORGANISATION, IRT. This created the mess that lead to the design of "abuse-c:" But if this is the way we go forward then we can avoid previous pitfalls with good management tools. I think you misunderstood the point about email being (in)sufficient information. I agree almost all abuse reports come via email. My point was, what happens if the complainant gets no response to the email complaint? If the email address is all the information they have, then they hit a brick wall. They don't know what organisation, company, individual sits behind that email address. But again, if this is the way we move forward then we have to put our business analyst and software engineering hats on and solve the problem by providing better information to consumers of this data. Bottom line....it is the intention of the DB-WG co chairs to resolve the issues stated in the problem statement on this round of talks. We will accept the consensus view of the community in these talks. If there is a clear consensus to add "abuse-c:" to resource objects, that is what we will ask the RIPE NCC to implement. I just want to be sure people understand the issues, both operational and technical, before making their decision. Once the decision is made, if there are other issues that may come up as a consequence, then we will solve those issues....but we must move this problem towards a resolution this time. cheers denis co-chair DB-WG From: Sebastian Wiesinger via db-wg <db-wg(a)ripe.net> To: db-wg(a)ripe.net Sent: Thursday, 20 April 2017, 11:47 Subject: Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems * denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > 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. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > 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. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [db-wg] NWI-7 proposal for fixing "abuse-c:" problems
by Sebastian Wiesinger 20 Apr '17

20 Apr '17

* denis walker via db-wg <db-wg(a)ripe.net> [2017-04-18 16:11]: > Colleagues Below is a proposal for fixing the problems with > "abuse-c:" as shown in the problem statement for > NWI-7 https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items > > I look forward to comments. Hello Denis, thank you for this. I've read it three times now to understand how it it works and I think this underlines what I tried to say in the original problem statement: The problem statement looks good to me, I only would like to comment that the current way seems *too* complicated / bloated for a lot of people. So a solution should aim to be more "lightweight" for lack of a better word. That might happen naturally when tackling the problem statement but nontheless I would like to mention it. So... I don't think this will make it easier to understand or implement for people who just want to add an abuse contact and subsequently will not improve abuse contact information in the database. > 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. Also the RIPE NCC has stated that it does not want two ORG-IDs for an enduser. If this goes forward I think it would be a good idea to have at least a statement from the RIPE NCC that they would be okay with an enduser having multiple chained organisation objects for this. > 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. I think it is a show stopper. You have to understand the logic and implement the tools. Many LIRs will shy away from that. Instead just adding an "abuse-c:" field to an object is easily understandable. As for email being not sufficient information, in the last 10+ years I cannot remember a single abuse complaint that was not done via email. The only exception might be some special cases that directly involve law enforcement or such, and for those the main ORG object should be enough. To sum it up, I don't think that this approach will make it easier to add and maintain abuse information in the database and as such will not improve the goal of having accurate and up-to-date abuse contact information. I would not support the proposal in this form. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

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