From alexb at ripe.net Tue Feb 2 09:45:31 2016 From: alexb at ripe.net (Alex Band) Date: Tue, 2 Feb 2016 09:45:31 +0100 Subject: [db-wg] [members-discuss] ripe objects as single text field In-Reply-To: <56A08BA2.9030500@velder.li> References: <56549374.9050100@f-solutions.fi> <9CEFDDEE-42E1-494E-82E9-8817DDC7E3E8@ripe.net> <56A08BA2.9030500@velder.li> Message-ID: <0855E2BC-FAC0-456C-AD2B-2D294E939B72@ripe.net> Hi Patrick, We just deployed a new release to retain empty attributes, along with several other small improvements. Please let us know if you have any other feedback. Kind regards, Alex > On 21 Jan 2016, at 08:41, Patrick Velder wrote: > > Hello Alex > > Thanks for bringing back the single text field editor. Unfortunately it deletes all empty "remarks:" lines. I use them to separate blocks in my objects. Please fix that. > > Thanks and best regards > Patrick > > On 20.01.2016 20:29, Alex Band wrote: >> Dear colleagues, >> >> As promised, we have been working hard on bringing back updates in a single text area. This functionality is now available for creating and modifying objects. >> >> In webupdates, you will find a button in the top right corner to switch back and forth between "text area" and "single lines", allowing you to choose your preferred update method before making changes. A new feature is that your preference is saved for the next time you visit. >> >> https://alexband.nl/temp/textupdates.png >> >> In addition, we added we added Force Delete to webupdates, which you can select from the authentication dialog box when modifying an existing object. This functionality?which was previously known as "reclaim"?allows you to delete inet(6)num, domain and route(6) objects using the maintainer of a covering address space object, instead of the maintainer of the object itself. This is useful in cases where you don't have control over an object, and it is blocking you from creating a new one. >> >> When choosing Force Delete, we retrieve all of the maintainers that can be used to remove the selected object. Simply select a maintainer you can use to authenticate and you're done. >> >> https://alexband.nl/temp/force-delete.png >> >> Lastly, with your feedback and by analysing how the new design is being used, we included lots of small improvements to make your life a little easier. >> >> If you have any comments or something isn't working quite right, please do not hesitate to use the Feedback button on the RIPE Database pages to send us a screenshot with your annotations. >> >> Kind regards, >> >> Alex Band >> Product Manager >> RIPE NCC >> >> >> >>> On 1 Dec 2015, at 12:27, Alex Band wrote: >>> >>> Hello everyone, >>> >>> We're happy that there is such an active discussion on RIPE Database functionality. >>> >>> In my previous message we said we would implement updating the RIPE Database in a single text area if there would be enough demand. It is very clear this is something that many of you want back as soon as possible. :) >>> >>> As promised, we will work on making an elegant solution to achieve this. The current workaround is to copy and paste the object you queried into "Syncupdates" and go from there: >>> >>> https://apps.db.ripe.net/syncupdates/simple-rpsl.html >>> >>> This update method will allow you to use your SSO account to authenticate as well, if it is associated with your maintainer. >>> >>> We would like to remind you that all changes and new functionality that is created for the RIPE Database is deployed to the Release Candidate environment first. This way you can test and provide feedback several weeks before it is deployed to production, allowing us to adjust course if needed. >>> >>> https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candidate-environment >>> >>> Please subscribe to the Database Working Group mailing list to participate in functionality discussions and stay up to date on new releases. >>> >>> https://www.ripe.net/participate/ripe/wg/db >>> >>> Kind regards, >>> >>> Alex Band >>> Product Manager >>> RIPE NCC >>> >>> >>>> On 30 Nov 2015, at 18:50, Erik Bais - A2B Internet wrote: >>>> >>>> Hi Alex, >>>> >>>> The change where the single text field was depreciated into a 2 step, is creating additional work / window switching. >>>> >>>> Especially since you need to copy and paste the current info from another window into a second screen, paste/edit the info, update the object. >>>> >>>> Is there an option where this is going to be reverted back as it was, as it was actually used ... >>>> >>>> Especially being able to search an object and being able to select it to change it in a single text field.. Instead of having to cut and paste. ( yes we are lazy and yes that is what you get if you try to automate as much as possible ;-) ) >>>> >>>> Regards, >>>> Erik Bais >>>> >>>> >>>>> Op 25 nov. 2015 om 12:07 heeft Alex Band het volgende geschreven: >>>>> >>>>> Hello everyone, >>>>> >>>>> I would just like to clarify a couple of things on the redesigned user interface, based on the feedback we have received so far. >>>>> >>>>> First of all, these are the URLs to all of the different parts of the RIPE Database web ui, as it seems some people are getting a bit lost: >>>>> >>>>> Query: https://apps.db.ripe.net/search/query.html >>>>> Create using single text field: https://apps.db.ripe.net/db-web-ui/ >>>>> Create/Update using multiline text area: https://apps.db.ripe.net/syncupdates/simple-rpsl.html >>>>> >>>>> In addition, the TEST database user interface now has its own dedicated URL, instead of having to select it with a radio button: >>>>> >>>>> https://apps-test.db.ripe.net/ >>>>> >>>>> The option to edit an existing object in a single text area is functionality that was used very infrequently according to our statistics. We decided to leave it out of the first phase of the redesign, as most people use email or scripting to update the RIPE Database in a single text area. If there is a lot of demand, we'll implement that option as well for the web interface as well. >>>>> >>>>> Please keep in mind that it not impossible to edit an existing object in a single text area, it is simply a two-step process. You can copy and paste the object you queried into Syncupdates and go from there. This update method will allow you to use your SSO account to authenticate as well, if it is associated with your maintainer. >>>>> >>>>> Lastly, I realise "Syncupdates" is not the most descriptive name ever. We will make sure that we have a look at the wording of the different menu items to avoid confusion. >>>>> >>>>> Kind regards, >>>>> >>>>> Alex Band >>>>> Product Manager >>>>> RIPE NCC >>>>> >>>>>> On 25 Nov 2015, at 11:28, Andy Betts wrote: >>>>>> >>>>>> Yep, I just discovered that feature had been removed (or really well hidden) this morning. >>>>>> >>>>>> Please bring it back. >>>>>> >>>>>> Regards >>>>>> Andy >>>>>> From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of David Wilkinson >>>>>> Sent: 24 November 2015 17:06 >>>>>> To: Tapio Haapala; members-discuss at ripe.net >>>>>> Subject: Re: [members-discuss] ripe objects as single text field >>>>>> >>>>>> Hi Tapio, >>>>>> >>>>>> Looks like they have removed it. I can't see away to use the single text update either. (Unless both of us are blind) >>>>>> >>>>>> That is quite annoying as to update some records it was easier to edit via the single text area than adding each attribute one by one. >>>>>> >>>>>> Regards >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: members-discuss [mailto:members-discuss-bounces at ripe.net] On Behalf Of Tapio Haapala >>>>>> Sent: 24 November 2015 16:42 >>>>>> To: members-discuss at ripe.net >>>>>> Subject: [members-discuss] ripe objects as single text field >>>>>> >>>>>> Signed PGP part >>>>>> I was just adding domain objects to DB. Suddenly that ui ask me to login again. After that I did not find way to add objects via single text fied. >>>>>> Can someone check that do they really remove one of most used feature at whole portal or is it just me who is blind or dumb? >>>>>> >>>>>> -- >>>>>> F-Solutions Oy >>>>>> >>>>>> Tapio Haapala >>>>>> >>>>>> PL7, 90571 Oulu >>>>>> GSM 0400 998371 >>>>>> Skype burner- >>>>>> IRC Burner at ircnet >>>>>> >>>>>> >>>>>> ---- >>>>>> If you don't want to receive emails from the RIPE NCC members-discuss mailing list, please log in to your LIR Portal account and go to the general page: >>>>>> https://lirportal.ripe.net/general/ >>>>>> >>>>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >>>>>> >>>>>> ---- >>>>>> If you don't want to receive emails from the RIPE NCC members-discuss >>>>>> mailing list, please log in to your LIR Portal account and go to the general page: >>>>>> https://lirportal.ripe.net/general/ >>>>>> >>>>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >>>>>> >>>>>> ________________________________ >>>>>> This email has been scanned inbound by Node4's Email Security System. >>>>>> ________________________________ >>>>>> This email message has been delivered safely and archived online by Mimecast. >>>>>> ________________________________ >>>>>> >>>>>> *************************************************************************************************************************************************** >>>>>> Node4 Limited is registered in England No: 04759927 and has its registered office at Millennium Way, Pride Park, Derby, DE24 8HZ >>>>>> The information contained in this email is confidential and is intended for the exclusive use of the email addressee shown. >>>>>> If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. >>>>>> If you have received this mail in error, please notify our mail manager at abuse at node4.co.uk and delete it from your system. >>>>>> Opinions expressed in this email are those of the individual not the company, unless specifically indicated to that effect. >>>>>> >>>>>> >>>>>> >>>>>> This email has been scanned by Node4's Email Security System. >>>>>> >>>>>> This email message has been delivered safely and archived online by Mimecast. >>>>>> **************************************************************************************************************************************************** >>>>>> ---- >>>>>> If you don't want to receive emails from the RIPE NCC members-discuss >>>>>> mailing list, please log in to your LIR Portal account and go to the general page: >>>>>> https://lirportal.ripe.net/general/ >>>>>> >>>>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >>>>> >>>>> ---- >>>>> If you don't want to receive emails from the RIPE NCC members-discuss >>>>> mailing list, please log in to your LIR Portal account and go to the general page: >>>>> https://lirportal.ripe.net/general/ >>>>> >>>>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >>> >>> ---- >>> If you don't want to receive emails from the RIPE NCC members-discuss >>> mailing list, please log in to your LIR Portal account and go to the general page: >>> https://lirportal.ripe.net/general/ >>> >>> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. >>> >> > > From tim at ripe.net Tue Feb 2 12:57:59 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Tue, 2 Feb 2016 12:57:59 +0100 Subject: [db-wg] Release 1.85 (changed phase 3) deployed to RC In-Reply-To: <915C23FB-EC22-41C1-A86A-1CFBF7370F69@ripe.net> References: <915C23FB-EC22-41C1-A86A-1CFBF7370F69@ripe.net> Message-ID: <57E39D25-AFE7-41B7-8887-EBB0240C1569@ripe.net> Dear working group, This has now been deployed to production. Somewhat related to this work. As documented here: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-1-description-of-attributes-common-to-all-objects The "created:" date on objects reflects when the object was created in the database, but we do not have accurate data on this from before 21 December 2001. However we can back date objects on demand. And after discussing with the chairs we agreed that we will make an effort to use the date found in the "netname:" attribute for inetnums, or the date in the oldest "changed:" attribute (with a sanity check that it's not before April 1992), in those cases where did not find a date. Kind regards, Tim Bruijnzeels > On 22 Dec 2015, at 12:35, Tim Bruijnzeels wrote: > > Dear working group, > > We have just deployed release 1.85 to the Release Candidate environment. > > This release completes the deprecation of the "changed:" attribute: > https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database > > With this release we will: > > = Filter out "changed:" from all RIPE Database objects > = Actively remove "changed:" from all RIPE Database objects > = Reject updates that contain "changed:" > > We encourage all users of the database to test their tools. If no issues are found we plan to deploy this release to production on Monday 1 February 2016. > > Note that this release includes all changes from the previous release, 1.84.1. But, we only plan to upgrade the RIPE Database hardware, and deploy the 1.84.1 release, in the first half of January. Because this upgrade will involve a brief outage for updates to the Database, we will communicate a more detailed plan with time lines closer to the date. > > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC Database Group > > > > > From tim at ripe.net Thu Feb 11 17:30:59 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 11 Feb 2016 17:30:59 +0100 Subject: [db-wg] Implementation proposal descr line In-Reply-To: References: <20160114165425.GK2857@57.rev.meerval.net> Message-ID: <8246C541-C7DB-40C8-A463-09042B34A7BD@ripe.net> Dear working group, After discussing this with the working group chairs it was decided that the best cause of action would be let working group discuss the future of "netname:", and in the meantime proceed with the "descr:" clean-up as proposed earlier. We are currently working on an implementation consisting of two parts: = Make "descr:" an optional multi-line attribute = Clean up existing "descr:" that RIPE NCC has been enforcing We plan to deploy release 1.86 for this to the Release Candidate environment on Wednesday 2 March. Provided no issues are found we plan to deploy this version to production on Monday 21 March. We will inform the working group again when we do these deployments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 28 Jan 2016, at 17:38, Tim Bruijnzeels wrote: > > Dear working group, > > Please allow me to clarify a few things. > > First of all we are suggesting this now, because there may be an opportunity to combine this work with the intended cleanup of "descr:". However, if this proves controversial or requires more discussion then we have no problem with finishing the "descr:" clean up first. > > The RIPE NCC enforces the "netname:" attribute for allocation objects only, for PI assignments and AS number assignments the attribute is currently editable by users. Given that the "netname:" attribute is not enforced for these resources it may be out of sync with the name recorded in the organisation object which has implications for data quality. > > The proposed cleanup would only apply to inetnum objects for allocations done by the RIPE NCC. So, in response to the comment Andreas made: this would not affect "netname:" attributes used on more specific assignment for customers. > > Finally a subtlety about the dates used in "netname:". The dates here reflect the date of issuance of the resource. That means that if a resource is transferred, the original date is kept. In that it may be different from the "created:" date that reflects when the object was created. The date of first issuance of all resources can also be found in the extended delegated statistics published here: http://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > > However, if it is important that the date of issuance is also visible in the RIPE Database, then we would suggest that we automatically update the "created:" attribute for resources allocated or issued by the RIPE NCC to reflect the same date that can be found in the statistics file. > > We hope that this makes it more clear. > > Kind regards, > > Tim Bruijnzeels > >> On 27 Jan 2016, at 17:27, Tim Bruijnzeels wrote: >> >> Dear working group, >> >> We expect that we can implement this as part of the 1.86 release of the DB. We should be able to deploy this to the RC environment by Wednesday 2 March. And can then deploy to production on Monday 21 March. >> >> However, we realised that a similar reasoning could also be applied to the "netname:" and "asname:" attributes that the RIPE NCC has been maintaining. A "netname:" for an inetnum (allocation) object is built up using the regid of the member, and the allocation date. However, since there is an "org:" reference and a "created:" attribute on the object this is redundant. >> >> So before implementing the cleanup of "descr:" we would like to verify the following options with the working group: >> >> >> 1) RIPE NCC cleans up, and the attributes become optional >> >> In this scenario "netname:" and "asname:" would become optional. And a one time effort is done to remove the attribute where it has been enforced so-far. >> This is our preferred option because not having duplicate possibly inconsistent data will improve data quality and reduce work. >> >> We are not aware that either attribute has great operational value today, but this is something we would like to verify. So, please speak up if you see any operational or other concerns with this option. >> >> If this option has consensus it would make sense to do this together with the cleanup of "descr:", and we avoid updating objects more often than necessary. >> >> >> 2) RIPE NCC stops maintaining, and the attributes become user modifiable >> >> Alternatively we could leave these attributes as mandatory, but allow users to change them - without any clean-up of existing cases. We can then also add this to resource request forms so that future objects can have a value specified by the member. >> >> >> 3) RIPE NCC continues maintaining, and the attributes cannot be modified by the user >> >> In this case we just keep doing what we have been doing so-far. >> >> >> >> >> Kind regards, >> >> Tim Bruijnzeels >> >> Assistant Manager Software Engineering >> RIPE NCC Database Group >> >> >> >>> On 14 Jan 2016, at 17:54, Job Snijders wrote: >>> >>> Dear Working group, RIPE NCC, >>> >>> Support was shown for this proposal and no objections were raised after >>> this round of discussion. >>> >>> I asked RIPE NCC schedules implementation of this plan as proposed by >>> Tim (keeping in mind Shane's comment about empty "descr:" attributes). >>> >>> Thank you all for your time reviewing this! >>> >>> Kind regards, >>> >>> Job Snijders >>> DB-WG Chairs >>> >>> On Tue, Oct 20, 2015 at 12:23:02PM +0200, Tim Bruijnzeels wrote: >>>> Dear working groups, >>>> >>>> Following discussion in this group it was decided that the RIPE NCC >>>> should stop enforcing that the first "descr:" attribute of resource >>>> objects reflects the name of the organisation, for resources that it >>>> alloced or assigned. This practice has been place for a long time, but >>>> now that all such objects have a reference to an organisation object >>>> and the RIPE NCC ensures that this reflects the resource requests, >>>> this is no longer needed. >>>> >>>> Furthermore it was decided that the RIPE NCC should clean up existing >>>> organisation names in "descr:" attributes in order to: >>>> (1) avoid confusion about where the organisation name should be found; >>>> (2) avoid that the names here are different from the name of the actual organisation; >>>> (3) make it very clear which attributes are verified by RIPE NCC, and which attributes are not. >>>> >>>> Hereby the RIPE NCC would like to propose an implementation plan for >>>> these changes. We invite the working group to review and discuss if >>>> needed. As soon as the working group co-chairs formally call >>>> consensus, we can proceed to implement shortly. >>>> >>>> Implementation proposal: >>>> ======================== >>>> >>>> = Change "descr:" to an 'optional multiple' attribute >>>> >>>> We believe that the working group concluded that it would be >>>> appropriate to make "descr:" optional. The reason is that when the >>>> organisation name is cleaned up, there may be no description lines >>>> left. The working group considered whether the attribute should be >>>> 'single optional', but there seemed to be no strong preference for >>>> this, and it would have a bigger impact. Therefore we propose to go >>>> for the easier option of making it 'optional multiple'. >>>> >>>> Technically this change is not hard to do on the server side, but can >>>> impact users of the database because there may be no "descr:" >>>> attribute, and this can affect parsers. >>>> >>>> Because this can have an impact on automated systems the RIPE NCC will >>>> announce this change ncc-announce at ripe.net, and use a longer week >>>> staging period in the Release Candidate environment allowing users to >>>> test and update their systems. >>>> >>>> Dependent on formal consensus call we may be able to combine this with >>>> the upcoming release for deprecating "changed:" phase 3, to avoid >>>> delays. >>>> >>>> = Clean up existing "descr:" attributes where RIPE NCC enforced the organisation name >>>> >>>> The RIPE NCC will remove the "descr:" attributes that it has been enforcing. >>>> >>>> = Add "descr:" to allocation object editor in LIR Portal >>>> >>>> So that LIRs can edit this themselves. >>>> >>>> = Stop setting the "descr:" on new allocations or assignments done by the RIPE NCC >>>> >>>> We will leave "descr:" blank. It can be edited by the LIR or end-user later. >> >> > > From tim at ripe.net Thu Feb 11 17:40:39 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 11 Feb 2016 17:40:39 +0100 Subject: [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by In-Reply-To: <57963B25-D0B9-4B8A-B6C8-5602A882ED7E@ripe.net> References: <36C98324-8E57-4CCE-8778-F0B8FF62C577@ripe.net> <20160119144717.GG31053@hydra.ck.polsl.pl> <57963B25-D0B9-4B8A-B6C8-5602A882ED7E@ripe.net> Message-ID: Dear working group, After discussing this with the working group chairs it was decided that we should implement the following: = RIPE NCC should send a warning email to contacts we can find for objects that use the RIPE-NCC-RPSL-MNT = RIPE NCC will implement a business rule to prevent the future use of RIPE-NCC-RPSL-MNT on mnt-by = RIPE NCC will remove RIPE-NCC-RPSL-MNT from objects, locking them if no other maintainers are present We plan to deploy release 1.86 for this to the Release Candidate environment on Wednesday 2 March. We aim to send warning emails on Monday 7 March. Provided no issues are found we plan to deploy the business rule to production, and remove the RIPE-NCC-RPSL-MNT from mnt-by on objects on Monday 21 March. We will inform the working group again when we do each step. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group > On 19 Jan 2016, at 16:23, Tim Bruijnzeels wrote: > > Dear working group, > >> On 19 Jan 2016, at 15:47, Piotr Strzyzewski wrote: >> >> Dear Tim, DB-WG Members >> >> It seems that support was shown for this proposal and no strong >> objections were raised during the discussion. >> >> Tim, would you be so kind and prepare the schedule for implementing this >> proposal? > > Of course. > > Tentatively I would say that we can work on this in February, but I can give a more detailed schedule by the beginning of next week. > > Kind regards, > > Tim Bruijnzeels > > >> >> Kind regards, >> Piotr >> >> -- >> gucio -> Piotr Strzy?ewski >> E-mail: Piotr.Strzyzewski at polsl.pl > > From ricardo.cukier at gmail.com Thu Feb 11 22:19:05 2016 From: ricardo.cukier at gmail.com (Ricardo Cukier) Date: Thu, 11 Feb 2016 16:19:05 -0500 Subject: [db-wg] Question about RIPE Database Message-ID: Hi. I am using the following FTP files to identify IPs per Country: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest ftp://ftp.apnic.net/pub/stats/iana/delegated-iana-latest While doing some searchs on the web, I found a few IP Addresses that are not included in those files, for example, 2.190.0.0 however, when i searched on the Web Database (see attached screenshot), it was found as an IRAN subnet and assigned by RIPENCC. Why I am unable to see this subnet in the files? Am I doing the download of the incorrect files? Can someone please help me to identify whats the best process to get the correct list of IPs/subnets per country? -- Best Regards, Ricardo Cukier -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Query.jpg Type: image/jpeg Size: 199773 bytes Desc: not available URL: From anandb at ripe.net Mon Feb 15 15:04:18 2016 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 15 Feb 2016 15:04:18 +0100 Subject: [db-wg] Question about RIPE Database In-Reply-To: References: Message-ID: <56C1DAE2.8060803@ripe.net> On 11/02/16 22:19, Ricardo Cukier wrote: Hi Ricardo, > Hi. I am using the following FTP files to identify IPs per Country: > ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest > ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest > ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest > ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest > ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest > ftp://ftp.apnic.net/pub/stats/iana/delegated-iana-latest > > While doing some searchs on the web, I found a few IP Addresses that are > not included in those files, for example, 2.190.0.0 The stats file for RIPE NCC does have this information, but it is aggregated by this entry: ripencc|IR|ipv4|2.176.0.0|1048576|20101018|allocated|74a401bc-01b6-40c1-be04-ef2d6e1add62 The fourth field is the number of addresses allocated, starting with 2.176.0.0, so this line covers the range: 2.176.0.0 - 2.191.255.255. For more information about the format of this file, please refer to: http://ftp.ripe.net/pub/stats/ripencc/RIR-Statistics-Exchange-Format.txt Regards, Anand Buddhdev RIPE NCC From tdacruzper at ripe.net Fri Feb 19 10:27:53 2016 From: tdacruzper at ripe.net (Thiago da Cruz Pereira) Date: Fri, 19 Feb 2016 10:27:53 +0100 Subject: [db-wg] RIPE DB services downtime Message-ID: Dear working group, Later today, we?re going to restart our servers to apply a patch. A short downtime to updates is expected and queries will not be affected. Kind regards, Thiago da Cruz Software Engineer - Ripe Database Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2625 bytes Desc: not available URL: From job at ntt.net Fri Feb 19 10:36:18 2016 From: job at ntt.net (Job Snijders) Date: Fri, 19 Feb 2016 10:36:18 +0100 Subject: [db-wg] increase daily db dump frequency? Message-ID: <20160219093618.GH19703@22.rev.meerval.net> Hi RIPE NCC, WG, I have a use-case in which secondaire NRTM mirrors can't easily reseed from the data stored at ftp.ripe.net:/ripe/dbase/ because the intermediate NRTM mirror retains less history than the actual delta between when the dump was made and the current serial. In other words, if I want to reseed an IRR instance I have to do so before lunch (UTC), because after lunch the delta usually is too large. This can be mitigated if the dump files in ftp.ripe.net:/ripe/dbase/split are refreshed more often then once a day. Would it be possible to dump every 6 hours instead of every 24 hours? Kind regards, Job From brian.nisbet at heanet.ie Fri Feb 19 10:46:42 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 19 Feb 2016 09:46:42 +0000 Subject: [db-wg] [anti-abuse-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC In-Reply-To: <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> Message-ID: <56C6E482.1010909@heanet.ie> Tim, On 14/01/2016 14:57, Tim Bruijnzeels wrote: > Hi all, > > > >> On 12 Jan 2016, at 15:23, Brian Nisbet wrote: >> >> Afternoon(-ish), >> >> As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed. >> >> Tim, is the date of the 1st of February still possible for the first mailing on this? > > Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. I was just wondering, would you be able to provide an update on this project? Thanks, Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 fax: +35316603666 web: http://www.heanet.ie/ From eshryane at ripe.net Fri Feb 19 10:50:47 2016 From: eshryane at ripe.net (Edward Shryane) Date: Fri, 19 Feb 2016 10:50:47 +0100 Subject: [db-wg] [anti-abuse-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC In-Reply-To: <56C6E482.1010909@heanet.ie> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> <56C6E482.1010909@heanet.ie> Message-ID: <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> > On 19 Feb 2016, at 10:46, Brian Nisbet wrote: > > Tim, > > On 14/01/2016 14:57, Tim Bruijnzeels wrote: >> Hi all, >> >> >> >>> On 12 Jan 2016, at 15:23, Brian Nisbet wrote: >>> >>> Afternoon(-ish), >>> >>> As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed. >>> >>> Tim, is the date of the 1st of February still possible for the first mailing on this? >> >> Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. > > I was just wondering, would you be able to provide an update on this project? > > Thanks, > > Brian > Morning Brian, we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email. Regards Ed Shryane RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brian.nisbet at heanet.ie Fri Feb 19 10:52:50 2016 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 19 Feb 2016 09:52:50 +0000 Subject: [db-wg] [anti-abuse-wg] RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC In-Reply-To: <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> References: <61E8987E-8774-422F-A758-17A6E6EB6DF7@ripe.net> <567046AC.3000802@heanet.ie> <568B8CF4.2070208@heanet.ie> <56950C55.4060802@heanet.ie> <7035FAF5-4DF7-43E6-8759-20FF9FDBBEA4@ripe.net> <56C6E482.1010909@heanet.ie> <2FFA7B8E-E9D9-4FD8-90C5-F782D24F0EEA@ripe.net> Message-ID: <56C6E5F2.30009@heanet.ie> On 19/02/2016 09:50, Edward Shryane wrote: > >> On 19 Feb 2016, at 10:46, Brian Nisbet wrote: >> >> Tim, >> >> On 14/01/2016 14:57, Tim Bruijnzeels wrote: >>> Hi all, >>> >>> >>> >>>> On 12 Jan 2016, at 15:23, Brian Nisbet wrote: >>>> >>>> Afternoon(-ish), >>>> >>>> As I'm pretty sure Monday is now everywhere in the world, I think that given the lack of further responses or discussion or, importantly, disagreements with the general feeling of consensus, I think we can proceed. >>>> >>>> Tim, is the date of the 1st of February still possible for the first mailing on this? >>> >>> Yes. Unless we hear otherwise we will send the emails on 1 February and proceed to set the abuse-c on 15 February. So people have two weeks to set their abuse contact to something else before we create it. However no action is necessary in case they are happy with the email address we will use in the object, and they can of course also modify the abuse-mailbox later. >> >> I was just wondering, would you be able to provide an update on this project? >> >> Thanks, >> >> Brian >> > > Morning Brian, > > we set the abuse-c for the remaining organisations on 15 February, as planned, and contacted those affected by email. Thanks for the update! Brian Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 fax: +35316603666 web: http://www.heanet.ie/ From tdacruzper at ripe.net Fri Feb 19 15:33:57 2016 From: tdacruzper at ripe.net (Thiago da Cruz Pereira) Date: Fri, 19 Feb 2016 15:33:57 +0100 Subject: [db-wg] RIPE DB services downtime In-Reply-To: References: Message-ID: Dear working group, The patch was applied successfully. There was no query downtime and updates were down for around 20 minutes. Kind regards, Thiago da Cruz Software Engineer - Ripe Database Team > On 19 Feb 2016, at 10:27, Thiago da Cruz Pereira wrote: > > Dear working group, > > Later today, we?re going to restart our servers to apply a patch. > A short downtime to updates is expected and queries will not be affected. > > Kind regards, > Thiago da Cruz > Software Engineer - Ripe Database Team > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2625 bytes Desc: not available URL: From william.sylvester at addrex.net Fri Feb 19 15:36:19 2016 From: william.sylvester at addrex.net (William Sylvester) Date: Fri, 19 Feb 2016 14:36:19 +0000 Subject: [db-wg] increase daily db dump frequency? In-Reply-To: <20160219093618.GH19703@22.rev.meerval.net> References: <20160219093618.GH19703@22.rev.meerval.net> Message-ID: <78E9B85D-D17F-4C32-BA29-7DE1D180F8DF@addrex.net> I agree with Job and would also like to see the frequency change. Thanks, Billy > On Feb 19, 2016, at 4:36 AM, Job Snijders wrote: > > Hi RIPE NCC, WG, > > I have a use-case in which secondaire NRTM mirrors can't easily reseed > from the data stored at ftp.ripe.net:/ripe/dbase/ because the > intermediate NRTM mirror retains less history than the actual delta > between when the dump was made and the current serial. > > In other words, if I want to reseed an IRR instance I have to do so > before lunch (UTC), because after lunch the delta usually is too large. > > This can be mitigated if the dump files in ftp.ripe.net:/ripe/dbase/split > are refreshed more often then once a day. > > Would it be possible to dump every 6 hours instead of every 24 hours? > > Kind regards, > > Job > From Piotr.Strzyzewski at polsl.pl Fri Feb 19 15:38:09 2016 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Fri, 19 Feb 2016 15:38:09 +0100 Subject: [db-wg] increase daily db dump frequency? In-Reply-To: <78E9B85D-D17F-4C32-BA29-7DE1D180F8DF@addrex.net> References: <20160219093618.GH19703@22.rev.meerval.net> <78E9B85D-D17F-4C32-BA29-7DE1D180F8DF@addrex.net> Message-ID: <20160219143809.GC28974@hydra.ck.polsl.pl> On Fri, Feb 19, 2016 at 02:36:19PM +0000, William Sylvester wrote: > I agree with Job and would also like to see the frequency change. +1 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From tdacruzper at ripe.net Mon Feb 22 15:55:04 2016 From: tdacruzper at ripe.net (Thiago da Cruz Pereira) Date: Mon, 22 Feb 2016 15:55:04 +0100 Subject: [db-wg] increase daily db dump frequency? In-Reply-To: <20160219093618.GH19703@22.rev.meerval.net> References: <20160219093618.GH19703@22.rev.meerval.net> Message-ID: <0FA67D88-7281-4E69-8F55-C30DF53B3043@ripe.net> Dear WG, We?re investigating the possibility of increasing the frequency of refreshing the split files on the FTP site and the impact it would have for other users. As an alternative solution, can you use our primary mirror since it?s up-to-date? Kind regards, Thiago da Cruz Software Engineer - RIPE NCC Database Team > On 19 Feb 2016, at 10:36, Job Snijders wrote: > > Hi RIPE NCC, WG, > > I have a use-case in which secondaire NRTM mirrors can't easily reseed > from the data stored at ftp.ripe.net:/ripe/dbase/ because the > intermediate NRTM mirror retains less history than the actual delta > between when the dump was made and the current serial. > > In other words, if I want to reseed an IRR instance I have to do so > before lunch (UTC), because after lunch the delta usually is too large. > > This can be mitigated if the dump files in ftp.ripe.net:/ripe/dbase/split > are refreshed more often then once a day. > > Would it be possible to dump every 6 hours instead of every 24 hours? > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2625 bytes Desc: not available URL: From job at instituut.net Mon Feb 22 16:02:37 2016 From: job at instituut.net (Job Snijders) Date: Mon, 22 Feb 2016 16:02:37 +0100 Subject: [db-wg] increase daily db dump frequency? In-Reply-To: <0FA67D88-7281-4E69-8F55-C30DF53B3043@ripe.net> References: <20160219093618.GH19703@22.rev.meerval.net> <0FA67D88-7281-4E69-8F55-C30DF53B3043@ripe.net> Message-ID: <20160222150237.GO8440@57.rev.meerval.net> On Mon, Feb 22, 2016 at 03:55:04PM +0100, Thiago da Cruz Pereira wrote: > We?re investigating the possibility of increasing the frequency of > refreshing the split files on the FTP site and the impact it would > have for other users. Thank you. > As an alternative solution, can you use our primary mirror since it?s > up-to-date? No. My requirement in this case is to use our own mirrors. Kind regards, Job From rv at NIC.DTAG.DE Sun Feb 28 19:38:10 2016 From: rv at NIC.DTAG.DE (Ruediger Volk) Date: Sun, 28 Feb 2016 19:38:10 +0100 Subject: [db-wg] objection to RIPE policy proposal 2016-01 Message-ID: <11461.1456684690@x59.NIC.DTAG.DE> Dear colleagues, I object to passing the policy as proposed. There is no serious need for the policy, and at this time and under curent circumstance it would actually be harmful. I believe that the supposed good intentions would be better served by other actions, and the policy focussing on enforcement is ill advised. I understand that the current implementation of the RIPE database allows legacy holders to enter abuse-c attributes for their legacy resources if that's currently not possible the required extension of the database should be discussed (in the approprioate wg) and implementation would NOT require the PDP (as more drastic changes have been done to the database - and that extension hardly would contradict existing policy). No PDP is needed to send friendly invitations to legacy holders to populate their data objects with abuse-c information; I'm sure asking the RIPE NCC to do this would not create an undue burden or serious problem. Enhancing the invitations with some additional information potentially helpful to the recipients could be considered too: - some hints/guidance about expected use and support of that mailbox (active members of the abuse handling community probably will NOT be the typical recipient! and no injuries are expected if any community member sees that information:-) - specific suggestions what to put into the abuse-c field (whatever the RIPE NCC might use to extrapolate abuse-c from existing data) The working group should contribute helpful information to be included. I'm quite certain running a second invitation campaign would be even less of a problem and effort for RIPE NCC; I cannot predict how much the information provided in a later campaign can be improved based on feedback and experience from an earlier one. You may argue, that such more friendly approach could have been used also earlier - and I would very much agree and I certainly complained and suggested that at least the forced population of missing abuse-c should be postponed until friendly information was made available. Now we do NOT HAVE TO repeat past errors... Specifically with legacy resource holders it would be a good idea for RIPE community and NCC to address them with an inviting and helpful approach; as there is a sad history of seemingly coercive and unfriendly communications towards legacy holders. REPEATING the error now - even considering the much lower number of relevant records - is however actually MORE SERIOUS in DAMAGING the CREDIBILITY of the working group (and as a consequence the RIPE NCCs position) because of the accumulated history. Repeated requests for information on supposed use und handling of abuse-c has been answered by pointing out that it is required by a policy that was consciously created without any such information. The new policy proposal painfully fits into the sad observation that the anti-abuse working group as a community has constantly put effort into enforcing creation and population of abuse-c data but not (even tried) to provide to the rest of the world helpful explanations on requirements and expected handling at the requested mailboxes. That observations leads to the question whether the community is not able to come up with some helpful explanation or whether it does not care... :-( In both cases asking for enforcement does seem neither appropriate nor acceptable and means that the request cannot be taken serious - bad for the perception of RIPE and RIPE NCC activety by parties that are not heavily involved in the community processes. Consider the typical person confronted with a request to define abuse-c: how deeply is he involved with the anti-abuse working group (where a common understanding might exist - I consider myself only occassional observer and not a member and don't know)? Trying to close more quickly and on a more constructive perspective let me skip to elaborate here on my judgement: at close inspection the rationale and arguments look quite broken. The policy content does actually not matter that much - look for a sketch of a potential harmless implementation approach above in this message. What matters is appropriate use of the PDP (it can be abused!!!) and what are good goals of the working group and good ways of achieving them. The assumed good goals (as I understand it) are (a) improving quality of abuse-c information in order to (b) improve abuse reporting and report handling processes and (c) extending the abuse-c coverage for Internet number resources in the RIPE NCC registry The policy proposal references (a) and (b) quite explicitly; I took the liberty to interpolate (b) which actually seems to be the primary goal, and it looks like the working group decided that this will be helped by means of creating distinctly identified mailbox information to be put into abuse-c. The criterium for gauging (a) seems to be whether "improved data" actually helps "improve processing" (b) - what else? Creating abuse-c entries of better/good quality obviously depends on the recipient being appropriate and informed about expected potential messages and preparing to deal with them. Forcing creation of abuse-c in any other way is not going to create better quality but actually looses information (you loose track of which entries have the "quality of informed and [potentially] prepared recipient"). We have to assume that Internet number resource holders requested to establish abuse-c - usually are NOT focussed an abuse handling (different core business:-) - in many cases are not members of the anti-abuse working (and unlikely to have insight into undocumented potential consensus views of the working group or the larger abuse-c activist community) - in general willing to cooperate (we really should care for those and help them! ... yes, there are others - from "don't care" to "evil") For making a reasoned decision about the recipient for abuse-c and preparing for handling messages one obviously needs some understanding/explanation of what is expected. If no such helpful information is offered at the time of requesting abuse-c setup, many well intentioned parties will *something* (not really good "quality") to fill required fields and little motivation to followup will remain. If they care to ask for helpful information and the answer stays "this is required by policy, and it consciously declines to explain", they are likely to conclude that they have to submit to RIPE policies and the policy makers+process that cannot be taken serious... I note that for goal (b) of course some common understanding of expected use and handling for the abuse-c mailbox is a prerequisite on BOTH sides (senders also!) I do not expect to see formal, precise, and exhaustive definition of requirements and intended/expected use of abuse-c use - that would seem fairly impossible and certainly would not provide a practical answer to the issue. The working group needs to followup it previous abuse-c policy by starting to create practically useful explanations, before considering more "enforcement" (actually IMHO all enforcement activety should [have] be[en] postponed - potentially replaced by friendly invitations). It may take considerable effort to develope consensus on such documentation - but is it reasonable to rely on all relevant outside parties to have the first contact figure out completely on his own and explain to his management, consultants, service providers, etc... what needs to be done? (what aggregated cost and what "quality" implications do you expect?) It's ok to have working groups that just have internal fun between some birds of a feather. If a working group feels like making demands (e.g. policies) to a larger community it should also consider what support it needs to provide to serve the purposes of that larger community. Thanks for your attention and consideration. Ruediger Volk P.S.: Sorry, for a painfully long message. Trust me I had more painful time writing - and making it shorter would have been worse - with termination not secure:-) I hope that the painful length does not obscure - valid concern - constructive suggestions From training at ripe.net Mon Feb 29 14:41:41 2016 From: training at ripe.net (Training Services) Date: Mon, 29 Feb 2016 14:41:41 +0100 Subject: [db-wg] [training] RIPE NCC Training Courses April-June 2016 Message-ID: <56D44A95.40807@ripe.net> Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Budapest, Tirana, Manchester, Lisbon, Bologna, Munich, Tallinn, Moscow, Vienna, Valletta, Reykjavik. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From ops.lists at gmail.com Mon Feb 29 12:09:25 2016 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 29 Feb 2016 16:39:25 +0530 Subject: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: > We have to assume that Internet number resource holders requested > to establish abuse-c > - usually are NOT focussed an abuse handling (different core business:-) With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. Admittedly their core business is not providing internet access or managing abuse. Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues (which might further lead to data leaks from their company etc)? With abuse-c an external reporter can reach out to the appropriate team, which might possibly be a third party vendor, rather than having to call or email the brewery?s corporate HQ and then have the message work through several layers of staff and possibly just get lost. This merely provides a standard format to contact the relevant team - which may well be the same corporate IT team for them that manages their IP space and routing. Reporters are simply spared the decision tree of whether to mail a tech contact for a ddos issue where he / she may be totally different from the security department that handles it. Or an ISP providing services and allocating a range to their customer may want their information in the abuse-c. From michele at blacknight.com Mon Feb 29 13:37:16 2016 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Mon, 29 Feb 2016 12:37:16 +0000 Subject: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <734DEF8D-6AD8-420C-8F2F-F53563DF3E2C@blacknight.com> Reedier I disagree A standardised abuse-c contact was introduced by RIPE some time ago based on the anti-abuse WG?s work. This was communicated via various media and via RIPE staff and at RIPE meetings etc., The ?new? policy that is being proposed improves the overall ecosystem for all users and any delay in implementing it is ill advised. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From dhc at dcrocker.net Mon Feb 29 16:09:11 2016 From: dhc at dcrocker.net (Dave Crocker) Date: Mon, 29 Feb 2016 07:09:11 -0800 Subject: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> References: <11461.1456684690@x59.NIC.DTAG.DE> <432BB70C-DD25-42C1-AFBA-BAB04E64C27A@gmail.com> Message-ID: <56D45F17.3010100@dcrocker.net> On 2/29/2016 3:09 AM, Suresh Ramasubramanian wrote: > On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: >> We have to assume that Internet number resource holders requested >> to establish abuse-c >> - usually are NOT focussed an abuse handling (different core business:-) > > With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. ... > Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues ... > With abuse-c an external reporter can reach out to the appropriate team, ... +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jerry1upton at aol.com Mon Feb 29 21:51:23 2016 From: jerry1upton at aol.com (Jerry Upton) Date: Mon, 29 Feb 2016 15:51:23 -0500 Subject: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <56D45F17.3010100@dcrocker.net> Message-ID: <1532eccbe5a-60ba-8c84@webprd-m49.mail.aol.com> +2 Jerry Upton Executive Director M3AAWG.org -----Original Message----- From: Dave Crocker To: Suresh Ramasubramanian ; Ruediger Volk Cc: aa-wg-chairs ; db-wg-chairs ; db-wg ; anti-abuse-wg Sent: Mon, Feb 29, 2016 9:10 am Subject: Re: [anti-abuse-wg] objection to RIPE policy proposal 2016-01 On 2/29/2016 3:09 AM, Suresh Ramasubramanian wrote: > On 29-Feb-2016, at 12:08 AM, Ruediger Volk wrote: >> We have to assume that Internet number resource holders requested >> to establish abuse-c >> - usually are NOT focussed an abuse handling (different core business:-) > > With all due respect - assume that the number resource holder is a corporation engaged in, for example, brewing beer. ... > Wouldn?t they have a corporate IT team tasked with looking at compromises on their network that are causing abuse / DDoS issues ... > With abuse-c an external reporter can reach out to the appropriate team, ... +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fw at deneb.enyo.de Mon Feb 29 22:06:55 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 29 Feb 2016 22:06:55 +0100 Subject: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01 In-Reply-To: <11461.1456684690@x59.NIC.DTAG.DE> (Ruediger Volk's message of "Sun, 28 Feb 2016 19:38:10 +0100") References: <11461.1456684690@x59.NIC.DTAG.DE> Message-ID: <87lh638bv4.fsf@mid.deneb.enyo.de> * Ruediger Volk: > No PDP is needed to send friendly invitations to legacy holders to > populate their data objects with abuse-c information; I'm sure > asking the RIPE NCC to do this would not create an undue burden or > serious problem. How is 2016-01 different from sending such notices? The net effect seems to be about the same. The interesting question (with either approach) is what RIPE NCC should do if it has proof that the contact information in the RIPE database is incorrect.