From hank at efes.iucc.ac.il Tue Apr 7 14:03:00 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 07 Apr 2015 15:03:00 +0300 Subject: [ncc-services-wg] RIPE-NCC-LEGACY-MNT Message-ID: <5.1.1.6.2.20150407145624.05213100@efes.iucc.ac.il> Not sure which list is appropriate so please reply only to the list that people point out as the one which should handle the following issue: I have modified a number of objects to be now LEGACY objects. inet-nums and aut-nums. When the object is processed and converted into a LEGACY object, RIPE auto-adds the following line to each object: mnt-by: RIPE-NCC-LEGACY-MNT This is documented here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 Policy 2012-07: Legacy holder organisations cannot change their organisation name in their org object if it is referenced by an INETNUM or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. I then noticed I needed to delete some import and export lines on my aut-num policy. No can do any more. I now get the error: Authorisation for [aut-num] AS378 failed using "mnt-by:" not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT So this now means *every* change to any legacy IP block or ASN has to go via RIPE. But I have been unable to find how to go about informing RIPE that I need to make an object modification. Any pointers would be helpful. Regards, Hank From andrea at ripe.net Tue Apr 7 17:28:51 2015 From: andrea at ripe.net (Andrea Cima) Date: Tue, 07 Apr 2015 17:28:51 +0200 Subject: [ncc-services-wg] RIPE-NCC-LEGACY-MNT In-Reply-To: <5.1.1.6.2.20150407145624.05213100@efes.iucc.ac.il> References: <5.1.1.6.2.20150407145624.05213100@efes.iucc.ac.il> Message-ID: <5523F7B3.3010600@ripe.net> Hi Hank, Thanks for your email. The error message you received is normal, though it's understandable that it might be a little confusing. When a legacy Internet resource is covered by a contractual relationship, it receives the RIPE-NCC-LEGACY-MNT maintainer, in addition to the End User's maintainer (as "mnt-by:"). For an object to be updated, only one of these two maintainers must pass the authentication. In this case, the update was not authenticated on your end, and so the error message is correctly telling you that neither our maintainer nor yours was authenticated. This legacy maintainer follows the same business rules as other RIPE NCC maintainers: - RIPE-NCC-LEGACY-MNT can only be added or removed by the RIPE NCC - If RIPE-NCC-LEGACY-MNT is present in AUT-NUM and INETNUM objects as MNT-BY, ORG-ID cannot be changed - If the ORGANISATION object is referenced in resources where RIPE-NCC-LEGACY-MNT is present, then the "org-name:" cannot be edited by anyone other than the RIPE NCC. So this means that all other attributes can be updated with only the End User's maintainer and without involving the RIPE NCC. Please let me know if you have any further questions. Kind regards Andrea Cima Registration Services RIPE NCC On 7/4/15 14:03, Hank Nussbacher wrote: > Not sure which list is appropriate so please reply only to the list that > people point out as the one which should handle the following issue: > > I have modified a number of objects to be now LEGACY objects. inet-nums > and aut-nums. > When the object is processed and converted into a LEGACY object, RIPE > auto-adds the following line to each object: > mnt-by: RIPE-NCC-LEGACY-MNT > > This is documented here: > https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 > Policy 2012-07: Legacy holder organisations cannot change their > organisation name in their org object if it is referenced by an INETNUM > or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. > > I then noticed I needed to delete some import and export lines on my > aut-num policy. > > No can do any more. I now get the error: > > Authorisation for [aut-num] AS378 failed > using "mnt-by:" > not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT > > So this now means *every* change to any legacy IP block or ASN has to go > via RIPE. But I have been unable to find how to go about informing RIPE > that I need to make an object modification. Any pointers would be > helpful. > > Regards, > Hank > > From hank at efes.iucc.ac.il Tue Apr 7 17:37:27 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 07 Apr 2015 18:37:27 +0300 Subject: [ncc-services-wg] [db-wg] RIPE-NCC-LEGACY-MNT In-Reply-To: <5523F7B3.3010600@ripe.net> References: <5.1.1.6.2.20150407145624.05213100@efes.iucc.ac.il> <5.1.1.6.2.20150407145624.05213100@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20150407183714.052ce020@efes.iucc.ac.il> At 17:28 07/04/2015 +0200, Andrea Cima wrote: Thanks! Works. -Hank >Hi Hank, > >Thanks for your email. The error message you received is normal, though >it's understandable that it might be a little confusing. > >When a legacy Internet resource is covered by a contractual >relationship, it receives the RIPE-NCC-LEGACY-MNT maintainer, in >addition to the End User's maintainer (as "mnt-by:"). For an object to >be updated, only one of these two maintainers must pass the >authentication. In this case, the update was not authenticated on your >end, and so the error message is correctly telling you that neither our >maintainer nor yours was authenticated. > >This legacy maintainer follows the same business rules as other RIPE NCC >maintainers: > >- RIPE-NCC-LEGACY-MNT can only be added or removed by the RIPE NCC >- If RIPE-NCC-LEGACY-MNT is present in AUT-NUM and INETNUM objects as >MNT-BY, ORG-ID cannot be changed >- If the ORGANISATION object is referenced in resources where >RIPE-NCC-LEGACY-MNT is present, then the "org-name:" cannot be edited by >anyone other than the RIPE NCC. > >So this means that all other attributes can be updated with only the End >User's maintainer and without involving the RIPE NCC. > >Please let me know if you have any further questions. > >Kind regards > >Andrea Cima >Registration Services >RIPE NCC > > >On 7/4/15 14:03, Hank Nussbacher wrote: > > Not sure which list is appropriate so please reply only to the list that > > people point out as the one which should handle the following issue: > > > > I have modified a number of objects to be now LEGACY objects. inet-nums > > and aut-nums. > > When the object is processed and converted into a LEGACY object, RIPE > > auto-adds the following line to each object: > > mnt-by: RIPE-NCC-LEGACY-MNT > > > > This is documented here: > > https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 > > Policy 2012-07: Legacy holder organisations cannot change their > > organisation name in their org object if it is referenced by an INETNUM > > or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. > > > > I then noticed I needed to delete some import and export lines on my > > aut-num policy. > > > > No can do any more. I now get the error: > > > > Authorisation for [aut-num] AS378 failed > > using "mnt-by:" > > not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT > > > > So this now means *every* change to any legacy IP block or ASN has to go > > via RIPE. But I have been unable to find how to go about informing RIPE > > that I need to make an object modification. Any pointers would be > > helpful. > > > > Regards, > > Hank > > > > From nick at netability.ie Tue Apr 21 13:17:19 2015 From: nick at netability.ie (Nick Hilliard) Date: Tue, 21 Apr 2015 12:17:19 +0100 Subject: [ncc-services-wg] ARC DNS consistency checks Message-ID: <553631BF.8060700@netability.ie> A couple of months ago, I did an assisted registry check for a LIR, and the info in the Reverse DNS Consistency widget was out of date - from what I remember, over a year. This caused some confusion, as several of the problems had actually been fixed in the interim. Would it be possible to get up-to-date checks scheduled in advance of future ARC checks? It should be straightforward for the dev people to write a tool to take a regid and schedule a batch check for all the things which are reviewed in the ARC. Nick From matt.parker at ripe.net Wed Apr 22 10:22:54 2015 From: matt.parker at ripe.net (Matt Parker) Date: Wed, 22 Apr 2015 10:22:54 +0200 Subject: [ncc-services-wg] ARC DNS consistency checks In-Reply-To: <553631BF.8060700@netability.ie> References: <553631BF.8060700@netability.ie> Message-ID: <55375A5E.1010003@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nick, Thank you for your feedback. Please note that the data presented in the Reverse DNS Consistency widget relates to the most recent occasion that the DNS check was performed. You can see the date of this check in the column titled "Last DNS Check". You can always refresh this data by performing a manual DNS check for the listed prefixes. To do this, you just need to click on the date of the last check and a new window will be launched where you can initiate a new check. We would also like to thank you for the suggested improvements to RIPEstat. We?re always looking for ways to make the user interface more intuitive and will take your feedback into consideration when designing future releases. Kind regards, Matt Parker IP Resource Analyst Trainer RIPE NCC On 21/04/15 13:17, Nick Hilliard wrote: > A couple of months ago, I did an assisted registry check for a LIR, > and the info in the Reverse DNS Consistency widget was out of date > - from what I remember, over a year. This caused some confusion, > as several of the problems had actually been fixed in the interim. > > Would it be possible to get up-to-date checks scheduled in advance > of future ARC checks? It should be straightforward for the dev > people to write a tool to take a regid and schedule a batch check > for all the things which are reviewed in the ARC. > > Nick > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJVN1peAAoJEEIO6Y0u/zaYF4IIAJbejJzcZq7JJ2y92J7w3d9C Wj0nMOhxBSYti2T7J7sZ3/d4TuSxkF2p6iXu4S726tMsGnvB/SF5ElXZ8Qd4sSGN HuXwJSc5ic45b2/ZbvSEOW7uPxnbk+wA0HOlpjE/jHsfkR+PHO6MvxqpQZlT5Q/Z eW5WA6IZ+Mvd86pPlgD14izX2R028I6EFk/9HgGhKVRO27qSh6G307FixNli/EWl UfuFFr39ZqNBw7H3CjQHkVdolKndOF2zemNVUUrOcrnmRqtF8eaa4ui637buUgcS G6HDMBtE1iLHA767bFM/0DpwECktUNhGZDHQgZ87oa1fioB4XpMcD+LRk5ZjkDk= =9Oa4 -----END PGP SIGNATURE----- From nick at netability.ie Wed Apr 22 17:56:35 2015 From: nick at netability.ie (Nick Hilliard) Date: Wed, 22 Apr 2015 16:56:35 +0100 Subject: [ncc-services-wg] ARC DNS consistency checks In-Reply-To: <55375A5E.1010003@ripe.net> References: <553631BF.8060700@netability.ie> <55375A5E.1010003@ripe.net> Message-ID: <5537C4B3.7080502@netability.ie> On 22/04/2015 09:22, Matt Parker wrote: > Please note that the data presented in the Reverse DNS Consistency > widget relates to the most recent occasion that the DNS check was > performed. You can see the date of this check in the column titled > "Last DNS Check". > > You can always refresh this data by performing a manual DNS check for > the listed prefixes. To do this, you just need to click on the date of > the last check and a new window will be launched where you can > initiate a new check. yep, that's correct. But when you're doing an ARC with a LIR who hasn't gone through the process before, the information presented during the check can be out of date, which means that the ARC isn't really performing what it's supposed to do. Would it be possible to update the procedure to have the RIPE NCC auto-refresh the DNS check data before the ARC check so that the check is done against fresh data? thanks, Nick From nigel at titley.com Wed Apr 22 18:09:10 2015 From: nigel at titley.com (Nigel Titley) Date: Wed, 22 Apr 2015 18:09:10 +0200 Subject: [ncc-services-wg] ARC DNS consistency checks In-Reply-To: <5537C4B3.7080502@netability.ie> References: <553631BF.8060700@netability.ie> <55375A5E.1010003@ripe.net> <5537C4B3.7080502@netability.ie> Message-ID: <5537C7A6.2070504@titley.com> On 22/04/2015 17:56, Nick Hilliard wrote: > Would it be possible to update the procedure to have the RIPE NCC > auto-refresh the DNS check data before the ARC check so that the check is > done against fresh data? This does seem to make a lot of sense, unless I'm missing something Nigel From andrea at ripe.net Thu Apr 23 15:33:29 2015 From: andrea at ripe.net (Andrea Cima) Date: Thu, 23 Apr 2015 15:33:29 +0200 Subject: [ncc-services-wg] ARC DNS consistency checks In-Reply-To: <5537C7A6.2070504@titley.com> References: <553631BF.8060700@netability.ie> <55375A5E.1010003@ripe.net> <5537C4B3.7080502@netability.ie> <5537C7A6.2070504@titley.com> Message-ID: <5538F4A9.2090605@ripe.net> Hi Nick and Nigel, On 22/4/15 18:09, Nigel Titley wrote: > > On 22/04/2015 17:56, Nick Hilliard wrote: >> Would it be possible to update the procedure to have the RIPE NCC >> auto-refresh the DNS check data before the ARC check so that the check is >> done against fresh data? > This does seem to make a lot of sense, unless I'm missing something We agree that this makes sense, though it will require some engineering work. We will therefore strive to implement this before the RIPE Meeting. Best regards Andrea Cima RIPE NCC > Nigel > From bijal at euro-ix.net Tue Apr 28 13:18:01 2015 From: bijal at euro-ix.net (Bijal Sanghani) Date: Tue, 28 Apr 2015 12:18:01 +0100 Subject: [ncc-services-wg] Draft minutes: RIPE 69 NCC Services WG Message-ID: Hi All, We just realised the minutes from the last services working group session in London were not posted to the list, please see minutes here and apologies for delivering them a little late. https://www.ripe.net/participate/ripe/wg/services/minutes/ripe-69-ripe-ncc-services-working-group-minutes Best regards, NCC Services WG Chairs From tim at ripe.net Thu Apr 30 11:58:02 2015 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 30 Apr 2015 11:58:02 +0200 Subject: [ncc-services-wg] Policy Proposal Implemented: 2014-06, "Publication of Sponsoring LIR for Legacy Internet Resource Holders" Message-ID: <146FCACB-41D7-41A0-A987-126C7CEACF52@ripe.net> Dear colleagues, We are pleased to announce that following the deployment of release 1.79.1 of the RIPE Database earlier this week, the accepted RIPE Policy Proposal 2014-06, "Publication of Sponsoring LIR for Legacy Internet Resource Holders", has now been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2014-06 The new RIPE Document, ripe-639, "RIPE NCC Services to Legacy Internet Resource Holders ", is available at: https://www.ripe.net/publications/docs/ripe-639 Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: