- db-wg - mailman.ripe.net

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
by Lu Heng 09 Oct '17

09 Oct '17

A On Mon, Oct 9, 2017 at 21:48 denis walker via db-wg <db-wg(a)ripe.net> wrote: > Colleagues > > This has been discussed many times with many views expressed. We are sure > lots of you are bored with commenting on this issue. Unfortunately no > consensus has yet been found. So we would like to take it back to the basic > question and see if we can get a conclusive answer. This is not a question > specifically about the Afrinic homing project. It's a more general question > about the RIPE Database providing this 'feature'. Even if you have > commented before, please do so once more so we can get a definitive answer > to this question. I know there is a tendency to say nothing if someone else > has made the point you support. But this time we do need numbers. So even > if what you are thinking has been said, please at least add a +1 so we know > you also agree with that point. > > Question - Should the RIPE Database allow creation of ROUTE objects for > non RIPE resources? > > We see three most likely answers to this question. Each possible answer > does have consequences. > > A: Yes the RIPE Database should allow creation of ROUTE objects for non > RIPE resources. If this is the answer then we can look at how to make the > data more trusting in the short term (and there may be ways to do that). > > B: No the RIPE Database should not allow creation of ROUTE objects for any > non RIPE resource. If this is the answer then maybe we need to look at a > project to remove all non RIPE resource related ROUTE(6)/AUT-NUM objects > from the RIPE Database and disable the feature. But that needs to look at > what to do with ROUTE objects for prefixes from one region and ASNs from a > different region. > > C: Just leave things as they are. Don't promote the service but no > projects to remove any data from the RIPE Database either. Just drift along > on the principle "if it ain't broken, don't fix it". This also means > document this as the answer to this question and no more discussions. Of > course any problems associated with this feature don't go away. > > > I will briefly review the discussions over the last 2 years: > > At the update given at RIPE 72 for the removal of the data starting with > the Afinic homing project, there was no consensus and a call for more > comments on the mailing list. A discussion continued on the mailing list > until October. There was both support and opposition to removing these > objects from the RIPE Database. One point raised during this discussion > regarding the Afrinic homing project was, "I believe that what is needed > here most of all is a clear message from both communities that it is > desirable to have the ROUTE(6) objects for AFRINIC space in the AFRINIC IRR > where the registered resource holders can properly authorise objects." No > one has yet referred to a declared consensus of opinion by the Afrinic > community to the removal of these objects from the RIPE Database. Also > during this discussion Afrinic said that they have not yet worked out all > the fine details of the proposed move of this data. Several issues were > raised on the technicalities of moving this data and it was said in the > discussion that no one has yet even done the analysis to see if any of > these conditions exist (like duplicate, but different data in both > databases). > > At the update given at RIPE 73, there was still no consensus. The RIPE NCC > and Afrinic were asked to do a check on what could go wrong and who members > could contact in the event of things going wrong. This doesn't seem to have > been done. The RIPE NCC suggested they may be able to produce a video or > webinar about the transfer. This doesn't seem to have been done either. The > call was again made that both the RIPE and Afrinic communities re-state > that they both want this project to go forward. That has not happened. It > was said that Afrinic is the first of many RIRs that may want data > transferred out of the RIPE Database. Is it the RIRs or the communities > that want this? The only question raised in the meeting was opposed to the > transfer. No discussion followed on the mailing list. > > At RIPE 74 there was no update on this issue. > > The next discussion wasn't until July 2017. In this discussion there was > mention of developing a global IRR database with a couple of supporters. We > all know such ideas often take years to be agreed on, designed and > implemented as a practical solution. We want to answer this question in > relation to the situation today. There were some pointers made back to > previous mailing list discussions, but nothing else new was said. > > cheers > denis > co-chair DB WG > -- -- Kind regards. Lu

1 0

Foreign ROUTE objects in RIPE Database - final decision?
by denis walker 09 Oct '17

09 Oct '17

Colleagues This has been discussed many times with many views expressed. We are sure lots of you are bored with commenting on this issue. Unfortunately no consensus has yet been found. So we would like to take it back to the basic question and see if we can get a conclusive answer. This is not a question specifically about the Afrinic homing project. It's a more general question about the RIPE Database providing this 'feature'. Even if you have commented before, please do so once more so we can get a definitive answer to this question. I know there is a tendency to say nothing if someone else has made the point you support. But this time we do need numbers. So even if what you are thinking has been said, please at least add a +1 so we know you also agree with that point. Question - Should the RIPE Database allow creation of ROUTE objects for non RIPE resources? We see three most likely answers to this question. Each possible answer does have consequences. A: Yes the RIPE Database should allow creation of ROUTE objects for non RIPE resources. If this is the answer then we can look at how to make the data more trusting in the short term (and there may be ways to do that). B: No the RIPE Database should not allow creation of ROUTE objects for any non RIPE resource. If this is the answer then maybe we need to look at a project to remove all non RIPE resource related ROUTE(6)/AUT-NUM objects from the RIPE Database and disable the feature. But that needs to look at what to do with ROUTE objects for prefixes from one region and ASNs from a different region. C: Just leave things as they are. Don't promote the service but no projects to remove any data from the RIPE Database either. Just drift along on the principle "if it ain't broken, don't fix it". This also means document this as the answer to this question and no more discussions. Of course any problems associated with this feature don't go away. I will briefly review the discussions over the last 2 years: At the update given at RIPE 72 for the removal of the data starting with the Afinic homing project, there was no consensus and a call for more comments on the mailing list. A discussion continued on the mailing list until October. There was both support and opposition to removing these objects from the RIPE Database. One point raised during this discussion regarding the Afrinic homing project was, "I believe that what is needed here most of all is a clear message from both communities that it is desirable to have the ROUTE(6) objects for AFRINIC space in the AFRINIC IRR where the registered resource holders can properly authorise objects." No one has yet referred to a declared consensus of opinion by the Afrinic community to the removal of these objects from the RIPE Database. Also during this discussion Afrinic said that they have not yet worked out all the fine details of the proposed move of this data. Several issues were raised on the technicalities of moving this data and it was said in the discussion that no one has yet even done the analysis to see if any of these conditions exist (like duplicate, but different data in both databases). At the update given at RIPE 73, there was still no consensus. The RIPE NCC and Afrinic were asked to do a check on what could go wrong and who members could contact in the event of things going wrong. This doesn't seem to have been done. The RIPE NCC suggested they may be able to produce a video or webinar about the transfer. This doesn't seem to have been done either. The call was again made that both the RIPE and Afrinic communities re-state that they both want this project to go forward. That has not happened. It was said that Afrinic is the first of many RIRs that may want data transferred out of the RIPE Database. Is it the RIRs or the communities that want this? The only question raised in the meeting was opposed to the transfer. No discussion followed on the mailing list. At RIPE 74 there was no update on this issue. The next discussion wasn't until July 2017. In this discussion there was mention of developing a global IRR database with a couple of supporters. We all know such ideas often take years to be agreed on, designed and implemented as a practical solution. We want to answer this question in relation to the situation today. There were some pointers made back to previous mailing list discussions, but nothing else new was said. cheers denis co-chair DB WG

1 0

Work Items, Ideas & Documentation
by Brian Nisbet 04 Oct '17

04 Oct '17

Colleagues, At RIPE74 I (foolishly?) agreed to spend a bit of time trying to come up with a proposal on how to try to better document and record the decisions made in regards to ideas or work items brought to the WG. This was especially in relation to ideas that the WG may not be enthusiastic about. There is something potentially simple (and I understand the issues even with saying that) which is just an extension of/adherence to a process that's already in place. There is already a new thread started for any NWI, but a lot of these are left hanging with no new inputs. So perhaps it's as easy as saying that the Chairs, sorry folks, need to make sure those loops are closed. They can be closed with "the Working Group did not feel the proposal should be carried forward" but maybe something more. I am sensitive to the delicate nature of some of this and I hope we could maybe put in more detail to fend off the habit of returning to the same points? If a proposal doesn't even become an NWI maybe a reference in the WG Meeting minutes is enough, or maybe a quick separate mail would be useful (and might generate conversation). I know some of this is contained in the minutes but I'm not foolish enough to believe that everyone reads them (nor am I claiming I always do). So what I'm proposing is that there is an action on the Chairs to make sure an NWI thread is closed with some type of conclusion and that other proposals are extracted from the minutes and a clear result (even if there are scant details) is recorded. I'm not sure if this deals with Denis' issues, but it seems reasonably straight forward to implement and may help. Brian -- Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Randy Bush 04 Oct '17

04 Oct '17

> I haven't seen any reply to Nick's email from either David or any of > the co-Chairs. Now maybe lots is going on in the background, but that > would seem strange. > > I find the situation concerning, but what I find even more concerning > is the complete lack of response from any of the WG Chairs. <aol> barring self correction, alternative actions seem a bit strong for the culture. but that is where it seems to be heading. sad. randy

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Brian Nisbet 03 Oct '17

03 Oct '17

Afternoon, I haven't seen any reply to Nick's email from either David or any of the co-Chairs. Now maybe lots is going on in the background, but that would seem strange. I find the situation concerning, but what I find even more concerning is the complete lack of response from any of the WG Chairs. Can I ask if there are plans to address this in any way shape or form and, if not, why not? Thanks, Brian Brian Nisbet Network Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 On 25/09/2017 12:51, Nick Hilliard via db-wg wrote: > It would be good if David took the opportunity to explain what he did > and how / whether it's compatible with being co-chair of DBWG. David, It's been two weeks since someone alleged that you were sending spam. Do you have any plans to address this issue? Nick

1 0

Fw: [db-wg] Fw: NWI-7: abuse-c implementation plan modification
by denis walker 03 Oct '17

03 Oct '17

Hi Tim, colleagues No one has expressed any serious concerns over this small change. I think we can safely go ahead and only send the one email notification in these cases when you change the objects. cheersdenisco-chair DB-WG ----- Forwarded Message ----- From: denis walker via db-wg <db-wg(a)ripe.net> To: Database WG <db-wg(a)ripe.net> Sent: Wednesday, 27 September 2017, 11:55 Subject: [db-wg] Fw: NWI-7: abuse-c implementation plan modification Colleagues I think the suggestion below from Tim is OK. There seems little point sending notifications to users about changes they don't need to take action on of data that is redundant. So if anyone has any strong objections please let us know by the end of this week. Otherwise we can give Tim the go ahead to this modification to the implementation plan. cheersdenisco-chair DB-WG From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Sent: Wednesday, 30 August 2017, 21:32 Subject: Re: [db-wg] NWI-7: abuse-c implementation plan Dear working group, We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line: > 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) > > In these cases we propose to send a warning email to the holders of these objects with the following main message: > > “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." > > And then 4 weeks later we will preform the clean-up and refer back to this communication. On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice.

2 1

Re: [db-wg] Fw: NWI-7: abuse-c implementation plan modification
by Peter Hessler 27 Sep '17

27 Sep '17

My traditional response to any modification of the database: As long as a notification that the objects were modified is sent, I have no objections. On 2017 Sep 27 (Wed) at 09:56:09 +0000 (+0000), denis walker via db-wg wrote: :Date: Wed, 27 Sep 2017 09:44:42 +0000 (UTC) :From: denis walker <ripedenis(a)yahoo.co.uk> :To: Database WG <db-wg(a)ripe.net> :Subject: Fw: [db-wg] NWI-7: abuse-c implementation plan modification : :Colleagues : : :I think the suggestion below from Tim is OK. There seems little point sending notifications to users about changes they don't need to take action on of data that is redundant. So if anyone has any strong objections please let us know by the end of this week. Otherwise we can give Tim the go ahead to this modification to the implementation plan. :cheersdenisco-chair DB-WG : : From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> : To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> : Sent: Wednesday, 30 August 2017, 21:32 : Subject: Re: [db-wg] NWI-7: abuse-c implementation plan : :Dear working group, : :We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line: : : :> 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) :> :> In these cases we propose to send a warning email to the holders of these objects with the following main message: :> :> “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." :> :> And then 4 weeks later we will preform the clean-up and refer back to this communication. : :On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice. :

1 0

Fw: [db-wg] NWI-7: abuse-c implementation plan modification
by denis walker 27 Sep '17

27 Sep '17

Colleagues I think the suggestion below from Tim is OK. There seems little point sending notifications to users about changes they don't need to take action on of data that is redundant. So if anyone has any strong objections please let us know by the end of this week. Otherwise we can give Tim the go ahead to this modification to the implementation plan. cheersdenisco-chair DB-WG From: Tim Bruijnzeels via db-wg <db-wg(a)ripe.net> To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Sent: Wednesday, 30 August 2017, 21:32 Subject: Re: [db-wg] NWI-7: abuse-c implementation plan Dear working group, We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line: > 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) > > In these cases we propose to send a warning email to the holders of these objects with the following main message: > > “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." > > And then 4 weeks later we will preform the clean-up and refer back to this communication. On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice.

1 0

Whois release 1.90 in Release Candidate environment, production release planned for 16 October
by Tim Bruijnzeels 27 Sep '17

27 Sep '17

Dear working group, RIPE Database Release 1.90 was deployed to the Release Candidate Environment, last week on 22 September 2017. If no issues are raised, we plan to deploy this version to production on Monday 16 October 2017 Release 1.90 introduces the following main features in support of NWI-7 (abuse-c implementation): = Allow adding an "abuse-c:" attribute to INET(6)NUM and AUT-NUM objects = Disallow adding "abuse-c:" to object types other than ROLE, INET(6)NUM and AUT-NUM Release 1.90 contains a number of small improvements: = Make org-name validation case-sensitive (no longer consider case changes a no-op) = Support to remove generated AUT-NUM "remarks:" regarding legacy status The complete list of other minor issues solved by this release can be found here: https://github.com/RIPE-NCC/whois/blob/master/changes.txt Please let us know if you see any issues with this release in the RC environment. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technical Officer RIPE NCC

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Nick Hilliard 27 Sep '17

27 Sep '17

Clement Cavadore via db-wg wrote: > While there are many examples where spammers uses RIPE DB, more > specifically when it comes to "IPv4 reselling market", I think that it > is unacceptable to tolerate such a behavior from a chair (and/or from > anyone from his company). A (co-)chair should fight against such > practices, especially from his or her co-workers. It would be good if David took the opportunity to explain what he did and how / whether it's compatible with being co-chair of DBWG. Separately, if people have received spam from Larus, they should complain to the RIPE NCC. Nick

2 2

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by ripedenis＠yahoo.co.uk 14 Sep '17

14 Sep '17

Hi Nick Let's not single anyone out here, perhaps people should report spam to the RIPE NCC from 'any' broker offering deals on address space. Cheers Denis Co-chair DB-WG -------------------------------------------- On Thu, 14/9/17, Nick Hilliard via db-wg <db-wg(a)ripe.net> wrote: Separately, if people have received spam from Larus, they should complain to the RIPE NCC. Nick -----Inline Attachment Follows-----

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Henriette Van Ingen 14 Sep '17

14 Sep '17

Dear Elvis, You asked us the following question: “can you please present a report showing how many LIRs have reported RIPE DB T&C violations? How many were resolved and what was the outcome? - Specifically, how many times has the RIPE NCC taken any action other than a warning message.” Since September 2016, the RIPE NCC has received ten reports regarding the abuse of contact data in the RIPE Database, thereby violating the RIPE Database Terms and Conditions. - We sent warning emails to the parties that were reported. - We sent two of these parties a second warning. - One party continued to violate the RIPE Database Terms and Conditions. We ultimately terminated the Broker Agreement between this party and the RIPE NCC on the grounds of multiple violations of the RIPE Database Terms and Conditions. Regards, Henriette van Ingen Assistant Manager Customer Services RIPE NCC > On 12 Sep 2017, at 09:42, Elvis Daniel Velea via db-wg <db-wg(a)ripe.net> wrote: > > > From: Elvis Daniel Velea <elvis(a)velea.eu> > Subject: violation of DB T&C by DB-WG co-chair, is it acceptable? > Date: 12 September 2017 at 00:33:12 GMT+2 > To: db-wg(a)ripe.net > Reply-To: elvis(a)velea.eu > > > Dear RIPE NCC, > > can you please present a report showing how many LIRs have reported RIPE DB T&C violations? How many were resolved and what was the outcome? > > - Specifically, how many times has the RIPE NCC taken any action other than a warning message. > Dear DB-WG, should we accept that one of the chairs of this WG is purposely violating the T&Cs of the RIPE DB? > > Please see below one of the e-mails received from David, the RIPE DB-WG co-chair, by a RIPE NCC member named <company>. > (I'd like to mention that <company> has never had a business relationship with Larus Cloud Service Limited, has never subscribed to any mailing list and has never requested the message below - which I find to be spam as it was never solicited). > > regards, > > elvis > From: Larus Team <vendors(a)laruscloudservice.net> <mailto:vendors@laruscloudservice.net> > Subject: Unused IPv4 space of <company> > Dear Colleagues, > > We are contacting you regarding potential unused IPv4 address currently registered to your organisation <company>. > > Organisations like yours have in the past received address IPv4 space, it sometimes remains unused after changes to networks. Based on the available information it appears that your organisation is currently holding IPv4 space that appears unused or underutilised. > > We would like to offer you the possibility to capitalise on these addresses, we can assist you in either finding organisation to permanently transfer (sell) towards, or assist you in finding and forging long term relationships with some of our clients by leasing the unused space to them, generating a long-term income. We are a company based in Hong Kong, our CEO Heng Lu, has over ten years’ experience in managing Internet resources across the globe. Our IP manager David Hilario previously worked for the RIPE NCC one of the five RIR and as such has an intricate knowledge of the policies in the RIR policies especially when it comes to transfers and leasing the address space. > > We have clients lined up waiting for permanent transfers or long-term lease, so we can fulfil any of your requirements. > > We offer clients with available IP space a 3 months exclusivity contract. based on your requirements, we will match our waiting list clients with your criteria so that your IP space can be capitalise as soon as possible at the best possible rate. Please note that if you are leasing out your address space, we will offer it on a minimum of yearly basis with advance payment from our clients. > > Please find attached to this email our NDA to be filled in from your side and returned to us before we can proceed any further in our cooperation in regard to these transfers or long-term lease. We can lease and sell IP space to and from ARIN (North America) APNIC (Asia Pacific) and RIPE NCC (Europe, Middle East and parts of Central Asia). > > Kind Regards, > David Hilario > > IP Manager > Larus Cloud Service Limited > > p: +852 29888918 m: +359 89 764 1784 > f: +852 29888068 > a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR > w: laruscloudservice.net > e: d.hilario(a)outsideheaven.com <mailto:d.hilario@outsideheaven.com> > > Larus Team > www.laruscloudservice.net <http://sctrack.mail.laruscloudservice.net/track/click/eyJ1c2VyX2lkIjogNDE4M…> >

1 0

Re: [db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Clement Cavadore 14 Sep '17

14 Sep '17

Dear all, On Thu, 2017-09-14 at 04:08 +0200, Elvis Daniel Velea via db-wg wrote: > The questions stand. > I am curious to see what the rest of the wg members think. While there are many examples where spammers uses RIPE DB, more specifically when it comes to "IPv4 reselling market", I think that it is unacceptable to tolerate such a behavior from a chair (and/or from anyone from his company). A (co-)chair should fight against such practices, especially from his or her co-workers. DB is not meant for a marketing and advertising usage. And if any company is caught the hand in the honey pot, it should be publicly shamed/unsubscribed/banned from reading DB contact infos/whatever. -- Clément Cavadore

1 0

re:[db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Anne-vivien Paris 14 Sep '17

14 Sep '17

Hi Elvis, Regarding your claim that our company misuses operation emails, we would like to address the issue in the following as it deeply affects our company's image as well as customer's credibility for us: 1. Although David sent the email, he is not the one who decides the recipient list. This is decided by the marketing team. 2. As a company which fully upholds fairness and respects customers ‘privacy, Larus NEVER uses any operation emails or technical emails for commercial use. The emails we used for commercial purpose are only those that are open to public. Please let us know if there is any misunderstanding. 3. We also respect our customer's privacy by implementing a un-subscription policy. Customers can unsubscribe anytime at their liberty. Larus never sends spam emails to our customers nor misuse any operation emails. Every employee of Larus follows strictly this policy. We do not tolerate any improper behaviour within the company as well as any false claims. Please do not hesitate to contact us in private if you find an operation email is used for commercial purpose.

3 2

re:[db-wg] violation of DB T&C by DB-WG co-chair, is it acceptable?
by Anne-vivien Paris 13 Sep '17

13 Sep '17

Hi Elvis, Regarding your claim that our company misuses operation emails, we would like to address the issue in the following as it deeply affects our company's image as well as customer's credibility for us: 1. Although David sent the email, he is not the one who decides the recipient list. This is decided by the marketing team. 2. As a company which fully upholds fairness and respects customers ‘privacy, Larus NEVER uses any operation emails or technical emails for commercial use. The emails we used for commercial purpose are only those that are open to public. Please let us know if there is any misunderstanding. 3. We also respect our customer's privacy by implementing a un-subscription policy. Customers can unsubscribe anytime at their liberty. Larus never sends spam emails to our customers nor misuse any operation emails. Every employee of Larus follows strictly this policy. We do not tolerate any improper behaviour within the company as well as any false claims. Please do not hesitate to contact us in private if you find an operation email is used for commercial purpose.

1 0

Draft Agenda RIPE75 - Database Working Group
by William Sylvester 11 Sep '17

11 Sep '17

Dear all, Below is the draft outline for the Database Working Group agenda for RIPE75. If you have any questions or comments please let the chairs know. Best regards, William, David, Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database - 40 mins Tim Bruijnzeels, RIPE NCC C. Update on DB-WG mailing list challenges - 5 mins D. NWI - Open Proposals - 10 mins E. Identifier Technology Health Indicators (ITHI) - 20 mins Alain Durand, ICANN Z) AOB (open discussion)

1 0

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by Horváth Ágoston János 11 Sep '17

11 Sep '17

Hi all, Agreed that a yearly email ping-pong is not really a good verification of abuse contact address. It's trivial to let RIPE NCC mails through and throw away the rest. But, one might ask, what's the point of a database if the data is not reliable? What's the point of all that contact info if we can't trust it? Why would we want to store (and serve) data that is not correct? Data validation is standard industry practice, pretty much everywhere. You can't even buy a bar of chocolate without validating your email address. One might ask, why would RIPE NCC not follow even the most basic industry practices while validating data of this importance? Cheers, Agoston On Thu, Sep 7, 2017 at 6:54 PM, Sascha Luck [ml] via db-wg <db-wg(a)ripe.net> wrote: > > > ---------- Forwarded message ---------- > From: "Sascha Luck [ml]" <dbwg(a)c4inet.net> > To: db-wg(a)ripe.net > Cc: anti-abuse-wg(a)ripe.net > Bcc: > Date: Thu, 7 Sep 2017 17:54:04 +0100 > Subject: Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes > All, > > I will discuss this here as I do not accept the Anti-Abuse WG as > a forum for this proposal. For one thing, this proposal affects > every ripedb user - in fact, as this entails changes to how the > NCC provides services, the services-wg would be an even better > venue. For another, given the "population" and culture of > "debate" on the AAWG, any "consensus" reached there would be so > worthless as to be farcical. (If anyone wants amplification on > this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/ > provides ample evidence. > > To the meat of the proposal: > > Firstly, this proposal conflicts somewhat with NWI-7 in this very > WG. (Another reason why it should have gone here in the first > place) With the upcoming possibility of delegating abuse-c: to > (customers') resource objects, who bears any consequences of > these customers not replying to this proposed email? >> >> Rationale >> a. Arguments supporting the proposal > > >> Accurate and validated information in the RIPE Database is >> essential to establish a trusted and transparent environment in >> which all network operators can operate safely. > > > abuse-c: is a contact object, just as admin-c: or tech-c: and > (correct me if I'm wrong) audited at the same time as the rest of > the contact information. What makes it so unique that this > verification is not enough? > >> Accurate and >> validated information helps Internet troubleshooting at all >> levels, but it also helps to attribute malicious online >> activities that undermine this trusted environment. > > > See above. > >> The lack of reliable accurate and validated information in the >> database negatively impacts legitimate uses of the RIPE Database, >> including: > > > An *email adress* that doesn't reply once a year does NOT equate > to a "lack of reliable accurate and validated information". I > find this statement somewhat insulting to the NCC team who do > make the effort to keep the ripedb data accurate and do audit > resource holders. > There is an issue with the reliability of out-of-region and > legacy resource data but as the NCC has no "enforcement" powers > over these resource holders, in these cases this proposal > snatches at thin air. >> >> Assuring the security and reliability of the network by >> identifying points of contact for IP addresses for network >> operators, ISPs, and certified computer incident response teams; > > > "org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist. > >> Ensuring that IP address holders are accountable, so individuals, >> consumers and the public are empowered to resolve abusive >> practices that impact safety and security; >> Assisting businesses, consumer groups, healthcare organisations >> and other organisations that are combating fraud (some of which >> have mandates to electronically save records) to comply with >> relevant legal and public safety safeguards; > > > The contact object that does (or *should*) stand for the person(s) who > can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role > account in a NOC or even a ticket system unlikely to have any > decision-making power. An attempt to make these roles (perhaps > even personally) responsible for the behaviour of a LIR and its > customers is counter-productive. I for one would flatly refuse to > do any abuse report handling under these circumstances. > >> Complying with national, civil and criminal due process laws in >> support of investigations and providing justice for victims. > > > Would the proposers please amplify exactly which law or due > process is violated by the NCC not sending an email once a year > to an abuse-c:? Myself, and I'm sure the NCC legal team, would be > interested to know. > > On a technical note, email is neither a secure nor a reliable > transport for such verification. In the day of blocklists and > large email providers imposing arbitrary restrictions on email > senders it is not guaranteed that a verification email reaches > the intended address or that a reply reaches the sender. The NCC > ARC procedure, however employs both email and personal contact > via telephone to verify the accuracy of the ripedb information. > > In toto, this proposal would impose unneccessary work on LIRs and > the NCC, using unsuitable means to rectify a non-existing issue, and I therefore oppose it. > >

1 0

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by Sascha Luck [ml] 10 Sep '17

10 Sep '17

All, I will discuss this here as I do not accept the Anti-Abuse WG as a forum for this proposal. For one thing, this proposal affects every ripedb user - in fact, as this entails changes to how the NCC provides services, the services-wg would be an even better venue. For another, given the "population" and culture of "debate" on the AAWG, any "consensus" reached there would be so worthless as to be farcical. (If anyone wants amplification on this, https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/ provides ample evidence. To the meat of the proposal: Firstly, this proposal conflicts somewhat with NWI-7 in this very WG. (Another reason why it should have gone here in the first place) With the upcoming possibility of delegating abuse-c: to (customers') resource objects, who bears any consequences of these customers not replying to this proposed email? >Rationale >a. Arguments supporting the proposal >Accurate and validated information in the RIPE Database is >essential to establish a trusted and transparent environment in >which all network operators can operate safely. abuse-c: is a contact object, just as admin-c: or tech-c: and (correct me if I'm wrong) audited at the same time as the rest of the contact information. What makes it so unique that this verification is not enough? >Accurate and >validated information helps Internet troubleshooting at all >levels, >but it also helps to attribute malicious online >activities that undermine this trusted environment. See above. >The lack of reliable accurate and validated information in the >database negatively impacts legitimate uses of the RIPE Database, >including: An *email adress* that doesn't reply once a year does NOT equate to a "lack of reliable accurate and validated information". I find this statement somewhat insulting to the NCC team who do make the effort to keep the ripedb data accurate and do audit resource holders. There is an issue with the reliability of out-of-region and legacy resource data but as the NCC has no "enforcement" powers over these resource holders, in these cases this proposal snatches at thin air. >Assuring the security and reliability of the network by >identifying points of contact for IP addresses for network >operators, ISPs, and certified computer incident response teams; "org:", "admin-c:", "tech-c:", "mnt-by:" and, yes, "abuse-c:" exist. >Ensuring that IP address holders are accountable, so individuals, >consumers and the public are empowered to resolve abusive >practices that impact safety and security; >Assisting businesses, consumer groups, healthcare organisations >and other organisations that are combating fraud (some of which >have mandates to electronically save records) to comply with >relevant legal and public safety safeguards; The contact object that does (or *should*) stand for the person(s) who can speak for a LIR, legally, is "admin-c:". "abuse-c:" is some role account in a NOC or even a ticket system unlikely to have any decision-making power. An attempt to make these roles (perhaps even personally) responsible for the behaviour of a LIR and its customers is counter-productive. I for one would flatly refuse to do any abuse report handling under these circumstances. >Complying with national, civil and criminal due process laws in >support of investigations and providing justice for victims. Would the proposers please amplify exactly which law or due process is violated by the NCC not sending an email once a year to an abuse-c:? Myself, and I'm sure the NCC legal team, would be interested to know. On a technical note, email is neither a secure nor a reliable transport for such verification. In the day of blocklists and large email providers imposing arbitrary restrictions on email senders it is not guaranteed that a verification email reaches the intended address or that a reply reaches the sender. The NCC ARC procedure, however employs both email and personal contact via telephone to verify the accuracy of the ripedb information. In toto, this proposal would impose unneccessary work on LIRs and the NCC, using unsuitable means to rectify a non-existing issue, and I therefore oppose it.

4 3

Re: [db-wg] RIPE Policy Proposal 2017-02 Validates Database Attributes
by William Sylvester 08 Sep '17

08 Sep '17

DB WG Members, We understand there are many opinions on this proposal. We encourage everyone to discuss this request on the anti-abuse mailing list. We have been coordinated with the AA-WG chairs on this and would appreciate expressing your support or objections in the AA-WG as that is the forum this proposal was raised. If you have any questions or concerns please contact the db-wg chairs. Thanks, William, Denis, and David Database WG Chairs On Sep 7, 2017, at 1:05 PM, Marco Schmidt via db-wg <db-wg(a)ripe.net<mailto:db-wg@ripe.net>> wrote: <mime-attachment>

1 0

RIPE Policy Proposal 2017-02 Validates Database Attributes
by Marco Schmidt 08 Sep '17

08 Sep '17

Dear colleagues, We just published RIPE Policy proposal, 2017-02, "Regular abuse-c Validation", to the Anti-Abuse Working Group mailing list. The goal of this proposal is to give the RIPE NCC a mandate to regularly validate "abuse-c:" information, and to follow up in cases where contact information is found to be invalid. As this proposal relates to contact information put into the RIPE Database, we would like to notify the Database Working Group specifically. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-02 We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 6 October 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 2

Re: Last Call for Agenda Items DB-WG Meeting - RIPE75 - Dubai, UAE
by William Sylvester 01 Sep '17

01 Sep '17

Dear DB-WG Members, This is the last call for agenda items for the DB-WG Meeting at RIPE75 at the Conrad Dubai in Dubai, UAE. Due to restrictions by UAE law we will not be able to add last minute presentations. Please submit your proposals to the working group chairs as soon as possible not later than September 6, 2017. 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 Wednesday, October 25th, 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://ripe75.ripe.net/programme/meeting-plan/ Note: due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements We are looking forward to another successful meeting in Dubai. Kind regards, William, Denis, & David DB WG Chairs

1 0

Whois Master Database Patch
by Edward Shryane 31 Aug '17

31 Aug '17

Dear working group, Tomorrow afternoon, Friday 1 September, we will apply a patch to the Whois Master database server. This will cause a short downtime for Whois updates. Queries will not be affected. Regards, Ed Shryane RIPE NCC

1 0

Re: [db-wg] NWI-7: abuse-c implementation plan
by Tim Bruijnzeels 30 Aug '17

30 Aug '17

Dear working group, We have a proposed timeline for the implementation. Let me quote the proposal sent out on 28 June here, and comment in-line: > 1) Allow “abuse-c:” on INET(6)NUM and AUT-NUM objects > > We will deploy a new version of whois where the “abuse-c:” attribute will be allowed to exist on INET(6)NUM and AUT-NUM objects. The syntax will be the same as for the ORGANISATION object: > abuse-c: [optional] [single] [inverse key] > > The Abuse Finder logic will be updated to use the first "abuse-c:" found in this order of priority: > -the local "abuse-c:" in the resource object > -the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the resource object > -search up the resource object hierarchy (less specific objects) > --the "abuse-c:" in the less specific resource object > --the "abuse-c:" in an ORGANISATION object referenced by the "org:" attribute in the less specific resource object > > The search will stop when the top level resource object is reached. > > In addition to this we plan to introduce a business rule that will disallow “abuse-mailbox:” to be modified, or (re-)added to any object, other than ROLE objects. This will enable us to do a phased clean-up of this data without invalidating objects. We plan to have a whois release 1.90 for this (and the updated use of the ‘pn’ keyword mentioned under item #5 below) in the Release Candidate environment no later than Monday 2 October. We plan to deploy this version to production on Monday 16 October. > 2) Clean up of “abuse-mailbox:” on ORGANISATION objects > > Three cases exist: > > A) “abuse-mailbox:” is present and it is the same as the “abuse-mailbox:” in the also present “abuse-c:” reference (8919 cases) > > In this case we propose to simply delete the “abuse-mailbox:” attribute and inform the holder. We will work on a clear text for this email, but the main message would be: > "We removed “abuse-mailbox:” from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with the same email address in its its “abuse-mailbox:” attribute. No action is required.” > > > B) “abuse-mailbox:” is present and it is different from the “abuse-mailbox:” in the also present “abuse-c:” reference (1848 cases) > > Note that some of these cases have been caused by the fact that since the introduction of “abuse-c:” LIRs can no longer modify the value of the “abuse-mailbox:” attribute. The intent was that “abuse-mailbox:” would have been cleaned up earlier, but unfortunately that dit not happen. That being said “abuse-c:” has been kept up to date by the LIR, and out of the two is also the one that is being shown on the Abuse Finder. > > Therefore we propose to delete the “abuse-mailbox:” attribute in these cases, and send a different notification to the holder with the following main message: > > "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, we see that you were already using the preferred way to document abuse contact details for your organisation and you are referencing an “abuse-c:” ROLE object with that uses $email_2 in its “abuse-mailbox:” attribute. If the latter is correct no action is required. However if you want to modify the email address in your “abuse-c:” ROLE object, you can do so here (link to webupdates).” > > > C) “abuse-mailbox:” is present, and there is no “abuse-c:” reference (28312 cases) > > We *could* create “abuse-c:” ROLE objects for these cases, using the same maintainers as the ORGANISATION object. However, the “abuse-mailbox:” attribute has not been shown in the Abuse Finder, and this change could lead to wrong or out-of-date addresses suddenly receiving abuse reports. Therefore we suggest that we delete the attribute instead, and send the following main message to the holder of the ORGANISATION object: > > "We removed “abuse-mailbox:” with value $email from your ORGANISATION object because this attribute is deprecated as the final step in the deployment of the "abuse-c:" attribute. However, if you wish to add an email address for abuse reports you can do so by editing your object here (link to web updates for the ORGANISATION object)." > > We plan to perform these clean-ups on Monday 30 October. > 3) Clean up of “abuse-mailbox:” on PERSON (89k cases), MNTNER (2500 cases) and IRT (238 cases) > > In these cases we propose to send a warning email to the holders of these objects with the following main message: > > “The “abuse-mailbox:” is deprecated on these object and will be removed in 4 weeks, if you want to set up abuse contact information on your resource objects you can do so by having a default “abuse-c:” on your ORGANISATION referenced by your resource objects, or possibly overriding that default with a specific “abuse-c:” reference on applicable resource objects." > > And then 4 weeks later we will preform the clean-up and refer back to this communication. On further reflection we would prefer to alter the plan, and just a single clean-up of these objects on Monday 30 October as well. This way the clean-up process will be consistent across all object types. Furthermore, there is no action to be taken on these objects and “abuse-mailbox:” on these objects is ignored in the Abuse Finder. In short there does not seem to be a strong motivation for bothering the holders of these objects twice. > 4) Clean up whois code > > Now that “abuse-mailbox:” only appears where it should, we will be able to update the whois code itself so that “abuse-mailbox:” is no longer syntactically allowed on objects other than ROLE objects. This will allow us to remove the business rule added in phase 1 and simplify the whois code and maintenance. We will also update the RIPE Database Documentation to reflect this. We plan to do this as part of a future whois 1.91 release, as yet unplanned. This clean-up will not change any publicly visible functionality. > > > 5) Inverse queries > > As requested we can change the behaviour of the “pn” short cut to also search for “abuse-c:” in inverse queries. I.e. one can use: > whois -r -i pn uk41-ripe > > Instead of: > whois -r -i abuse-c,admin-c,tech-c,zone-c,author uk41-ripe As mentioned above, we plan to include this in the whois 1.90 release. Kind regards Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 4 Aug 2017, at 14:39, William Sylvester via db-wg <db-wg(a)ripe.net> wrote: > > > From: William Sylvester <william.sylvester(a)addrex.net> > Subject: NWI-7: abuse-c implementation plan > Date: 3 August 2017 at 21:12:06 GMT+2 > To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> > > > Working group members, > > Based on the responses we have received for NWI-7 : Abuse-c implementation, there is a clear consensus for the proposed implementation that has been presented by Tim from RIPE NCC as written for improving "abuse-c:". > > At this time, the DB-WG co-chairs would like to ask the RIPE NCC to proceed with this implementation. > > Kind Regards, > > DB-WG Chairs > > > > >

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Clement Cavadore 14 Aug '17

14 Aug '17

On Tue, 2017-07-18 at 15:26 +0200, Nick Hilliard via db-wg wrote: > > I am not in favour of having the RIPE database as an open-access > database on the basis that this mixes up two sets of data, > authoritative > and non-authoritative, and it it is impossible for someone casually > querying the database to determine which is which. > > Some people are inserting random route: objects into the database, and > those route: objects are being picked up by provisioning systems and > ending up configured on routers and IXP route servers. This enables > prefix hijacking, which is a pressing operational issue. I agree with Nick's position. It legitimates what seems to be rogue announcements, like for example 196.16.0.0/14, as mentionned recently on the NANOG mailing list (*). We should, IMHO not be able to insert out of region route(6) object without having a prior authentication mechanism, or making it be specially flagged, so the auto ACL system from upstreams wouldnt match it. (*) https://mailman.nanog.org/pipermail/nanog/2017-August/091954.html -- Clément Cavadore

1 0

Re: [db-wg] out of region routing in the RIPE Database
by Daniel Shaw 11 Aug '17

11 Aug '17

On 11/08/2017, 05:14, Randy Bush via db-wg typed: > >> >> databases. It's that they never have, and it's just the "way things >> have been done". It's always ended up that they *can* support multiple >> databases if asked to. > > when negotiating with a prospective peer, i would rather not add "you > will have to change operational practice and code for this to work." That is a good point. I would also rather not, generally. And that is the basis of my original fears around this something like a year ago. What I found in practise (so far) has been that when stated not as "you will *have* to change operations", but as "would it be possible for you to change operations for me?", the answer has usually been "Ok". I have to be honest, that was a surprise. - Daniel

1 0