- db-wg - mailman.ripe.net

Cleanup work for "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06
by Tim Bruijnzeels 04 Mar '16

04 Mar '16

Dear working group, As you know, the RIPE NCC completed the work for the 2011-06 policy on 15 February, and "abuse-c:" is now added to all organisations that hold resources allocated or assigned by the RIPE NCC. Going forward we propose to: - Remove "abuse-mailbox:" for all ORGANISATION objects that *have* "abuse-c:" in a one-off operation - Introduce a business rule to prevent adding "abuse-mailbox:" to ORGANISATION objects, urging people to use "abuse-c:" instead Please note that the proposal above does not force anyone to use "abuse-c:", it just enforces that "abuse-c:" is used instead of "abuse-mailbox:". Having both attributes on an ORGANISATION object is extremely confusing, and currently updating "abuse-mailbox:" does not work in the LIR Portal organisation object editor. We therefore believe that the cleanup is needed, and we hope that this will not be controversial. We would like to ask the working group for the mandate to do the cleanup proposed above. Originally the intent was to clean up "abuse-mailbox:" on all objects (except in abuse-c roles) and possibly IRT objects. However, we are fully aware that more controversy exists here. There is a lot of discussion about whether "abuse-c:" can be mandatory for organisations holding legacy resources (2016-01). Questions are being raised about the data model. We are following these discussions with interest and we believe that this part of the originally proposed cleanup should be put on hold until we have a more clear direction from those discussions. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

2 1

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by Gert Doering 03 Mar '16

03 Mar '16

Hi, On Thu, Mar 03, 2016 at 12:56:05PM +0200, andre(a)ox.co.za wrote: > it is actually very simple: > > any rigorously correct resource allocation registry data must > include accurate abuse records. No. It needs to contain accurate records of who has been delegated responsibility for that (admin-c / org). abuse-c is a way to ease finding the *right* contacts instead of always having to write paper mail to the company CEO - and that makes sense, but it's a convenience to operators (as is tech-c), and in no means required for the function as registry. Which might conincide with the fact that the paperwork you sign when opening a LIR has no field for abuse-c... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 4

[training] RIPE NCC Training Courses April-June 2016
by Training Services 29 Feb '16

29 Feb '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in 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

1 0

RIPE DB services downtime
by Thiago da Cruz Pereira 19 Feb '16

19 Feb '16

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

1 1

RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
by Tim Bruijnzeels 19 Feb '16

19 Feb '16

Dear working groups, As you know all organisations that have internet number resources allocated or assigned by the RIPE NCC need to have an abuse-c attribute according to policy 2011-06. The following implementation plan was communicated for this policy: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… Phase 1 of this plan was completed in December 2013, setting up abuse-c for then existing LIRs. Phase 2 of this plan was completed for organisations holding sponsored PI resources in November 2014. However, since then LIRs and end-users have been responsible for ensuring that an abuse-c exists for their organisation. In practice it has proven difficult to enforce this, since abuse-c is not a mandatory attribute in the RIPE DB schema, and as a result new cases where organisations do not have an abuse contact have been created. There is an important change in the implementation we would like to do – based on our experiences thus far – which would like the community's mandate on. We propose to use the end-user organisation's email address instead of the sponsoring LIR email address. We believe there are valid reasons for this change, but of course if this suggested change is controversial we would encourage discussing it in the anti-abuse working group. Ideally, we need to have a decision on this by early January so that we can prepare the work. 1) Prevent NEW cases We want to ensure that no new cases will be created as follows: = Since 1 March, the new member application form already provides much better integration with the RIPE Database - because of this an abuse contact is now created whenever a new LIR is activated - it can be modified the LIR, e.g. using web-updates, but not removed = We are currently adapting the new create organisation webupdates form to include abuse-c by default allowing the user to: - reference an existing abuse-c role object, or - enter an email address to create an abuse-c role for the organisation (using the same maintainer) = We are also adapting the edit organisation webupdates form to always suggest adding an abuse-c contact if it's not present = We plan to extend the new request forms: - check that an end-user organisation has abuse-c before it can be used - if not, refer to the edit form for the organisation where it will be easy to add reference an existing abuse contact, or create a new object 2) Resolve remaining EXISTING cases Originally the idea for phase 2 was to use the sponsoring LIR's email address in case the end-user organisation was unresponsive to requests to set their own abuse contact. However, since then policy 2012-08 has been implemented and nowadays the sponsoring LIR, and its abuse contact, can be found through the sponsoring-org attribute. Also, the RIPE NCC found that using the sponsoring organisation's email address leads to a number of issues: - end-users have no incentive to set their own abuse-c, rather then letting abuse questions go to their sponsor, so the majority remains unresponsive - in case an end-user has resources from more than one sponsor it is ambiguous which sponsor's email should be used - many LIRs were unpleasantly surprised by finding their email address in the abuse-c of the organisation they sponsor - in case LIRs no longer wish to sponsor resources, or when they are returned, existing references to their email in the end-user abuse-c are not cleaned up We would therefore like to propose a change to the implementation plan when addressing the remaining cases. Today, in case no abuse contact is set, users of the database will resort to using the organisation's default email. Therefore, adding a dedicated abuse-c role object using this email address, doesn't cause any noticeable new effects on organisations. It may well be the correct email address to use for an organisation, and no action would be required. However, it *enables* an organisation to use a different email address for abuse questions if appropriate. We would like to email remaining LIRs, and end-user organisations and sponsoring LIRs on Monday 1 February, giving them until Monday 15 February to set their abuse contact. We realise that this means we would have another delay, but we believe that it would be unwise to do this change over the end of year holiday period, and to ensure that we can give proper support to questions we want to avoid doing this at the same time as the start of the year invoicing. Please let us know what you think. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14

Question about RIPE Database
by Ricardo Cukier 15 Feb '16

15 Feb '16

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

2 1

Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working group, There is an open action point on us regarding the use of the RIPE-NCC-RPSL-MNT maintainer: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004626.html > I'd like to ask RIPE NCC to provide the group with an implementation > plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from > being used to authenticate updates to an object after the object has > been created. We also ask that the RIPE NCC look into cleaning up > existing references to RIPE-NCC-RPSL-MNT and tell us their plan. Note that there is an ongoing an important parallel discussion about the authorisation of out-of-region IRR objects in general. But this is specifically about the use of 'RIPE-NCC-RPSL-MNT' on "mnt-by:". As long as we do have RIPE-NCC-RPSL-MNT, there are things we can improve and we want to propose the following to working group: 1) implement a business rule to prevent that this maintainer is used as 'mnt-by' Submitting an object that includes 'mnt-by: RIPE-NCC-RPSL-MNT' would result in a hard error, with a message like: "The RIPE-NCC-RPSL-MNT is used to authorise the creation of out-of-region aut-num and route(6) objects, but may not be used as 'mnt-by'" This is fairly trivial to implement, provided of course that the working group agrees to this. 2) remove the maintainer from existing objects There are roughly 2000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' only, and about 10000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' and at least one other maintainer. In the first case we propose to lock the object, i.e. set 'mnt-by: RIPE-NCC-LOCKED-MNT', and send out a custom notification to any contacts on the object explaining that the object has been locked to prevent a hijack of the object, and that ripe-dbm(a)ripe.net can be contacted to unlock the object. In the second case we propose to leave the remaining maintainer and send out a custom notification informing contacts on the object that the "RIPE-NCC-RPSL-MNT" has been removed to prevent a hijack of the object, and listing which maintainer(s) remain. Technically this is not difficult either, but it can result in a lot of questions. Therefore we prefer to do this in batches to make sure that we can process possible follow up requests to ripe-dbm(a)ripe.net properly. For reference we used a similar approach when dealing with locking the old MD5 passwords earlier this year. Provided that the working group agrees with this, we expect this can be done in the space of a few weeks after the business rule is implemented. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14

Implementation proposal descr line
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

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(a)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.

8 14

Release 1.85 (changed phase 3) deployed to RC
by Tim Bruijnzeels 02 Feb '16

02 Feb '16

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-… 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

1 1

Re: [db-wg] [members-discuss] ripe objects as single text field
by Alex Band 02 Feb '16

02 Feb '16

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 <A.Betts(a)node4.co.uk> 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@ripe.net] On Behalf Of David Wilkinson > Sent: 24 November 2015 17:06 > To: Tapio Haapala; members-discuss(a)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@ripe.net] On Behalf Of Tapio Haapala > Sent: 24 November 2015 16:42 > To: members-discuss(a)ripe.net<mailto:members-discuss@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@ircnet<mailto:Burner@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(a)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.

7 9