From denis at ripe.net Tue Oct 1 12:51:12 2013 From: denis at ripe.net (Denis Walker) Date: Tue, 01 Oct 2013 12:51:12 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now In-Reply-To: <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> References: <522DCCD6.9060205@ripe.net> <52404724.7070409@ripe.net> <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> Message-ID: <524AA920.1040202@ripe.net> Dear Aris, If you use the keyword 'DIFF' in a subject line of an email update the software will treat the update as a dry-run and does not handle multiple objects. There is no need to use 'DIFF' as a keyword to get a diff output. By default all notification messages for object modifications now return the diff output followed by the full new object. Regards Denis Walker Business Analyst RIPE NCC Database Team On 01/10/2013 12:34, Aris Lambrianidis wrote: > Hello Denis and all, > > Any chance the new feature broke multiple object updates via a single > email (without using the dry-run option, ofc.)? We seem to be getting > error messages when trying to do that, I've already notified > auto-dbm@ about it. > > Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 > http://www.ams-ix.net/ > > On Sep 23, 2013, at 15:50 , Denis Walker wrote: > >> Dear colleagues, >> >> Release 1.69 of the RIPE Database has now been fully deployed. >> >> Regards, >> >> Denis Walker Business Analyst RIPE NCC Database Team >> >> >> >> >> -------- Original Message -------- Subject: [db-wg] RIPE Database >> Release 1.69 Available Soon Date: Mon, 09 Sep 2013 15:27:50 +0200 >> From: Denis Walker Organization: RIPE NCC To: >> Database WG , NCC Services WG >> >> >> Dear colleagues, >> >> The RIPE NCC is pleased to announce that we have deployed a new >> release of the RIPE Database to the TEST Database environment. >> Detailed information about the new release, including dates and >> information about the changes can be found here: >> https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.69 >> >> >> Of special note in this release is the inclusion of "dry-run". Using the >> dry-run function you can test whether an update would succeed or >> not. The update procedure runs as normal except that no change is >> made to the database. Find out more about the dry-run function >> here: >> https://labs.ripe.net/Members/denis/dry-run-testing-in-the-ripe-database >> >> >> Due to recent issues with the REST API, we've extended the migration >> period up until the 1.70 release. This release is currently >> scheduled for the end of October. >> >> If you have any questions or comments, we look forward to hearing >> them! >> >> Regards, >> >> Denis Walker Business Analyst RIPE NCC Database Team >> >> >> >> >> > From rhe at nosc.ja.net Tue Oct 1 13:05:13 2013 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 1 Oct 2013 12:05:13 +0100 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now In-Reply-To: <524AA920.1040202@ripe.net> References: <522DCCD6.9060205@ripe.net> <52404724.7070409@ripe.net> <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> <524AA920.1040202@ripe.net> Message-ID: <6BEEF0DD-8E9F-46FB-A2EA-C8FB26530581@nosc.ja.net> Hi Denis, > There is no need to use 'DIFF' as a keyword to get a diff output. By default all notification messages for object modifications now return the diff output followed by the full new object. Yes, this is one of the changes that has tripped me up. Not being in the habit of reading all the release notes of minor updates to the database (or even knowing when to), it used to be standard practice for us to use 'diff' in the subject line of an update so that we could see what changed between two versions of a fairly large object. At some point, a minor release then started rejecting updates with that keyword. Now it is back, but with a different meaning. There are good reasons for this, I am sure, but from a user interface point of view it could perhaps have been communicated better, or a different "new" keyword used rather than overload one that has previously been used. Cheers, Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From richih.mailinglist at gmail.com Tue Oct 1 13:08:09 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 1 Oct 2013 13:08:09 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now In-Reply-To: <6BEEF0DD-8E9F-46FB-A2EA-C8FB26530581@nosc.ja.net> References: <522DCCD6.9060205@ripe.net> <52404724.7070409@ripe.net> <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> <524AA920.1040202@ripe.net> <6BEEF0DD-8E9F-46FB-A2EA-C8FB26530581@nosc.ja.net> Message-ID: On Oct 1, 2013 1:05 PM, "Rob Evans" wrote: > There are good reasons for this, I am sure, but from a user interface point of view it could perhaps have been communicated better, or a different "new" keyword used rather than overload one that has previously been used. Agreed. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Tue Oct 1 15:35:39 2013 From: denis at ripe.net (Denis Walker) Date: Tue, 01 Oct 2013 15:35:39 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now In-Reply-To: <326A5C6F-F7FC-4896-878F-0C1DC95C67A9@ams-ix.net> References: <522DCCD6.9060205@ripe.net> <52404724.7070409@ripe.net> <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> <524AA920.1040202@ripe.net> <326A5C6F-F7FC-4896-878F-0C1DC95C67A9@ams-ix.net> Message-ID: <524ACFAB.5000002@ripe.net> Dear Aris This was a small change that we implemented quite some time ago. It was not included in previous releases and added into the latest which is probably why we missed it in the release notes. We had previously announced the change in the 'DIFF' implementation with this now being the default behaviour. We were asked at the last RIPE Meeting for this dry-run behaviour. If it is still considered useful to have a subject line keyword to trigger a dry-run we can change it to a new keyword (DRY-RUN) on the next release. Regards Denis Walker Business Analyst RIPE NCC Database Team On 01/10/2013 13:03, Aris Lambrianidis wrote: > Thanks for the explanation Denis! > > Perhaps it'd be prudent to clarify that somewhere on the website. In > my mind the deprecated use of the DIFF keyword was a completely > separate issue from the dry-run option, as those modifications as to > how objects are parsed were done at different points in time. > > Plus, the warnings and errors produced are not as helpful, there's > the (standard) warning about using the DIFF keyword and then an error > about "dry-run being supported only when a single object is > specified". > > Kind regards, > > Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 > http://www.ams-ix.net/ > > > > > On Oct 1, 2013, at 12:51 , Denis Walker wrote: > >> Dear Aris, >> >> If you use the keyword 'DIFF' in a subject line of an email update >> the software will treat the update as a dry-run and does not handle >> multiple objects. >> >> There is no need to use 'DIFF' as a keyword to get a diff output. >> By default all notification messages for object modifications now >> return the diff output followed by the full new object. >> >> Regards Denis Walker Business Analyst RIPE NCC Database Team >> >> >> On 01/10/2013 12:34, Aris Lambrianidis wrote: >>> Hello Denis and all, >>> >>> Any chance the new feature broke multiple object updates via a >>> single email (without using the dry-run option, ofc.)? We seem to >>> be getting error messages when trying to do that, I've already >>> notified auto-dbm@ about it. >>> >>> Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 >>> http://www.ams-ix.net/ >>> >>> On Sep 23, 2013, at 15:50 , Denis Walker wrote: >>> >>>> Dear colleagues, >>>> >>>> Release 1.69 of the RIPE Database has now been fully deployed. >>>> >>>> Regards, >>>> >>>> Denis Walker Business Analyst RIPE NCC Database Team >>>> >>>> >>>> >>>> >>>> -------- Original Message -------- Subject: [db-wg] RIPE >>>> Database Release 1.69 Available Soon Date: Mon, 09 Sep 2013 >>>> 15:27:50 +0200 From: Denis Walker >>>> Organization: RIPE NCC To: Database WG , NCC >>>> Services WG >>>> >>>> Dear colleagues, >>>> >>>> The RIPE NCC is pleased to announce that we have deployed a >>>> new release of the RIPE Database to the TEST Database >>>> environment. Detailed information about the new release, >>>> including dates and information about the changes can be found >>>> here: >>>> https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.69 >>>> >>>> >>>> >> >>>> Of special note in this release is the inclusion of "dry-run". Using the >>>> dry-run function you can test whether an update would succeed >>>> or not. The update procedure runs as normal except that no >>>> change is made to the database. Find out more about the dry-run >>>> function here: >>>> https://labs.ripe.net/Members/denis/dry-run-testing-in-the-ripe-database >>>> >>>> >>>> >> >>>> Due to recent issues with the REST API, we've extended the migration >>>> period up until the 1.70 release. This release is currently >>>> scheduled for the end of October. >>>> >>>> If you have any questions or comments, we look forward to >>>> hearing them! >>>> >>>> Regards, >>>> >>>> Denis Walker Business Analyst RIPE NCC Database Team >>>> >>>> >>>> >>>> >>>> >>> > From gert at space.net Tue Oct 1 17:38:56 2013 From: gert at space.net (Gert Doering) Date: Tue, 1 Oct 2013 17:38:56 +0200 Subject: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now In-Reply-To: <524ACFAB.5000002@ripe.net> References: <522DCCD6.9060205@ripe.net> <52404724.7070409@ripe.net> <18C15B5E-1E95-46AC-A541-305E307EB3C1@ams-ix.net> <524AA920.1040202@ripe.net> <326A5C6F-F7FC-4896-878F-0C1DC95C67A9@ams-ix.net> <524ACFAB.5000002@ripe.net> Message-ID: <20131001153856.GQ65295@Space.Net> Hi, On Tue, Oct 01, 2013 at 03:35:39PM +0200, Denis Walker wrote: > If it is still considered useful to have a subject line keyword to > trigger a dry-run we can change it to a new keyword (DRY-RUN) on the > next release. This. And make it very clear in the resulting output that *this* keyword triggered the behaviour (to avoid nasty surprises if someone happens to accidentially have "dry-run" in the subject, for whatever reason). Gert Doering -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From bijal.sanghani at euro-ix.net Wed Oct 2 15:25:40 2013 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Wed, 2 Oct 2013 16:25:40 +0300 Subject: [ncc-services-wg] NCC Services WG Draft Agenda - RIPE 67 Message-ID: <70812C72-31B0-4722-AAF6-7FA4F87B2AE6@euro-ix.net> Dear colleague, Please see below and online the draft agenda for the NCC Services WG - RIPE 65 - https://ripe67.ripe.net/programme/meeting-plan/services-wg/ Date: Wednesday 26 September 2012 Time: 16.00 - 17.45 Chair: Kurtis Lindqvist Co-Chair: Bijal Sanghani A. Administrative Matters (5 minutes) Welcome Select a scribe Finalise agenda Approve minutes from RIPE 66 B. RIPE NCC Survey Results - Serge Radovcic, RIPE NCC and Desiree Miloshevic, Oxford Internet Institute (15 minutes) C. RIPE NCC outlook - Axel Pawlik, RIPE NCC (20 minutes) D. Services update and address hijacking issues - Andrew de la Haye, RIPE NCC (20 minutes) E. Policy Proposals Update - NCC Services WG Chairs (10 minutes) - 2012-07, RIPE NCC Services to Legacy Internet Resource Holders - 2012-08, Publication of Sponsoring LIR for Independent Number Resources, Nick Hilliard, INEX - 2013-04, Resource Certification for non-RIPE NCC members F. Open Microphone Session Z. AOB regards, Bijal & Kurtis NCC Services WG Chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Wed Oct 9 12:38:44 2013 From: denis at ripe.net (Denis Walker) Date: Wed, 09 Oct 2013 12:38:44 +0200 Subject: [ncc-services-wg] Syntax Change to Aut-num Object in the RIPE Database Message-ID: <52553234.3020002@ripe.net> Dear colleagues, We would like to give you a heads-up about a proposal, currently being considered, to add two new attributes to the aut-num object in the RIPE Database: "import-via:" and "export-via:". In this email we are not concerned with the details of this specific change so much as the fact that a change is being considered. We know that these objects are very important for routing and many of them are updated daily in the RIPE Database. We also know that many scripts exist for auto-generating these objects and processing the contents. Although the RFC for RPSL clearly states that scripts should be written to ignore attributes they don't recognise, we don't know if all scripts are written this way. The RIPE NCC is considering the best ways to get information about any changes to routing object syntax in the RIPE Database out to the people who need to know. We would welcome any feedback on this issue from the community. Regards, Denis Walker Business Analyst RIPE NCC Database Team From alexb at ripe.net Thu Oct 10 14:35:12 2013 From: alexb at ripe.net (Alex Band) Date: Thu, 10 Oct 2013 14:35:12 +0200 Subject: [ncc-services-wg] Expansion of eligible address space for Resource Certification (RPKI) Message-ID: <1A4CBD89-AF1D-4DBB-B8FF-97F9273B6764@ripe.net> Dear colleagues, When the Resource Certification (RPKI) service was launched in 2011, only address space allocated to the RIPE NCC directly by IANA was eligible for certification. Today, we are happy to announce that all address space that was historically transferred to the RIPE NCC from other Regional Internet Registries (RIRs) is also eligible. These ranges are so called "minority" address space, meaning that the full /8 block is managed by one of the four other RIRs, but a subset is managed by the RIPE NCC. LIRs who hold address space in these minority ranges will automatically have those resources added to their certificate, if they already have one. Starting today, they can create Route Origin Authorisations (ROAs) for the BGP announcements that they make with these prefixes. Resource Certification (RPKI) is a free service offered by all RIRs to offer BGP Origin Validation. It allows operators to request a digital certificate containing their Internet number resources and make cryptographically verifiable statements about their intended BGP announcements. These ROAs allow other network operators to make reliable routing decisions. In the RIPE NCC service region, more than 1,600 LIRs have requested a resource certificate and created ROAs for over six /8s worth of address space. To read more about this service, please visit: http://ripe.net/certification If you have any questions, please do not hesitate to contact us at Kind regards, Alex Band Product Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipak.sitaula at zapfi.com Thu Oct 10 15:40:10 2013 From: dipak.sitaula at zapfi.com (Sitaula, Dipak) Date: Thu, 10 Oct 2013 13:40:10 +0000 Subject: [ncc-services-wg] Account/login (Customer number : 112319 , Registry ID : be.zapfinv , Reference : RIPE) Message-ID: Dear, We got an e-mail from RIPE to update our contact information of the RIPE account but we have lost our Login (username and password) detail. Technical contact is : KDM Can u provide us our login detail please... Kind regards, -- Dipak Sitaula Network Administrator M: +32 495 267467 E: dipak.sitaula at zapfi.com www.zapfi.com Intelligent Mobile Marketing Click to view our disclaimer. We are committed to the preservation of the environment. We encourage you to only print this email if absolutely necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Thu Oct 10 16:07:34 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 10 Oct 2013 16:07:34 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) Message-ID: Dear colleagues, The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the main differences from version 3.0 include: - Rewording and new text in section 1.2 (Scope) - Rewording and new text in section 2.6 (No relationship) - New section 2.7 (Lapse of relationship or agreement) - Rewording and new text in section 3.0 (Contractual requirements) - An amendment to the existing policy document ripe-592 You can find the full proposal and impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-07 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-07/draft We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From ebais at a2b-internet.com Thu Oct 10 16:51:20 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 10 Oct 2013 16:51:20 +0200 Subject: [ncc-services-wg] Account/login (Customer number : 112319 , Registry ID : be.zapfinv , Reference : RIPE) In-Reply-To: References: Message-ID: <019c01cec5c8$2e9375b0$8bba6110$@a2b-internet.com> Hi Dipak, You can email lir-help at ripe.net for these kind of questions. The ncc-services-wg@ mailing list is probably not the best location to ask for password resets. The listed contacts within your LIR might be able to assist: organisation: ORG-ZN6-RIPE org-name : Zapfi NV org-type : LIR address : Zapfi NV address : Stationsplein 10/0201 address : 8000 Brugge address : BE e-mail : gery.pollet@ zapfi.be mnt-ref : RIPE-NCC-HM-MNT mnt-ref : MNT-NVS mnt-by : RIPE-NCC-HM-MNT admin-c : NS3914-RIPE person : Nico Van Severen address : Stationsplein 10/201 address : 8000 Brugge address : Belgium phone : +32479947344 e-mail : nico@ zapfi.be nic-hdl : NS3914-RIPE mnt-by : NS49375-MNT Regards, Erik Bais From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Sitaula, Dipak Sent: donderdag 10 oktober 2013 15:40 To: ncc-services-wg at ripe.net Subject: [ncc-services-wg] Account/login (Customer number : 112319 , Registry ID : be.zapfinv , Reference : RIPE) Dear, We got an e-mail from RIPE to update our contact information of the RIPE account but we have lost our Login (username and password) detail. Technical contact is : KDM Can u provide us our login detail please? Kind regards, -- Dipak Sitaula Network Administrator M: +32 495 267467 E: dipak.sitaula at zapfi.com www.zapfi.com Intelligent Mobile Marketing Click to view our disclaimer. We are committed to the preservation of the environment. We encourage you to only print this email if absolutely necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Mon Oct 14 14:15:47 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 14 Oct 2013 14:15:47 +0200 Subject: [ncc-services-wg] Fwd: [db-wg] Improvements to RIPE Database Software Release Management Message-ID: <525BE073.2050600@CC.UniVie.ac.at> Dear Services and Routing folks, please see below fyi. My apologies for the short notice and/or duplicate messages. Regards, Wilfried -------- Original Message -------- Subject: [db-wg] Improvements to RIPE Database Software Release Management Date: Mon, 7 Oct 2013 13:31:06 +0200 From: Johan ?hl?n To: db-wg at ripe.net Dear colleagues, Following recent discussion regarding the release management of the RIPE Database software, we looked closely at our procedures and would like to propose some improvements. Together with the Database Working Group chairs, we've scheduled an informal meeting during RIPE 67, open for anyone that is interested in this topic, to discuss the proposals and talk about how we can improve our procedures. The meeting will take place on Monday, 14 October from 18:00-19:00 in room Sigma + Theta. We hope you will join us. Of course, you can also send your feedback and suggestions to this list. This is what we propose: - Split the RIPE Database software into smaller modules. Modularisation would minimise the release frequency for our services. For instance, with a modern API like RDAP we might have bi-weekly major releases and weekly minor releases to quickly respond to changes in the specification. With the NRTM feed, there might be just one major release per year or even less. - Replace the "emergency release" with a "minor release" that only contains patches for operational purposes and bug fixes. No new functionality would be introduced and no feature changes. We would also have "major releases" where functionality is added, changed or removed. With major releases we would keep the minimum two-week user test period leading up to the production release as stated in the previously proposed release procedure. With any minor release, we would put it in production as soon as it's available. Most bugs affect some users. Rather than trying to determine urgency based on numbers of users, size of users, number of networks affected, importance of functionality affected, etc., we would treat all bugs the same. In short, if someone reports an issue to us, we fix it right away. This process has generally worked well over recent years. - Improve the test environment. We know that users would like to have their real data to do proper testing. To solve this issue, we propose to use snapshots of the current database for this purpose. - Improve communication surrounding new releases. This covers all documentation and how we inform users about changes. We hope that you find this way forward beneficial. Kind regards, Johan ?hl?n Assistant Manager Database RIPE NCC From training at ripe.net Tue Oct 15 14:38:55 2013 From: training at ripe.net (Training Team) Date: Tue, 15 Oct 2013 14:38:55 +0200 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates Message-ID: <525D375F.5090805@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://lirportal.ripe.net/training/courses Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services -------------- next part -------------- An HTML attachment was scrubbed... URL: From niall.oreilly at ucd.ie Tue Oct 15 23:13:09 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 16 Oct 2013 00:13:09 +0300 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <5256b53e.c5510f0a.4c05.066eSMTPIN_ADDED_MISSING@mx.google.com> References: <5256b53e.c5510f0a.4c05.066eSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <5CEEA383-EF87-400C-9170-40E85A74B454@ucd.ie> On 10 Oct 2013, at 15:07, Marco Schmidt wrote: > The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. > > Some of the main differences from version 3.0 include: > > - Rewording and new text in section 1.2 (Scope) > - Rewording and new text in section 2.6 (No relationship) > - New section 2.7 (Lapse of relationship or agreement) > - Rewording and new text in section 3.0 (Contractual requirements) > - An amendment to the existing policy document ripe-592 Thanks to Marco for a concise and accurate list of differences. Thanks also to Athina and Andrea for making us proposers aware of gaps in the previous version and of passages where divergent readings of the text could lead to differences of understanding. Here's Marco's list again, with some extra detail. - Rewording and new text in section 1.2 (Scope) Proposed policy will supersede provisions of any existing RIPE policy which refer to legacy resources. Part of one sentence of RIPE-592 is the only policy identified as affected by this. Proposed policy will allow scope of any future RIPE policy to include legacy resources, but only if this is done explicitly. Proposed policy deliberately avoids specifying or restricting what rights are enjoyed by the holders of legacy resources. Proposed policy provides for surrender or conversion of legacy resources on the basis of informed choice by the holder. - Rewording and new text in section 2.6 (No relationship) Redundant text was removed; remaining text was tidied up. - New section 2.7 (Lapse of relationship or agreement) RIPE NCC identified the absence of guidance on how to handle lapse of agreement as a gap in the previous version of the proposal. - Rewording and new text in section 3.0 (Contractual requirements) New text focuses on mutual obligations, and avoids reference to rights of legacy resource holders, as these are placed out of scope in the current version of the proposal. - An amendment to the existing policy document ripe-592 This amendment was recognized as necessary in order to ensure coherency between RIPE-592 and the proposed new policy. Best regards, Niall O'Reilly From kurtis at kurtis.pp.se Wed Oct 16 09:04:07 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Wed, 16 Oct 2013 09:04:07 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call Message-ID: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> All, following the discussions regarding policy proposal 2012-08 in the NCC-Services WG the chairs have decided a consensus for moving forward exists and thus the proposal is moved to Last Call. Kurtis & Bijal NCC Services WG chairs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mschmidt at ripe.net Wed Oct 16 09:48:04 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 16 Oct 2013 09:48:04 +0200 Subject: [ncc-services-wg] 2012-08 Last Call for Comments (Publication of Sponsoring LIR for Independent Number Resources) Message-ID: Dear colleagues, The proposal described in 2012-08, Publication of Sponsoring LIR for Independent Number Resources, is now in its Concluding Phase. The RIPE NCC Services Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 14 November 2013 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-08 Please e-mail any final comments about this proposal to ncc-services-wg at ripe.net before 14 November 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From sergey at devnull.ru Wed Oct 16 10:07:20 2013 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 16 Oct 2013 11:07:20 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> Message-ID: <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> Hi Kurtis, Bijal, as for me, there is no clear consensus. RIPE NCC is going to publish sensitive financial-related information, which can affect members' business processes. This information is not a contact data for abuse contacts. Probably the other way for approval such publication is a voting of NCC members at the GM. -- Sergey On Oct 16, 2013, at 10:04 AM, Lindqvist Kurt Erik wrote: > > > All, > > following the discussions regarding policy proposal 2012-08 in the NCC-Services WG the chairs have decided a consensus for moving forward exists and thus the proposal is moved to Last Call. > > > Kurtis & Bijal > NCC Services WG chairs > > From kurtis at kurtis.pp.se Wed Oct 16 10:43:50 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Wed, 16 Oct 2013 10:43:50 +0200 Subject: [ncc-services-wg] 2013-04 Resource Certification for non-RIPE NCC Members has concluded Message-ID: <44DCBF22-3C2C-4DC7-9097-13C2A4F4B9F7@kurtis.pp.se> The policy proposal 2013-04 has concluded and the WG Chairs collective have declared that the PDP process has been followed. Announcement to follow from the RIPE NCC. Kurtis & Bijal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kurtis at kurtis.pp.se Wed Oct 16 10:46:20 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Wed, 16 Oct 2013 10:46:20 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> Message-ID: Sergey, On 16 okt 2013, at 10:07, Sergey Myasoedov wrote: > as for me, there is no clear consensus. you can appeal this decision if you believe we have acted in error. However, I would like to point out that consensus does not mean universal agreement, and I still believe there is a consensus for this proposal in the WG. > RIPE NCC is going to publish sensitive financial-related information, which can affect members' business processes. This information is not a contact data for abuse contacts. Probably the other way for approval such publication is a voting of NCC members at the GM. That's a question for the RIPE NCC GM. Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Wed Oct 16 10:52:28 2013 From: randy at psg.com (Randy Bush) Date: Wed, 16 Oct 2013 11:52:28 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> Message-ID: Sergey Myasoedov , >> as for me, there is no clear consensus. Kurtis: > you can appeal this decision if you believe we have acted in error. > However, I would like to point out that consensus does not mean > universal agreement, and I still believe there is a consensus for this > proposal in the WG. perhaps sergey would find draft-resnick-on-consensus-05.txt helpful consensus != unanimity randy From kurtis at kurtis.pp.se Wed Oct 16 10:55:46 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Wed, 16 Oct 2013 10:55:46 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> Message-ID: <734DDB47-3851-4E52-BAB3-560C993C43EB@kurtis.pp.se> On 16 okt 2013, at 10:52, Randy Bush wrote: > Sergey Myasoedov , >>> as for me, there is no clear consensus. > > Kurtis: >> you can appeal this decision if you believe we have acted in error. >> However, I would like to point out that consensus does not mean >> universal agreement, and I still believe there is a consensus for this >> proposal in the WG. > > perhaps sergey would find draft-resnick-on-consensus-05.txt helpful > > consensus != unanimity Thanks, this can be found at http://tools.ietf.org/html/draft-resnick-on-consensus-05 for reference. Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kaa at net-art.cz Wed Oct 16 11:01:29 2013 From: kaa at net-art.cz (Sergey Myasoedov) Date: Wed, 16 Oct 2013 12:01:29 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> Message-ID: <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> Randy, you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. Kurtis, Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda). -- Sergey On Oct 16, 2013, at 11:52 AM, Randy Bush wrote: > Sergey Myasoedov , >>> as for me, there is no clear consensus. > > Kurtis: >> you can appeal this decision if you believe we have acted in error. >> However, I would like to point out that consensus does not mean >> universal agreement, and I still believe there is a consensus for this >> proposal in the WG. > > perhaps sergey would find draft-resnick-on-consensus-05.txt helpful > > consensus != unanimity > > randy > From danny at danysek.cz Wed Oct 16 11:34:12 2013 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 16 Oct 2013 11:34:12 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> Message-ID: <525E5D94.4070905@danysek.cz> IP address space is a technical ressource in general. Difference between PI and PA is just administrative, assigned IP address will always work independently on it's status. For PA address space, financial-related informations ale published already (should be, by policy), there's no real reason to hide similar informations for PI address space. By publishing sponsoring LIR, only existence of relationship between LIR and End-User is visible. It's not about detailed contract content (financial aspects). Members of RIPE also should be able to verify, if ripe-452 policy is implemented properly by RIPE NCC. Publication of sponsoring LIR provides this option. There should not be some "dark" IP spaces, where we'll not able to found responsible LIR. Policies aren't developed on GM. There's no reason to postpone this until GM. This proposal brings more transparency and it was discussed properly within WG. With regards, Daniel On 10/16/2013 11:01 AM, Sergey Myasoedov wrote: > Randy, > you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. > > Kurtis, > Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda). > > > -- > Sergey > > > On Oct 16, 2013, at 11:52 AM, Randy Bush wrote: > >> Sergey Myasoedov , >>>> as for me, there is no clear consensus. >> >> Kurtis: >>> you can appeal this decision if you believe we have acted in error. >>> However, I would like to point out that consensus does not mean >>> universal agreement, and I still believe there is a consensus for this >>> proposal in the WG. >> >> perhaps sergey would find draft-resnick-on-consensus-05.txt helpful >> >> consensus != unanimity >> >> randy >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4240 bytes Desc: S/MIME Cryptographic Signature URL: From sergey at devnull.ru Wed Oct 16 12:34:30 2013 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 16 Oct 2013 13:34:30 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <525E5D94.4070905@danysek.cz> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> Message-ID: Daniel, exactly, all this administrativia is in our mind. PI objects have no privileges in comparing with PA, nothing is hidden. We don't need to know who is collecting the payments for LIR sponsoring. As well as we don't need to know who exactly signed the contract or what is a birthdate of PI owner's CEO. RIPE-452 condition check is performing by the RIPE NCC and I am satisfied with this. The good thing is that NCC decided on obligatory publication of PI holder name. That is enough, I believe. 2007-01 is not yet completely implemented, there are some PIs without the sponsoring LIR remains. Let the NCC work on this. -- Sergey On Oct 16, 2013, at 12:34 PM, Daniel Suchy wrote: > IP address space is a technical ressource in general. Difference between > PI and PA is just administrative, assigned IP address will always work > independently on it's status. > > For PA address space, financial-related informations ale published > already (should be, by policy), there's no real reason to hide similar > informations for PI address space. By publishing sponsoring LIR, only > existence of relationship between LIR and End-User is visible. It's not > about detailed contract content (financial aspects). > > Members of RIPE also should be able to verify, if ripe-452 policy is > implemented properly by RIPE NCC. Publication of sponsoring LIR provides > this option. There should not be some "dark" IP spaces, where we'll not > able to found responsible LIR. > > Policies aren't developed on GM. There's no reason to postpone this > until GM. This proposal brings more transparency and it was discussed > properly within WG. > > With regards, > Daniel > > On 10/16/2013 11:01 AM, Sergey Myasoedov wrote: >> Randy, >> you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. >> >> Kurtis, >> Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda). >> >> >> -- >> Sergey >> >> >> On Oct 16, 2013, at 11:52 AM, Randy Bush wrote: >> >>> Sergey Myasoedov , >>>>> as for me, there is no clear consensus. >>> >>> Kurtis: >>>> you can appeal this decision if you believe we have acted in error. >>>> However, I would like to point out that consensus does not mean >>>> universal agreement, and I still believe there is a consensus for this >>>> proposal in the WG. >>> >>> perhaps sergey would find draft-resnick-on-consensus-05.txt helpful >>> >>> consensus != unanimity >>> >>> randy >>> >> >> > From danny at danysek.cz Wed Oct 16 13:51:21 2013 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 16 Oct 2013 13:51:21 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> Message-ID: <525E7DB9.1000802@danysek.cz> Hello, On 10/16/2013 12:34 PM, Sergey Myasoedov wrote: > exactly, all this administrativia is in our mind. PI objects have no privileges in comparing with PA, nothing is hidden. We don't need to know who is collecting the payments for LIR sponsoring. As well as we don't need to know who exactly signed the contract or what is a birthdate of PI owner's CEO. For PA space, I'm able to locate LIR responsible for each particular assignment almost without exception. I just like similar option for PI addresses. This information is hidden. PI address space wasn't designed for this kind of "privacy". Why should be there any difference between end-user of PA and end-user of PI address in terms of responsible LIR publication? You didn't provided clear ansver for that. For PA end-users, contract is always clear "who is collecting the payments" (and this is majority of addresses managed by RIPE). And still, in ripe-592, PI existence is still declared mainly for *multihoming* purposes - just for technical reasons. PI existence was *never* declared for privacy you're requesting. If some LIRs assigned PI just because there're less informations traceable (and it seems you did), that was wrong understanding of PI space. That's my oppinion. > RIPE-452 condition check is performing by the RIPE NCC and I am satisfied with this. The good thing is that NCC decided on obligatory publication of PI holder name. That is enough, I believe. > > 2007-01 is not yet completely implemented, there are some PIs without the sponsoring LIR remains. Let the NCC work on this. That's no reason for hiding this information for PI space, where this information is available. As mentioned above. I then can ask RIPE NCC, why on particular PI IP isn't this information available. But I don't have to contact RIPE NCC in case of any problem with PI end-user, if I have such information available - I can simply contact LIR directly, in case of direct End User contact failure. It's normal RIR-LIR-EndUser hiearchy. It works for PA for years, and there's no reason not to have similar hiearchy publicly reachable for PI. With regards, Daniel > > -- > Sergey > > On Oct 16, 2013, at 12:34 PM, Daniel Suchy wrote: > >> IP address space is a technical ressource in general. Difference between >> PI and PA is just administrative, assigned IP address will always work >> independently on it's status. >> >> For PA address space, financial-related informations ale published >> already (should be, by policy), there's no real reason to hide similar >> informations for PI address space. By publishing sponsoring LIR, only >> existence of relationship between LIR and End-User is visible. It's not >> about detailed contract content (financial aspects). >> >> Members of RIPE also should be able to verify, if ripe-452 policy is >> implemented properly by RIPE NCC. Publication of sponsoring LIR provides >> this option. There should not be some "dark" IP spaces, where we'll not >> able to found responsible LIR. >> >> Policies aren't developed on GM. There's no reason to postpone this >> until GM. This proposal brings more transparency and it was discussed >> properly within WG. >> >> With regards, >> Daniel >> >> On 10/16/2013 11:01 AM, Sergey Myasoedov wrote: >>> Randy, >>> you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. >>> >>> Kurtis, >>> Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda). >>> >>> >>> -- >>> Sergey >>> >>> >>> On Oct 16, 2013, at 11:52 AM, Randy Bush wrote: >>> >>>> Sergey Myasoedov , >>>>>> as for me, there is no clear consensus. >>>> >>>> Kurtis: >>>>> you can appeal this decision if you believe we have acted in error. >>>>> However, I would like to point out that consensus does not mean >>>>> universal agreement, and I still believe there is a consensus for this >>>>> proposal in the WG. >>>> >>>> perhaps sergey would find draft-resnick-on-consensus-05.txt helpful >>>> >>>> consensus != unanimity >>>> >>>> randy >>>> >>> >>> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4240 bytes Desc: S/MIME Cryptographic Signature URL: From sergey at devnull.ru Wed Oct 16 14:10:52 2013 From: sergey at devnull.ru (Sergey Myasoedov) Date: Wed, 16 Oct 2013 15:10:52 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <525E7DB9.1000802@danysek.cz> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> Message-ID: Daniel, thank you for the discussion. > For PA space, I'm able to locate LIR responsible for each particular > assignment almost without exception. I just like similar option for PI > addresses. This information is hidden. Sponsoring LIR is not responsible for the PI assignment at all, so we should not talk about 'similar option'. The goal of sponsoring is to provide to customer (PI owner) with a RIPE-452-compliant contract. There is often no connectivity service provided. Even more, sponsoring LIR normally is not controlling the database objects related to PI. > PI address space wasn't designed for this kind of "privacy". Why should > be there any difference between end-user of PA and end-user of PI > address in terms of responsible LIR publication? You didn't provided > clear ansver for that. I am not talking about privacy. The requirement of transparency is present in RIPE-452: ? A clear statement that the resources will return by default to the RIPE NCC if The resource holder cannot be contacted So in case when PI holder does not wish to answer to your mails, you can not do anything, and even if you know that nl.example is in contractual relationship with the 'PI Owner Ltd' - you still can not require the answer from the PI holder. > I then can ask RIPE NCC, why on particular PI IP isn't this information > available. But I don't have to contact RIPE NCC in case of any problem > with PI end-user, if I have such information available - I can simply > contact LIR directly, in case of direct End User contact failure. It's > normal RIR-LIR-EndUser hiearchy. It works for PA for years, and there's > no reason not to have similar hiearchy publicly reachable for PI. As 2012-08 does not have an obligation for sponsoring LIR to be a mail-broker between the whole world and PI holders - this proposal seems useless and harmful to me. -- Sergey On Oct 16, 2013, at 2:51 PM, Daniel Suchy wrote: > Hello, > > On 10/16/2013 12:34 PM, Sergey Myasoedov wrote: >> exactly, all this administrativia is in our mind. PI objects have no privileges in comparing with PA, nothing is hidden. We don't need to know who is collecting the payments for LIR sponsoring. As well as we don't need to know who exactly signed the contract or what is a birthdate of PI owner's CEO. > For PA space, I'm able to locate LIR responsible for each particular > assignment almost without exception. I just like similar option for PI > addresses. This information is hidden. > > PI address space wasn't designed for this kind of "privacy". Why should > be there any difference between end-user of PA and end-user of PI > address in terms of responsible LIR publication? You didn't provided > clear ansver for that. > > For PA end-users, contract is always clear "who is collecting the > payments" (and this is majority of addresses managed by RIPE). And > still, in ripe-592, PI existence is still declared mainly for > *multihoming* purposes - just for technical reasons. PI existence was > *never* declared for privacy you're requesting. If some LIRs assigned PI > just because there're less informations traceable (and it seems you > did), that was wrong understanding of PI space. That's my oppinion. > >> RIPE-452 condition check is performing by the RIPE NCC and I am satisfied with this. The good thing is that NCC decided on obligatory publication of PI holder name. That is enough, I believe. >> >> 2007-01 is not yet completely implemented, there are some PIs without the sponsoring LIR remains. Let the NCC work on this. > That's no reason for hiding this information for PI space, where this > information is available. As mentioned above. > > I then can ask RIPE NCC, why on particular PI IP isn't this information > available. But I don't have to contact RIPE NCC in case of any problem > with PI end-user, if I have such information available - I can simply > contact LIR directly, in case of direct End User contact failure. It's > normal RIR-LIR-EndUser hiearchy. It works for PA for years, and there's > no reason not to have similar hiearchy publicly reachable for PI. > > With regards, > Daniel > >> >> -- >> Sergey >> >> On Oct 16, 2013, at 12:34 PM, Daniel Suchy wrote: >> >>> IP address space is a technical ressource in general. Difference between >>> PI and PA is just administrative, assigned IP address will always work >>> independently on it's status. >>> >>> For PA address space, financial-related informations ale published >>> already (should be, by policy), there's no real reason to hide similar >>> informations for PI address space. By publishing sponsoring LIR, only >>> existence of relationship between LIR and End-User is visible. It's not >>> about detailed contract content (financial aspects). >>> >>> Members of RIPE also should be able to verify, if ripe-452 policy is >>> implemented properly by RIPE NCC. Publication of sponsoring LIR provides >>> this option. There should not be some "dark" IP spaces, where we'll not >>> able to found responsible LIR. >>> >>> Policies aren't developed on GM. There's no reason to postpone this >>> until GM. This proposal brings more transparency and it was discussed >>> properly within WG. >>> >>> With regards, >>> Daniel >>> >>> On 10/16/2013 11:01 AM, Sergey Myasoedov wrote: >>>> Randy, >>>> you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. >>>> >>>> Kurtis, >>>> Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda). >>>> >>>> >>>> -- >>>> Sergey >>>> >>>> >>>> On Oct 16, 2013, at 11:52 AM, Randy Bush wrote: >>>> >>>>> Sergey Myasoedov , >>>>>>> as for me, there is no clear consensus. >>>>> >>>>> Kurtis: >>>>>> you can appeal this decision if you believe we have acted in error. >>>>>> However, I would like to point out that consensus does not mean >>>>>> universal agreement, and I still believe there is a consensus for this >>>>>> proposal in the WG. >>>>> >>>>> perhaps sergey would find draft-resnick-on-consensus-05.txt helpful >>>>> >>>>> consensus != unanimity >>>>> >>>>> randy >>>>> >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 16 14:15:24 2013 From: gert at space.net (Gert Doering) Date: Wed, 16 Oct 2013 14:15:24 +0200 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> Message-ID: <20131016121524.GM65295@Space.Net> Hi, On Wed, Oct 16, 2013 at 03:10:52PM +0300, Sergey Myasoedov wrote: > As 2012-08 does not have an obligation for sponsoring LIR to be a mail-broker between the whole world and PI holders - this proposal seems useless and harmful to me. We have heard your opposition to the proposal, noted it, and the WG chairs have considered it as *addressed* and moved forward to Last Call. The PDP permits that. So unless you have new ground for opposition, repetition of already-considered statements will not make any difference now. Gert Doering -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From mschmidt at ripe.net Wed Oct 16 15:34:40 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 16 Oct 2013 15:34:40 +0200 Subject: [ncc-services-wg] 2013-04 Proposal Accepted (Resource Certification for non-RIPE NCC Members) Message-ID: Dear colleagues, Consensus has been reached, and the proposal described in 2013-04 has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-04/ The new RIPE document is ripe-596 and it is available at: https://www.ripe.net/ripe/docs/ripe-596 An announcement regarding the implementation will follow. Thank you for your input. Regards Marco Schmidt Policy Development Office RIPE NCC From lists-ripe at c4inet.net Wed Oct 16 18:59:57 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 16 Oct 2013 17:59:57 +0100 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <525E7DB9.1000802@danysek.cz> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> Message-ID: <20131016165956.GA33137@cilantro.c4inet.net> On Wed, Oct 16, 2013 at 01:51:21PM +0200, Daniel Suchy wrote: >For PA space, I'm able to locate LIR responsible for each particular >assignment almost without exception. I just like similar option for PI >addresses. This information is hidden. That is exactly the nub of the argument. There IS NO responsibility of a LIR for a PI assignment, this responsibility lies with the resource holder. The only "responsibility" the sponsoring LIR has is to forward information to the NCC, the LIR does not even have the discretion to approve or deny this assignment itself. This proposal tries to establish a responsibility on the part of the sponsoring LIR for the behaviour of the resource holder. The NCC has, cynically, acknowledged this fact by designing an implementation procedure whereby each sponsoring LIR is asked whether they don't want to get rid of inconvenient PI contracts altogether. >PI address space wasn't designed for this kind of "privacy". Why should >be there any difference between end-user of PA and end-user of PI >address in terms of responsible LIR publication? You didn't provided >clear ansver for that. For the fundamental difference between PI and PA, see above. If this difference is not wanted, please support 2013-06. I have one more thing to say to the RIPE community: The outcome of the "PDP" seems to have, lately, mostly depended on *who* floated a proposal, *who* objected and *who* yelled the loudest. Not even to mention ad hominem attacks from "terrorist" to "crazy". If you keep insisting on making this PDP a vehicle for giving the ideas of a small clique a veneer of legitimacy, the internet community *will route around you*. The RIR system will become irrelevant. That's all folks, Sascha Luck PS: I'm still opposed to this proposal, in case it wasn't clear enough. Not that it matters. From sander at steffann.nl Thu Oct 17 09:27:06 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 17 Oct 2013 10:27:06 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <20131016165956.GA33137@cilantro.c4inet.net> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> <20131016165956.GA33137@cilantro.c4inet.net> Message-ID: <3929207B-643D-484D-8B68-E3C2C8330B5B@steffann.nl> Hi Sasha, A small correction: > That is exactly the nub of the argument. There IS NO responsibility of a LIR for a PI assignment, this responsibility lies with the resource holder. The policy (RIPE-452) says: "Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date". So the LIR does have a responsibility. > I have one more thing to say to the RIPE community: The outcome of the "PDP" seems to have, lately, mostly depended on *who* floated a proposal, *who* objected and *who* yelled the loudest. I am sorry that you feel like this, but I can assure you that the collective of working group chairs watches each other carefully to make sure that all policy development is done correctly. If a working group chair declares consensus when the working group is not unanimously supporting a policy proposal then that basis for that decision is carefully evaluated. And there is always the option to appeal a decision made by a working group chair. The chairs are volunteers working for their working group community after all. > If you keep insisting on making this PDP a vehicle for giving the ideas of a small clique a veneer of legitimacy, the internet community *will route around you*. One of the chair's responsibilities is to make sure that policy development is based on consensus. Objections to a policy must be handled in some way. Finding a better policy text that removes those objections and is also supported by the rest of the working group is preferred, but support for a policy does not have to be unanimous. Sometimes it is not possible to make everybody happy. The chairs then weigh all options and try to find the best outcome for the whole community. I can assure you that this is *difficult* but we (the WG chairs collective as a whole) do our best. Cheers, Sander From lists-ripe at c4inet.net Thu Oct 17 12:26:41 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 17 Oct 2013 11:26:41 +0100 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <3929207B-643D-484D-8B68-E3C2C8330B5B@steffann.nl> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> <20131016165956.GA33137@cilantro.c4inet.net> <3929207B-643D-484D-8B68-E3C2C8330B5B@steffann.nl> Message-ID: <20131017102641.GA35997@cilantro.c4inet.net> Hi Sander, On Thu, Oct 17, 2013 at 10:27:06AM +0300, Sander Steffann wrote: > >The policy (RIPE-452) says: "Notice that the LIR is responsible for >liaising with the resource holder to keep registration records >up-to-date". So the LIR does have a responsibility. I know, what I meant was "responsibility to police behaviour of the resource holder" Sorry for not being clearer. >chair declares consensus when the working group is not unanimously >supporting a policy proposal then that basis for that decision is >carefully evaluated. And there is always the option to appeal a >decision made by a working group chair. The chairs are volunteers >working for their working group community after all. Sure, but this proposal fundamentally changes the relationship between a sponsoring LIR and a resource holder in the guise of "just adding another field to the inet[6]num object". I feel that such change deserves a better argumentation and defence than just some hand-wavy "oh, BUT MORE TRANSPARENCY!!1!" ideological rhetoric. I find it interesting how, with some proposals, every hair is split three ways, every minor wording change endlessly debated and with others any objection is swept off the table because "doesn't matter, it's more transparent". A couple things that would make the PDP more palatable: - would it be too much of an extra burden on the WG-chairs to summarise, briefly, how they arrived at the decision that consensus has been achieved/not achieved? (much like a judge would substantiate how they arrived at a given verdict but maybe not quite so verbose) - stop the +1 BS. Every voice in support *or* against a proposal to, at least, give a brief reasoning why. I consider it disrespectful if one spends much time composing and arguing an objection if it can be overridden by "+1". It's changing the way Internet resources are being managed, not godsdamn Facebook. rgds, Sascha Luck From sander at steffann.nl Thu Oct 17 13:20:59 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 17 Oct 2013 14:20:59 +0300 Subject: [ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call In-Reply-To: <20131017102641.GA35997@cilantro.c4inet.net> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> <20131016165956.GA33137@cilantro.c4inet.net> <3929207B-643D-484D-8B68-E3C2C8330B5B@steffann.nl> <20131017102641.GA35997@cilantro.c4inet.net> Message-ID: <001AD2DD-6777-4D54-9933-AC2156BAFDB9@steffann.nl> Hi Sasha, > A couple things that would make the PDP more palatable: > > - would it be too much of an extra burden on the WG-chairs to summarise, briefly, how they arrived at the decision that consensus has been achieved/not achieved? (much like a judge would substantiate how they arrived at a given verdict but maybe not quite so verbose) We do try to do that, but I agree: this this is very important! > - stop the +1 BS. Every voice in support *or* against a proposal to, at least, give a brief reasoning why. I disagree with you here. A policy proposal is made for a reason, and that reason is included in the proposal itself. A +1 is expressing support for the proposal for the reasons specified in that policy. > I consider it disrespectful if one spends much time composing and arguing an objection if it can be overridden by "+1". It is important for the chairs to see the difference between people who don't care about a policy proposal and people who stay silent because they agree with the content. Seeing +1 messages helps here. For example: a proposal with no feedback on the mailing list at all will likely be dropped/withdrawn, but a proposal with +1 replies will likely not be dropped/withdrawn. An objection will always be discussed based on its supporting arguments, and only if the objection can't be resolved will the chairs consider any +1's: we cannot abandon a policy proposal because one person (or a few) have a non-resolvable objection that is not shared by rest of the community. Nobody has veto rights. > It's changing the way Internet resources are being managed, not godsdamn Facebook. I know. Sander From kurtis at kurtis.pp.se Thu Oct 17 13:56:31 2013 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Thu, 17 Oct 2013 13:56:31 +0200 Subject: [ncc-services-wg] How to determine consensus for a proposal. In-Reply-To: <20131017102641.GA35997@cilantro.c4inet.net> References: <942BC351-C5AE-48FD-A7CE-3A0829BDDB16@kurtis.pp.se> <03F185FA-1F2E-41D7-982D-7119B543EC98@devnull.ru> <2A8E8D66-8D36-4354-88BF-8C0CF87571A3@net-art.cz> <525E5D94.4070905@danysek.cz> <525E7DB9.1000802@danysek.cz> <20131016165956.GA33137@cilantro.c4inet.net> <3929207B-643D-484D-8B68-E3C2C8330B5B@steffann.nl> <20131017102641.GA35997@cilantro.c4inet.net> Message-ID: <32D4B62F-98CC-405A-9BD3-BA3227A93411@kurtis.pp.se> Sascha, As this is now a generic thread and have nothing to do with 2012-08 I have changed the topic. On 17 okt 2013, at 12:26, Sascha Luck wrote: >> chair declares consensus when the working group is not unanimously >> supporting a policy proposal then that basis for that decision is >> carefully evaluated. And there is always the option to appeal a >> decision made by a working group chair. The chairs are volunteers >> working for their working group community after all. > > Sure, but this proposal fundamentally changes the relationship between a sponsoring LIR and a resource holder in the guise of "just adding another field to the inet[6]num object". I feel that such change deserves a better argumentation and defence than just some hand-wavy "oh, BUT MORE TRANSPARENCY!!1!" ideological rhetoric. > I find it interesting how, with some proposals, every hair is split > three ways, every minor wording change endlessly debated and with others any objection is swept off the table because "doesn't matter, > it's more transparent". Hoe much discussion and how detail a proposal receives is up to the members of the working group and not the chairs. I can't substantiate this but my impression is that the detailed level of discussion has more to do with how complex a proposal is than anything else. > A couple things that would make the PDP more palatable: > > - would it be too much of an extra burden on the WG-chairs to summarise, briefly, how they arrived at the decision that consensus > has been achieved/not achieved? (much like a judge would substantiate > how they arrived at a given verdict but maybe not quite so verbose) I think writing a "verdict" might be hard. Consensus is when, as described in draft-resnick-on-consensus, all issues as been addressed but not accommodated. I can only speak for this working group, but we at least go through the archives to make sure this is the case, and we then look at how people have argued and if in favor or against. This is not voting, but determining that there is wide support, and that all issues have been addressed. In this particular proposal I believe it would have passed if using majority voting, consensus etc. But it wasn't unanimous. If the WG-chairs where to have to distill all concerns raised against a proposal, how they where addressed and if they where accommodated, yes that would be a lot of work. Again, the WG chairs decisions are being screened by the other WG chairs, and there is an appeals procedure. > - stop the +1 BS. Every voice in support *or* against a proposal to, at > least, give a brief reasoning why. I consider it disrespectful if one > spends much time composing and arguing an objection if it can be > overridden by "+1". It's changing the way Internet resources are being > managed, not godsdamn Facebook. I at least interpret the +1 (or -1 or don't support comments) as the view of someone who has read a proposal and either believes it adds value or makes a policy "better", or not. I don't see how that would need to be elaborated more, and in most cases it probably even wouldn't. But if you could give more examples perhaps that would help. Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jarle at uninett.no Fri Oct 18 07:57:24 2013 From: jarle at uninett.no (Jarle Greipsland) Date: Fri, 18 Oct 2013 07:57:24 +0200 (CEST) Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131010141013.3BF69336340@epost.uninett.no> References: <20131010141013.3BF69336340@epost.uninett.no> Message-ID: <20131018.075724.532479318.jarle@uninett.no> "Marco Schmidt" writes: > You can find the full proposal and impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2012-07 > > And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > We encourage you to read the draft document text and send any > comments to ncc-services-wg at ripe.net before 8 November 2013. I think this a sound policy proposal, and I support its adaption as RIPE policy. -jarle -- Of course there's no reason for it, it's just our policy. From rhe at nosc.ja.net Mon Oct 21 14:15:35 2013 From: rhe at nosc.ja.net (Rob Evans) Date: Mon, 21 Oct 2013 13:15:35 +0100 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) Message-ID: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Hi, > We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. I (personally, of course) support this proposal. In the interests of discussion, though, I'll note that my interpretation of 'Registry Service Elements' in section 1.1 was any single service provided by the RIR, either current or future. However, in the impact analysis the RIPE NCC has interpreted it as only any one of the specific existing services mentioned in 1.1. Does that match with the authors' intention? (If not, does it matter?) Not knowing how the RIPE NCC performs checks on the holder of legacy resources, the onus appears to be on the holder to submit appropriate documentation. Is it safe to assume that the NCC also has a record of relevant InterNIC records to match who the resources were originally assigned to, and so if the holder hasn't changed then the documentation could be along the lines of just checking the organisations match? I'll also note that we had a brief discussion in last week's routing working group session relevant to the part of section 'D' of the impact analysis relating to adding an attribute to the aut-num object. Most of the comments tended to suggest that as long as the RFC says unknown attributes should be ignored, then there should be little problem. However, sufficient notice will need to be given so that tools that work off local copies of the aut-num will submit it with the relevant fields (or given that it isn't something the holder can change, the update software can add the correct line in if it is missing in an update). Cheers, Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From niall.oreilly at ucd.ie Mon Oct 21 16:08:31 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 21 Oct 2013 15:08:31 +0100 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Oct 2013, at 13:15, Rob Evans wrote: > I (personally, of course) support this proposal. Thanks, Rob. > In the interests of discussion, though, I'll note that my interpretation of 'Registry Service Elements' > in section 1.1 was any single service provided by the RIR, either current or future. However, in the > impact analysis the RIPE NCC has interpreted it as only any one of the specific existing services > mentioned in 1.1. Does that match with the authors' intention? (If not, does it matter?) Thanks for asking for clarification. Perhaps because I've been "on the inside" of the process, both as an author and in working out differences of understanding between the authors and the RIPE NCC, I'm not seeing the discrepancy that you describe. I'm glad of the opportunity to explain my interpretation. If this is not consistent with your reading of the texts or if, although convinced, you feel that another reasonable reader might not be, I'll appreciate it if you will make this clear. As the authors intend, "Registry Services" refers to a bundle of services which are to be offered to every legacy resource holder whose relationship with the RIPE NCC is covered by any of sub-sections 2.1 .. 2.5 in section 2. The specification is open-ended so that the bundle may be extended by including one or more additional services from time to time. In the impact analysis, the RIPE NCC proposes a process for doing this. As I see it, this process is consistent with the intent of the proposal. I notice, and didn't before, that in the impact analysis, the NCC uses "Registration Services" instead of "Registry Services". The authors have made a distinction between "Registry Services" as a bundle and the particular set of individual "Registry Service Elements" already provided by the RIPE NCC for any given legacy resource prior to establishing a relationship under which the full bundle could be offered. The set involved may (in principle) vary between one legacy resource and another. In practice, it is unlikely to include only a single service, and also unlikely to include certification. The idea is that any legacy resource holder who wishes to have the full bundle of Registry Services should enter into a relationship with the RIPE NCC, while one to whom certain Registry Service Elements are already provided is protected against withdrawal of those specific service elements but cannot claim to be entitled to others. I hope this helps. Best regards, Niall -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAlJlNWAACgkQeYfkja6ZXtnZgACgitekmgt63fPpE3iezwbtTnBU GJcAmwc1eu0ERKITbbPpNmdHZAS71LGR =DMR/ -----END PGP SIGNATURE----- From Woeber at CC.UniVie.ac.at Mon Oct 21 16:12:42 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 21 Oct 2013 16:12:42 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: Message-ID: <5265365A.4030701@CC.UniVie.ac.at> Marco Schmidt wrote: > Dear colleagues, > > The draft document for version 4.0 of the policy proposal 2012-07, > "RIPE NCC Services to Legacy Internet Resource Holders" has now been > published, along with an impact analysis conducted by the RIPE NCC. While working through the Impact Analysis I am somewhat at a loss how Option 1 and Option 3 are to be handled. In particular, going for Option 1: would the Legacy Resource lose its status: LEGACY and be relabelled to PI or PA? If this is the case, I do not see the rationale for the text in Option 3: In the latter case, however, it should be made clear that the RIPE NCC will not allow the Legacy Resource Holder to become the sponsoring LIR for its own Legacy Internet Resources. In case the status: LEGACY for Option 1 is preserved, then I can agree to the restriction as quoted. Any clarification would be appreciated. Thanks, Wilfried From Woeber at CC.UniVie.ac.at Mon Oct 21 16:40:11 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 21 Oct 2013 16:40:11 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: <52653CCB.5080408@CC.UniVie.ac.at> Rob Evans wrote: > Hi, [...] > I (personally, of course) support this proposal. So do I, in general, with the 2 caveats: - it is not clear, how the NCC will handle "really old" bits and pieces, for which back then there was no concept of "documentation" yet, other than receiving it (over the phone or other comms.channel) and starting to use it as intended. Being too strict in this case may actually defeat the goal of getting as much as possible of that stuff under a contractual umbrella. and 2ndly - given the other proposal to extend Certification to PI resources, I wonder whether we need a separate/different approch for LEGACY, and why the option of GM was not included in the IA, Section "Resource Certification", like in other items? Any comments? Wilfried. From tim at haitabu.net Mon Oct 21 17:37:39 2013 From: tim at haitabu.net (Tim Kleefass) Date: Mon, 21 Oct 2013 17:37:39 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131018.075724.532479318.jarle@uninett.no> References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> Message-ID: <52654A43.1020400@haitabu.net> On 18.10.2013 7:57 AM, Jarle Greipsland wrote: > "Marco Schmidt" writes: >> You can find the full proposal and impact analysis at: >> https://www.ripe.net/ripe/policies/proposals/2012-07 >> >> And the draft document at: >> https://www.ripe.net/ripe/policies/proposals/2012-07/draft > >> We encourage you to read the draft document text and send any >> comments to ncc-services-wg at ripe.net before 8 November 2013. > I think this a sound policy proposal, and I support its adaption > as RIPE policy. +1 -tim From randy at psg.com Mon Oct 21 19:08:10 2013 From: randy at psg.com (Randy Bush) Date: Mon, 21 Oct 2013 19:08:10 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <52654A43.1020400@haitabu.net> References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> <52654A43.1020400@haitabu.net> Message-ID: > I think this a sound policy proposal, and I support its adaption > as RIPE policy. similarly, i have read it in all its iterations and support it as sound policy. rady From mansaxel at besserwisser.org Tue Oct 22 00:10:31 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 22 Oct 2013 00:10:31 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> <52654A43.1020400@haitabu.net> Message-ID: <20131021221031.GK2783@besserwisser.org> Subject: Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) Date: Mon, Oct 21, 2013 at 07:08:10PM +0200 Quoting Randy Bush (randy at psg.com): > > I think this a sound policy proposal, and I support its adaption > > as RIPE policy. > > similarly, i have read it in all its iterations and support it as sound > policy. While I can't claim that I've been as thorough as Randy, I'd like to chime in here. I've read the text and support it. Regards, -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We just joined the civil hair patrol! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From m.hallgren at free.fr Tue Oct 22 00:22:08 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 22 Oct 2013 00:22:08 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131021221031.GK2783@besserwisser.org> References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> <52654A43.1020400@haitabu.net> <20131021221031.GK2783@besserwisser.org> Message-ID: <5265A910.6010901@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 22/10/2013 00:10, M?ns Nilsson a ?crit : With a similar claim, added, so do I. ;-) Cheers, mh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJlqQsACgkQZNZ/rrgsqaftbACfUPXtc2OXAa9Vwz9ocsClBION GS4AoJALoIePQjnJJ9JL1KUHi4E/pPBC =VcvJ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.hallgren at free.fr Tue Oct 22 00:22:08 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 22 Oct 2013 00:22:08 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131021221031.GK2783@besserwisser.org> References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> <52654A43.1020400@haitabu.net> <20131021221031.GK2783@besserwisser.org> Message-ID: <5265A910.1040909@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 22/10/2013 00:10, M?ns Nilsson a ?crit : > Subject: Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) Date: Mon, Oct 21, 2013 at 07:08:10PM +0200 Quoting Randy Bush (randy at psg.com): >>> I think this a sound policy proposal, and I support its adaption >>> as RIPE policy. >> >> similarly, i have read it in all its iterations and support it as sound >> policy. > > While I can't claim that I've been as thorough as Randy, I'd like to > chime in here. I've read the text and support it. With a similar claim, added, so do I. ;-) Cheers, mh > > > Regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJlqRAACgkQZNZ/rrgsqafvLQCfdDExKrAc9SOij/1Qg8DcbVn6 pcAAn26dV5Rh4gj45k79fsTKqSJTOJQL =GD3m -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jac.Kloots at surfnet.nl Tue Oct 22 08:47:48 2013 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Tue, 22 Oct 2013 08:47:48 +0200 (CEST) Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: Hi, On Mon, 21 Oct 2013, Rob Evans wrote: > Hi, > >> We encourage you to read the draft document text and send any comments to >> ncc-services-wg at ripe.net before 8 November 2013. > > I (personally, of course) support this proposal. I'm with Rob. Regards, Jac -- Jac Kloots Network Services SURFnet bv From niall.oreilly at ucd.ie Tue Oct 22 09:53:31 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 22 Oct 2013 08:53:31 +0100 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <5265365A.4030701@CC.UniVie.ac.at> References: <5265365A.4030701@CC.UniVie.ac.at> Message-ID: <4F4D67FF-9C0F-4935-A1AD-102FA09B8698@ucd.ie> On 21 Oct 2013, at 15:12, Wilfried Woeber wrote: > While working through the Impact Analysis I am somewhat at a loss how > Option 1 and Option 3 are to be handled. > > In particular, going for Option 1: would the Legacy Resource lose its > status: LEGACY and be relabelled to PI or PA? No. > If this is the case, I do not see the rationale for the text in Option 3: > > In the latter case, however, it should be made clear that the RIPE > NCC will not allow the Legacy Resource Holder to become the > sponsoring LIR for its own Legacy Internet Resources. > > In case the status: LEGACY for Option 1 is preserved, then I can agree to > the restriction as quoted. > > Any clarification would be appreciated. There is an option, under section 1.2 (Scope) for relabelling, but then the resource in question is placed outside the scope of the proposed policy. I hope this helps. Best regards, Niall From alexb at ripe.net Tue Oct 22 10:12:39 2013 From: alexb at ripe.net (Alex Band) Date: Tue, 22 Oct 2013 10:12:39 +0200 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources Message-ID: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> Dear colleagues, In March of this year, the RIPE NCC held a community consultation about the certification of Internet number resources held by non-RIPE NCC members. The discussion that unfolded led to RIPE Policy Proposal 2013-04, "Resource Certification for non-RIPE NCC Members". This proposal reached consensus on 16 October 2013. Now that the Community has decided that certification of non-member resources should be a RIPE NCC service, we would once again like to summarise the three possible implementation options for PI End User resources: 1) A PI End User becomes a RIPE NCC member 2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the Route Origin Access (ROA) management system themselves, or they delegate management to the sponsoring LIR 3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system It became apparent from the discussion that PI End Users fall into two groups: - Those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves - Those who rely on the sponsoring LIR for everything, ranging from BGP routing to RIPE Database updates In order to cater to both groups, the feedback so far suggests we facilitate options 2 and 3, while option 1 will continue to remain available at all times. For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is the possibility to provide an automated solution for which only PI End Users who have submitted a 2007-01 End User Assignment Agreement are eligible. This means the RIPE NCC will need to develop a solution where the following informational elements are cross-referenced with each other: a) The authoritative control over the address space (i.e. the ability to authenticate against the relevant objects in the RIPE Database) b) The End User Assignment Agreement that was submitted and verified by the RIPE NCC c) The RIPE NCC Access credentials for accessing the certification management interface In order to offer insight into the resources required for the implementation, the RIPE NCC has provided a cost estimate. One of the clarifications that was given during the discussion is the fact that there is a lot of overlap in the implementation of option 2 and 3, meaning that building both would not result in a significantly higher cost than offering just one of them. The only aspect that remained a discussion point were the requirements that the RIPE NCC should impose on PI End Users when they would like to request a resource certificate directly from the RIPE NCC (option 3). We would like to ask you to provide further feedback on this topic. The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system? While this discussion is ongoing, we would like to propose to start building the framework to offer this functionality, and deliver option 2 as soon as it is ready. We look forward to your feedback. Kind regards, Alex Band Product Manager RIPE NCC P.S. The RIPE NCC has explained the implementation options and associated cost at the following locations: http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002145.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002149.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002252.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002256.html From Woeber at CC.UniVie.ac.at Tue Oct 22 11:01:47 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 22 Oct 2013 11:01:47 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <4F4D67FF-9C0F-4935-A1AD-102FA09B8698@ucd.ie> References: <5265365A.4030701@CC.UniVie.ac.at> <4F4D67FF-9C0F-4935-A1AD-102FA09B8698@ucd.ie> Message-ID: <52663EFB.50005@CC.UniVie.ac.at> Thanks for the clarification, so I fully support V4 of 2012-07. A big THANKS to everyone who contributed to that important project! Wilfried Niall O'Reilly wrote: > On 21 Oct 2013, at 15:12, Wilfried Woeber wrote: > > >>While working through the Impact Analysis I am somewhat at a loss how >>Option 1 and Option 3 are to be handled. >> >>In particular, going for Option 1: would the Legacy Resource lose its >>status: LEGACY and be relabelled to PI or PA? > > > No. > > >>If this is the case, I do not see the rationale for the text in Option 3: >> >> In the latter case, however, it should be made clear that the RIPE >> NCC will not allow the Legacy Resource Holder to become the >> sponsoring LIR for its own Legacy Internet Resources. >> >>In case the status: LEGACY for Option 1 is preserved, then I can agree to >>the restriction as quoted. >> >>Any clarification would be appreciated. > > > There is an option, under section 1.2 (Scope) for relabelling, > but then the resource in question is placed outside the scope of > the proposed policy. > > I hope this helps. > > Best regards, > Niall > From Jac.Kloots at surfnet.nl Tue Oct 22 11:06:03 2013 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Tue, 22 Oct 2013 11:06:03 +0200 (CEST) Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> Message-ID: Alex, On Tue, 22 Oct 2013, Alex Band wrote: > The issue is: A PI End user must prove to the RIPE NCC that they truly are > the legitimate holder of the resources they would like to have a > certificate for. What proof do they need to give to the RIPE NCC before we > grant them access to the system? Not having followed all of this discussion, but isn't there an effort going on as result of RIPE-452 (http://www.ripe.net/ripe/docs/ripe-452) for having a contractual relationship between PI end-users and the RIPE-NCC. Isn't this contractual relationship the best proof for being the legitimate holder of the PI resource? Jac -- Jac Kloots Network Services SURFnet bv From schmid at dfn.de Tue Oct 22 13:39:22 2013 From: schmid at dfn.de (Thomas Schmid) Date: Tue, 22 Oct 2013 13:39:22 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: <526663EA.2010204@dfn.de> Hi all, On 22.10.2013 08:47, Jac Kloots wrote: > > Hi, > > On Mon, 21 Oct 2013, Rob Evans wrote: > >> Hi, >> >>> We encourage you to read the draft document text and send any >>> comments to ncc-services-wg at ripe.net before 8 November 2013. >> >> I (personally, of course) support this proposal. > > I'm with Rob. > me too. Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4589 bytes Desc: S/MIME Cryptographic Signature URL: From alexb at ripe.net Tue Oct 22 13:55:18 2013 From: alexb at ripe.net (Alex Band) Date: Tue, 22 Oct 2013 13:55:18 +0200 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> Message-ID: <57C322CA-EFB8-4C81-8070-154F10FC8BD5@ripe.net> On 22 Oct 2013, at 11:06, Jac Kloots wrote: > > Alex, > > On Tue, 22 Oct 2013, Alex Band wrote: > >> The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system? > > Not having followed all of this discussion, but isn't there an effort going on as result of RIPE-452 (http://www.ripe.net/ripe/docs/ripe-452) for having a contractual relationship between PI end-users and the RIPE-NCC. > > Isn't this contractual relationship the best proof for being the legitimate holder of the PI resource? Allow me to illustrate this using an example scenario, where a PI End User wants a certificate without going through their sponsoring LIR: 1: The PI End User logs in with their RIPE NCC Access account on ripe.net (after creating one) 2: They go to a webpage with a form where they enter the prefix(es) they would like a resource certificate for 3: The background system checks if these prefixes: a) are PI End User resources b) have the status "End User Documents Approved", meaning that a RIPE-452 contract was submitted and verified 4: The PI End User must enter the RIPE Database MNTNER password/key(s) for the inetnum objects of the resources, to prove they have authoritative control over them 5: If this is successful, the RIPE NCC Access credentials, resources and ROA management interface are associated with each other, allowing them to use the system It is up to the Community and membership to decide if this would be an acceptable workflow or if additional steps or checks would need to be added. You should keep in mind that at all times, the sponsoring LIR is the only point of contact the RIPE NCC has, and according to the signed contract they are held responsible for the resources and PI End User relationship. Cheers, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From stolpe at resilans.se Tue Oct 22 15:36:44 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 22 Oct 2013 15:36:44 +0200 (CEST) Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: On Mon, 21 Oct 2013, Rob Evans wrote: > Hi, > >> We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. > > I (personally, of course) support this proposal. +1 Cheers, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From sid at free.net Tue Oct 22 18:36:55 2013 From: sid at free.net (Dimitri I Sidelnikov) Date: Tue, 22 Oct 2013 20:36:55 +0400 Subject: [ncc-services-wg] policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" Message-ID: <5266A9A7.6080709@free.net> Hi. Let me express my support for policy proposal 2012-07. -- Kind regards, --- D.Sidelnikov From elvis at v4escrow.net Tue Oct 22 20:55:30 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 23 Oct 2013 02:55:30 +0800 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> Message-ID: <5266CA22.5010703@v4escrow.net> Hi, On 10/22/13 9:36 PM, Daniel Stolpe wrote: > > On Mon, 21 Oct 2013, Rob Evans wrote: > >> Hi, >> >>> We encourage you to read the draft document text and send any >>> comments to ncc-services-wg at ripe.net before 8 November 2013. >> >> I (personally, of course) support this proposal. > > +1 I also agree with this proposed policy changed. > > > Cheers, > > Daniel Stolpe > Cheers, elvis -- V4Escrow, LLC From nick at netability.ie Wed Oct 23 11:00:08 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 23 Oct 2013 17:00:08 +0800 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> Message-ID: <52679018.6000907@netability.ie> On 22/10/2013 16:12, Alex Band wrote: > The issue is: A PI End user must prove to the RIPE NCC that they truly > are the legitimate holder of the resources they would like to have a > certificate for. What proof do they need to give to the RIPE NCC before > we grant them access to the system? there's no way of necessarily knowing that the contact info in the ripe database is correct, even if the resources are correctly registered to the legal person described in the organisation object. This means that the RIPE NCC has no real way of knowing if J. Random end user is the correct contact for the PI resource, which means that it needs to devolve the initial stage of this authorisation to the sponsoring LIR. This probably sucks. Nick From gert at space.net Wed Oct 23 11:20:00 2013 From: gert at space.net (Gert Doering) Date: Wed, 23 Oct 2013 11:20:00 +0200 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <52679018.6000907@netability.ie> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> <52679018.6000907@netability.ie> Message-ID: <20131023092000.GI50205@Space.Net> Hi, On Wed, Oct 23, 2013 at 05:00:08PM +0800, Nick Hilliard wrote: > there's no way of necessarily knowing that the contact info in the ripe > database is correct, even if the resources are correctly registered to the > legal person described in the organisation object. This means that the > RIPE NCC has no real way of knowing if J. Random end user is the correct > contact for the PI resource, which means that it needs to devolve the > initial stage of this authorisation to the sponsoring LIR. This probably > sucks. OTOH, for RPKI, do we really need to know *who* the user is? If - as Alex proposes - the system checks "is there an approved contactual relationship for the resource in question, *and* does the user have the necessary credentials to satisfy the mnt-routes: criteria for the object?", the ability to create ROAs would correspond to the ability to create route: objects - and since RPKI isn't certifying identity, but "this person is authorized to authorize routing for the resource", this sounds workable for me. The bit "show me your credentials" is going to be interesting for PGP, but can be done ("show nonce, ask for signature on it, copy back to text field")... 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From herve.clement at orange.com Wed Oct 23 11:18:10 2013 From: herve.clement at orange.com (herve.clement at orange.com) Date: Wed, 23 Oct 2013 11:18:10 +0200 Subject: [ncc-services-wg] RIPE Policy Proposal 2012-07 "RIPE NCC Services to Legacy Internet Resource Holders" Message-ID: <28559_1382519890_52679452_28559_6019_1_0989C1432603124E8E1631FCEBD1ED735CAD911014@PUEXCB1C.nanterre.francetelecom.fr> As this policy proposal brings clarification on management of Legacy Internet Resources, Orange supports its adoption as RIPE policy. Best regards [cid:image001.gif at 01CECFE1.24CB7D70] Herv? CLEMENT Naming, Addressing and Numbering Project Manager Orange/IMT/OLN/AQS/NAN t?l. +33 (0)1 57 36 17 97 mob. +33 (0)6 78 91 39 38 herve.clement at orange.com _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1264 bytes Desc: image001.gif URL: From randy at psg.com Wed Oct 23 11:34:37 2013 From: randy at psg.com (Randy Bush) Date: Wed, 23 Oct 2013 11:34:37 +0200 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <20131023092000.GI50205@Space.Net> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> <52679018.6000907@netability.ie> <20131023092000.GI50205@Space.Net> Message-ID: > OTOH, for RPKI, do we really need to know *who* the user is? well, almost. we need to know that we have the public key corresponding to the private key of the holder of the resource. we do not really need to know _who_ they are in the human/organizational sense any more than to satisfy whatever the ncc's administrative needs are. randy From nick at netability.ie Wed Oct 23 12:41:31 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 23 Oct 2013 18:41:31 +0800 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <57C322CA-EFB8-4C81-8070-154F10FC8BD5@ripe.net> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> <57C322CA-EFB8-4C81-8070-154F10FC8BD5@ripe.net> Message-ID: <5267A7DB.5010109@netability.ie> On 22/10/2013 19:55, Alex Band wrote: > 4: The PI End User must enter the RIPE Database MNTNER password/key(s) for > the inetnum objects of the resources, to prove they have authoritative > control over them you're assuming that the end user maintains their objects. This is not always going to be the case. Nick From frederic.loui at renater.fr Wed Oct 23 12:37:31 2013 From: frederic.loui at renater.fr (=?utf-8?Q?Fr=C3=A9d=C3=A9ric_Loui?=) Date: Wed, 23 Oct 2013 12:37:31 +0200 Subject: [ncc-services-wg] policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" In-Reply-To: <5266A9A7.6080709@free.net> References: <5266A9A7.6080709@free.net> Message-ID: <4F79F5E6-C5D7-4F12-8215-840433CA3809@renater.fr> Hi all, I support this proposal. Bgrds, -- Fr?d?ric LOUI/RENATER From ripe-wgs.cs at schiefner.de Wed Oct 23 12:22:56 2013 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 23 Oct 2013 12:22:56 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: Message-ID: <5267A380.9020802@schiefner.de> Dear colleagues - On 10.10.2013 16:07, Marco Schmidt wrote: > - An amendment to the existing policy document ripe-592 ...which is the following: Replace section 5.5 of ripe-592, currently: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." with "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System." Shall my understanding be that the rationale for replacing "the IANA" by "otherwise through the Regional Internet Registry System" is that the former - implying Legacy Internet Resources - would be in contradiction with the second paragraph: "Any existing or future RIPE policy referring to resources shall not apply to legacy resources unless the policy explicitly includes legacy resources in its scope." of section 1.2 "Scope" of the proposal? If not, what else is the rationale for this side effect on ripe-592 then? Anhow: the proposal gets my support - I'd like to see it becoming policy. Best, -C. From andreas.larsen at ip-only.se Wed Oct 23 14:15:18 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Wed, 23 Oct 2013 14:15:18 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <5266CA22.5010703@v4escrow.net> References: <1566C683-5CDC-4A6D-8F75-A20C58310670@nosc.ja.net> <5266CA22.5010703@v4escrow.net> Message-ID: <8B02FFFB-DE3F-4A62-A982-5D9EF86010D7@ip-only.se> +1 Med v?nlig h?lsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se 22 okt 2013 kl. 20:55 skrev Elvis Daniel Velea >: Hi, On 10/22/13 9:36 PM, Daniel Stolpe wrote: On Mon, 21 Oct 2013, Rob Evans wrote: Hi, We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. I (personally, of course) support this proposal. +1 I also agree with this proposed policy changed. Cheers, Daniel Stolpe Cheers, elvis -- V4Escrow, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexb at ripe.net Wed Oct 23 15:24:22 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 23 Oct 2013 15:24:22 +0200 Subject: [ncc-services-wg] Implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <5267A7DB.5010109@netability.ie> References: <692B8080-EDFE-4D75-8A69-0F98516C6C09@ripe.net> <57C322CA-EFB8-4C81-8070-154F10FC8BD5@ripe.net> <5267A7DB.5010109@netability.ie> Message-ID: On 23 Oct 2013, at 12:41, Nick Hilliard wrote: > On 22/10/2013 19:55, Alex Band wrote: >> 4: The PI End User must enter the RIPE Database MNTNER password/key(s) for >> the inetnum objects of the resources, to prove they have authoritative >> control over them > > you're assuming that the end user maintains their objects. This is not > always going to be the case. I'm not assuming that at all. If the sponsoring LIR manages the RIPE DB objects on behalf of the PI End User, they will be able to authenticate against the inetnum and perform these steps. -Alex From alexb at ripe.net Thu Oct 24 09:44:24 2013 From: alexb at ripe.net (Alex Band) Date: Thu, 24 Oct 2013 09:44:24 +0200 Subject: [ncc-services-wg] IP Analyser for Android Pilot - Proposed Discontinuation Message-ID: Dear colleagues, In 2012, the RIPE NCC introduced the IP Analyser mobile client for Android pilot to gauge interest from the membership. After careful evaluation of the usage, feedback and available resources to maintain or expand this pilot, we propose to discontinue the pilot from 20 November 2013. The IP Analyser for Android was a very lightweight trial to see if members would be interested in having IP Analyser information available on the go. Considering the amount of active installations and queries from mobile clients, it is apparent that spending the available resources on expanding the web interface and API is more valuable. For example, we plan to develop IPv6 functionality in the near future. By removing this service, the RIPE NCC would be in a position to focus its resources on the remaining services that provide the most value to members. If you have any questions or comments, please do not hesitate to contact us. Kind regards, Alex Band Product Manager RIPE NCC From bengan at resilans.se Thu Oct 24 14:13:19 2013 From: bengan at resilans.se (=?ISO-8859-1?Q?Bengt_G=F6rd=E9n?=) Date: Thu, 24 Oct 2013 14:13:19 +0200 Subject: [ncc-services-wg] IP Analyser for Android Pilot - Proposed Discontinuation In-Reply-To: References: Message-ID: <52690EDF.1090905@resilans.se> 2013-10-24 09:44, Alex Band skrev: > Dear colleagues, > > In 2012, the RIPE NCC introduced the IP Analyser mobile client for Android pilot to gauge interest from the membership. After careful evaluation of the usage, feedback and available resources to maintain or expand this pilot, we propose to discontinue the pilot from 20 November 2013. > > The IP Analyser for Android was a very lightweight trial to see if members would be interested in having IP Analyser information available on the go. Considering the amount of active installations and queries from mobile clients, it is apparent that spending the available resources on expanding the web interface and API is more valuable. For example, we plan to develop IPv6 functionality in the near future. > > By removing this service, the RIPE NCC would be in a position to focus its resources on the remaining services that provide the most value to members. > > If you have any questions or comments, please do not hesitate to contact us. Hi, I wasn't aware of this mobile client. Maybe it's my fault but looking through the ncc-services-wg archives for 2011-2013 I couldn't find any reference at all to this. Has it not been announced here? Is it still avalible for a quick test? regards, Bengt G?rd?n Resilans AB From lists-ripe at c4inet.net Thu Oct 24 16:28:14 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 24 Oct 2013 15:28:14 +0100 Subject: [ncc-services-wg] IP Analyser for Android Pilot - Proposed Discontinuation In-Reply-To: References: Message-ID: <20131024142814.GA65036@cilantro.c4inet.net> Alex, On Thu, Oct 24, 2013 at 09:44:24AM +0200, Alex Band wrote: >The IP Analyser for Android was a very lightweight trial to see if >members would be interested in having IP Analyser information available >on the go. Considering the amount of active installations and queries >from mobile clients, it is apparent that spending the available >resources on expanding the web interface and API is more valuable. For >example, we plan to develop IPv6 functionality in the near future. The low uptake might well be owing to the fact that functionality was very limited and switching between LIRs very awkward. I like the idea of a mobile IP Analyser but I guess this functionality might be as easily provided via a suitable mobile version of the web interface? rgds, Sascha Luck From ms at uakom.sk Fri Oct 25 13:53:58 2013 From: ms at uakom.sk (Martin Stanislav) Date: Fri, 25 Oct 2013 13:53:58 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131018.075724.532479318.jarle@uninett.no> References: <20131010141013.3BF69336340@epost.uninett.no> <20131018.075724.532479318.jarle@uninett.no> Message-ID: <20131025115358.GD16224@moon.uakom.sk> > > You can find the full proposal and impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-07 > > > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > > I think this a sound policy proposal, and I support its adaption > as RIPE policy. +1 Martin From ms at man-da.de Fri Oct 25 16:24:15 2013 From: ms at man-da.de (Marcus Stoegbauer) Date: Fri, 25 Oct 2013 16:24:15 +0200 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <20131010141006.6BEB810CFE8@ns.man-da.de> References: <20131010141006.6BEB810CFE8@ns.man-da.de> Message-ID: <6EA9FFF2-0879-4BEF-A555-7060F1048638@man-da.de> On 10.10.2013, at 16:07, Marco Schmidt wrote: > The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. > > Some of the main differences from version 3.0 include: > > - Rewording and new text in section 1.2 (Scope) > - Rewording and new text in section 2.6 (No relationship) > - New section 2.7 (Lapse of relationship or agreement) > - Rewording and new text in section 3.0 (Contractual requirements) > - An amendment to the existing policy document ripe-592 > > You can find the full proposal and impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2012-07 > > And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > > We encourage you to read the draft document text and send any comments to ncc-services-wg at ripe.net before 8 November 2013. > in my eyes this proposal provides a very good balance between the expectations of the legacy resource holders and the RIPE NCC members. I fully support it and like to thank everyone involved for their hard and excellent work. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-71022 Mornewegstr. 30 Fax: +49 6151 16-71198 D-64293 Darmstadt e-mail: ms at man-da.de Gesch?ftsf?hrer Marcus St?gbauer AG Darmstadt, HRB 94 84 From erik at bais.name Sat Oct 26 18:06:25 2013 From: erik at bais.name (Erik Bais) Date: Sat, 26 Oct 2013 16:06:25 +0000 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <5CEEA383-EF87-400C-9170-40E85A74B454@ucd.ie> References: <5256b53e.c5510f0a.4c05.066eSMTPIN_ADDED_MISSING@mx.google.com> <5CEEA383-EF87-400C-9170-40E85A74B454@ucd.ie> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C8F17ED18@E2010-MBX04.exchange2010.nl> On 10 Oct 2013, at 15:07, Marco Schmidt wrote: > The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. I support version 4 of 2012-07. Regards, Erik Bais From nst at google.com Mon Oct 28 05:02:43 2013 From: nst at google.com (nst at google.com) Date: Mon, 28 Oct 2013 04:02:43 +0000 Subject: [ncc-services-wg] [8-1123000002024] Peering down between AS57633 and Google [ref a76933] Message-ID: <18lebhg00000000003fq58005hoiesw70mj2c9i6co30c1g60p30chk@mail.gmail.com> Google Network Incident Notification - Reference *a76933* ------------------------------ Our monitoring systems have detected the following problem: BGP peering session with AS 57633 is down. Details: Google ASN: 15169Peer ASN: 57633Google Address:37.49.236.2 Peer Address: 37.49.236.226 Symptom(s): Hold Timer Expired Error Please investigate and provide an update via this email thread. Thank you for peering with Google! ------------------------------ PRIVILEGE AND CONFIDENTIALITY NOTICE: The information in this e-mail communication and any attached documents may be privileged, confidential or otherwise protected from disclosure and is intended only for the use of the designated recipient(s). If the reader is neither the intended recipient nor an employee or agent thereof who is responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution, copying or other use of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by return e-mail and promptly delete the original electronic e-mail communication and any attached documentation. Receipt by anyone other than the intended recipient is not a waiver of any attorney-client or work-product privilege. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops at ripe.net Mon Oct 28 11:39:33 2013 From: ops at ripe.net (Csaba Nagy) Date: Mon, 28 Oct 2013 11:39:33 +0100 Subject: [ncc-services-wg] [ripe.net #1109662] [8-1123000002024] Peering down between AS57633 and Google [ref a76933] In-Reply-To: <18lebhg00000000003fq58005hoiesw70mj2c9i6co30c1g60p30chk@mail.gmail.com> References: <18lebhg00000000003fq58005hoiesw70mj2c9i6co30c1g60p30chk@mail.gmail.com> Message-ID: Hi All, We are not responsible for AS57633, please check 'whois' and contact to the organisation which is responsible for that AS number. aut-num: AS57633 as-name: TERANET2 descr: E-TERA org: ORG-EA22-RIPE organisation: ORG-EA22-RIPE org-name: E-TERA org-type: LIR address: E-tera address: 46, rue Sere de Rivieres address: 81000 address: ALBI address: FRANCE phone: +33 563 43 30 00 fax-no: +33 563 43 30 30 e-mail: lir at e-tera.com Best regards, RIPE NCC On Mon Oct 28 05:08:07 2013, nst at google.com wrote: > Google Network Incident Notification - Reference *a76933* > ------------------------------ > Our monitoring systems have detected the following problem: > > BGP peering session with AS 57633 is down. > > Details: > Google ASN: 15169Peer ASN: 57633Google Address:37.49.236.2 Peer Address: > 37.49.236.226 > Symptom(s): > Hold Timer Expired Error > > > Please investigate and provide an update via this email thread. > > Thank you for peering with Google! > > ------------------------------ > > PRIVILEGE AND CONFIDENTIALITY NOTICE: The information in this e-mail > communication and any attached documents may be privileged, confidential or > otherwise protected from disclosure and is intended only for the use of the > designated recipient(s). If the reader is neither the intended recipient > nor an employee or agent thereof who is responsible for delivering it to > the intended recipient, you are hereby notified that any review, > dissemination, distribution, copying or other use of this communication is > strictly prohibited. If you have received this communication in error, > please immediately notify us by return e-mail and promptly delete the > original electronic e-mail communication and any attached documentation. > Receipt by anyone other than the intended recipient is not a waiver of any > attorney-client or work-product privilege. > From training at ripe.net Tue Oct 29 08:53:08 2013 From: training at ripe.net (Training Team) Date: Tue, 29 Oct 2013 08:53:08 +0100 Subject: [ncc-services-wg] [training] RIPE NCC Webinars - new dates Message-ID: <526F6964.5090100@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From mihael.dimec at arnes.si Wed Oct 30 09:55:01 2013 From: mihael.dimec at arnes.si (Mihael Dimec) Date: Wed, 30 Oct 2013 09:55:01 +0100 Subject: [ncc-services-wg] Policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" Message-ID: <5270C965.8000200@arnes.si> Hello all, I would like to add my support for policy proposal 2012-07. Best regards, Mihael Dimec From denis at ripe.net Wed Oct 30 17:17:19 2013 From: denis at ripe.net (Denis Walker) Date: Wed, 30 Oct 2013 17:17:19 +0100 Subject: [ncc-services-wg] RIPE Database Release 1.70 Available Message-ID: <5271310F.4000707@ripe.net> Dear colleagues, The RIPE NCC is pleased to announce that we will deploy a new release of the RIPE Database to the TEST Database environment on Thursday, 31 October 2013. The release is scheduled for production deployment on Thursday, 12 November 2013. Detailed information about the new release, including dates and information about the changes, can be found at: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.70 Of special note in this release is the inclusion of "pending route authentication". This is an alternative and simplified way of authorising route object creation. Two separate updates for a single route/route6 object are treated as one create request. This has no impact on users who still submit a complete route object with all authorisations included. If you have any questions or comments, we look forward to hearing them. Regards, Denis Walker Business Analyst RIPE NCC Database Team