- db-wg - mailman.ripe.net

Re: Foreign ROUTE objects in RIPE Database - final decision?
by Alexander Stranzky 09 Oct '17

09 Oct '17

personal opinion: I don't care as a programmer. company's opinion: A - all our network resources are routed solely through our RIPE-AutNum. -- 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

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

09 Oct '17

Hello Denis, WG On Mon, 2017-10-09 at 15:49 +0200, denis walker via db-wg wrote: > 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). That one, but with a *strong* enhancement on a trust model for such objects. We just cannot simply allow non-ripe route objects to be inserted in the db without any legitimity checks. -- Clément Cavadore

1 0

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

09 Oct '17

Denis, On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg wrote: >Question - Should the RIPE Database allow creation of ROUTE >objects for non RIPE resources? > >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. Either A or C, insofar as they are different. Not allowing "foreign" resources in the ripedb denies the reality that there will always be RIPE-allocated prefixes originated from non-RIPE-assigned ASNs and vice versa. One could make an argument for not allowing route: objects where both the prefix and ASN are from outside RIPE. This would complicate (or make impossible) any attempt at automating acceptance filters, unless and until this information is available from other (trusted?) sources. As it currently stands, this would, on balance, be worse for the "good of the internet". cheers, Sascha Luck

1 0

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