From comms+reply at ripe.net Tue Mar 5 16:29:23 2013 From: comms+reply at ripe.net (Romeo Zwart) Date: Tue, 5 Mar 2013 16:29:23 +0100 Subject: [ncc-services-wg] DNS outage Message-ID: [Apologies for duplicate emails] Dear colleagues, This morning, the RIPE NCC briefly experienced a problem on the ripe.net DNS servers. Operation of K-root and other public DNS services was not impacted at any time during this outage. At 11:45 UTC this morning, an error in the deployment script used to update the ripe.net zone caused a partial zone file to be activated. This caused the ripe.net DNS servers to return NX-domain responses for some valid hosts and/or subdomains in the ripe.net zone, which effectively rendered some of the RIPE NCC services unavailable during this period. DNS resolution for ripe.net was fully restored at 12:15 UTC. Caching of the erroneous responses may have caused reachability problems until 13:15 UTC. The error in the script has been identified and is only triggered in a specific corner case. This error will be corrected today. We apologise for any inconvenience caused. Incident start: 05-Mar-2013 11:45:01 UTC Incident end: 05-Mar-2013 12:14:58 UTC Regards, Romeo Zwart GII Services Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhilario at ripe.net Wed Mar 6 10:22:15 2013 From: dhilario at ripe.net (David Hilario) Date: Wed, 6 Mar 2013 10:22:15 +0100 Subject: [ncc-services-wg] Policy Proposal 2012-06 Revert "Run Out Fairly" implemented Message-ID: [Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-06, Revert "Run Out Fairly" , has been implemented. The RIPE NCC is now ready to accept requests for IPv4 assignments and IPv4 allocations under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals/proposals/2012-06 The updated "IPv4 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-582 IPv4 assignments request forms have been updated. You can access the request forms through the LIR Portal or online at: http://www.ripe.net/ripe/docs/ripe-583 The supporting notes are available at: http://www.ripe.net/ripe/docs/ripe-584 If you have any questions, please contact. Regards, David Hilario Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Wed Mar 6 17:21:06 2013 From: andrea at ripe.net (Andrea Cima) Date: Wed, 06 Mar 2013 17:21:06 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B7E87.8070008@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B76A8.2010704@ripe.net> <512B77FC.2040205@netability.ie> <512B7DFD.8070309@ripe.net> <512B7E87.8070008@netability.ie> Message-ID: <51376CF2.8050302@ripe.net> Hi Nick, On 2/25/13 4:08 PM, Nick Hilliard wrote: > On 25/02/2013 15:06, Andrea Cima wrote: >> You are correct. These are listed here: >> ftp://ftp.ripe.net/erx/ >> >> I will get the webpages updated with the 192/8, 198/8 and 196/8 information. > actually, would the converse be possible? I.e. that > ftp://ftp.ripe.net/erx/ could contain the transferred blocks for the other /8s? As requested we have moved the transferred blocks to ftp://ftp.ripe.net/erx/ Best regards, Andrea Cima RIPE NCC > Nick > > From laura at ripe.net Thu Mar 7 18:10:20 2013 From: laura at ripe.net (Laura Cobley) Date: Thu, 07 Mar 2013 18:10:20 +0100 Subject: [ncc-services-wg] Improving Data Quality on the FTP Site Message-ID: <5138C9FC.70806@ripe.net> Dear colleagues, As part of our efforts to improve data quality across the RIPE NCC, we would like to update a file within the FTP site: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt According to our records, this file should contain a list of allocated address space held by the RIPE NCC membership. However, in addition to the expected data, the file also contains a number of references to obsoleted member accounts which no longer exist. These include, for example, accounts created for internal testing and accounts which have subsequently been renamed and therefore appear twice. We are therefore proposing a clean-up of this data so that it shows only allocated address space held by the RIPE NCC membership. Other than removing the erroneous information, the format of the data will not be changed. We plan to begin the clean-up three weeks from today (Thursday 28 March, 2013) and would be grateful for any feedback via this mailing list or sent to before then. Kind regards, Laura Cobley RIPE NCC Customer Services Manager From cfriacas at fccn.pt Fri Mar 8 18:13:51 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 8 Mar 2013 17:13:51 +0000 (WET) Subject: [ncc-services-wg] Improving Data Quality on the FTP Site In-Reply-To: <5138C9FC.70806@ripe.net> References: <5138C9FC.70806@ripe.net> Message-ID: Good! As a regular observer of this file's content i'm happy to see this clean-up going forward soon. Regards, Carlos Fria?as On Thu, 7 Mar 2013, Laura Cobley wrote: > Dear colleagues, > > As part of our efforts to improve data quality across the RIPE NCC, we > would like to update a file within the FTP site: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > According to our records, this file should contain a list of allocated > address space held by the RIPE NCC membership. However, in addition to > the expected data, the file also contains a number of references to > obsoleted member accounts which no longer exist. These include, for > example, accounts created for internal testing and accounts which have > subsequently been renamed and therefore appear twice. > > We are therefore proposing a clean-up of this data so that it shows only > allocated address space held by the RIPE NCC membership. Other than > removing the erroneous information, the format of the data will not be > changed. > > We plan to begin the clean-up three weeks from today (Thursday 28 March, > 2013) and would be grateful for any feedback via this mailing list or > sent to before then. > > Kind regards, > > Laura Cobley > RIPE NCC Customer Services Manager > > From inigo at infornografia.net Wed Mar 13 10:22:18 2013 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 13 Mar 2013 10:22:18 +0100 Subject: [ncc-services-wg] Improving Data Quality on the FTP Site In-Reply-To: <5138C9FC.70806@ripe.net> References: <5138C9FC.70806@ripe.net> Message-ID: Dear all, As a consumer of this data, I have a question regarding the legitimately closed (no test nor renamed) LIRs in file. On Thu, Mar 7, 2013 at 6:10 PM, Laura Cobley wrote: > Dear colleagues, > > As part of our efforts to improve data quality across the RIPE NCC, we > would like to update a file within the FTP site: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > According to our records, this file should contain a **list of allocated > address space held by the RIPE NCC membership**. However, in addition to > the expected data, the file also contains a number of references to > obsoleted member accounts which no longer exist. These include, for > example, accounts created for internal testing and accounts which have > subsequently been renamed and therefore appear twice. > > We are therefore proposing a clean-up of this data so that it shows **only > allocated address space held by the RIPE NCC membership**. Other than > removing the erroneous information, the format of the data will not be > changed. > > Just to make it clear: does this mean the file will just include active LIRs and their allocations, effectively excluding all sort of closed LIRs? > We plan to begin the clean-up three weeks from today (Thursday 28 March, > 2013) and would be grateful for any feedback via this mailing list or > sent to before then. > > Kind regards, > > Laura Cobley > RIPE NCC Customer Services Manager > > Thanks in advance and have a nice day, I?igo Ortiz de Urbina Cazenave -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripencc-management at ripe.net Thu Mar 14 12:41:33 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Thu, 14 Mar 2013 12:41:33 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space Message-ID: Dear colleagues, On 11 February, the RIPE NCC asked the RIPE NCC membership and the RIPE community for feedback on how to make Provider Independent (PI) End User address space eligible for resource certification (RPKI). Although we?ve received valuable input at several operator meetings and through various other communication channels, we want to emphasise the importance of your participation on this mailing list. We strongly encourage further feedback on this important issue, before the consultation period comes to a close. To summarise, the discussion so far involves three possible implementation options: 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 ROA management system themselves, or delegates 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 The feedback provided so far clearly differentiates between two groups of PI End Users: those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves, and 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 both options 2 and 3, while option 1 will continue to remain available at all times. These options have different expected impacts on the RIPE NCC?s operations. The RIPE NCC does not expect option 1 or 2 to have a major impact, as they align with our current business practices. Option 3 would require PI End Users to have a direct contact with the RIPE NCC. As this would be a new venture for the RIPE NCC, we expect it would be the most labour intensive of the three options and would have the greatest impact in terms of resources. Some feedback has pointed out the lack of RIPE Policy on this issue. At this time, the RIPE NCC is requesting feedback on whether or not resource certification should expand beyond a RIPE NCC member service. Discussions about potential RIPE Policy, should this happen, can take place via the appropriate channels. Again, we strongly encourage your feedback before the consultation period ends on 30 March 2013, after which time the RIPE NCC Executive Board will recommend which option(s) to implement. We look forward to hearing from you. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC From gert at space.net Thu Mar 14 13:20:47 2013 From: gert at space.net (Gert Doering) Date: Thu, 14 Mar 2013 13:20:47 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: References: Message-ID: <20130314122047.GO51699@Space.Net> Hi, On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote: > 2) A PI End User requests a resource certificate through their sponsoring > LIR and gets access to the ROA management system themselves, or delegates > 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 Supporting both 2) and 3) seem to make sense to me. To avoid creating a high workload, 3) would need to be done in a mostly automated fashion - similar to what is happening today: if the sponsoring LIR sets up a mntner object that permits the end user to create their own route:/route6: objects, the end user can create "old-style" route authorization without involving the NCC. Something like this, sort of "between 2) and 3)" - the sponsoring LIR creating an access code of some sorts, and the end user using that to talk to the NCC systems. 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 (89) 32356-444 USt-IdNr.: DE813185279 From jim at rfc1035.com Thu Mar 14 15:44:26 2013 From: jim at rfc1035.com (Jim Reid) Date: Thu, 14 Mar 2013 14:44:26 +0000 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <20130314122047.GO51699@Space.Net> References: <20130314122047.GO51699@Space.Net> Message-ID: On 14 Mar 2013, at 12:20, Gert Doering wrote: > On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote: >> 2) A PI End User requests a resource certificate through their sponsoring >> LIR and gets access to the ROA management system themselves, or delegates >> 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 > > Supporting both 2) and 3) seem to make sense to me. > > To avoid creating a high workload, 3) would need to be done in a mostly > automated fashion - similar to what is happening today: if the sponsoring > LIR sets up a mntner object that permits the end user to create their > own route:/route6: objects, the end user can create "old-style" route > authorization without involving the NCC. Something like this, sort > of "between 2) and 3)" - the sponsoring LIR creating an access code of > some sorts, and the end user using that to talk to the NCC systems. Could it actually be that straightforward? It seems unlikely, though I hope otherwise. An obvious rat-hole in this scenario is figuring out what to do for PI End Users who can't/won't go through a sponsoring LIR. Presumably this amended option 3) would still mean the PI End User entering some sort of contractual relationship with the NCC => introducing extra procedures and infrastructure around billing, paperwork and so forth. A PI End User would or should pay something to get resource certificates, right? Perhaps we'll get a re-run of the debate over legacy resource holders becoming LIRs or going through a sponsoring LIR. My preference would be to avoid option 3) -- or variations of 3) -- for the reasons Andrew outlined. That said, it would be helpful to get more data on the extent of the issue and a rough idea of likely costs. How many PI End Users are there and what are the best case and worst case scenarios for the amount of work that would be involved in issuing them with resource certificates? If the costs to the NCC for option 3) will always be insignificant, then there's nothing to see here, move along. Just do it. OTOH if option 3) has the potential to grow into a monster that needs a small army to administer it, we should not go down that path. From bijal.sanghani at euro-ix.net Thu Mar 14 21:42:12 2013 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Thu, 14 Mar 2013 20:42:12 +0000 Subject: [ncc-services-wg] Call for Agenda Items RIPE66 -RIPE NCC Services WG Message-ID: Dear NCC-Services WG, RIPE66 is just round the corner and we are putting the agenda together for the NCC Services WG. This is your opportunity to let the RIPE NCC know what you want from them, if you would like to suggest a topic for discussion or have a presentation you have or would like to see presented please get in touch with Kurtis or myself. Kind regards, Bijal Sanghani RIPE NCC Services WG Co-Chair From alexb at ripe.net Fri Mar 15 15:20:37 2013 From: alexb at ripe.net (Alex Band) Date: Fri, 15 Mar 2013 15:20:37 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: References: <20130314122047.GO51699@Space.Net> Message-ID: On 14 Mar 2013, at 15:44, Jim Reid wrote: > On 14 Mar 2013, at 12:20, Gert Doering wrote: > >> On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote: >>> 2) A PI End User requests a resource certificate through their sponsoring >>> LIR and gets access to the ROA management system themselves, or delegates >>> 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 >> >> Supporting both 2) and 3) seem to make sense to me. >> >> To avoid creating a high workload, 3) would need to be done in a mostly >> automated fashion - similar to what is happening today: if the sponsoring >> LIR sets up a mntner object that permits the end user to create their >> own route:/route6: objects, the end user can create "old-style" route >> authorization without involving the NCC. Something like this, sort >> of "between 2) and 3)" - the sponsoring LIR creating an access code of >> some sorts, and the end user using that to talk to the NCC systems. > > Could it actually be that straightforward? It seems unlikely, though I hope otherwise. Just to clarify option 3: a Resource Certificate is not for identification purposes, nor does it contain identity information; this is what the Registry is for. All that the RIPE NCC needs to ensure is that we issue a certificate to the party who has authoritative control over the address space. Establishing this could be done using the maintainer of the relevant INETNUM object, for example, which means it could be implemented in an automated fashion, as Gert suggests. It all depends if that is "good enough". Every additional check that is required, such as submitting paperwork, will add to the complexity, cost and labour involved, but could very well be worth the effort. All of this will be evaluated and taken into account when taking the decision on the actual implementation. Cheers, Alex From richih.mailinglist at gmail.com Fri Mar 15 20:12:38 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:12:38 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" Message-ID: Dear all, this is the second suggestion: The canonical name of all PDPs will be RIPE-PDP-YYYY-NN. Updated versions will receive suffixes like Internet Drafts, i.e. -v1, -v2, -v3. Old-style PDP names of the format YYYY-NN will remain valid, but all new documentation and communication by RIPE will use the new format. Alternatively, the name of the Working Group may be embedded in all names, e.g. RIPE-PDP-APWG-YYYY-NN, or RIPE-APWG-PDP-YYYY-NN. Rationale should again be obvious: Encoding information in names is good practice. Unique names make life easier for everyone involved. If other RIRs follow suit, cross-referencing becomes easier. Rationale for keeping "PDP" in the WG option is because a WG may want to publish something other than a PDP at some point. The alternatives should be decided upon during the discussion phase of the PDP. Richard From richih.mailinglist at gmail.com Fri Mar 15 20:13:00 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:13:00 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All PDP emails, documents and websites should come with unified diff" Message-ID: Dear all, this is the third suggestion: All PDP-related emails, web pages, and other documents by RIPE will either carry a unified diff (diff -ruN) or directly link to a page which shows said unified diff. Other formats, like full text, old/new text, etc are encouraged as well, but the diff is the binding format in which PDPs are published, documented, and discussed. Rationale: It's needlessly hard to read and compare full or partial text dumps, forcing people to do work by themselves and for themselves which a computer could do once and for all. A XML-based format that's parse-able by new tools has been proposed as an alternative. This would mean extra work while defining the XML format, to write new tools, and cut of the extensive tools and workflows around unified diffs. The point has also been raised that word diffs may be easier to read. Quoth the manpage: Nevermerge! Show words as [-removed-] and {+added+}. Makes no attempts to escape the delimiters if they appear in the input, so the output may be ambiguous. Ironically, --word-diff in git comes with an option that allows parsing, --porcelain, which turns word-based diff back into line-based diffs: Use a special line-based format intended for script consumption. Added/removed/unchanged runs are printed in the usual unified diff format, starting with a +/-/` ` character at the beginning of the line and extending to the end of the line. Newlines in the input are represented by a tilde ~ on a line of its own. Long story short: Unified diffs are called unified diffs and universally accepted for a reason. Richard From richih.mailinglist at gmail.com Fri Mar 15 20:13:36 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:13:36 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" Message-ID: Dear all, this is the fourth suggestion: All RIPE documents are made available by means of a git repository, both via anonymous pull and via a web interface. The read-only access is open to everyone, RIPE member or not. Within RIPE, this git repository is the canonical place for all published documents. All published documents are copied from it. All PDPs will be maintained as a separate branch. Every new version of a PDP is an update within that branch. The branch will either be merged back into master or left unmerged but intact, depending on if they are accepted or not. Old documents and PDPs, if still on record, will be put into separate branches that reflect correct history. The master branch is then merged into old history, creating one single history. This will happen one year after this policy comes into effect at the latest. If the proposal "All PDP emails, documents and websites should come with unified diff" is accepted, all diffs will be generated from git. Rationale: git is here to stay, it's highly efficient, allows off-line work, and has generally won the fight for version control systems in the foreseeable future. Not relying on technical tools which were created with ever-chaning text files in mind is inefficient at best. I offer to help maintain said git repository pro bono for at least 12 months or until the history has been merged, whichever is later. Richard PS: Think of those five emails as a patchset ;) From richih.mailinglist at gmail.com Fri Mar 15 20:13:51 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:13:51 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" Message-ID: Dear all, this is the fifth suggestion: RIPE will create a yearly list of all services it provides to members or the general public This list will include at least: * Name of the service * Cost in time and money of maintaining and possibly extending this service * Cost in time and money of maintaining the backend needed for this service; this is to catch stuff that relies on old and brittle infra * Number of users if applicable/traceable per year * Number of queries/transactions if applicable/traceable per year * General usefulness of the service from RIPE's POV * Status of service, such as "active, supported", "deprecated", or "scheduled for decommissioning on YYYY-MM-DD" * A suggestion for the future status of the service If in doubt, RIPE will focus less on detailed interpretation and analysis and more on giving out as many hard facts and stats as possible. Interpretation will happen on the mailing lists anyway. RIPE will implement this policy in a light-weight manner that is not a drain on resources in and as of itself. From richih.mailinglist at gmail.com Fri Mar 15 20:12:14 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:12:14 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" Message-ID: Dear all, this is the first in a series of emails which I hope will advance into PDPs and then updated policies. Some of them are closely related, but I submit them individually so that if there are any hold-ups with a specific one, the other ones can still progress. My first suggestion is: The canonical and binding format of all documents is plain text in UTF-8 encoding. If a document can not reasonably be stored as plain text, PDF/A-1a[1] will be used. If any document exists in both plain text and PDF/A-1a, plain text is binding. Any other form is considered non-binding as soon as a plain text or PDF/A-1a variant exist. All legacy documents which are still valid or relevant to current policies will be transformed within a year of this proposal becoming policy. The reasoning behind this should be obvious: Ensure that all documents will be in the most simple-to-parse format now and forever. Richard [1] https://en.wikipedia.org/wiki/PDF/A From richih.mailinglist at gmail.com Fri Mar 15 20:18:31 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 20:18:31 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" Message-ID: --Resending as the first mail seems to have been eaten by a grinch-- Dear all, this is the first in a series of emails which I hope will advance into PDPs and then updated policies. Some of them are closely related, but I submit them individually so that if there are any hold-ups with a specific one, the other ones can still progress. My first suggestion is: The canonical and binding format of all documents is plain text in UTF-8 encoding. If a document can not reasonably be stored as plain text, PDF/A-1a[1] will be used. If any document exists in both plain text and PDF/A-1a, plain text is binding. Any other form is considered non-binding as soon as a plain text or PDF/A-1a variant exist. All legacy documents which are still valid or relevant to current policies will be transformed within a year of this proposal becoming policy. The reasoning behind this should be obvious: Ensure that all documents will be in the most simple-to-parse format now and forever. Richard [1] https://en.wikipedia.org/wiki/PDF/A From sander at steffann.nl Fri Mar 15 20:56:15 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 20:56:15 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: Hi Richard, > All RIPE documents are made available by means of a git repository, > both via anonymous pull and via a web interface. The read-only access > is open to everyone, RIPE member or not. > Within RIPE, this git repository is the canonical place for all > published documents. All published documents are copied from it. I don't know how useful this is, as RIPE documents don't change once they are published. If a revision of a RIPE document is published it gets a new number. So I don't think a version control system will be useful here. Cheers, Sander From richih.mailinglist at gmail.com Fri Mar 15 21:03:20 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 21:03:20 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: On Fri, Mar 15, 2013 at 8:56 PM, Sander Steffann wrote: > I don't know how useful this is, as RIPE documents don't change once they are published. If a revision of a RIPE document is published it gets a new number. So I don't think a version control system will be useful here. While that is true, this will still allow anyone to see how PDPs progressed and resulted in new documents. Also, I don't think the power of a single, canonical resource that you can easily sync to your local machines and which you _know_ is up to date should be underestimated. We shouldn't discard using a toold just because we won't need all features it provides. Thanks for your quick feedback, Richard From richih.mailinglist at gmail.com Fri Mar 15 21:10:09 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 21:10:09 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: On Fri, Mar 15, 2013 at 9:07 PM, Rob Evans wrote: > Whilst understanding the limits and overheads of rsync, I'd have thought there is enough experience of the software within the NCC (think RPKI) to be able to set up an rsync server for the documents fairly trivially. There are several different technologies which provide some or all of the features git offers. Yet, the package as a whole is unmatched, imo. I am well aware that this is the weakest of all proposals as it specifies a specific piece of software that should be used. I still think it would be a Very Good Thing, but if this one fails and the others come through, I will be happy. -- Richard From sander at steffann.nl Fri Mar 15 21:12:50 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 21:12:50 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> Hi, >> I don't know how useful this is, as RIPE documents don't change once they are published. If a revision of a RIPE document is published it gets a new number. So I don't think a version control system will be useful here. > > While that is true, this will still allow anyone to see how PDPs > progressed and resulted in new documents. Now, if *that* history is maintained then I see the value. Seeing that a RIPE document is based on an older document, seeing which proposal changed it (from the commit message) and seeing the differences between them might be useful for some. It might even be useful to maintain this for policy proposals to keep track of the proposed changes. The final version of the policy proposal could then be copied to the ripe-documents section. Hmmm. It might be much more than we need, and rsync might be enough for what we need, but I can also see some benefits now. Thanks, Sander From sander at steffann.nl Fri Mar 15 21:16:25 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 21:16:25 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> References: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> Message-ID: <530FF7E0-A5F4-494F-B1DC-E98EDE76B22A@steffann.nl> Hi, > Hmmm. It might be much more than we need, and rsync might be enough for what we need, but I can also see some benefits now. Just to be clear: I don't think your ideas should go through the PDP. This is procedural stuff for the NCC, not a policy. But the NCC Services WG seems the right place to discuss these new services and/or procedures. I'll leave the details of how to proceed to the NCCS chairs :-) Cheers, Sander From richih.mailinglist at gmail.com Fri Mar 15 21:21:30 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 21:21:30 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> References: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> Message-ID: On Fri, Mar 15, 2013 at 9:12 PM, Sander Steffann wrote: > Now, if *that* history is maintained then I see the value. Of course it would be. > Seeing that a RIPE document is based on an older document, seeing which proposal changed it (from the commit message) and seeing the differences between them might be useful for some. And visualizing those differences is laughably easy with git. > It might even be useful to maintain this for policy proposals to keep track of the proposed changes. The final version of the policy proposal could then be copied to the ripe-documents section. That is the basic goal of this proposal. All changes during a PDP process are simply one patch for every update. Once the PDP changing document 123 gets approved and results in 124, the final commit in the branch is a simple `git mv 123 124` and is then merged into master. > Hmmm. It might be much more than we need, and rsync might be enough for what we need, but I can also see some benefits now. I have noticed this particular proposal growing on people over time several times over the few months I bounced it around on IRC. Richard From richih.mailinglist at gmail.com Fri Mar 15 21:22:32 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 21:22:32 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <530FF7E0-A5F4-494F-B1DC-E98EDE76B22A@steffann.nl> References: <4864D333-42A7-4980-BFE1-21D04812EC2D@steffann.nl> <530FF7E0-A5F4-494F-B1DC-E98EDE76B22A@steffann.nl> Message-ID: On Fri, Mar 15, 2013 at 9:16 PM, Sander Steffann wrote: > Just to be clear: I don't think your ideas should go through the PDP. This is procedural stuff for the NCC, not a policy. But the NCC Services WG seems the right place to discuss these new services and/or procedures. I'll leave the details of how to proceed to the NCCS chairs :-) To be honest, I don't care in the least if they do not result in PDPs. I want to see change within RIPE; I don't care about the name tag that's been attached to the means of change. Richard From rhe at nosc.ja.net Fri Mar 15 21:07:06 2013 From: rhe at nosc.ja.net (Rob Evans) Date: Fri, 15 Mar 2013 16:07:06 -0400 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: > While that is true, this will still allow anyone to see how PDPs > progressed and resulted in new documents. Also, I don't think the > power of a single, canonical resource that you can easily sync to your > local machines and which you _know_ is up to date should be > underestimated. Whilst understanding the limits and overheads of rsync, I'd have thought there is enough experience of the software within the NCC (think RPKI) to be able to set up an rsync server for the documents fairly trivially. Cheers, Rob From sergey at devnull.ru Fri Mar 15 21:38:50 2013 From: sergey at devnull.ru (Sergey Myasoedov) Date: Fri, 15 Mar 2013 21:38:50 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: Message-ID: <1831051651.20130315213850@devnull.ru> Dear Richard, a good idea, but wrong proposal format. Let's ask the Board to do such reports. -- Sergey Friday, March 15, 2013, 8:13:51 PM, you wrote: RH> Dear all, RH> this is the fifth suggestion: RH> RIPE will create a yearly list of all services it provides to RH> members or the general public RH> This list will include at least: RH> * Name of the service RH> * Cost in time and money of maintaining and possibly extending this service RH> * Cost in time and money of maintaining the backend needed for this RH> service; this is to catch stuff that relies on old and brittle infra RH> * Number of users if applicable/traceable per year RH> * Number of queries/transactions if applicable/traceable per year RH> * General usefulness of the service from RIPE's POV RH> * Status of service, such as "active, supported", "deprecated", or RH> "scheduled for decommissioning on YYYY-MM-DD" RH> * A suggestion for the future status of the service RH> If in doubt, RIPE will focus less on detailed interpretation and RH> analysis and more on giving out as many hard facts and stats as RH> possible. Interpretation will happen on the mailing lists anyway. RH> RIPE will implement this policy in a light-weight manner that is not RH> a drain on resources in and as of itself. From richih.mailinglist at gmail.com Fri Mar 15 21:58:31 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 21:58:31 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: <1831051651.20130315213850@devnull.ru> References: <1831051651.20130315213850@devnull.ru> Message-ID: On Fri, Mar 15, 2013 at 9:38 PM, Sergey Myasoedov wrote: > a good idea, but wrong proposal format. > Let's ask the Board to do such reports. Wouldn't the Board simply ask RIPE NCC to provide this list? I don't really care who puts their name under the document; feedback by RIPE as to which part of it could most efficiently produce such a list may be helpful in this context. Richard From tore at fud.no Fri Mar 15 22:01:23 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Mar 2013 22:01:23 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: <51438C23.3000202@fud.no> * Richard Hartmann > this is the first in a series of emails which I hope will advance into > PDPs and then updated policies. Some of them are closely related, but > I submit them individually so that if there are any hold-ups with a > specific one, the other ones can still progress. > > My first suggestion is: > > The canonical and binding format of all documents is plain text in > UTF-8 encoding. > If a document can not reasonably be stored as plain text, > PDF/A-1a[1] will be used. > If any document exists in both plain text and PDF/A-1a, plain text is binding. > Any other form is considered non-binding as soon as a plain text or > PDF/A-1a variant exist. > All legacy documents which are still valid or relevant to current > policies will be transformed within a year of this proposal becoming > policy. > > The reasoning behind this should be obvious: Ensure that all documents > will be in the most simple-to-parse format now and forever. Having recently authored a rather intrusive policy proposal that touches a lot of text, I can only strongly agree with this. The pre-publication procedure appears to be to send complete versions of the proposed new policy document back and forth by e-mail (sometimes in different document formats), with no easy way to pinpoint exactly what has changed between the various versions. This makes the entire process needlessly time-consuming, and increases the risk that some typo or mistake accidentally sneaks into the proposal and makes it all through the PDP. So there should definitively be an authoritative, easy to collaborate on source format for all RIPE documents. Plain text is one obvious alternative, but would preclude text formatting and inclusion of figures, so a document such as ripe-500 can not be converted into plain text without loss of information. I do not like the idea of using PDF for documents like ripe-500 though. PDFs are hard to collaborate on; standard tools like diff cannot meaningfully represent the differences between two versions of a document. I would prefer something like HTML, where you could download an archive file containing the main policy text as a HTML file and any figure or image files referred to by it. I'd also suggest that a conventional 80-character line length limit would be used in the source format, as limiting the line length makes reading diffs easier. That doesn't mean the published document's web page cannot be reformatted to have longer lines of course (something that would happen automatically with HTML). -- Tore Anderson From richih.mailinglist at gmail.com Fri Mar 15 22:17:41 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:17:41 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <51438C23.3000202@fud.no> References: <51438C23.3000202@fud.no> Message-ID: On Fri, Mar 15, 2013 at 10:01 PM, Tore Anderson wrote: > Plain text is one obvious > alternative, but would preclude text formatting and inclusion of > figures, so a document such as ripe-500 can not be converted into plain > text without loss of information. I honestly can't see how that picture is really needed to understand the process. Especially as RIPE would be free to keep a version with a picture around if it wanted to. But that diagram would work in text, as well. > I do not like the idea of using PDF for documents like ripe-500 though. > PDFs are hard to collaborate on; standard tools like diff cannot > meaningfully represent the differences between two versions of a > document. I would prefer something like HTML, where you could download > an archive file containing the main policy text as a HTML file and any > figure or image files referred to by it. Why not collaborate on a text file and export the result into PDF if it really can not be stored as text? WRT HTML, can we be certain that it will still render the same in ten years? > I'd also suggest that a conventional 80-character line length limit > would be used in the source format, as limiting the line length makes > reading diffs easier. That doesn't mean the published document's web > page cannot be reformatted to have longer lines of course (something > that would happen automatically with HTML). Very good point, though 78 or even the email default of 72 may make more sense, especially once people start quoting in emails, etc. Unified diff already eats one more character, add a single level of quoting and 78 is too long. There's a standard for email hidden somewhere that basically says that trailing whitespace equals word wrap whereas no trailing whitespace means proper end of line. That eats another column, but it would be easy to parse. Though if we go that far, why not retain that width for everything new? Old documents should not be changed for obvious reasons. Alternatively, "one sentence per line" would make diffing easier on the eyes, as well. Richard From sander at steffann.nl Fri Mar 15 22:22:44 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 22:22:44 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: <1831051651.20130315213850@devnull.ru> Message-ID: Hi, >> a good idea, but wrong proposal format. >> Let's ask the Board to do such reports. > > Wouldn't the Board simply ask RIPE NCC to provide this list? Most likely: yes, unless there is a strong reason not to (legal, financial etc). The board is usually really responsive in my experience. It might not even need to go all the way to the board. Maybe NCC senior management can comment on this? Thanks, Sander From richih.mailinglist at gmail.com Fri Mar 15 22:23:33 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:23:33 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: On Fri, Mar 15, 2013 at 8:13 PM, Richard Hartmann wrote: > All PDPs will be maintained as a separate branch. Every new version > of a PDP is an update within that branch. The branch will either be > merged back into master or left unmerged but intact, depending on if > they are accepted or not. To make this point clear: I am not saying that a proposer should be forced to know git. If RIPE NCC receives the proposal/update as simple text file, it should import that data into git (retaining author information) and commit the result. Or nudge the proposer into the right direction if need be. Again, I will help with the git side of things for at least 12 months if this proposal is accepted. Richard From tore at fud.no Fri Mar 15 22:24:10 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Mar 2013 22:24:10 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: <5143917A.4070309@fud.no> * Sander Steffann >> All RIPE documents are made available by means of a git >> repository, both via anonymous pull and via a web interface. The >> read-only access is open to everyone, RIPE member or not. Within >> RIPE, this git repository is the canonical place for all published >> documents. All published documents are copied from it. > > I don't know how useful this is, as RIPE documents don't change once > they are published. If a revision of a RIPE document is published it > gets a new number. So I don't think a version control system will be > useful here. I can see one particular advantage of using a version control system - the "git blame" command, which will show when a particular sentence or paragraph was added or last modified. There's several times I've read RIPE documents and wondered along the lines of: ?Where did this come from? What was the rationale behind it?? I rarely go through the trouble to find out. That said, while I agree that Git is a very good tool, I'm reluctant to micro-manage the NCC by saying ?you MUST use Git? (or any other particular tool for that matter). The current system can be improved a whole lot without requiring a version control system, I like to point to the IETF's tools page, which shows all the revisions of a draft leading up to its publication as RFC, and where you can generate both in-line and side-by-side diffs on the fly. One example: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 In any case, for maximum use of any form of version control system, you'd have to consider that even though e.g. ripe-582 is a new version of ripe-577 which in turn is a new version of ripe-553 and so on, the history of ripe-582 alone isn't nearly as interesting as the history of ripe-582 plus all preceding versions combined. So either the file name needs to stay the same between versions (unlike today). or you'd have to import the entire history of the previous version into whatever you're starting the PDP with for the proposed new version. I don't know if Git allows for this. -- Tore Anderson From sander at steffann.nl Fri Mar 15 22:35:30 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 22:35:30 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <5143917A.4070309@fud.no> References: <5143917A.4070309@fud.no> Message-ID: <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> Hi, > That said, while I agree that Git is a very good tool, I'm reluctant to > micro-manage the NCC by saying ?you MUST use Git? (or any other > particular tool for that matter). I agree. If we want something then we should specify *what* we want and give the NCC the freedom to choose an implementation that fits both the needs of the community and of the NCC itself. I personally would like: - a word-by-word diff (not line-by-line) - being able to see the diff between a RIPE document and any RIPE document version that preceded it - being able to see the history of a document with or without the policy proposal versions in between - for every RIPE document change I would like to see what caused it (policy proposal, cosmetic surgery, RIPE NCC, etc) - being able to see the history even for policy proposals that haven't (yet) become RIPE documents - a pony (optional) And we have to remember that not all RIPE documents are policy documents. Working Groups and the RIPE NCC also publish other types of RIPE documents. I suggest we see what we want, and then ask the NCC to give feedback on how they see it, if it is doable etc. Sander From richih.mailinglist at gmail.com Fri Mar 15 22:42:09 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:42:09 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <5143917A.4070309@fud.no> References: <5143917A.4070309@fud.no> Message-ID: On Fri, Mar 15, 2013 at 10:24 PM, Tore Anderson wrote: > I can see one particular advantage of using a version control system - > the "git blame" command, which will show when a particular sentence or > paragraph was added or last modified. There's several times I've read > RIPE documents and wondered along the lines of: ?Where did this come > from? What was the rationale behind it?? I rarely go through the trouble > to find out. For example: Re-allocated blocks will be signed to establish the current allocation owner. ;) > That said, while I agree that Git is a very good tool, I'm reluctant to > micro-manage the NCC by saying ?you MUST use Git? (or any other > particular tool for that matter). I am painfully aware of that. The community is free to shoot this down, but if it's accepted, it would be possible to change this. _Especially_ once there's a yearly list of services through which RIPE NCC can give feedback on if they want to get rid of it and replace it with VCS 3.0 in a decade. > The current system can be improved a > whole lot without requiring a version control system, I like to point to > the IETF's tools page, which shows all the revisions of a draft leading > up to its publication as RFC, and where you can generate both in-line > and side-by-side diffs on the fly. One example: > > http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 Submitting Internet Drafts is a different valley of pain, but the end user interface is somewhat decent. Still, RIPE NCC would need to either ask for that code of code a similar system themselves. Gitweb and gitolite are free and available today. Plus, IETF lacks any offline capabilities. > In any case, for maximum use of any form of version control system, > you'd have to consider that even though e.g. ripe-582 is a new version > of ripe-577 which in turn is a new version of ripe-553 and so on, the > history of ripe-582 alone isn't nearly as interesting as the history of > ripe-582 plus all preceding versions combined. Internally git tracks changesets, not files. Thus, there is no `git cp` which allows you to trace the forking of a file directly. That being said, git log supports --find-copies which does the same on the fly. Also, just like RFCs, documents carry inline information about what other forms they update. > So either the file name > needs to stay the same between versions (unlike today). or you'd have to > import the entire history of the previous version into whatever you're > starting the PDP with for the proposed new version. I don't know if Git > allows for this. If you have an existing repository, importing the old data into the past of the repo will change history, resulting in issues for everyone who cloned from that repo. There are two ways to mitigate this: 1) Recreate full history before starting to really use the main repo. Optionally have a scratch repo for new PDPs which can be rebased on top of the historic repo once it's done. This leaves you with a sparkling clean history, but is a lot of work up front and means people need to actively migrate away from the temporary repo. 2) Use main repo without full history from day one. Once history has been recreated, merge current master into the history and make that the new master. You would have one clear spot in your history where you would always be able to see that two repos were merged. But the actual impact is neglible and work up front minimal. Richard From tore at fud.no Fri Mar 15 22:43:57 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Mar 2013 22:43:57 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: <51438C23.3000202@fud.no> Message-ID: <5143961D.10205@fud.no> Hi, * Richard Hartmann > On Fri, Mar 15, 2013 at 10:01 PM, Tore Anderson wrote: > >> Plain text is one obvious >> alternative, but would preclude text formatting and inclusion of >> figures, so a document such as ripe-500 can not be converted into plain >> text without loss of information. > > I honestly can't see how that picture is really needed to understand > the process. Especially as RIPE would be free to keep a version with a > picture around if it wanted to. But that diagram would work in text, > as well. It was just one example. Another would be ripe-566, which has a couple of tables. Sure, you can create an ASCII art tables, but doing so and at the same time everything below 72 characters of width might not be easiest thing in the world. A future document might want to include some other figures or other external content which cannot be (easily) represented in plain text. > Why not collaborate on a text file and export the result into PDF if > it really can not be stored as text? Because once that PDF is the authoritative version it's hard for someone else to come along and make changes to it later. > WRT HTML, can we be certain that it will still render the same in ten years? Reasonably, if you keep the amount of markup to a minimum. The point after all isn't to get RIPE documents that are glitzy AJAX Web2.0 HTML5 interactive stuff, just to allow for the inclusion of basic figures, tables, images and a minimum of formatting. > Alternatively, "one sentence per line" would make diffing easier on > the eyes, as well. I have a nasty tendency to write very long lines, so I think perhaps if you do "max one sentence per line" you want to do it *in addition* to a max line length of N chars. The result will probably look weird in plain text though, but not so in HTML (as newline characters don't get rendered as such). Best regards, -- Tore Anderson From jim at rfc1035.com Fri Mar 15 22:46:14 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Mar 2013 21:46:14 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> On 15 Mar 2013, at 21:23, Richard Hartmann wrote: > If RIPE NCC receives the proposal/update as simple text file, it > should import that data into git (retaining author information) and > commit the result NO! A million times no. First, git may well be the flavour-of-the-month as a version control repository/system today. It won't be in the future. What happens then? Next, this could force EVERYONE to use some git client. The NCC's supposed to be neutral. It should not get into the game of requiring the community to use specific tools or software. Just because some people have a git-shaped hammer doesn't mean every problem in the area of version control and document management has to be made to look like a git-shaped nail. You also appear to be defining outcomes before the requirements are agreed. Or even clear. Let's first understand what problem needs solved and then decide what's the best way to solve them. From richih.mailinglist at gmail.com Fri Mar 15 22:50:07 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:50:07 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> References: <5143917A.4070309@fud.no> <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> Message-ID: On Fri, Mar 15, 2013 at 10:35 PM, Sander Steffann wrote: > I agree. If we want something then we should specify *what* we want and give the NCC the freedom to choose an implementation that fits both the needs of the community and of the NCC itself. I would not mind changing the proposal that way; I am confident git would win, anyway. Using anything else today would be weird at best. > I personally would like: > - a word-by-word diff (not line-by-line) See my initial email. word-by-word can be ambiguous. PDPs must be explicit and without doubt of the underlying data. Offering word-by-word as an optional extra to line-by-line diffs would be trivial, though. And you could even do so on your own client, have it color the diff the way you want, etc etc. > - being able to see the diff between a RIPE document and any RIPE document version that preceded it Trivial on CLI, may not be doable on web without minor updates to gitweb/gitolite. You will need both filenames. > - being able to see the history of a document with or without the policy proposal versions in between Trivial on CLI, may not be doable on web without minor updates to gitweb/gitolite. You will need specific commits or, better, tags. Every finished PDP can simply be tagged. > - for every RIPE document change I would like to see what caused it (policy proposal, cosmetic surgery, RIPE NCC, etc) That's what the commit message or the tag message is for. Plus, _every single copy_ of the document set (i.e. git repo) would carry all that info. > - being able to see the history even for policy proposals that haven't (yet) become RIPE documents Trivial. `git pull; gitk --all` > - a pony (optional) Sadly, you missed the time window in which every Ikea offered horse kotbullar. > And we have to remember that not all RIPE documents are policy documents. Working Groups and the RIPE NCC also publish other types of RIPE documents. True. Maybe focus on policy documents for now? > I suggest we see what we want, and then ask the NCC to give feedback on how they see it, if it is doable etc. Should we do that in this early phase or later? I would prefer early. Richard From sander at steffann.nl Fri Mar 15 22:54:53 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 22:54:53 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: <5143917A.4070309@fud.no> <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> Message-ID: <105B7691-6A00-45C0-8098-BDD3F574424F@steffann.nl> Hi Richard, > Trivial on CLI, may not be doable on web without minor updates to > gitweb/gitolite. You will need both filenames. Please stop thinking in solutions, and start thinking in requirements. Oh, and add two other requirements: - No CLI, knowing of filenames or such things must be necessary - A way must be provided for users to clone the RIPE document repository and perform the same analysis as the RIPE NCC offers on their own system Cheers, - Sander From richih.mailinglist at gmail.com Fri Mar 15 22:55:22 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:55:22 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> References: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> Message-ID: On Fri, Mar 15, 2013 at 10:46 PM, Jim Reid wrote: > First, git may well be the flavour-of-the-month as a version control repository/system today. It won't be in the future. What happens then? What always happens: We migrate. I strongly disagree with your assessment that it's "of the month", though. Most if not all major FLOSS projects (which allow GPL software) use git or are migrating to it. Even Microsoft is starting to support it. git will not go away for a long time. And if it does, it will have provided real benefit to everyone within RIPE. > Next, this could force EVERYONE to use some git client. The NCC's supposed to be neutral. It should not get into the game of requiring the community to use specific tools or software. No, it would not. The whois data is maintained within a SQL DB. I don't need SQL to access whois information. Just because data is stored in a specific canonical place does not mean it's the only place. Point in case: Do you know what RIPE NCC's canonical policy document storage is? Do you care as long as you get to access the files via www, ftp, etc? > Just because some people have a git-shaped hammer doesn't mean every problem in the area of version control and document management has to be made to look like a git-shaped nail. While that statement is true in and as of itself, I fail to see how it relates to the discussion at hand. > You also appear to be defining outcomes before the requirements are agreed. Or even clear. Let's first understand what problem needs solved and then decide what's the best way to solve them. That's what we are doing. To arrive at that, we need something to base our discussion on. If I hadn't proposed the above, we would not be having this conversation. Richard From richih.mailinglist at gmail.com Fri Mar 15 22:58:39 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 22:58:39 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <105B7691-6A00-45C0-8098-BDD3F574424F@steffann.nl> References: <5143917A.4070309@fud.no> <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> <105B7691-6A00-45C0-8098-BDD3F574424F@steffann.nl> Message-ID: On Fri, Mar 15, 2013 at 10:54 PM, Sander Steffann wrote: > Please stop thinking in solutions, and start thinking in requirements. I was answering your specific questions, but I see your point. > - No CLI, knowing of filenames or such things must be necessary CLI offers this, you are not forced to use CLI to arrive at this. If you know you want to compare ripe-XXX and ripe-YYY, you have the file names. How could you compare two files without knowing their file names? > - A way must be provided for users to clone the RIPE document repository and perform the same analysis as the RIPE NCC offers on their own system That is one of the pivotal points of my proposal. Please note the anonymous pull I explicitly mention in the proposal. When I say "CLI", I mean "CLI on your own computer on a fully offline clone of all data". -- Richard From aleheux at kobo.com Fri Mar 15 23:01:07 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Fri, 15 Mar 2013 23:01:07 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: Hi, > The canonical and binding format of all documents is plain text in > UTF-8 encoding. > If a document can not reasonably be stored as plain text, > PDF/A-1a[1] will be used. > If any document exists in both plain text and PDF/A-1a, plain text is binding. > Any other form is considered non-binding as soon as a plain text or > PDF/A-1a variant exist. > All legacy documents which are still valid or relevant to current > policies will be transformed within a year of this proposal becoming > policy. > > > The reasoning behind this should be obvious: Ensure that all documents > will be in the most simple-to-parse format now and forever. For policy documents: +1 Other RIPE documents may be graphics-heavy, although most probably won't be. It would be good to have a provision for non-policy documents that just can't be represented in plain text. Alex From sander at steffann.nl Fri Mar 15 23:04:30 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Mar 2013 23:04:30 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: <5143917A.4070309@fud.no> <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> <105B7691-6A00-45C0-8098-BDD3F574424F@steffann.nl> Message-ID: <72C0E71B-72C3-4E3A-8EFF-C3C303CF7C21@steffann.nl> Hi, >> - No CLI, knowing of filenames or such things must be necessary > > CLI offers this, you are not forced to use CLI to arrive at this. Which CLI offers this? Remember: we are not talking about specific implementations of a system like git, we are defining requirements :-) > If you know you want to compare ripe-XXX and ripe-YYY, you have the > file names. How could you compare two files without knowing their file > names? For example with links on the webpage of ripe-XXX. The web page of ripe-554 contains a link 'Updates: ripe-501'. Adding a link 'Compare to ripe-501' would be very useful. >> - A way must be provided for users to clone the RIPE document repository and perform the same analysis as the RIPE NCC offers on their own system > > That is one of the pivotal points of my proposal. Please note the > anonymous pull I explicitly mention in the proposal. When I say "CLI", > I mean "CLI on your own computer on a fully offline clone of all > data". I understand, but we need to specify that without specifying the tool to do it with. That's how you build requirements ;-) Cheers, Sander From richih.mailinglist at gmail.com Fri Mar 15 23:05:20 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 23:05:20 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <5143961D.10205@fud.no> References: <51438C23.3000202@fud.no> <5143961D.10205@fud.no> Message-ID: On Fri, Mar 15, 2013 at 10:43 PM, Tore Anderson wrote: > It was just one example. Another would be ripe-566, which has a couple > of tables. Sure, you can create an ASCII art tables, but doing so and at > the same time everything below 72 characters of width might not be > easiest thing in the world. A future document might want to include some > other figures or other external content which cannot be (easily) > represented in plain text. The various TeX flavors can generate PDF/A. I understand that this would add complexity for people who need to create PDFs. Which may be a benefit overall as this would result in a stronger incentive to use plain text. All this while still allowing easily diffed collaboration on text files in all cases. > Because once that PDF is the authoritative version it's hard for someone > else to come along and make changes to it later. Fair point; see above. > Reasonably, if you keep the amount of markup to a minimum. The point > after all isn't to get RIPE documents that are glitzy AJAX Web2.0 HTML5 > interactive stuff, just to allow for the inclusion of basic figures, > tables, images and a minimum of formatting. Even then, fonts may get lost over time; that will not happen with PDF/A which embeds all fonts. I am not saying we need eternal docs that always look the same, but it would be nice to have and as we are debating redoing things anyway.... Richard From richih.mailinglist at gmail.com Fri Mar 15 23:10:33 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 23:10:33 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: <72C0E71B-72C3-4E3A-8EFF-C3C303CF7C21@steffann.nl> References: <5143917A.4070309@fud.no> <4C405007-AA30-4633-93E1-1D09A5222EE0@steffann.nl> <105B7691-6A00-45C0-8098-BDD3F574424F@steffann.nl> <72C0E71B-72C3-4E3A-8EFF-C3C303CF7C21@steffann.nl> Message-ID: On Fri, Mar 15, 2013 at 11:04 PM, Sander Steffann wrote: > Which CLI offers this? Remember: we are not talking about specific implementations of a system like git, we are defining requirements :-) I was offering solutions within the context of what you asked for, mainly to show that git can do everything you wanted. In requirement-mode, my answer is "yes, I agree" to all your points. > For example with links on the webpage of ripe-XXX. The web page of ripe-554 contains a link 'Updates: ripe-501'. Adding a link 'Compare to ripe-501' would be very useful. Agreed. > I understand, but we need to specify that without specifying the tool to do it with. That's how you build requirements ;-) Again, I was still in answer mode. My reference to anonymous pull is equivalent to the requirement "everyone on earth should have easy access to the raw data" I will add some more: * Easy, quick and reliable way to get all updates * Easy, quick and reliable way to verify local data is OK * Full access to history while off line Richard From aleheux at kobo.com Fri Mar 15 23:11:39 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Fri, 15 Mar 2013 22:11:39 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: Message-ID: <6A970D2A8B029E45826C95E9EEF9317F3691DF5F@koboexch1> Hi, >>It was just one example. Another would be ripe-566, which has a couple >> of tables. Sure, you can create an ASCII art tables, but doing so and at >> the same time everything below 72 characters of width might not be >> easiest thing in the world. A future document might want to include some >> other figures or other external content which cannot be (easily) >> represented in plain text. > >The various TeX flavors can generate PDF/A. I understand that this >would add complexity for people who need to create PDFs. Which may be >a benefit overall as this would result in a stronger incentive to use >plain text. All this while still allowing easily diffed collaboration >on text files in all cases. *if* plain text becomes the authoritative format, the RIPE NCC can then use whatever tools to create whatever formats of policy documents that they deem useful. No need to get dirty and bring TeX into the discussion ;) Alex Le Heux Kobo Inc From jim at rfc1035.com Fri Mar 15 23:13:07 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Mar 2013 22:13:07 +0000 Subject: [ncc-services-wg] git is the answer: now what was the question? In-Reply-To: References: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> Message-ID: <81559A8B-D3A7-4CF3-B49A-235D30587C9F@rfc1035.com> On 15 Mar 2013, at 21:55, Richard Hartmann wrote: >> You also appear to be defining outcomes before the requirements are agreed. Or even clear. Let's first understand what problem needs solved and then decide what's the best way to solve them. > > That's what we are doing. To arrive at that, we need something to base > our discussion on. If I hadn't proposed the above, we would not be > having this conversation. Your emails on this topic are NOT doing that at all. They're doing the very opposite. You've already decided that git is the solution to everything. As yet it's not clear what problem needs fixing. [Or if there's a consensus that this problem does indeed need fixing.] I suggest you focus on that. From richih.mailinglist at gmail.com Fri Mar 15 23:13:01 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 23:13:01 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: On Fri, Mar 15, 2013 at 11:01 PM, Alex Le Heux wrote: > For policy documents: > > +1 > > Other RIPE documents may be graphics-heavy, although most probably won't be. It would be good to have a provision for non-policy documents that just can't be represented in plain text. Wouldn't PDF/A work for them? I mainly care about policy documents, though. If we can start with those, it would be an incredible win for all of RIPE. Richard From richih.mailinglist at gmail.com Fri Mar 15 23:14:34 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 23:14:34 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <6A970D2A8B029E45826C95E9EEF9317F3691DF5F@koboexch1> References: <6A970D2A8B029E45826C95E9EEF9317F3691DF5F@koboexch1> Message-ID: On Fri, Mar 15, 2013 at 11:11 PM, Alex Le Heux wrote: > No need to get dirty and bring TeX into the discussion ;) I am sure watching some poor MS Office person write TeX right before a deadline could be fun. Richard From richih.mailinglist at gmail.com Fri Mar 15 23:17:48 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 15 Mar 2013 23:17:48 +0100 Subject: [ncc-services-wg] git is the answer: now what was the question? In-Reply-To: <81559A8B-D3A7-4CF3-B49A-235D30587C9F@rfc1035.com> References: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> <81559A8B-D3A7-4CF3-B49A-235D30587C9F@rfc1035.com> Message-ID: On Fri, Mar 15, 2013 at 11:13 PM, Jim Reid wrote: > Your emails on this topic are NOT doing that at all. They're doing the very opposite. You've already decided that git is the solution to everything. As yet it's not clear what problem needs fixing. [Or if there's a consensus that this problem does indeed need fixing.] I suggest you focus on that. I stated initially that I was aware that this is the weakest of my proposals. I also agreed to switch over to defining requirements. Do I still expect git to be the solution? Yes. Do I want to dive into a meta-discussion about points I already conceded during a fast-paced discussion? No. Richard From tore at fud.no Fri Mar 15 23:22:36 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Mar 2013 23:22:36 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: <51438C23.3000202@fud.no> <5143961D.10205@fud.no> Message-ID: <51439F2C.7010505@fud.no> * Richard Hartmann > The various TeX flavors can generate PDF/A. I understand that this > would add complexity for people who need to create PDFs. Which may be > a benefit overall as this would result in a stronger incentive to use > plain text. All this while still allowing easily diffed collaboration > on text files in all cases. In this case, the TeX format should be the authoritative one, not PDF. (You can convert HTML to PDF, too.) It's been a while since I wrote anything in TeX, but IIRC it's rather forbidding for someone who's never seen it before. HTML is more approachable. But, never mind about that, if we do it Sander's way and define my preferences as non-specific requirements instead: - For documents that are all text, plaintext is preferred - For documents that are not all text or cannot be easily be represented in plaintext, the alternate format should be chosen based on the following criteria: - It should be open and platform-independent - It should easy for a complete beginner to understand and modify - It should keep any text parts of the document as similar to plaintext as possible (to allow for easy diffing and collaboration) - It should be easy to convert into other formats > Even then, fonts may get lost over time; that will not happen with > PDF/A which embeds all fonts. I don't see any problems with fonts changing. Plaintext doesn't have any concept of fonts either... -- Tore Anderson From jim at rfc1035.com Fri Mar 15 23:32:08 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Mar 2013 22:32:08 +0000 Subject: [ncc-services-wg] let's use git for everything: it can always be changed later In-Reply-To: References: <5143917A.4070309@fud.no> Message-ID: <6793297E-40ED-47EF-8600-6935DDF9E470@rfc1035.com> On 15 Mar 2013, at 21:42, Richard Hartmann wrote: >> That said, while I agree that Git is a very good tool, I'm reluctant to >> micro-manage the NCC by saying ?you MUST use Git? (or any other >> particular tool for that matter). > > I am painfully aware of that. The community is free to shoot this > down, but if it's accepted, it would be possible to change this. Boiling the ocean is also possible. In theory anyway... That doesn't make it a good idea or a sensible use of resources. Policy development is already sclerotic. Now imagine just how difficult it will be for the community to reach consensus on a policy to replace last year's shiny version control fad with next year's model. The potential for rat-holing and shed painting will be off-the-scale scary. Let's not forget backwards compatibility issues and having to keep the old platform(s) running because people can't or won't change the stuff they already use and rely on. Locking in the PDP to particular tools or document formats is also stunningly unwise. It's the sort of thing the ITU does. A policy stating "the NCC must use git" is no different from one which states "the NCC must only use vi" or "the NCC must only write code in Java". I'll repeat what I previously said. First identify the problem that needs solving. Then come up with agreed requirements. Once that's done, trust the NCC to choose the right tools and platforms in consultation with the community to deliver the desired outcome(s). Personally, I think all that's needed is to have proposal versions published in a neutral format -- probably plain text -- which allows for the files to be imported into whatever version control tools and document management systems each individual chooses for themself and presumably fits their needs. Whatever the IETF is doing for RFCs and I-Ds might well be good enough. From job.snijders at atrato.com Fri Mar 15 23:40:10 2013 From: job.snijders at atrato.com (Job Snijders) Date: Fri, 15 Mar 2013 23:40:10 +0100 Subject: [ncc-services-wg] let's use git for everything: it can always be changed later In-Reply-To: <6793297E-40ED-47EF-8600-6935DDF9E470@rfc1035.com> References: <5143917A.4070309@fud.no> <6793297E-40ED-47EF-8600-6935DDF9E470@rfc1035.com> Message-ID: <3438D82A-0A11-4B78-BB5E-25677CC5260E@atrato.com> I agree with what Jim says. - Job On Mar 15, 2013, at 11:32 PM, Jim Reid wrote: > On 15 Mar 2013, at 21:42, Richard Hartmann wrote: > >>> That said, while I agree that Git is a very good tool, I'm reluctant to >>> micro-manage the NCC by saying ?you MUST use Git? (or any other >>> particular tool for that matter). >> >> I am painfully aware of that. The community is free to shoot this >> down, but if it's accepted, it would be possible to change this. > > Boiling the ocean is also possible. In theory anyway... That doesn't make it a good idea or a sensible use of resources. > > Policy development is already sclerotic. Now imagine just how difficult it will be for the community to reach consensus on a policy to replace last year's shiny version control fad with next year's model. The potential for rat-holing and shed painting will be off-the-scale scary. Let's not forget backwards compatibility issues and having to keep the old platform(s) running because people can't or won't change the stuff they already use and rely on. > > Locking in the PDP to particular tools or document formats is also stunningly unwise. It's the sort of thing the ITU does. A policy stating "the NCC must use git" is no different from one which states "the NCC must only use vi" or "the NCC must only write code in Java". > > I'll repeat what I previously said. First identify the problem that needs solving. Then come up with agreed requirements. Once that's done, trust the NCC to choose the right tools and platforms in consultation with the community to deliver the desired outcome(s). > > Personally, I think all that's needed is to have proposal versions published in a neutral format -- probably plain text -- which allows for the files to be imported into whatever version control tools and document management systems each individual chooses for themself and presumably fits their needs. Whatever the IETF is doing for RFCs and I-Ds might well be good enough. > > From jim at rfc1035.com Fri Mar 15 23:52:24 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 15 Mar 2013 22:52:24 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: <4F1B3F70-3539-4363-8113-852A6458A69D@rfc1035.com> Message-ID: On 15 Mar 2013, at 21:55, Richard Hartmann wrote: > On Fri, Mar 15, 2013 at 10:46 PM, Jim Reid wrote: > >> First, git may well be the flavour-of-the-month as a version control repository/system today. It won't be in the future. What happens then? > > What always happens: We migrate. I strongly disagree with your > assessment that it's "of the month", though. I exaggerated (a little) for effect. So shoot me. I'm an Old Fart and have lived through far too much of new version control software snake oil and hype. IMO in a few years git will be as dead as SCCS, RCS, CVS, and subversion are. YMMV. > Most if not all major FLOSS projects (which allow GPL software) use git or are migrating to it. Even Microsoft is starting to support it. git will not go away for a long time. And if it does, it will have provided real benefit to everyone within RIPE. By this argument, we'd do Track Changes in Word because that's what "everybody does". > Point in case: Do you know what RIPE NCC's canonical policy document > storage is? Do you care as long as you get to access the files via > www, ftp, etc? >> Just because some people have a git-shaped hammer doesn't mean every problem in the area of version control and document management has to be made to look like a git-shaped nail. > > While that statement is true in and as of itself, I fail to see how it > relates to the discussion at hand. Because you strongly suggested git was the way to fix something before it's clear what needs fixing or what the requirements are. >> You also appear to be defining outcomes before the requirements are agreed. Or even clear. Let's first understand what problem needs solved and then decide what's the best way to solve them. > > That's what we are doing. To arrive at that, we need something to base > our discussion on. If I hadn't proposed the above, we would not be > having this conversation. So let's stop this meta-discussion and get back to what should be getting discussed: a clear problem statement and identification of requirements. From ebais at a2b-internet.com Sat Mar 16 00:09:36 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Mar 2013 00:09:36 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: <51438C23.3000202@fud.no> <5143961D.10205@fud.no> Message-ID: <004c01ce21d2$2bd04000$8370c000$@a2b-internet.com> Hi Richard, > The various TeX flavors can generate PDF/A. /shiver I was wondering when someone would start about (LA)TeX ... and it didn't even took very long ... I have to agree with Sander, this is something that should start with actual requirements. Currently what I see is someone who is very happy in using CLI, GIT and such to see the difference between all these versions .. and whishing that he would have the output in (LA)TeX, where I'm more a regular Latex kind of guy (fun intended) .. more of a wysiwyg and clicker ... So if the actual end-results need to be published in multiple types of output and that could be done without costing the community an arm and a leg, feel free to write a requirement document (in txt :). One of the things that we would need to avoid imho is that people would have to start publishing PDP proposals in some kind of TeX dialect or anything alike ... or that people would have to get familiar with a CLI and all great GIT options before they would follow what is going on. I'm sure that would work for a select few, but the interaction within the community as is, is already shockingly low. Especially if we want to keep the community open for none-ISP tech savvy people. (think about LEA's or regular enterprises that start to deal with RIPE as their ISP's are running out of v4 and now they need to become an LIR), simplicity to use is key in my opinion and additional interfaces on how to export / filter / Diff etc through the data, is a nice bonus for those that want it. Regards, Erik Bais From ml+ripe-list at x-net.be Sat Mar 16 14:20:22 2013 From: ml+ripe-list at x-net.be (Gerry Demaret) Date: Sat, 16 Mar 2013 14:20:22 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: <51447196.1080202@x-net.be> On 03/15/2013 08:12 PM, Richard Hartmann wrote: > The canonical and binding format of all documents is plain text in > UTF-8 encoding. > If a document can not reasonably be stored as plain text, > PDF/A-1a[1] will be used. > If any document exists in both plain text and PDF/A-1a, plain text is binding. > Any other form is considered non-binding as soon as a plain text or > PDF/A-1a variant exist. > All legacy documents which are still valid or relevant to current > policies will be transformed within a year of this proposal becoming > policy. I would be very happy if this suggestion would turn into a policy, I can agree with the way it is formulated above. That doesn't mean I can't have some remarks which could still be up for discussion. * I feel it would be even better to have a plain text version be mandatory and authoritative for each and every document. We could allow for a PDF/A appendix to documents (or even a full PDF/A version of said document) which really can't do without. * The RFC style guide [1] could be a good base. Replace ASCII with UTF-8, remove the paging requirement and perhaps some other bits and pieces we don't need and I think we could be there. Having very similar guidelines as other major organizations does seem like a big plus to me. As a relative newcomer to all-things-RIPE, I would have expected there to be a policy about document formats already. Either I can't find it or I'm rightfully surprised there currently isn't one at all. Gerry [1] http://www.rfc-editor.org/rfc-style-guide/rfc-style From ml+ripe-list at x-net.be Sat Mar 16 14:35:25 2013 From: ml+ripe-list at x-net.be (Gerry Demaret) Date: Sat, 16 Mar 2013 14:35:25 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: References: Message-ID: <5144751D.5090301@x-net.be> On 03/15/2013 08:12 PM, Richard Hartmann wrote: > The canonical name of all PDPs will be RIPE-PDP-YYYY-NN. > Updated versions will receive suffixes like Internet Drafts, i.e. > -v1, -v2, -v3. > Old-style PDP names of the format YYYY-NN will remain valid, but all > new documentation and communication by RIPE will use the new format. +1 I actually had the exact same thought a few weeks ago, so I guess it wouldn't be a bad thing. > Alternatively, the name of the Working Group may be embedded in all > names, e.g. RIPE-PDP-APWG-YYYY-NN, or RIPE-APWG-PDP-YYYY-NN. I'm not a fan of this alternative. Embedding the WG's name would make the names longer and would mean that either the YYYY-NN part would need to remain globally unique in the RIPE-PDP-* namespace or it wouldn't. Both options could cause confusion since: * RIPE-PDP-APWG-2013-01 and RIPE-PDP-APWG-2013-03 could exist, but perhaps RIPE-PDP-APWG-2013-02 not. I might spend useless time looking for a document that never existed. * Both RIPE-PDP-APWG-2013-01 and RIPE-PDP-AAWG-2013-01 would exist. It might be just me, but those strings confuse my brain. I would prefer to stick with RIPE-PDP-2013-01. Gerry From sander at steffann.nl Sat Mar 16 15:32:42 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 16 Mar 2013 15:32:42 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <5144751D.5090301@x-net.be> References: <5144751D.5090301@x-net.be> Message-ID: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> Hi, > Both options could cause confusion since: > > * RIPE-PDP-APWG-2013-01 and RIPE-PDP-APWG-2013-03 could exist, but > perhaps RIPE-PDP-APWG-2013-02 not. I might spend useless time > looking for a document that never existed. > > * Both RIPE-PDP-APWG-2013-01 and RIPE-PDP-AAWG-2013-01 would exist. > It might be just me, but those strings confuse my brain. I would > prefer to stick with RIPE-PDP-2013-01. I see a benefit in showing the working group, but not so much in prepending RIPE-PDP- to the number. How about 2014-86-APWG for example? Or, if we want to prepend: RIPE-PDP-2014-86-APWG. At least put the WG name after the number. I agree that otherwise it seems to become part of the namespace. - Sander From aleheux at kobo.com Sat Mar 16 16:20:31 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Sat, 16 Mar 2013 15:20:31 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> Message-ID: <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> On 2013-03-16 15:32 , "Sander Steffann" wrote: >Hi, > >> Both options could cause confusion since: >> >> * RIPE-PDP-APWG-2013-01 and RIPE-PDP-APWG-2013-03 could exist, but >> perhaps RIPE-PDP-APWG-2013-02 not. I might spend useless time >> looking for a document that never existed. >> >> * Both RIPE-PDP-APWG-2013-01 and RIPE-PDP-AAWG-2013-01 would exist. >> It might be just me, but those strings confuse my brain. I would >> prefer to stick with RIPE-PDP-2013-01. > >I see a benefit in showing the working group, but not so much in >prepending RIPE-PDP- to the number. How about 2014-86-APWG for example? >Or, if we want to prepend: RIPE-PDP-2014-86-APWG. At least put the WG >name after the number. I agree that otherwise it seems to become part of >the namespace. I think that overloading the name in such a way is only useful if both 2014-86-APWG and 2014-86-NCCSERVICES are possible. If the serial number of a proposal is unique across the different working groups, I don't see a need to include the WG in the name. Otherwise we should also consider including things like the name of the proposer, current stage of the PDP it is in, version, etc, etc :) Alex From pk at DENIC.DE Sat Mar 16 17:03:24 2013 From: pk at DENIC.DE (Peter Koch) Date: Sat, 16 Mar 2013 17:03:24 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: References: Message-ID: <20130316160324.GF13727@x28.adm.denic.de> Andrew, > impact, as they align with our current business practices. Option 3 would > require PI End Users to have a direct contact with the RIPE NCC. As this > would be a new venture for the RIPE NCC, we expect it would be the most > labour intensive of the three options and would have the greatest impact > in terms of resources. could you please clarify whether options (1) and (3) would differ in resource consumption and why? Option (3) makes no indication regarding cost recovery. Setting the legacy resource holder debate aside, is the expectation that option (3) would provide the service free of charge, billed on hours incurred or by a fixed fee? Given that the current charging model is flat, but does not have to remain flat in the future, is a subscription model feasible? (a subscriber is basically a paying customer receiving the same services as a member, whithout having the rights and duties of a member)). -Peter, as an individual From lists-ripe at c4inet.net Sat Mar 16 17:51:39 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sat, 16 Mar 2013 16:51:39 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> References: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> Message-ID: <20130316165139.GA99348@cilantro.c4inet.net> On Sat, Mar 16, 2013 at 03:20:31PM +0000, Alex Le Heux wrote: >I think that overloading the name in such a way is only useful if both >2014-86-APWG and 2014-86-NCCSERVICES are possible. If the serial number of >a proposal is unique across the different working groups, I don't see a >need to include the WG in the name. > >Otherwise we should also consider including things like the name of the >proposer, current stage of the PDP it is in, version, etc, etc :) Or put the metadata in a block at the start, like it is done in RFCs? cheers, Sascha Luck > >Alex > > From richih.mailinglist at gmail.com Sat Mar 16 17:54:35 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 16 Mar 2013 17:54:35 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> References: <5144751D.5090301@x-net.be> <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> Message-ID: On Sat, Mar 16, 2013 at 3:32 PM, Sander Steffann wrote: > I see a benefit in showing the working group, but not so much in prepending RIPE-PDP- to the number. The prefix makes it easy to find the proposal without context. You don't need to know that 2014-86 is a RIPE policy document if you see a reference to it somewhere. You will know and a simple search without context other than the document's name will lead you to the correct place. > How about 2014-86-APWG for example? Or, if we want to prepend: RIPE-PDP-2014-86-APWG. At least put the WG name after the number. I agree that otherwise it seems to become part of the namespace. Appending makes sense, actually. It shows what WG the PDP is in, yet it allows one single sequence to be counted up without arguments about spanning namespaces. Richard From richih.mailinglist at gmail.com Sat Mar 16 17:55:05 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 16 Mar 2013 17:55:05 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <20130316165139.GA99348@cilantro.c4inet.net> References: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> <20130316165139.GA99348@cilantro.c4inet.net> Message-ID: On Sat, Mar 16, 2013 at 5:51 PM, Sascha Luck wrote: > Or put the metadata in a block at the start, like it is done in RFCs? I was just about to reply exactly the same. Richard From gert at space.net Sat Mar 16 18:31:37 2013 From: gert at space.net (Gert Doering) Date: Sat, 16 Mar 2013 18:31:37 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <20130316160324.GF13727@x28.adm.denic.de> References: <20130316160324.GF13727@x28.adm.denic.de> Message-ID: <20130316173137.GB51699@Space.Net> Hi, On Sat, Mar 16, 2013 at 05:03:24PM +0100, Peter Koch wrote: > Option (3) makes no indication regarding cost recovery. Setting the legacy > resource holder debate aside, is the expectation that option (3) would provide > the service free of charge, billed on hours incurred or by a fixed fee? > Given that the current charging model is flat, but does not have to remain > flat in the future, is a subscription model feasible? (a subscriber is > basically a paying customer receiving the same services as a member, > whithout having the rights and duties of a member)). My gut feeling suggests that the "50 EUR per year and network" fee we currently have should cover the certification costs nicely, if we find a way to make it automated for "almost all" cases... Gert Doering -- PI holder, member, ... -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Sat Mar 16 18:33:31 2013 From: gert at space.net (Gert Doering) Date: Sat, 16 Mar 2013 18:33:31 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> References: <5144751D.5090301@x-net.be> <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> Message-ID: <20130316173331.GC51699@Space.Net> Hi, On Sat, Mar 16, 2013 at 03:32:42PM +0100, Sander Steffann wrote: > How about 2014-86-APWG for example? ^^ Someone is getting ambitious, are you...? Gert Doering -- someone's co-chair :-) -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From davidm at futureinquestion.net Sun Mar 17 20:42:04 2013 From: davidm at futureinquestion.net (David Monosov) Date: Sun, 17 Mar 2013 20:42:04 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: <1831051651.20130315213850@devnull.ru> Message-ID: <51461C8C.3000803@futureinquestion.net> Dear ncc-services-wg, Sander, Richard, Such a list published annually would be quite valuable. It appears from multiple posts in recent years both here, in address-policy-wg as well as on members-discuss that the RIPE NCC membership is increasingly keen on being able to rationally participate in budgeting discussion and decisions rather than embrace the operational status quo, and this would serve as a tool to make such discussion considerably more informed. I'd like to second the request for RIPE NCC to comment on the possibility of providing this information in the form of a regular e-mail to ncc-services-wg, on its website, or as an appendix to the annual report. -- Respectfully yours, David Monosov On 03/15/2013 10:22 PM, Sander Steffann wrote: > Hi, > >>> a good idea, but wrong proposal format. >>> Let's ask the Board to do such reports. >> >> Wouldn't the Board simply ask RIPE NCC to provide this list? > > Most likely: yes, unless there is a strong reason not to (legal, financial etc). The board is usually really responsive in my experience. It might not even need to go all the way to the board. Maybe NCC senior management can comment on this? > > Thanks, > Sander > > From dr at cluenet.de Mon Mar 18 10:23:05 2013 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 18 Mar 2013 10:23:05 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> References: <6C7745AA-B13B-45F3-881A-EB1CDBA42788@steffann.nl> <6A970D2A8B029E45826C95E9EEF9317F3691E593@koboexch1> Message-ID: <20130318092305.GA4314@srv03.cluenet.de> On Sat, Mar 16, 2013 at 03:20:31PM +0000, Alex Le Heux wrote: > I think that overloading the name in such a way is only useful if both > 2014-86-APWG and 2014-86-NCCSERVICES are possible. If the serial number of > a proposal is unique across the different working groups, I don't see a > need to include the WG in the name. I find the proposal to be very good, and agree with Alex that no WG should be included, if the serial number is unique anyway. > Otherwise we should also consider including things like the name of the > proposer, current stage of the PDP it is in, version, etc, etc :) Don't forget shoe size. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From stolpe at resilans.se Mon Mar 18 10:32:46 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 18 Mar 2013 10:32:46 +0100 (CET) Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: <51461C8C.3000803@futureinquestion.net> References: <1831051651.20130315213850@devnull.ru> <51461C8C.3000803@futureinquestion.net> Message-ID: Last GM there was (eventually) an activity plan with budget figures so it's a step. I'm sure NCC has all data needed so it shold just be a question of format. On Sun, 17 Mar 2013, David Monosov wrote: > Dear ncc-services-wg, Sander, Richard, > > Such a list published annually would be quite valuable. It appears from multiple > posts in recent years both here, in address-policy-wg as well as on > members-discuss that the RIPE NCC membership is increasingly keen on being able > to rationally participate in budgeting discussion and decisions rather than > embrace the operational status quo, and this would serve as a tool to make such > discussion considerably more informed. > > I'd like to second the request for RIPE NCC to comment on the possibility of > providing this information in the form of a regular e-mail to ncc-services-wg, > on its website, or as an appendix to the annual report. > > -- > Respectfully yours, > > David Monosov > > > On 03/15/2013 10:22 PM, Sander Steffann wrote: >> Hi, >> >>>> a good idea, but wrong proposal format. >>>> Let's ask the Board to do such reports. >>> >>> Wouldn't the Board simply ask RIPE NCC to provide this list? >> >> Most likely: yes, unless there is a strong reason not to (legal, financial etc). The board is usually really responsive in my experience. It might not even need to go all the way to the board. Maybe NCC senior management can comment on this? >> >> Thanks, >> Sander >> >> > > Regards, 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 olaf at NLnetLabs.nl Mon Mar 18 15:16:00 2013 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Mon, 18 Mar 2013 15:16:00 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <51447196.1080202@x-net.be> References: <51447196.1080202@x-net.be> Message-ID: On Mar 16, 2013, at 2:20 PM, Gerry Demaret wrote: > * The RFC style guide [1] could be a good base. Replace ASCII with > UTF-8, remove the paging requirement and perhaps some other bits > and pieces we don't need and I think we could be there. > Having very similar guidelines as other major organizations does > seem like a big plus to me. > [...] > [1] http://www.rfc-editor.org/rfc-style-guide/rfc-style FYI (and since it is fun to sign with a specific job-title), Note that the RFC Editor has just finished gathering requirements on how to evolve the series to deal with i18n issues and inclusion of diagrams (the document is approved for publication as RFC last week). http://tools.ietf.org/html/draft-iab-rfcformatreq-03 The RFC community is probably a little conservative as the RFC Series is an 'archival series'. But that draft documents some pros and cons. The issues that Gerry lists above can be found in the requirements draft. --Olaf Kolkman former ARSE (Acting RFC Series Editor) NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripencc-management at ripe.net Mon Mar 18 15:44:30 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Mon, 18 Mar 2013 15:44:30 +0100 Subject: [ncc-services-wg] [coms] Certifying of PI End User Address Space In-Reply-To: <20130316160324.GF13727@x28.adm.denic.de> References: <20130316160324.GF13727@x28.adm.denic.de> Message-ID: <077529C9-8B26-4E25-B42D-69A6F24E01F9@ripe.net> Dear Peter, To answer your first question, option 3 would require more resources than option 1 because it would require the RIPE NCC to create new processes for handling non-members. In addition to setting up these new processes, the RPKI system and its surrounding applications will need to be extended and maintained to facilitate this new process and allow non-members access. In response to your second question, I?d like to thank you for raising this issue. We cannot say at this moment what cost model option 3 would be subject to because it will be up to the membership to decide this. If option 3 is selected, we will ask for feedback on whether or not the membership expects some sort of cost recovery model, and this issue will need to be reviewed in the next round of charging scheme discussions. Based on that feedback, the Executive Board will provide several different cost models, and the membership will have the opportunity to decide what they feel is best for them. Kind regards, Andrew de la Haye Chief Operations Officer On Mar 16, 2013, at 5:03 PM, Peter Koch wrote: > Andrew, > >> impact, as they align with our current business practices. Option 3 would >> require PI End Users to have a direct contact with the RIPE NCC. As this >> would be a new venture for the RIPE NCC, we expect it would be the most >> labour intensive of the three options and would have the greatest impact >> in terms of resources. > > could you please clarify whether options (1) and (3) would differ in resource > consumption and why? > Option (3) makes no indication regarding cost recovery. Setting the legacy > resource holder debate aside, is the expectation that option (3) would provide > the service free of charge, billed on hours incurred or by a fixed fee? > Given that the current charging model is flat, but does not have to remain > flat in the future, is a subscription model feasible? (a subscriber is > basically a paying customer receiving the same services as a member, > whithout having the rights and duties of a member)). > > -Peter, as an individual > From hank at efes.iucc.ac.il Mon Mar 18 15:48:09 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 18 Mar 2013 16:48:09 +0200 Subject: [ncc-services-wg] End User Assignment Agreement in Word? Message-ID: <5.1.1.6.2.20130318164252.05564e50@efes.iucc.ac.il> I am looking for a RIPE End User Agreement in Word format. The standard format can be found here: http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement or a PDF version can be found here: http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 But RIPE NCC does not provide a Word format which can then be editted by LIRs - sooooo I am looking for someone else who has taken the sample and converted it into Word format. Thanks, Hank From fearghas at gmail.com Mon Mar 18 15:50:30 2013 From: fearghas at gmail.com (Fearghas McKay) Date: Mon, 18 Mar 2013 14:50:30 +0000 Subject: [ncc-services-wg] [coms] Certifying of PI End User Address Space In-Reply-To: <077529C9-8B26-4E25-B42D-69A6F24E01F9@ripe.net> References: <20130316160324.GF13727@x28.adm.denic.de> <077529C9-8B26-4E25-B42D-69A6F24E01F9@ripe.net> Message-ID: <927E04DA-815E-4AC8-93D2-D108A2AB6588@gmail.com> Andrew On 18 Mar 2013, at 14:44, Andrew de la Haye wrote: > To answer your first question, option 3 would require more resources than option 1 because it would require the RIPE NCC to create new processes for handling non-members. The NCC already sure has a large number of people in the dB who are non-members ? Some of whom will hold resources as well as being contacts ? Is the use case so drastically different ? Regards Fearghas From jim at rfc1035.com Mon Mar 18 17:33:16 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 18 Mar 2013 16:33:16 +0000 Subject: [ncc-services-wg] [coms] Certifying of PI End User Address Space In-Reply-To: <927E04DA-815E-4AC8-93D2-D108A2AB6588@gmail.com> References: <20130316160324.GF13727@x28.adm.denic.de> <077529C9-8B26-4E25-B42D-69A6F24E01F9@ripe.net> <927E04DA-815E-4AC8-93D2-D108A2AB6588@gmail.com> Message-ID: <9CFB46EF-91EB-4FFE-AF69-C06E3FA49C9E@rfc1035.com> On 18 Mar 2013, at 14:50, Fearghas McKay wrote: > The NCC already sure has a large number of people in the dB who are non-members ? > > Some of whom will hold resources as well as being contacts ? > > Is the use case so drastically different ? Yes. Maybe. Depends. The costs of maintaining existing DB entries for these non-members are probably negligible. I think. Money may well change hands whenever these non-members get additional services from the NCC such as resource certification. Unless of course the membership decides to absorb the costs of doing that "for free". Even if no charges are levied, NCC staff may need to spend a lot of time verifying who those PI holders are before issuing certification tokens for their resources. Although I have no idea about the extent of those incremental costs, they must surely be more than holding some tuples in the database. It would be helpful to get some upper and lower bounds on what the likely costs would be. I doubt they will be negligible or bankrupt the NCC. The question is where they might sit between these two extremes. We just don't know. I'd like to get this info as input to the discussions so we can hopefully arrive at a consensus on something that won't spring last-minute surprises. From richih.mailinglist at gmail.com Mon Mar 18 19:00:09 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 18 Mar 2013 19:00:09 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: <51447196.1080202@x-net.be> Message-ID: On Mon, Mar 18, 2013 at 3:16 PM, Olaf Kolkman wrote: > > Note that the RFC Editor has just finished gathering requirements on how > to evolve the series to deal with i18n issues and inclusion of diagrams > (the document is approved for publication as RFC last week). > > http://tools.ietf.org/html/draft-iab-rfcformatreq-03 > > The RFC community is probably a little conservative as the RFC Series is > an 'archival series'. But that draft documents some pros and cons. The > issues that Gerry lists above can be found in the requirements draft. > We would see if we can find consensus on this, but personally, I wouldn't mind following the stricter rules of RFCs in policy documents. This would probably mean using nroff or similar as source format, but the actual documents would be text, if paginated inline. Pagination is a problem though. RFCs do not change very often whereas RIPE NCC policy documents do change quite frequently. Diffs between RFCs are uncommon and mostly useless whereas diffs between policy documents are very useful. This inline pagination would result in horribly mangled diffs, every time a line gets added/removed. I see that this point is being addressed in the draft, but there is no conclusion either way, yet. Other than that, after a quick glance, this draft sounds like a very interesting base for discussion and raises all major points. I know from personal experience how sluggish things are working with IDs and RFCs so I guess there is no ETA for releasing actual results? Richard PS: As noted in this thread, trailing whitespaces would allow reflowing quite easily. A line has a trailing whitespace? Reflow at will. It does not? It's static. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at netability.ie Tue Mar 19 00:31:26 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 18 Mar 2013 23:31:26 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: References: Message-ID: <5147A3CE.5080201@netability.ie> On 14/03/2013 11:41, Andrew de la Haye wrote: > Some feedback has pointed out the lack of RIPE Policy on this issue. At > this time, the RIPE NCC is requesting feedback on whether or not resource > certification should expand beyond a RIPE NCC member service. Discussions > about potential RIPE Policy, should this happen, can take place via the > appropriate channels. I've been trying to figure out a diplomatic way of re-approaching this issue, but inspiration has not happened, so the direct way will have to do. RIPE Chair and RIPE NCC Board: there is a problem which you are not dealing with: RIPE community policy and RIPE NCC policy have diverged on an issue which the RIPE Community and a majority of the current RIPE NCC board felt was important enough to require formal policy proposals with community support to back them up. When policy consensus was not achieved in the RIPE Community in the first of what was intended as an entire series of proposals, the RIPE NCC board chose to ignore the lack of consensus and put forward proposals to implement resource certification as an NCC service. I'm not judging the content of the 2008-08 proposal here; nor am I disputing the right of the RIPE NCC membership to vote on issues at general meetings and expect the NCC to implement those decisions; nor is this a criticism of the excellent work of the RIPE NCC staff whose resource certification implementation has been exemplary. My concern is solely that the bottom-up process which validates the RIPE NCC's legitimacy has been ignored in an area of policy where bottom-up process actually matters and where a majority of current RIPE NCC board members have explicitly acknowledged this by their presence on the original RIPE (not RIPE NCC) certification task force and their authorship of policy 2008-08. This is important because the RIPE NCC publicly champions the principle of bottom-up stakeholder support, and it does so in a very prominent way. If it happens that this principle is sidelined - as it has been in this situation - then the RIPE NCC opens itself up to criticism that the bottom-up approach is meaningless and can be circumvented when expedient to do so. Rather than attempting to resolve this situation, the RIPE NCC is pushing forward with plans which will ultimately compound the problem and make it more difficult to resolve in the long term. Again, I don't dispute the legal right of the RIPE NCC to do this if their membership votes for it, but I have serious concerns about the wisdom of doing it because it de-legitimises the RIPE NCC's claims of bottom-up policy support. I'd like to ask for feedback from the RIPE Chair about whether he feels that bottom-up policy is achieved when it is appropriate for the RIPE NCC to create its own policies in situations where the RIPE Community feels that the topic is sufficiently divisive that they cannot form consensus. And if it is appropriate for the RIPE NCC to do this, whether there is any point in continuing to have a RIPE Community and a policy development process. Nick From nick at netability.ie Tue Mar 19 00:56:44 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 18 Mar 2013 23:56:44 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5147A3CE.5080201@netability.ie> References: <5147A3CE.5080201@netability.ie> Message-ID: <5147A9BC.6040505@netability.ie> On 18/03/2013 23:31, Nick Hilliard wrote: > [...] whether he feels > that bottom-up policy is achieved when it is appropriate for the RIPE NCC > to create its own policies ofc, this should have read: "whether he feels it is appropriate for the RIPE NCC to create its own policies..." From hank at efes.iucc.ac.il Tue Mar 19 09:21:53 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 19 Mar 2013 10:21:53 +0200 Subject: [ncc-services-wg] End User Agreement question Message-ID: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> While reviewing the suggested RIPE NCC End User Agreement located at: http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 I see in section 4.3.a: "The End User shall use the Independent Internet Number Resources assigned to it for internal purposes within its own network only." Legal counsel has stated that based on the text provided, any IP address block or ASN assigned could only be used within a company/corporate/organization Intranet and publishing such resource on the global Internet would violate the End User Agreement. Who has used this draft agreement and did you change the text? Strange that no one has spotted this before. Regards, Hank From david.freedman at uk.clara.net Tue Mar 19 10:07:05 2013 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 19 Mar 2013 09:07:05 +0000 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> Message-ID: Hi, We spotted this, I'll have to check the exact wording we use, but I do recall asking to change this to something like : "The End User shall use the Independent Internet Number Resources assigned to it for internal purposes *announced from* its own network only." We did note however, 4.3(c) states: ". The End User shall use the assigned Independent Internet Number Resources solely for the purpose as specified in the request" If the request was to provide for a piece of PI that would be internet routed (I.e the language and detail in the request explained exactly what was being achieved), we observed that the use of 'solely' may produce a conflict. Dave. On 19/03/2013 08:21, "Hank Nussbacher" wrote: >While reviewing the suggested RIPE NCC End User Agreement located at: >http://www.ripe.net/lir-services/resource-management/independent-resources >/independent-assignment-request-and-maintenance-agreement-1 >I see in section 4.3.a: > >"The End User shall use the Independent Internet Number Resources >assigned >to it for internal purposes within its own network only." > >Legal counsel has stated that based on the text provided, any IP address >block or ASN assigned could only be used within a >company/corporate/organization Intranet and publishing such resource on >the >global Internet would violate the End User Agreement. > >Who has used this draft agreement and did you change the text? Strange >that no one has spotted this before. > >Regards, >Hank > > From zsako at iszt.hu Tue Mar 19 10:09:46 2013 From: zsako at iszt.hu (Janos Zsako) Date: Tue, 19 Mar 2013 10:09:46 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> References: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> Message-ID: <51482B5A.2070005@iszt.hu> Dear Hank, > While reviewing the suggested RIPE NCC End User Agreement located at: > http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 > I see in section 4.3.a: > > "The End User shall use the Independent Internet Number Resources assigned to it for internal purposes within its own network only." > > Legal counsel has stated that based on the text provided, any IP address block or ASN assigned could only be used within a company/corporate/organization Intranet and publishing such resource on the global Internet would violate the End User Agreement. I am afraid the word "use" is misinterpreted by the legal counsel. In the context of the End User Agreement, use means use for identifying a host, i.e. the quoted text does not allow the End User to configure an IP address form that range on a host that is not in their own network. This is further clarified in point 4.3.b. I am sure you are aware of all I quote below, but I gathered these to help you in clarifying the issue with the legal counsel. Please note that the End User agreement says in Article 1 Definitions: "Assignment: act by which the RIPE NCC enables the End User to use Independent Internet Number Resources for its internal use. This may involve the publication in the RIPE Database of the End User as the assignee of the respective Internet Number Resources." You can have a look at http://www.ripe.net/ripe/docs/ripe-553 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" The paragraph 2.0.1. says: "Public IP addresses are assigned to be globally unique according to the goals described in Section 3 of this document." and paragraph 3.0.1. says: "Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified." The world wide uniqueness is indispensable for the reliable communication on the Internet (and would definitely not be relevant in case you used the IP addresses in your own network only - see RFC1918). I hope this helps. Best regards, Janos > Who has used this draft agreement and did you change the text? Strange that no one has spotted this before. > > Regards, > Hank > > > From hank at efes.iucc.ac.il Tue Mar 19 10:34:22 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 19 Mar 2013 11:34:22 +0200 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <51482B5A.2070005@iszt.hu> References: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> At 10:09 19/03/2013 +0100, Janos Zsako wrote: >Dear Hank, > >>While reviewing the suggested RIPE NCC End User Agreement located at: >>http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 >>I see in section 4.3.a: >> >>"The End User shall use the Independent Internet Number Resources >>assigned to it for internal purposes within its own network only." >> >>Legal counsel has stated that based on the text provided, any IP address >>block or ASN assigned could only be used within a >>company/corporate/organization Intranet and publishing such resource on >>the global Internet would violate the End User Agreement. > >I am afraid the word "use" is misinterpreted by the legal counsel. >In the context of the End User Agreement, use means use for identifying >a host, i.e. the quoted text does not allow the End User to configure >an IP address form that range on a host that is not in their own network. >This is further clarified in point 4.3.b. In our context the End User wants us to "park" an ASN under our LIR. Your interpretatio of "use" - "used to to identify a host" - does not cover the ASN instance. -Hank >I am sure you are aware of all I quote below, but I gathered these to help >you in clarifying the issue with the legal counsel. > >Please note that the End User agreement says in Article 1 Definitions: >"Assignment: >act by which the RIPE NCC enables the End User to use Independent Internet >Number Resources for its internal use. This may involve the publication in >the RIPE Database of the End User as the assignee of the respective Internet >Number Resources." > >You can have a look at http://www.ripe.net/ripe/docs/ripe-553 >"IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service >Region" > >The paragraph 2.0.1. says: >"Public IP addresses are assigned to be globally unique according to the >goals described in Section 3 of this document." >and paragraph 3.0.1. says: >"Uniqueness: Each public IPv4 address worldwide must be unique. This is an >absolute requirement guaranteeing that every host on the Internet can be >uniquely identified." > >The world wide uniqueness is indispensable for the reliable communication >on the Internet (and would definitely not be relevant in case you used the >IP addresses in your own network only - see RFC1918). > >I hope this helps. > >Best regards, >Janos > >>Who has used this draft agreement and did you change the text? Strange >>that no one has spotted this before. >> >>Regards, >>Hank >> >> From niall.oreilly at ucd.ie Tue Mar 19 11:16:51 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 19 Mar 2013 10:16:51 +0000 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> References: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> Message-ID: <64AE590A-6629-4F1A-A1CE-D57EE2942D61@ucd.ie> On 19 Mar 2013, at 09:34, Hank Nussbacher wrote: > In our context the End User wants us to "park" an ASN under our LIR. Your interpretatio of "use" - "used to to identify a host" - does not cover the ASN instance. Indeed so. The same problem came to light during work with HEAnet to prepare an EUA under which UCD's historical (but not legacy) ASN could be registered. I believe that the NCC's model EUA is overdue for review and that, pending such review, the NCC needs to be ready to give the contracting parties (Sponsoring LIR and End User) in each specific case appropriate freedom to construct an EUA which addresses the needs of that case. /Niall From hank at efes.iucc.ac.il Tue Mar 19 11:29:51 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 19 Mar 2013 12:29:51 +0200 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <64AE590A-6629-4F1A-A1CE-D57EE2942D61@ucd.ie> References: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20130319122735.0554a888@efes.iucc.ac.il> At 10:16 19/03/2013 +0000, Niall O'Reilly wrote: > I believe that the NCC's model EUA is overdue for review and > that, pending > such review, the NCC needs to be ready to give the contracting > parties > (Sponsoring LIR and End User) in each specific case appropriate > freedom to > construct an EUA which addresses the needs of that case. Members are not required to use the EUA as drafted by RIPE NCC. It is merely there as a basis for whatever we might wish to put together based on the policies listed here: http://www.ripe.net/lir-services/resource-management/independent-resources/requirements Regards, -Hank From zsako at iszt.hu Tue Mar 19 11:48:01 2013 From: zsako at iszt.hu (Janos Zsako) Date: Tue, 19 Mar 2013 11:48:01 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> References: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> Message-ID: <51484261.6020801@iszt.hu> Dear Hank, >>> While reviewing the suggested RIPE NCC End User Agreement located at: >>> http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 >>> I see in section 4.3.a: >>> >>> "The End User shall use the Independent Internet Number Resources assigned to it for internal purposes within its own network only." >>> >>> Legal counsel has stated that based on the text provided, any IP address block or ASN assigned could only be used within a company/corporate/organization Intranet and publishing such resource on the global Internet would violate the End User Agreement. >> >> I am afraid the word "use" is misinterpreted by the legal counsel. >> In the context of the End User Agreement, use means use for identifying >> a host, i.e. the quoted text does not allow the End User to configure >> an IP address form that range on a host that is not in their own network. >> This is further clarified in point 4.3.b. > > In our context the End User wants us to "park" an ASN under our LIR. Your interpretatio of "use" - "used to to identify a host" - does not cover the ASN instance. You are right, I am sorry, I was concentrating on IP addresses as for ASNs it makes even less sense to use them within the company only. If we are talking about ASNs, the document we have to look at is: http://www.ripe.net/ripe/docs/ripe-525 (Autonomous System (AS) Number Assignment Policies). Here we find the following (2.0 Assignment Criteria): "In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930." Paragraph 3.0 (Returning AS Numbers) also says: "If an organisation no longer uses the AS Number, it must be returned to the public pool of AS Numbers. The RIPE NCC can then reassign the AS Number to another organisation." Therefore it is clear that an ASN is not intended to be used "internally", moreover, you are not supposed to "park" it. I hope this helps. Best regards, Janos > -Hank > > >> I am sure you are aware of all I quote below, but I gathered these to help >> you in clarifying the issue with the legal counsel. >> >> Please note that the End User agreement says in Article 1 Definitions: >> "Assignment: >> act by which the RIPE NCC enables the End User to use Independent Internet >> Number Resources for its internal use. This may involve the publication in >> the RIPE Database of the End User as the assignee of the respective Internet >> Number Resources." >> >> You can have a look at http://www.ripe.net/ripe/docs/ripe-553 >> "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service >> Region" >> >> The paragraph 2.0.1. says: >> "Public IP addresses are assigned to be globally unique according to the >> goals described in Section 3 of this document." >> and paragraph 3.0.1. says: >> "Uniqueness: Each public IPv4 address worldwide must be unique. This is an >> absolute requirement guaranteeing that every host on the Internet can be >> uniquely identified." >> >> The world wide uniqueness is indispensable for the reliable communication >> on the Internet (and would definitely not be relevant in case you used the >> IP addresses in your own network only - see RFC1918). >> >> I hope this helps. >> >> Best regards, >> Janos >> >>> Who has used this draft agreement and did you change the text? Strange that no one has spotted this before. >>> >>> Regards, >>> Hank >>> >>> > > From nigel at titley.com Tue Mar 19 11:52:29 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 19 Mar 2013 10:52:29 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5147A3CE.5080201@netability.ie> References: <5147A3CE.5080201@netability.ie> Message-ID: <5148436D.2070802@titley.com> On 18/03/2013 23:31, Nick Hilliard wrote: > On 14/03/2013 11:41, Andrew de la Haye wrote: >> Some feedback has pointed out the lack of RIPE Policy on this issue. At >> this time, the RIPE NCC is requesting feedback on whether or not resource >> certification should expand beyond a RIPE NCC member service. Discussions >> about potential RIPE Policy, should this happen, can take place via the >> appropriate channels. > I've been trying to figure out a diplomatic way of re-approaching this > issue, but inspiration has not happened, so the direct way will have to do. > I think that your email is perfectly diplomatic and I'm going to try to respond to it. > I'd like to ask for feedback from the RIPE Chair about whether he feels > that bottom-up policy is achieved when it is appropriate for the RIPE NCC > to create its own policies in situations where the RIPE Community feels > that the topic is sufficiently divisive that they cannot form consensus. > And if it is appropriate for the RIPE NCC to do this, whether there is any > point in continuing to have a RIPE Community and a policy development process. This response isn't strictly speaking an official one. However, as one of the authors of the policy proposal in question, and as Chairman of the RIPE NCC board feel I have a certain amount of personal responsibility for the whole sorry business around certification. Perhaps I can explain my own reasoning, and perhaps the whole process will prove cathartic and I'll be able to start sleeping at nights again. Way back in 2006ish the RIPE community and RIPE NCC pulled together the Certification Authority Task Force (CATF) which had representation from the NCC and the community and which had the task of looking at Certification, its effects on the community and its effects on the NCC. The NCC did a lot of work, mainly on looking at business processes and the effects that certification would have on this, but also did some development work to see what the software might look like. The CATF reported regularly back to the community at RIPE meetings and via email and the community appeared to be generally in favour of the work (at least no or few objections were raised). Other RIRs, most notably APNIC, concentrated on the software development side and APNIC in particular produced a full blown implementation which they made available to their community. The RIPE NCC was continuing to work on business processes and eventually reached the stage where they felt that they had a sufficiently solid framework to start development of trial software. This was notified to the community at a regular report of the CATF, and certification activity was notified to the RIPE NCC membership through the Activity plan. Again, no objections were raised and informal approval from the community was given to continue with the work. Work started and trial software was developed and reported on to the community. The community (and membership) gave informal approval for operational software to be developed and funds were committed. At the same time, and as its final task the CATF wrote a policy proposal (2008-08) to formalise the support from the community. Up to this point, no objections had been received. 2008-08 started to make its way through the PDP and reactions were initially reasonably in favour. Objections mostly centered around the limited proposed life span of certificates and the fact that LIRs who failed to pay their membership fees might find themselves without valid certificates for their address space. Changes were made to the policy proposal to try and accommodate this but there was general agreement that certificates should be roughly tied to the commercial arrangements between the LIR and the RIPE NCC. Meanwhile work continued on the the development of the certification software as detailed in the activity plan. Eventually a form of the proposal was developed which seemed satisfactory to everyone and the policy moved through to the review phase. At this point, things started to go wrong. A small but vociferous group raised issues about the ability of certification and ROAs in particular to enable the RIPE NCC (and by extension, the Dutch government) to "switch off the internet". These concerns are perfectly valid but do depend on balance of probability arguments. In my opinion the PDP handles this sort of of argument very badly: it assumes that all discussion can be rationally argued and arguments of the form of "if condition A were to pertain then B will happen and B is undesirable, but the probability of A happening is a matter of opinion, and opinion varies wildly" don't enter into it. The fact that the arguments were only raised at the review stage didn't help either. Most of the proponents of the proposal had long lost interest in re-stating arguments that had been fought and won many months or even years previously and the discussion started to spiral into destruction. The CATF had long disbanded and as the only member with my name on the policy proposal I was left holding holding this particularly unpleasant orphaned child. I could see no approach but euthanasia and I reluctantly withdrew the policy. This was *my* decision, not the Board's and not the RIPE NCC's. However, this now left the RIPE NCC in a difficult position. They had spent some hundreds of thousands of euros on work which the community had assured them it wanted and which the community now was refusing to support. The membership were now being faced with the nightmare that worries me continuously: that the community asks the NCC to do something which has serious financial implications for the membership and for which there is no means, under the PDP, of refusal. Under the circumstances, the board took the only course sensibly available to them and asked the membership how they wanted to proceed: did they want to continue with certification work (having already spent a substantial amount of money) or did they want the work to stop? A further option of continuing but without the ability to generate ROAs (which is what gives the ability for the certification authority to affect routing) was also offered. You all know the outcome. The membership voted to continue the work and to continue to offer ROAs. The majorities were much slimmer than I would have liked to see, but they were majorities. And the RIPE NCC continued forward with certification work. This is my memory of the events as they happened. The chronology may be slightly off but the events are roughly in order. What have we learned from this? Well, there are a number of important lessons: 1. Don't accept informal expressions of "yes, let's try doing that" from the community, especially where substantial sums are involved. 2. Make sure that for really substantial changes in policy, community approval is obtained *first* (although there is the caveat that this may add unacceptable delays to the work to be done) 3. Try and make sure that the community is fully aware of the implications of what they are proposing 4. And finally don't equate lack of response with approval We have been bitten by 3) before now. Proposal 2007-01 caused an increase in operating costs of 17% when it was implemented and as a direct result, the NCC and board implemented a policy of delivering an impact analysis on all policy proposals. 1) and 2) haven't really come up since 2008-08 but be assured that the NCC and board have been bitten once and are now twice shy. So, after this long email, what do I say to your original question? Well, I passionately believe (and so does the Board and the NCC) in the bottom up process. I believe that it is vital to the growth and development of the internet and although it has its dark side, I don't think we've come up with anything better, so far. However, we have to be aware that it can sometimes move with glacial slowness and the RIPE NCC is running a commercial operation, with bills and staff to be paid. Sometimes a decision has to be made based on community "feeling". And as any working group chair will tell you, working out what that is is why they are paid the big bucks... In this case, having got a go ahead from the membership, however lukewarm, it didn't seem a large step to add certificates for PI as well as PA. Certification is one where the decision might have been made differently if that measure of feeling had been different, if people had looked up for their laptops in the working group and actually debated the issues *early on*. As it happened, the real debate only started to happen years after the money had been spent, and the membership (whose money it is) deserved a say in how to proceed. That's why I handled it like I did. And in similar circumstances I'd probably do it the same way again. Now, I'm going to have a nice cup of tea and get back to my day job. Nigel From nigel at titley.com Tue Mar 19 12:32:26 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 19 Mar 2013 11:32:26 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: Message-ID: <51484CCA.6030307@titley.com> Richard, On 15/03/2013 19:13, Richard Hartmann wrote: > Dear all, > > this is the fifth suggestion: > > > RIPE will create a yearly list of all services it provides to > members or the general public > We already make most of the information that is being requested in this proposal available in the RIPE NCC Annual Report, Activity Plan and the website, although it may not be quite in the format that is being proposed. One of the RIPE NCC Executive Board's functions is to check the costs and benefits of all RIPE NCC expenditures that are included in the Activity Plan. Therefore, we'll discuss this proposal at the Board meeting on the 26 March 2013 and make a decision on if and how this information could be better presented. Just one slight caveat, although the information is certainly available, producing it on a monthly basis in the form requested will add reporting overheads that might be deemed excessive. All the best Nigel From richih.mailinglist at gmail.com Tue Mar 19 12:51:31 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 19 Mar 2013 12:51:31 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: <51484CCA.6030307@titley.com> References: <51484CCA.6030307@titley.com> Message-ID: On Tue, Mar 19, 2013 at 12:32 PM, Nigel Titley wrote: > We already make most of the information that is being requested in this > proposal available in the RIPE NCC Annual Report, Activity Plan and the > website, although it may not be quite in the format that is being proposed. That's the point; this list would be the one canonical place to learn about those services. Of course, this list could be included in existing publications, this may even be preferable. This proposal lists requirements only, RIPE NCC is welcome to implement them as they see fit. > Therefore, we'll discuss this proposal at the Board meeting on the 26 March > 2013 and make a decision on if and how this information could be better > presented. That is great to hear. From your board POV, do you think it would make sense to still codify the requirement even if you decide to produce this list anyway? >From my community POV, I think it makes sense to make sure the service does not go away and will always fulfill a certain minimum. > Just one slight caveat, although the information is certainly available, > producing it on a monthly basis in the form requested will add reporting > overheads that might be deemed excessive. I proposed yearly, not monthly, reports. Thanks, Richard PS: FYI, I am planning to write new versions of all five proposals towards the end of the week to allow for more feedback. From nigel at titley.com Tue Mar 19 12:57:39 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 19 Mar 2013 11:57:39 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: <51484CCA.6030307@titley.com> Message-ID: <514852B3.9030006@titley.com> On 19/03/2013 11:51, Richard Hartmann wrote: > On Tue, Mar 19, 2013 at 12:32 PM, Nigel Titley wrote: > > >> We already make most of the information that is being requested in this >> proposal available in the RIPE NCC Annual Report, Activity Plan and the >> website, although it may not be quite in the format that is being proposed. > That's the point; this list would be the one canonical place to learn > about those services. Of course, this list could be included in > existing publications, this may even be preferable. This proposal > lists requirements only, RIPE NCC is welcome to implement them as they > see fit. OK > >> Therefore, we'll discuss this proposal at the Board meeting on the 26 March >> 2013 and make a decision on if and how this information could be better >> presented. > That is great to hear. From your board POV, do you think it would make > sense to still codify the requirement even if you decide to produce > this list anyway? > > >From my community POV, I think it makes sense to make sure the service > does not go away and will always fulfill a certain minimum. Yes, agreed. > > >> Just one slight caveat, although the information is certainly available, >> producing it on a monthly basis in the form requested will add reporting >> overheads that might be deemed excessive. > I proposed yearly, not monthly, reports. Sorry about that.... must have missed the frequency. Yearly would certainly nicely overlay what we already produce in the activity plan. All the best Nigel From richih.mailinglist at gmail.com Tue Mar 19 13:30:37 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 19 Mar 2013 13:30:37 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: <514852B3.9030006@titley.com> References: <51484CCA.6030307@titley.com> <514852B3.9030006@titley.com> Message-ID: On Tue, Mar 19, 2013 at 12:57 PM, Nigel Titley wrote: >> >From my community POV, I think it makes sense to make sure the service >> does not go away and will always fulfill a certain minimum. > > Yes, agreed. Great. > Sorry about that.... must have missed the frequency. Yearly would certainly > nicely overlay what we already produce in the activity plan. No worries; the fact that it's yearly is not exactly a coincidence, btw ;) Richard From Woeber at CC.UniVie.ac.at Tue Mar 19 13:41:36 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 19 Mar 2013 13:41:36 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> References: <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> Message-ID: <51485D00.5020904@CC.UniVie.ac.at> Hank Nussbacher wrote: > At 10:09 19/03/2013 +0100, Janos Zsako wrote: > >> Dear Hank, >> >>> While reviewing the suggested RIPE NCC End User Agreement located at: >>> http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 >>> >>> I see in section 4.3.a: >>> >>> "The End User shall use the Independent Internet Number Resources >>> assigned to it for internal purposes within its own network only." >>> >>> Legal counsel has stated that based on the text provided, any IP >>> address block or ASN assigned could only be used within a >>> company/corporate/organization Intranet and publishing such resource >>> on the global Internet would violate the End User Agreement. >> >> >> I am afraid the word "use" is misinterpreted by the legal counsel. >> In the context of the End User Agreement, use means use for identifying >> a host, i.e. the quoted text does not allow the End User to configure >> an IP address form that range on a host that is not in their own network. >> This is further clarified in point 4.3.b. > > > In our context the End User wants us to "park" an ASN under our LIR. > Your interpretatio of "use" - "used to to identify a host" - does not > cover the ASN instance. I do understand now that an AS# is a different story, but for completeness coming back to the general question... IIRC, the language used was chosen to make it clear, that PI space can not be divided up into smaller pieces and forwarded to other entities for use; in order to prevent operating an LIR out of PI space, rather than PA space. > -Hank Wilfried. >> I am sure you are aware of all I quote below, but I gathered these to >> help >> you in clarifying the issue with the legal counsel. >> >> Please note that the End User agreement says in Article 1 Definitions: >> "Assignment: >> act by which the RIPE NCC enables the End User to use Independent >> Internet >> Number Resources for its internal use. This may involve the >> publication in >> the RIPE Database of the End User as the assignee of the respective >> Internet >> Number Resources." >> >> You can have a look at http://www.ripe.net/ripe/docs/ripe-553 >> "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service >> Region" >> >> The paragraph 2.0.1. says: >> "Public IP addresses are assigned to be globally unique according to the >> goals described in Section 3 of this document." >> and paragraph 3.0.1. says: >> "Uniqueness: Each public IPv4 address worldwide must be unique. This >> is an >> absolute requirement guaranteeing that every host on the Internet can be >> uniquely identified." >> >> The world wide uniqueness is indispensable for the reliable communication >> on the Internet (and would definitely not be relevant in case you used >> the >> IP addresses in your own network only - see RFC1918). >> >> I hope this helps. >> >> Best regards, >> Janos >> >>> Who has used this draft agreement and did you change the text? >>> Strange that no one has spotted this before. >>> >>> Regards, >>> Hank >>> >>> > > From hank at efes.iucc.ac.il Tue Mar 19 15:39:12 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 19 Mar 2013 16:39:12 +0200 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <51484261.6020801@iszt.hu> References: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> At 11:48 19/03/2013 +0100, Janos Zsako wrote: >>In our context the End User wants us to "park" an ASN under our >>LIR. Your interpretatio of "use" - "used to to identify a host" - does >>not cover the ASN instance. > >Therefore it is clear that an ASN is not intended to be used "internally", >moreover, >you are not supposed to "park" it. Obviously you did not understand what I meant by "park". There are many resources out there - listed in the RIPE whois DB, actively being used, announced and routed on the Internet, but due to historical reasons, those resources are not listed under any LIR - they are just free hanging. RIPE NCC has been sending out hundreds (thousands?) of emails to all those "hanging" resources (mainly historical ones) - informing them that the resource has to be listed under a LIR and if not, it will be revoked. For lack of a better term, for a resource that exists, and is being used , and merely needs to be "assigned" to some LIR, I have used the term " to park". Regards, Hank From zsako at iszt.hu Tue Mar 19 16:20:06 2013 From: zsako at iszt.hu (Janos Zsako) Date: Tue, 19 Mar 2013 16:20:06 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> References: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> Message-ID: <51488226.3020200@iszt.hu> Dear Hank, >>> In our context the End User wants us to "park" an ASN under our LIR. Your interpretatio of "use" - "used to to identify a host" - does not cover the ASN instance. >> >> Therefore it is clear that an ASN is not intended to be used "internally", moreover, >> you are not supposed to "park" it. > > Obviously you did not understand what I meant by "park". You are right, thank you for the explanation. I had the impression that "parking" implied also that it will not be used (like parking a car: leave it somewhere while you do not use it). Anyway, it is clear that ASNs are also not meant to be used internally, as the legal counsel interpreted the wording used in the EUA. Best regards, Janos > There are many resources out there - listed in the RIPE whois DB, actively being used, announced and routed on the Internet, but due to historical reasons, those resources are not listed under any LIR - they are just free hanging. RIPE NCC has been sending out hundreds (thousands?) of emails to all those "hanging" resources (mainly historical ones) - informing them that the resource has to be listed under a LIR and if not, it will be revoked. For lack of a better term, for a resource that exists, and is being used , and merely needs to be "assigned" to some LIR, I have used the term " to park". > > Regards, > Hank > > From Woeber at CC.UniVie.ac.at Tue Mar 19 16:51:34 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 19 Mar 2013 16:51:34 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <51488226.3020200@iszt.hu> References: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> <51488226.3020200@iszt.hu> Message-ID: <51488986.9090401@CC.UniVie.ac.at> Janos Zsako wrote: > Dear Hank, > >>>> In our context the End User wants us to "park" an ASN under our >>>> LIR. Your interpretatio of "use" - "used to to identify a host" - >>>> does not cover the ASN instance. >>> >>> >>> Therefore it is clear that an ASN is not intended to be used >>> "internally", moreover, >>> you are not supposed to "park" it. >> >> >> Obviously you did not understand what I meant by "park". > > > You are right, thank you for the explanation. I had the impression that > "parking" implied also that it will not be used (like parking a car: > leave it somewhere while you do not use it). ...or parking a domain for later re-sale. That was *my* association and interpretation of the use of "park". :-) Wilfried. > Anyway, it is clear that ASNs are also not meant to be used internally, > as the legal counsel interpreted the wording used in the EUA. > > Best regards, > Janos > >> There are many resources out there - listed in the RIPE whois DB, >> actively being used, announced and routed on the Internet, but due to >> historical reasons, those resources are not listed under any LIR - >> they are just free hanging. RIPE NCC has been sending out hundreds >> (thousands?) of emails to all those "hanging" resources (mainly >> historical ones) - informing them that the resource has to be listed >> under a LIR and if not, it will be revoked. For lack of a better >> term, for a resource that exists, and is being used , and merely needs >> to be "assigned" to some LIR, I have used the term " to park". >> >> Regards, >> Hank >> >> > From kranjbar at ripe.net Tue Mar 19 17:29:53 2013 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 19 Mar 2013 17:29:53 +0100 Subject: [ncc-services-wg] Soft launch of "abuse-c:", ripe-563: Improving Abuse Contact Information Message-ID: [Apologies for duplicate emails] Dear Colleagues, RIPE NCC has initiated a soft launch of phase one of RIPE Policy 563: "Abuse Contact Management in the RIPE Database". All facilities to provide abuse contact information for organisations registered in the RIPE Database are be in production state. Please see the announcement sent earlier to the RIPE Anti-Abuse Working Group mailing list (http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2013-March/002226.html). Kind Regards, Kaveh Ranjbar Database Group Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr at cluenet.de Wed Mar 20 11:21:08 2013 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 20 Mar 2013 11:21:08 +0100 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5148436D.2070802@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> Message-ID: <20130320102108.GA32057@srv03.cluenet.de> On Tue, Mar 19, 2013 at 10:52:29AM +0000, Nigel Titley wrote: > At this point, things started to go wrong. A small but vociferous group > raised issues about the ability of certification and ROAs in particular to > enable the RIPE NCC (and by extension, the Dutch government) to "switch off > the internet". These concerns are perfectly valid but do depend on balance > of probability arguments. In my opinion the PDP handles this sort of of > argument very badly: it assumes that all discussion can be rationally > argued and arguments of the form of "if condition A were to pertain then B > will happen and B is undesirable, but the probability of A happening is a > matter of opinion, and opinion varies wildly" don't enter into it. Yes. I guess that's the same about the safety of atomic energy. There were (and still are) many people claiming that the probability of Chernobyl and Fukushima happening is very low, but the problem is that IF it happens, the results are devastating, at least for those impacted. Looks like we first have to suffer before re-considering in this case as well. > The fact that the arguments were only raised at the review stage didn't > help either. > Most of the proponents of the proposal had long lost interest in re-stating > arguments that had been fought and won many months or even years previously > and the discussion started to spiral into destruction. The arguments got rehashed in the wider "secure routing" context since many many years. The dangers have been discussed at length. People probably got tired of rehashing them again in the RIPE community, given that they are "common wisdom". And/or hoped that this effort will die off due to "no interest" or "no money". Unfortunately it didn't. > However, this now left the RIPE NCC in a difficult position. They had spent > some hundreds of thousands of euros on work which the community had assured > them it wanted and which the community now was refusing to support. That's the thing with research and proof-of-concepts. There is no guarrantee that it will move to production phase. What's happening here is what is called "go-minded" in aviation. Just that you are on approach, doesn't mean you're going to actually land. In fact, it's being trained that every approach leads into execution of a missed approach procedure at decision altitude/height UNLESS every parameter really indicates that it's safe to land. Very bad accidents have happend (and still continue to happen) because folks at the yoke/stick are "go-minded" and try to rescue an approach (or in this case, continue a project without broad backing of those affected). IMHO, the pilot monitoring (RIPE community) has called out "go around!" late (at decision altitude), but soon enough. Substantial concerns have not been properly addressed and dangers mitigated. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From nigel at titley.com Wed Mar 20 12:09:16 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 20 Mar 2013 11:09:16 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <20130320102108.GA32057@srv03.cluenet.de> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <20130320102108.GA32057@srv03.cluenet.de> Message-ID: <514998DC.4050408@titley.com> On 20/03/2013 10:21, Daniel Roesen wrote: > That's the thing with research and proof-of-concepts. There is no > guarrantee that it will move to production phase. What's happening > here is what is called "go-minded" in aviation. Just that you are on > approach, doesn't mean you're going to actually land. In fact, it's > being trained that every approach leads into execution of a missed > approach procedure at decision altitude/height UNLESS every parameter > really indicates that it's safe to land. Very bad accidents have > happend (and still continue to happen) because folks at the yoke/stick > are "go-minded" and try to rescue an approach (or in this case, > continue a project without broad backing of those affected). IMHO, the > pilot monitoring (RIPE community) has called out "go around!" late (at > decision altitude), but soon enough. To continue the analogy though, the aircrew in this case thought that the dangers were worth risking but still felt it worth while asking the airplane owners (some of who were on board) whether they wanted to take the risk of landing. The passengers and the folks on the ground were too busy shouting at each other for any sensible decision to be made. Nigel From dr at cluenet.de Wed Mar 20 12:48:42 2013 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 20 Mar 2013 12:48:42 +0100 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <514998DC.4050408@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <20130320102108.GA32057@srv03.cluenet.de> <514998DC.4050408@titley.com> Message-ID: <20130320114842.GA7114@srv03.cluenet.de> On Wed, Mar 20, 2013 at 11:09:16AM +0000, Nigel Titley wrote: > On 20/03/2013 10:21, Daniel Roesen wrote: >> That's the thing with research and proof-of-concepts. There is no >> guarrantee that it will move to production phase. What's happening here is >> what is called "go-minded" in aviation. Just that you are on approach, >> doesn't mean you're going to actually land. In fact, it's being trained >> that every approach leads into execution of a missed approach procedure at >> decision altitude/height UNLESS every parameter really indicates that it's >> safe to land. Very bad accidents have happend (and still continue to >> happen) because folks at the yoke/stick are "go-minded" and try to rescue >> an approach (or in this case, continue a project without broad backing of >> those affected). IMHO, the pilot monitoring (RIPE community) has called >> out "go around!" late (at decision altitude), but soon enough. > > To continue the analogy though, the aircrew in this case thought that the > dangers were worth risking but still felt it worth while asking the > airplane owners (some of who were on board) whether they wanted to take the > risk of landing. The passengers and the folks on the ground were too busy > shouting at each other for any sensible decision to be made. Not really. The aircrew comprises of the pilot flying (NCC) and pilot monitoring (RIPE community). If either one calls out "go around!", a missed approach is executed. Too bad in this case the veto (no consensus in vafor _is_ a factual veto in PDP) was ignored by the pilot flying. Instead of following good CRM procedures and listening to the pilot monitoring, he called the aircraft owners. What happens in that kind of scenarios then can be read up here: http://avherald.com/h?article=429ec5fa Regarding the RIPE community only as "passengers" would be troublesome to me. The RIPE community is part of the aircrew, in fact the "pilot monitoring". The aircraft owner thought the risk was worth taking, and the pilot flying adopted that opinion being bound by it, while the pilot monitoring vetoed but was ignored. In aviation, that's called a complete breakdown of CRM (crew resource management) and utterly bad airmanship. :) http://en.wikipedia.org/wiki/Crew_resource_management#United_Airlines_Flight_232 and following sections. I guess we differ in our interpretation of the role of the RIPE community in that analogy. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From nigel at titley.com Wed Mar 20 13:00:16 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 20 Mar 2013 12:00:16 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <20130320114842.GA7114@srv03.cluenet.de> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <20130320102108.GA32057@srv03.cluenet.de> <514998DC.4050408@titley.com> <20130320114842.GA7114@srv03.cluenet.de> Message-ID: <5149A4D0.403@titley.com> On 20/03/2013 11:48, Daniel Roesen wrote: > On Wed, Mar 20, 2013 at 11:09:16AM +0000, Nigel Titley wrote: > Not really. The aircrew comprises of the pilot flying (NCC) and > pilot monitoring (RIPE community). If either one calls out "go around!", a > missed approach is executed. Too bad in this case the veto (no consensus > in vafor _is_ a factual veto in PDP) was ignored by the pilot flying. > Instead of following good CRM procedures and listening to the pilot > monitoring, he called the aircraft owners. What happens in that kind of > scenarios then can be read up here: http://avherald.com/h?article=429ec5fa > > Regarding the RIPE community only as "passengers" would be troublesome > to me. The RIPE community is part of the aircrew, in fact the "pilot > monitoring". The aircraft owner thought the risk was worth taking, > and the pilot flying adopted that opinion being bound by it, while > the pilot monitoring vetoed but was ignored. In aviation, that's called > a complete breakdown of CRM (crew resource management) and utterly > bad airmanship. :) > > http://en.wikipedia.org/wiki/Crew_resource_management#United_Airlines_Flight_232 > and following sections. > > I guess we differ in our interpretation of the role of the RIPE > community in that analogy. > I suspect you may be right. And I also suspect that this analogy has been stretched a little too far. Your point is taken though. All the best Nigel From nick at netability.ie Wed Mar 20 18:10:32 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 20 Mar 2013 17:10:32 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5148436D.2070802@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> Message-ID: <5149ED88.9040602@netability.ie> Nigel, Thanks for replying. I had hoped - and still hope - for a reply from the RIPE chair (not the RIPE NCC chair) because I believe this to be a matter of some importance to the RIPE Community. I don't want to get into an analysis of why and how 2008-08 failed, but I do think it's worth noting that the razor-thin majority vote in the Sep 2011 RIPE NCC General Meeting suggests that there was and is substantially more community dissent about this than you admit in your reply. This was clear prior to the GM vote, given the scale of the fire storm which erupted over 2008-08, mid 2011. > continuously: that the community asks the NCC to do something which has > serious financial implications for the membership and for which there is no > means, under the PDP, of refusal. Research into resource certification was requested by the community via the task force, not via the PDP. The PDP later returned a result: that the issue was highly divisive. It wasn't a helpful result from the point of view of moving resource certification forward, and the NCC board chose to ignore it. > Under the circumstances, the board took the only course sensibly > available to them and asked the membership how they wanted to proceed: This wasn't the only course of action sensibly available, imo - but it was a course of action that had a significant risk of policy divergence which has now occurred. > So, after this long email, what do I say to your original question? Well, I > passionately believe (and so does the Board and the NCC) in the bottom up > process [...] > In this case, having got a go ahead from the membership, however > lukewarm, it didn't seem a large step to add certificates for PI as well > as PA. At least there was an attempt to engage with the community regarding PA blocks, even if it produced a frustrating result. For PI blocks, there has been no attempt to engage with the community. I don't understand how a complete lack of engagement with the RIPE Community on this issue is compatible with the bottom up process. By pressing ahead with these plans, the RIPE NCC board is sending a clear signal that it is prepared to ignore the bottom-up process when expedient to do so. I believe that this is deeply harmful to the RIPE community and ultimately to the RIPE NCC. Nick From nigel at titley.com Wed Mar 20 18:56:57 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 20 Mar 2013 17:56:57 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5149ED88.9040602@netability.ie> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> Message-ID: <5149F869.6090309@titley.com> Nick, On 20/03/2013 17:10, Nick Hilliard wrote: > Nigel, > > Thanks for replying. I had hoped - and still hope - for a reply from the > RIPE chair (not the RIPE NCC chair) because I believe this to be a matter > of some importance to the RIPE Community. I am sure that Rob will be replying in due course. I have urged him to do so. > > I don't want to get into an analysis of why and how 2008-08 failed, but I > do think it's worth noting that the razor-thin majority vote in the Sep > 2011 RIPE NCC General Meeting suggests that there was and is substantially > more community dissent about this than you admit in your reply. This was > clear prior to the GM vote, given the scale of the fire storm which erupted > over 2008-08, mid 2011. I did actually point out that the majority vote was far less than I would have hoped. > > > Research into resource certification was requested by the community via the > task force, not via the PDP. The PDP later returned a result: that the > issue was highly divisive. It wasn't a helpful result from the point of > view of moving resource certification forward, and the NCC board chose to > ignore it. No real opposition to to resource certification appeared until the end of the review stage of the PDP, in fact the PDP was nearly complete. At this point I had discussions with one of the opponents of the proposal, who admitted that he hadn't been following the PDP and didn't know how it worked anyway, but that he was opposed to certification. I pointed out to him that it was possible to raise objections, as late in the process as it was. I did this because I believe in the open process. The result was a firestorm indeed... many people suddenly woke up and started reiterating arguments that had been settled months or years earlier. I watched the process with horror, not because I had a particularly vested interest in the issue of certification (to be frank by this stage I would have liked to see it buried in a deep hole in the ground) but because I saw the community tearing itself apart. > > This wasn't the only course of action sensibly available, imo - but it was > a course of action that had a significant risk of policy divergence which > has now occurred. That is where we have to agree to differ. The board has a primary responsibility to the NCC membership, to ensure that the NCC continues as a financially viable organisation. As I pointed out in my previous email the decision to withdraw the proposal was mine and not the RIPE NCCs or the Board's. > > > At least there was an attempt to engage with the community regarding PA > blocks, even if it produced a frustrating result. > > For PI blocks, there has been no attempt to engage with the community. I > don't understand how a complete lack of engagement with the RIPE Community > on this issue is compatible with the bottom up process. Subsequent discussion on the list (some as recently as last week) indicated that now we had certification, extending it to PI seemed a minor step. > > By pressing ahead with these plans, the RIPE NCC board is sending a clear > signal that it is prepared to ignore the bottom-up process when expedient > to do so. I believe that this is deeply harmful to the RIPE community and > ultimately to the RIPE NCC. Just as a matter of interest, could I refer you to the proposal text that Axel sent out? "Following approximately six weeks of discussion (ending on 30 March 2013), the Executive Board will consider feedback from the list and propose options on moving forward on this matter which will be properly communicated." And looking through the email thread I've spotted one objection (yours), several expressions of approval and one who said that RPKI was outside policy. Just to reiterate. The NCC and Board *does* listen to the Members (and also the community). I think we've demonstrated that time and time again. I've tried to show how this one particular case was a very difficult one and how I tried to cut the Gordian knot with which we (the community, the members and the RIPE NCC) had tied ourselves up and I'm sorry you disagree with the way that was done. I can't really say much more and I look forward to discussing this with you in Dublin over a Guinness. Nigel From fw at deneb.enyo.de Wed Mar 20 20:10:27 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 20 Mar 2013 20:10:27 +0100 Subject: [ncc-services-wg] End User Agreement question In-Reply-To: <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> (Hank Nussbacher's message of "Tue, 19 Mar 2013 16:39:12 +0200") References: <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319101548.01f2db98@efes.iucc.ac.il> <5.1.1.6.2.20130319113243.01ee35d8@efes.iucc.ac.il> <5.1.1.6.2.20130319163404.054bb030@efes.iucc.ac.il> Message-ID: <87obedubto.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > For lack of a better term, for a resource > that exists, and is being used , and merely needs to be "assigned" to > some LIR, I have used the term " to park". I noticed that lack as well, but I usually refer to "sponsoring LIRs". From lists-ripe at c4inet.net Wed Mar 20 21:19:07 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 20 Mar 2013 20:19:07 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5149F869.6090309@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> Message-ID: <20130320201907.GA23187@cilantro.c4inet.net> Hi Nigel, On Wed, Mar 20, 2013 at 05:56:57PM +0000, Nigel Titley wrote: >And looking through the email thread I've spotted one objection >(yours), several expressions of approval and one who said that RPKI >was outside policy. That was me, IIRC. I've changed my mind, though, and would like to withdraw that assertion, see also below... >Just to reiterate. The NCC and Board *does* listen to the Members >(and also the community). I think we've demonstrated that time and I think the debate has now become more fundamental, viz whether the NCC should be constrained/supported by policy in all it does. I tend to agree that it should... cheers, Sascha Luck From nick at netability.ie Thu Mar 21 01:42:37 2013 From: nick at netability.ie (Nick Hilliard) Date: Thu, 21 Mar 2013 00:42:37 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <5149F869.6090309@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> Message-ID: <514A577D.3080208@netability.ie> On 20/03/2013 17:56, Nigel Titley wrote: > Just as a matter of interest, could I refer you to the proposal text that > Axel sent out? > > "Following approximately six weeks of discussion (ending on > 30 March 2013), the Executive Board will consider feedback from the list > and propose options on moving forward on this matter which will be > properly communicated." I read Axel's email carefully before sending my reply of February 11. He presented a proposal to choose between three different options for implementing RPKI for PI blocks. This is not bottom-up community stuff. It is presenting a foregone policy decision to the community and soliciting input on its implementation. My reply was firmly outside the context of the input that the RIPE NCC was soliciting. The RIPE community and the RIPE PDP were sidelined 18 months ago by the NCC because it seemed like the least inconvenient option. If the NCC proceeds with plans to roll out RPKI/PI in the absence of RIPE community policy, we will then have a firmly established precedent for the RIPE NCC to ignore the RIPE community on issues which should rightly be handled as RIPE policy. I believe this to be extremely harmful and that it sets a terrible example. We have a mechanism for dealing with RIPE policy. It may not be perfect, but it has full community support and we accept that it is generally a good basis for handling policy issues. If the process has problems such that difficult issues like resource certification lead to stalemate, then either the PDP needs to be re-examined or else the issues are truly too contentious to be implemented. Sidelining the PDP because it might produce the wrong result is not the way to deal with this situation. If the PDP needs to be fixed, then let us fix it. Nick From millnert at gmail.com Thu Mar 21 12:15:02 2013 From: millnert at gmail.com (Martin Millnert) Date: Thu, 21 Mar 2013 12:15:02 +0100 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <514A577D.3080208@netability.ie> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> Message-ID: <1363864502.5379.20.camel@galileo.millnert.se> Hi, [Internet Citizen hat on] On Thu, 2013-03-21 at 00:42 +0000, Nick Hilliard wrote: > We have a mechanism for dealing with RIPE policy. It may not be perfect, > but it has full community support and we accept that it is generally a good > basis for handling policy issues. If the process has problems such that > difficult issues like resource certification lead to stalemate, then either > the PDP needs to be re-examined or else the issues are truly too > contentious to be implemented. > > Sidelining the PDP because it might produce the wrong result is not the way > to deal with this situation. If the PDP needs to be fixed, then let us fix it. > (~Specific to RPKI) I agree with nick and can openly admit to being part of the small(*) but vocal opposition to 2008-08. I apologize for learning about the topic late, but as soon as I did (2010) and grasped the gravity of the implications it *will* bring (to me, it's a fact), I did my internet citizenry duty ~best I could. [ *A major problem is the topic is extremely complex and multi-dimensional, and most people who you talk to about it, and even make them understand, don't know where to turn to discuss it. RIPE Policy seems a difficult, perhaps bureaucratic beast at first, to most. A friend on IRC asked: "where do we discuss open internet questions?" Is RIPE this forum? RIPE certainly goes around in ~IGF conferences claiming to be representing us somehow, today...] This brings us to the general problem here: In which way is the RIPE NCC (Inc.) basing its monopoly integer registration operation on the internet at large, rather than its paying members? There's some argument that a service may or may not be subject for policy, such as measurement services, atlas, etc. Or that the RIPE DB is not. To me it's absolutely obvious and clear that matters with implications for not just internet addressing and resource registration & coordination, which RIPE NCC has been given a monopoly from the community to operate (because it's an easy way to do it), but also routing, are a matter of community sourced policy. This absolutely and definitely includes the RIPE DB, in the sense of it being where the distribution of addresses is documented. If there's no documentation, distribution may or may not work, but coordination absolutely does not. This task, not just from paying members, but from everybody, is not a one-way relationship. If it ever becomes a one-way relationship, the RIPE NCC will lose the legitimacy of its operation (business) and I don't think there's anyone here who want that pandoras box to open? And thus this is a discussion of principle. The go-around was ignored. Damage to the relationship has occurred. How does the RIPE NCC and RIPE Community which to resolve this? Do we want to resolve it, and how? Or is it time to part ways (and thereby by extension openly inviting competition to registry operations...) I have some ideas for the specific "single registry point of failure" issue which was overarching the debates surrounding 2008-08. This is perhaps a bit "meta", but it is extremely fundamental to what we are doing, higher-order politics aside. Best regards, Martin From nigel at titley.com Thu Mar 21 13:04:32 2013 From: nigel at titley.com (Nigel Titley) Date: Thu, 21 Mar 2013 12:04:32 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <1363864502.5379.20.camel@galileo.millnert.se> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> Message-ID: <514AF750.8080209@titley.com> On 21/03/2013 11:15, Martin Millnert wrote: > Hi, > > [Internet Citizen hat on] > > > (~Specific to RPKI) > I agree with nick and can openly admit to being part of the small(*) but > vocal opposition to 2008-08. I apologize for learning about the topic > late, but as soon as I did (2010) and grasped the gravity of the > implications it *will* bring (to me, it's a fact), I did my internet > citizenry duty ~best I could. But I'm sure you can understand the frustration and despair of those who *had* been arguing the topic for 2 years prior to this, had come to a reasonable policy agreement, and then suddenly found all of the old arguments suddenly resurrected again. It would have been really useful if you (and others) had made your arguments two years previously. (Those who were at the Rome meeting will remember me losing my temper (a very rare occurrence) on the platform over this). > This brings us to the general problem here: > In which way is the RIPE NCC (Inc.) basing its monopoly integer > registration operation on the internet at large, rather than its paying > members? Now this is a question that deserves further debate, and it strikes at the heart of the PDP. The authors of the PDP made it as far as possible completely standalone from the RIPE NCC (compare to the process in other regions). Now this has it's advantages (it answers your question above, in that it is entirely disjoint from the members and so can claim to represent the internet at large rather than the members). However (and at this point I put my NCC Board hat on) it has serious commercial implications in that the community has power without responsibility. As Jim Reid so cogently remarked a couple of weeks ago, the community could propose a policy that instructed Axel to hand out ?100 notes on the Dam square until the NCC went bust and if we followed the PDP to the letter there is nothing the Board could do about it despite the fact that this would personally bankrupt them too. All other regions have some sort of veto, or endorsement by the board, for all policies. The ARIN region even allows the board to make policy, without reference to either the community or the Advisory board. And they have exercised this right. So I would argue that in general, the RIPE NCC has a better right than any other RIR to claim to represent the Internet at large. And in general the PDP works well (but see below). > > If it ever becomes a one-way relationship, the RIPE NCC will lose the > legitimacy of its operation (business) and I don't think there's anyone > here who want that pandoras box to open? Agreed > > And thus this is a discussion of principle. The go-around was ignored. > Damage to the relationship has occurred. > How does the RIPE NCC and RIPE Community which to resolve this? > Do we want to resolve it, and how? > Or is it time to part ways (and thereby by extension openly inviting > competition to registry operations...) > I have some ideas for the specific "single registry point of failure" > issue which was overarching the debates surrounding 2008-08. It would be very useful for you to communicate those ideas with the NCC team currently working on the problem. > > This is perhaps a bit "meta", but it is extremely fundamental to what we > are doing, higher-order politics aside. > It is absolutely fundamental and I think we need to get the answers to a number of questions: 1. To what extent can policy be allowed to dictate the day to day running of the NCC 2. Does the membership (the owners) of the RIPE NCC have a right (under very specific circumstances) to dictate which policy they implement, and if the answer is yes, then how is this communicated and how are the circumstances decided. 3. Does the PDP, with its "authority but no responsibility" built-ins pose a threat to the NCC and hence the internet in the region. If so then how can we fix it. 4. Is our process of deciding policy by consensus still appropriate to the PDP? (Note that this is a different question to the issue of bottom up governance, to which we are all committed) 5. And what *exactly* do we mean by consensus? By the way, I'm writing this as a concerned citizen of the internet, to which I've given more than twenty years of my life. I genuinely want to sort this out (if it needs sorting out). Nothing I say above has anything to do with the NCC or the Board and any remarks I make are my responsibility alone. I welcome genuine debate All the best Nigel From randy at psg.com Thu Mar 21 13:13:40 2013 From: randy at psg.com (Randy Bush) Date: Thu, 21 Mar 2013 14:13:40 +0200 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <514AF750.8080209@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> <514AF750.8080209@titley.com> Message-ID: > 5. And what *exactly* do we mean by consensus? the ietf is making an effort in this space, see http://tools.ietf.org/html/draft-resnick-on-consensus-02 randy From nigel at titley.com Thu Mar 21 13:25:25 2013 From: nigel at titley.com (Nigel Titley) Date: Thu, 21 Mar 2013 12:25:25 +0000 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> <514AF750.8080209@titley.com> Message-ID: <514AFC35.7010109@titley.com> On 21/03/2013 12:13, Randy Bush wrote: >> 5. And what *exactly* do we mean by consensus? > the ietf is making an effort in this space, see > > http://tools.ietf.org/html/draft-resnick-on-consensus-02 > > Nice and useful document. Should be required reading for all WG-chairs. Nigel From randy at psg.com Thu Mar 21 13:28:12 2013 From: randy at psg.com (Randy Bush) Date: Thu, 21 Mar 2013 14:28:12 +0200 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: <514AFC35.7010109@titley.com> References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> <514AF750.8080209@titley.com> <514AFC35.7010109@titley.com> Message-ID: >> http://tools.ietf.org/html/draft-resnick-on-consensus-02 > Nice and useful document. Should be required reading for all > WG-chairs. and participants randy From olaf at NLnetLabs.nl Thu Mar 21 13:53:24 2013 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 21 Mar 2013 13:53:24 +0100 Subject: [ncc-services-wg] Divergence of RIPE / RIPE NCC policy In-Reply-To: References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> <514AF750.8080209@titley.com> Message-ID: On Mar 21, 2013, at 1:13 PM, Randy Bush wrote: >> 5. And what *exactly* do we mean by consensus? > > the ietf is making an effort in this space, see > > http://tools.ietf.org/html/draft-resnick-on-consensus-02 Yes! I like that document, but my personal observation is that rough consensus works best if there is a clear technical goal and a shared set of values. i.e. it is easier for topics for which there is agreement from the people in the room that that technical goal needs a solution against a specific set of requirements. In the IETF they/we try to manage that with having good charters and requirements documents and even there it is sometimes very difficult. The more you move to layer 9 the more difficult it gets to work towards consensus, mostly because the values start diverging. If one is at a point that the core values are diverged the consensus seeking turns into negotiation, and that is a whole different beast altogether (Dubai Dec 2013 comes to mind) I think that the RIPE community is still enough of a community to have shared core values to enable consensus seeking. That circles back to Nigel's questions, specifically his 'authority but no responsibility' remark. If it is the case that our policy development does not take into account responsibility towards the institutions that we need to maintain, then I think some of us don't share the same values. > I welcome genuine debate This thread will hit some fundamentals. To keep the entropy under control I promise myself to follow the 'not more than one mail per day rule' ;-) --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Mar 21 16:59:03 2013 From: jim at rfc1035.com (Jim Reid) Date: Thu, 21 Mar 2013 15:59:03 +0000 Subject: [ncc-services-wg] defining consensus In-Reply-To: References: <5147A3CE.5080201@netability.ie> <5148436D.2070802@titley.com> <5149ED88.9040602@netability.ie> <5149F869.6090309@titley.com> <514A577D.3080208@netability.ie> <1363864502.5379.20.camel@galileo.millnert.se> <514AF750.8080209@titley.com> <514AFC35.7010109@titley.com> Message-ID: On 21 Mar 2013, at 12:28, Randy Bush wrote: >>> http://tools.ietf.org/html/draft-resnick-on-consensus-02 >> Nice and useful document. Should be required reading for all >> WG-chairs. > > and participants +1 Pete's document is excellent. FWIW other organisations use a much more succinct definition of consensus: lack of sustained reasonable objection. From markus.debruen at bsi.bund.de Thu Mar 21 17:12:12 2013 From: markus.debruen at bsi.bund.de (de =?utf-8?q?Br=C3=BCn?=, Markus) Date: Thu, 21 Mar 2013 17:12:12 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space Message-ID: <201303211712.12336.markus.debruen@bsi.bund.de> Hey Andrew, I was hoping PI-space would eventually be coverd by RPKI. As a PI-space holder, who is not a RIPE NCC member, I would prefer option 2. Since the sponsoring LIR (in our case Deutsche Telekom) already has a contractual relationship with the RIPE NCC, this seems to be the straightforward approach. Option 3 is also okay although I understand the issue of non-members benefiting of RIPE-NCC services. If it comes to that, I am prepared to pay a fee as well ;-) Regards, Markus de Br?n From laura at ripe.net Fri Mar 22 11:47:35 2013 From: laura at ripe.net (Laura Cobley) Date: Fri, 22 Mar 2013 11:47:35 +0100 Subject: [ncc-services-wg] Improving Data Quality on the FTP Site In-Reply-To: References: <5138C9FC.70806@ripe.net> Message-ID: <514C36C7.4010005@ripe.net> Dear I?igo, Thank you for your question and apologies for the delay in getting back to you. The file will show all allocated address space, regardless of whether it is held in an active or a closed RIPE NCC member account. However, when closing member accounts, we follow the procedures outlined in ripe-578 and deregister the address space. Some allocations that are pending removal may temporarily appear in the file. These will disappear once the relevant administrative processes are complete. The full procedure is available at: http://www.ripe.net/ripe/docs/ripe-578 I hope this answers your question. Kind regards, Laura Cobley RIPE NCC On 3/13/13 10:22 AM, I?igo Ortiz de Urbina wrote: > Dear all, > > As a consumer of this data, I have a question regarding the legitimately > closed (no test nor renamed) LIRs in file. > > On Thu, Mar 7, 2013 at 6:10 PM, Laura Cobley wrote: > >> Dear colleagues, >> >> As part of our efforts to improve data quality across the RIPE NCC, we >> would like to update a file within the FTP site: >> >> ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt >> >> According to our records, this file should contain a **list of allocated >> address space held by the RIPE NCC membership**. However, in addition to >> the expected data, the file also contains a number of references to >> obsoleted member accounts which no longer exist. These include, for >> example, accounts created for internal testing and accounts which have >> subsequently been renamed and therefore appear twice. >> >> We are therefore proposing a clean-up of this data so that it shows **only >> allocated address space held by the RIPE NCC membership**. Other than >> removing the erroneous information, the format of the data will not be >> changed. >> >> > Just to make it clear: does this mean the file will just include active > LIRs and their allocations, effectively excluding all sort of closed LIRs? > > >> We plan to begin the clean-up three weeks from today (Thursday 28 March, >> 2013) and would be grateful for any feedback via this mailing list or >> sent to before then. >> >> Kind regards, >> >> Laura Cobley >> RIPE NCC Customer Services Manager >> >> > Thanks in advance and have a nice day, > > I?igo Ortiz de Urbina Cazenave > From niall.oreilly at ucd.ie Mon Mar 25 11:01:26 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 25 Mar 2013 10:01:26 +0000 Subject: [ncc-services-wg] 2012-07: Fresh draft In-Reply-To: References: <0EAAB5F9-FA78-418F-A8F4-EFBCA5DADE5C@steffann.nl> <380B5350-3C4F-4AB2-9573-60B2BE879906@ucd.ie> <19AD971F-651C-49EB-86E9-3CEB00FC5EF7@ucd.ie> <51374203.10109@heanet.ie> Message-ID: <66B25E49-74EA-4EF7-84A4-E3CE19F335BB@ucd.ie> On 25 Mar 2013, at 09:45, Dave Wilson wrote: > Morning, Niall! > > I was just wondering if the new draft went to the co-chairs and Emilio? Yes, on 8 March. > Is there anything I can do to help? I think you just have! Thanks for asking. /Niall From emadaio at ripe.net Mon Mar 25 11:19:03 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 25 Mar 2013 11:19:03 +0100 Subject: [ncc-services-wg] 2012-07: Fresh draft In-Reply-To: <66B25E49-74EA-4EF7-84A4-E3CE19F335BB@ucd.ie> References: <0EAAB5F9-FA78-418F-A8F4-EFBCA5DADE5C@steffann.nl> <380B5350-3C4F-4AB2-9573-60B2BE879906@ucd.ie> <19AD971F-651C-49EB-86E9-3CEB00FC5EF7@ucd.ie> <51374203.10109@heanet.ie> <66B25E49-74EA-4EF7-84A4-E3CE19F335BB@ucd.ie> Message-ID: Hi Niall, unfortunately you beat me in time. We heard only from Bijal from the NCC Services WG co-chairs but I presume Kurt agrees in going on with the Review Phase. I can confirm you that I already started the process for the production of the Impact Analysis and by the end of the week I'll be able to give you an update. Usually I send out a pre-announcement of the Review Phase announcement ("Documentation will be produce and we'll move to Review Phase") so that the community members will know what is going to happen. I'll do it today or tomorrow. Thank you very much for patience Regards Emilio On Mar 25, 2013, at 11:01 AM, "Niall O'Reilly" wrote: > > On 25 Mar 2013, at 09:45, Dave Wilson wrote: > >> Morning, Niall! >> >> I was just wondering if the new draft went to the co-chairs and Emilio? > > Yes, on 8 March. > >> Is there anything I can do to help? > > I think you just have! > Thanks for asking. > > /Niall > > From niall.oreilly at ucd.ie Mon Mar 25 11:57:10 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 25 Mar 2013 10:57:10 +0000 Subject: [ncc-services-wg] 2012-07: Fresh draft In-Reply-To: References: <0EAAB5F9-FA78-418F-A8F4-EFBCA5DADE5C@steffann.nl> <380B5350-3C4F-4AB2-9573-60B2BE879906@ucd.ie> <19AD971F-651C-49EB-86E9-3CEB00FC5EF7@ucd.ie> <51374203.10109@heanet.ie> <66B25E49-74EA-4EF7-84A4-E3CE19F335BB@ucd.ie> Message-ID: <4EFC5748-C3EB-4F0F-8B4E-CD254D9039DE@ucd.ie> On 25 Mar 2013, at 10:19, Emilio Madaio wrote: > Hi Niall, > unfortunately you beat me in time. > > We heard only from Bijal from the NCC Services WG co-chairs but I presume Kurt agrees in going on with the Review Phase. > > I can confirm you that I already started the process for the production of the Impact Analysis and by the end of the week I'll be able to give you an update. > > Usually I send out a pre-announcement of the Review Phase announcement ("Documentation will be produce and we'll move to Review Phase") so that the community members will know what is going to happen. I'll do it today or tomorrow. > > Thank you very much for patience Thank you too, Emilio. It's good to know that the process is moving. Best regards, Niall From ripencc-management at ripe.net Mon Mar 25 11:55:53 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Mon, 25 Mar 2013 11:55:53 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space Message-ID: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> Jim, Of the three implementation options, the most straightforward is option 1, where the PI End User becomes a full member, as this requires no additional development for the RIPE NCC. Note that the additional income from this scenario would exceed any additional cost. For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is a 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 Please keep in mind that in both estimates, where the actual cost falls in the given broadband depends on the amount of manual verification that is desired, which can range from random periodic audits to verification of every application by RIPE NCC staff. Also, the additional costs with smaller or larger uptake are estimated to be quite low. Option 2: A one time cost of 65 kEUR, with a running cost of 45 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. Option 3: A one time cost of 70kEUR, with a running cost of 70 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. Lastly, it is important to point out that as the certificate is valid for only one year, providing this service to PI End Users creates an opportunity for periodic confirmation of the 2007-01 End User Assignment Agreement, further improving the robustness of our Registry. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC From niall.oreilly at ucd.ie Mon Mar 25 12:17:36 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 25 Mar 2013 11:17:36 +0000 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> Message-ID: <49D665B9-8A11-42EE-965C-68929F99C85D@ucd.ie> On 25 Mar 2013, at 10:55, Andrew de la Haye wrote: > For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is a 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 > > Please keep in mind that in both estimates, where the actual cost falls in the given broadband depends on the amount of manual verification that is desired, which can range from random periodic audits to verification of every application by RIPE NCC staff. Also, the additional costs with smaller or larger uptake are estimated to be quite low. > > Option 2: > A one time cost of 65 kEUR, with a running cost of 45 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. > > Option 3: > A one time cost of 70kEUR, with a running cost of 70 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. > > Lastly, it is important to point out that as the certificate is valid for only one year, providing this service to PI End Users creates an opportunity for periodic confirmation of the 2007-01 End User Assignment Agreement, further improving the robustness of our Registry. Thank you for this useful information, Andrew. I'ld appreciate some further clarification, if you wouldn't mind. It seems to me that there must be significant overlap in the elements needed to implement either Option 2 or Option 3. Should we understand that the estimates you give correspond to the respective costs of implementing either option on its own, without implementing the other? If so, would it be reasonable to assume that implementing both might be done for a one-time cost nearer to ?75k than to ?135k and a running cost somewhere between your estimates, depending on the mix of PI End Users deciding for each of the options? Thanks in anticipation and best regards, Niall O'Reilly From jim at rfc1035.com Mon Mar 25 12:31:07 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Mar 2013 11:31:07 +0000 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> Message-ID: <4AD12307-8F73-451C-9B9D-255CA8C86903@rfc1035.com> Many thanks for the information Andrew. This will be very helpful. I hope it will make it easier for the community to reach consensus on the way forward. From randy at psg.com Mon Mar 25 14:08:05 2013 From: randy at psg.com (Randy Bush) Date: Mon, 25 Mar 2013 22:08:05 +0900 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> Message-ID: > Option 2: A one time cost of 65 kEUR, with a running cost of 45 kEUR, > based on an estimated uptake of 15% or approximately 2,500 PI End > Users. > > Option 3: A one time cost of 70kEUR, with a running cost of 70 kEUR, > based on an estimated uptake of 15% or approximately 2,500 PI End > Users. are the costs linear with N? e.g. in printing, it's all in the set-up, and the difference between 100 and 1000 copies is more like a factor of two than ten. and, of course, there are examples where cost is super- linear. randy, who worries about the magic number 2,500 From alexb at ripe.net Tue Mar 26 14:39:22 2013 From: alexb at ripe.net (Alex Band) Date: Tue, 26 Mar 2013 14:39:22 +0100 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <49D665B9-8A11-42EE-965C-68929F99C85D@ucd.ie> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> <49D665B9-8A11-42EE-965C-68929F99C85D@ucd.ie> Message-ID: <593B01E4-AF64-4E66-A949-B0FC04C7CAA0@ripe.net> Hi Niall, Randy, The cost estimate is based on treating option 2 and 3 completely individually, but there is indeed a lot of overlap in the implementation. Most of the development work goes into building the framework for associating a certificate with address space to a non-member. This means implementing both option 2 and 3 would not result in a significantly higher cost than offering just one of them. There is overlap in the running cost as well, for example in terms of support and auditing. With regards to scaling, there are two elements to keep in mind: a) Users requesting a certificate and entering data into the hosted RPKI system b) Users querying the RPKI repository for the content we publish With regards to a), the current RPKI infrastructure that the RIPE NCC runs is capable of handling certificates for all members and non-members and any ROAs they might create. There is no additional scaling needed on that end. As for b), depending on the amount of queries that our RPKI repository will receive, it will need to be scaled up. As more people enter data into the system, the usefulness of RPKI as a whole grows and with it the likelihood that people will want to query the repository. It is very hard to estimate at what pace data usage will grow, all we can say now is that the amount of queries to our repository is very low. Lastly, the RIPE NCC doesn't necessarily need to be responsible for distributing the RPKI related content set all by itself. I hope this puts things in perspective for you. Kind regards, Alex Band (filling in for Andrew) Product Manager RIPE NCC On 25 Mar 2013, at 12:17, Niall O'Reilly wrote: > > On 25 Mar 2013, at 10:55, Andrew de la Haye wrote: > >> For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is a 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 >> >> Please keep in mind that in both estimates, where the actual cost falls in the given broadband depends on the amount of manual verification that is desired, which can range from random periodic audits to verification of every application by RIPE NCC staff. Also, the additional costs with smaller or larger uptake are estimated to be quite low. >> >> Option 2: >> A one time cost of 65 kEUR, with a running cost of 45 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. >> >> Option 3: >> A one time cost of 70kEUR, with a running cost of 70 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. >> >> Lastly, it is important to point out that as the certificate is valid for only one year, providing this service to PI End Users creates an opportunity for periodic confirmation of the 2007-01 End User Assignment Agreement, further improving the robustness of our Registry. > > Thank you for this useful information, Andrew. > > I'ld appreciate some further clarification, if you wouldn't mind. > > It seems to me that there must be significant overlap in the elements needed to implement either > Option 2 or Option 3. Should we understand that the estimates you give correspond to the respective > costs of implementing either option on its own, without implementing the other? If so, would it > be reasonable to assume that implementing both might be done for a one-time cost nearer to ?75k > than to ?135k and a running cost somewhere between your estimates, depending on the mix of > PI End Users deciding for each of the options? From niall.oreilly at ucd.ie Tue Mar 26 15:02:52 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 26 Mar 2013 14:02:52 +0000 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <593B01E4-AF64-4E66-A949-B0FC04C7CAA0@ripe.net> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> <49D665B9-8A11-42EE-965C-68929F99C85D@ucd.ie> <593B01E4-AF64-4E66-A949-B0FC04C7CAA0@ripe.net> Message-ID: <6C6EE18C-C9F6-4B19-9D54-A067B2AD0CC8@ucd.ie> On 26 Mar 2013, at 13:39, Alex Band wrote: > The cost estimate is based on treating option 2 and 3 completely individually, but there is indeed a lot of overlap in the implementation. Most of the development work goes into building the framework for associating a certificate with address space to a non-member. This means implementing both option 2 and 3 would not result in a significantly higher cost than offering just one of them. There is overlap in the running cost as well, for example in terms of support and auditing. > > With regards to scaling, there are two elements to keep in mind: > > a) Users requesting a certificate and entering data into the hosted RPKI system > b) Users querying the RPKI repository for the content we publish > > With regards to a), the current RPKI infrastructure that the RIPE NCC runs is capable of handling certificates for all members and non-members and any ROAs they might create. There is no additional scaling needed on that end. > > As for b), depending on the amount of queries that our RPKI repository will receive, it will need to be scaled up. As more people enter data into the system, the usefulness of RPKI as a whole grows and with it the likelihood that people will want to query the repository. It is very hard to estimate at what pace data usage will grow, all we can say now is that the amount of queries to our repository is very low. Lastly, the RIPE NCC doesn't necessarily need to be responsible for distributing the RPKI related content set all by itself. > > I hope this puts things in perspective for you. Thanks, Alex; that helps. /Niall From emadaio at ripe.net Tue Mar 26 19:19:00 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 26 Mar 2013 19:19:00 +0100 Subject: [ncc-services-wg] 2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders) Message-ID: Dear Colleagues, The discussion period for the proposal described in 2012-07, "RIPE NCC Services to Legacy Internet Resources Holders", has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 Regards Emilio Madaio Policy Development Officer RIPE NCC From randy at psg.com Wed Mar 27 00:41:52 2013 From: randy at psg.com (Randy Bush) Date: Wed, 27 Mar 2013 08:41:52 +0900 Subject: [ncc-services-wg] Certifying of PI End User Address Space In-Reply-To: <593B01E4-AF64-4E66-A949-B0FC04C7CAA0@ripe.net> References: <0E72CBBD-346B-40CE-B889-46BE743AD12F@ripe.net> <49D665B9-8A11-42EE-965C-68929F99C85D@ucd.ie> <593B01E4-AF64-4E66-A949-B0FC04C7CAA0@ripe.net> Message-ID: thanks alex. that is very helpful. randy From Woeber at CC.UniVie.ac.at Wed Mar 27 13:28:37 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 27 Mar 2013 13:28:37 +0100 Subject: [ncc-services-wg] 2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: Message-ID: <5152E5F5.6080100@CC.UniVie.ac.at> Emilio Madaio wrote: > Dear Colleagues, > > The discussion period for the proposal described in 2012-07, "RIPE NCC > Services to Legacy Internet Resources Holders", has ended. > > A draft document and the RIPE NCC Impact Analysis will now be prepared > for review. We will publish the documents shortly and we will make an > announcement. In this context, may I ask for clarification of intent and/or word-smithing, by the authors or the NCC, regarding the phrase in 2.6: "... the RIPE NCC will ... and may update the related entries in the RIPE Database from time to time to correspond to current actual situation." > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-07 > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC Thanks, Wilfried From laura at ripe.net Wed Mar 27 16:10:50 2013 From: laura at ripe.net (Laura Cobley) Date: Wed, 27 Mar 2013 16:10:50 +0100 Subject: [ncc-services-wg] Improving Data Quality on the FTP Site In-Reply-To: <5138C9FC.70806@ripe.net> References: <5138C9FC.70806@ripe.net> Message-ID: <51530BFA.3090201@ripe.net> Dear colleagues, On 7 March, we asked for feedback on our proposal to clean up the file within the FTP site that contains allocated address space held by the RIPE NCC membership. This file is available at: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt We had one clarification request and one message of support. We will update the file tomorrow and send a further announcement when the clean-up is complete. Kind regards, Laura Cobley RIPE NCC Customer Services Manager On 3/7/13 6:10 PM, Laura Cobley wrote: > Dear colleagues, > > As part of our efforts to improve data quality across the RIPE NCC, we > would like to update a file within the FTP site: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > According to our records, this file should contain a list of allocated > address space held by the RIPE NCC membership. However, in addition to > the expected data, the file also contains a number of references to > obsoleted member accounts which no longer exist. These include, for > example, accounts created for internal testing and accounts which have > subsequently been renamed and therefore appear twice. > > We are therefore proposing a clean-up of this data so that it shows only > allocated address space held by the RIPE NCC membership. Other than > removing the erroneous information, the format of the data will not be > changed. > > We plan to begin the clean-up three weeks from today (Thursday 28 March, > 2013) and would be grateful for any feedback via this mailing list or > sent to before then. > > Kind regards, > > Laura Cobley > RIPE NCC Customer Services Manager > > > From niall.oreilly at ucd.ie Wed Mar 27 17:18:59 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 27 Mar 2013 16:18:59 +0000 Subject: [ncc-services-wg] 2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <5152E5F5.6080100@CC.UniVie.ac.at> References: <5152E5F5.6080100@CC.UniVie.ac.at> Message-ID: On 27 Mar 2013, at 12:28, Wilfried Woeber wrote: > In this context, may I ask for clarification of intent and/or word-smithing, > by the authors or the NCC, regarding the phrase in 2.6: Although I attempted to clarify the intent in a message archived here: http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-February/002009.html , you and almost everyone on either of the mailing lists receiving this can't yet have seen how we tried to express this when revising the proposal for v3. Here's what's in my diff-minus-u-style change-tracking copy of the current text of the proposal: 2.6 No relationship ------------------- In cases where the current holder of Legacy Internet Resources cannot be contacted, does not reply to contact from the RIPE NCC or is unknown, there is no formal relationship between the holder and the RIPE NCC. - In such a case, the RIPE NCC will continue to provide those registry - services which are already being provided in respect of the Legacy - Internet Resource or Resources involved, and may update the related - entries in the RIPE Database from time to time to correspond to - current actual situation. + In such a case, the RIPE NCC + - will continue to provide any registry service element already + provided in support of each Legacy Internet Resource involved; + - will have no obligation to begin to provide any registry service + element not already provided in support of a particular Legacy + Internet Resource, even in case the service element is provided in + support of any other Legacy Internet Resource held by the same or + another Resource Holder; + - and may update the related entries in the RIPE Database from time + to time to correspond to the current actual situation. Less formally, this is intended to mean that the NCC should - not curtail service; - not be obliged to implement any missing service element; and - have scope to act to improve the accuracy of the data held. I hope this helps, and encourage you to ask if it doesn't help enough. Best regards, /Niall From laura at ripe.net Thu Mar 28 15:23:57 2013 From: laura at ripe.net (Laura Cobley) Date: Thu, 28 Mar 2013 15:23:57 +0100 Subject: [ncc-services-wg] Improving Data Quality on the FTP Site In-Reply-To: <51530BFA.3090201@ripe.net> References: <5138C9FC.70806@ripe.net> <51530BFA.3090201@ripe.net> Message-ID: <5154527D.4030901@ripe.net> Dear colleagues, The clean-up is complete and the file within the FTP site now shows only allocated address space held by the RIPE NCC membership: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt Kind regards, Laura Cobley RIPE NCC Customer Services Manager On 3/27/13 4:10 PM, Laura Cobley wrote: > Dear colleagues, > > On 7 March, we asked for feedback on our proposal to clean up the file > within the FTP site that contains allocated address space held by the > RIPE NCC membership. This file is available at: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > We had one clarification request and one message of support. We will > update the file tomorrow and send a further announcement when the > clean-up is complete. > > Kind regards, > > Laura Cobley > RIPE NCC Customer Services Manager > > > On 3/7/13 6:10 PM, Laura Cobley wrote: >> Dear colleagues, >> >> As part of our efforts to improve data quality across the RIPE NCC, we >> would like to update a file within the FTP site: >> >> ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt >> >> According to our records, this file should contain a list of allocated >> address space held by the RIPE NCC membership. However, in addition to >> the expected data, the file also contains a number of references to >> obsoleted member accounts which no longer exist. These include, for >> example, accounts created for internal testing and accounts which have >> subsequently been renamed and therefore appear twice. >> >> We are therefore proposing a clean-up of this data so that it shows only >> allocated address space held by the RIPE NCC membership. Other than >> removing the erroneous information, the format of the data will not be >> changed. >> >> We plan to begin the clean-up three weeks from today (Thursday 28 March, >> 2013) and would be grateful for any feedback via this mailing list or >> sent to before then. >> >> Kind regards, >> >> Laura Cobley >> RIPE NCC Customer Services Manager >> >> >> > > From nick at netability.ie Thu Mar 28 17:50:40 2013 From: nick at netability.ie (Nick Hilliard) Date: Thu, 28 Mar 2013 16:50:40 +0000 Subject: [ncc-services-wg] 2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: <5152E5F5.6080100@CC.UniVie.ac.at> Message-ID: <515474E0.7070508@netability.ie> On 27/03/2013 16:18, Niall O'Reilly wrote: > Less formally, this is intended to mean that the NCC should > > - not curtail service; > - not be obliged to implement any missing service element; and > - have scope to act to improve the accuracy of the data held. > > I hope this helps, and encourage you to ask if it doesn't > help enough. I think it helps to clarify the scope of the proposal, but suspect that paying a service fee for registration services creates an implicit contract between the legacy resource holder and the RIPE NCC. No doubt the NCC will be able to clarify this. Nick From niall.oreilly at ucd.ie Thu Mar 28 18:15:19 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Thu, 28 Mar 2013 17:15:19 +0000 Subject: [ncc-services-wg] 2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <515474E0.7070508@netability.ie> References: <5152E5F5.6080100@CC.UniVie.ac.at> <515474E0.7070508@netability.ie> Message-ID: <7EDBE0D5-0FD4-4376-A08E-5455FA97FF49@ucd.ie> On 28 Mar 2013, at 16:50, Nick Hilliard wrote: > On 27/03/2013 16:18, Niall O'Reilly wrote: >> Less formally, this is intended to mean that the NCC should >> >> - not curtail service; >> - not be obliged to implement any missing service element; and >> - have scope to act to improve the accuracy of the data held. >> >> I hope this helps, and encourage you to ask if it doesn't >> help enough. > > I think it helps to clarify the scope of the proposal, but suspect that > paying a service fee for registration services creates an implicit contract > between the legacy resource holder and the RIPE NCC. No doubt the NCC will > be able to clarify this. I'm looking forward to seeing the Impact Analysis. /N From richih.mailinglist at gmail.com Fri Mar 29 17:06:05 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Mar 2013 17:06:05 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: Dear all, the updated, and very belated, version looks like: The canonical and binding format of all policy documents is plain text in ISO-8859-1 encoding. Author names and references may be encoded in UTF-8. If a policy document can not reasonably be stored as plain text, ALTERNATIVE will be used. If any policy document exists in both plain text and ALTERNATIVE, plain text is binding. Any other form is considered non-binding as soon as a plain text or ALTERNATIVE variant exist. All legacy policy documents which are still valid or relevant to current policies will be transformed within a year of this proposal becoming policy. All non-policy documents will be published in plain text or PDF/A-1a with no requirement to try to produce ASCII art or similar. ALTERNATIVE may equal PDF/A-1a or "text file with references to BMPs". Personally, I think I prefer plain text as that's easier to deal with on CLI, but as non-policy documents are in PDF (and if this gets accepted PDF/A-1a) already, it may make more sense to keep both in the same format. Feedback either way would be appreciated. Richard From richih.mailinglist at gmail.com Fri Mar 29 21:16:18 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Mar 2013 21:16:18 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: References: Message-ID: Dear all, this is the update for my second suggestion: The canonical name of all PDPs will be RIPE-PDP-YYYY-NN. Updated versions will receive suffixes like Internet Drafts, i.e. -v1, -v2, -v3. RIPE-PDP-YYYY-NN will always refer to the most up to date version of the PDP. Old-style PDP names of the format YYYY-NN will remain valid, but all new documentation and communication by RIPE will use the new format. Richard PS: I really like the metadata idea but I would like to keep that in a separate PDP so they can progress independently. PPS: Also, as Sascha was the first to actually publish that idea, I want to make sure he doesn't want to push it himself. From lists-ripe at c4inet.net Fri Mar 29 21:26:25 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 29 Mar 2013 20:26:25 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: References: Message-ID: <20130329202625.GA23091@cilantro.c4inet.net> On Fri, Mar 29, 2013 at 09:16:18PM +0100, Richard Hartmann wrote: >PPS: Also, as Sascha was the first to actually publish that idea, I >want to make sure he doesn't want to push it himself. By all means, incorporate it. cheers, Sascha Luck > From nick at netability.ie Fri Mar 29 21:46:11 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 29 Mar 2013 20:46:11 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: References: Message-ID: <5155FD93.6000108@netability.ie> On 29/03/2013 20:16, Richard Hartmann wrote: > The canonical name of all PDPs will be RIPE-PDP-YYYY-NN. > Updated versions will receive suffixes like Internet Drafts, i.e. > -v1, -v2, -v3. > RIPE-PDP-YYYY-NN will always refer to the most up to date version of the PDP. > Old-style PDP names of the format YYYY-NN will remain valid, but all > new documentation and communication by RIPE will use the new format. Does this need to be a policy? Could we not just ask the RIPE NCC kindly to implement this rather than spending the next 6 months arguing, nodding sagely or violently disagreeing about this? This is an operational detail; nothing to do with policy. Nick From richih.mailinglist at gmail.com Fri Mar 29 22:42:38 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Mar 2013 22:42:38 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All PDP emails, documents and websites should come with unified diff" In-Reply-To: References: Message-ID: Dear all, this is the updated version of my third suggestion: All PDP-related emails, web pages, and other documents published by RIPE NCC will either carry a unified diff (diff -ruN) or directly link to a page which shows said unified diff. Other formats, like full text, old/new text, etc are encouraged as well, but the diff is the binding format in which PDPs are published, documented, and discussed. Other than "published by RIPE NCC", there is no change. And, in the spirit of this proposal, see [1]. Richard [1] http://paste.debian.net/plain/245813 From jim at rfc1035.com Fri Mar 29 22:44:27 2013 From: jim at rfc1035.com (Jim Reid) Date: Fri, 29 Mar 2013 21:44:27 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <5155FD93.6000108@netability.ie> References: <5155FD93.6000108@netability.ie> Message-ID: <1C75F961-95FC-488D-BE53-0DC5348E934E@rfc1035.com> On 29 Mar 2013, at 20:46, Nick Hilliard wrote: > Does this need to be a policy? No. However we do seem to like to expend time on this kind of rat-holing and shed painting. Perhaps the Easter Bunny will get to join in the discussion this weekend. I am disappointed that cosmetic things like a numbering/naming convention get attention when far more serious problems appear to be ignored: for example the lack of decent search/browse functionality of our list archives to see how a proposal evolves as it goes through the sausage-making machinery or how the consensus decisions have been reached. Or that only two of the ten proposals from last year has managed to get adopted; one was withdrawn and seven are blocked waiting for something to happen. Note this is not a criticism of the people responsible for those proposals or the relevant WG (Chairs) but of the PDP itself. Something looks to have gone badly wrong here and nobody seems to have noticed or cared. I'm even more disappointed I've got nothing better to do with myself on a Friday night than type this. :-) From randy at psg.com Sat Mar 30 00:24:45 2013 From: randy at psg.com (Randy Bush) Date: Sat, 30 Mar 2013 08:24:45 +0900 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: you're a few days early From richih.mailinglist at gmail.com Sat Mar 30 00:47:28 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 00:47:28 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: Dear all, this is the updated version of the fourth proposal: All policy documents by RIPE NCC will be published in one canonical place which is freely accessible to the public. All other copies will be copied from this one canonical place. All PDPs and their versions should be archived, not matter if they are successful or not. A clear way to discern PDPs if were accepted eventually or not should be provided. An existing local copy should be easy to bring up to date with the current canonical version and to verify against local defects. All policy documents, their predecessors, and the PDPs leading to their existence will be archived and can easily be diffed on the RIPE NCC website. Said web system should allow successive policy documents to be diffed without the PDPs in between, as well. All lines of all policy proposals and PDPs should be trace-able to their first occurrence. Rationale and links to relevant discussions should be published along with the policy documents and PDPs. Historic versions should be imported in this system within one year after this proposal becomes policy. If the proposal "All PDP emails, documents and websites should come with unified diff" is accepted, all diffs will be generated from this system. A pony for Sander Again, if this proposal ends up using git, I am willing to help maintain this system for at least a year. Richard From richih.mailinglist at gmail.com Sat Mar 30 00:58:12 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 00:58:12 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "Yearly list of services by RIPE" In-Reply-To: References: Message-ID: No update is necessary to this proposal but as the 26th of March has passed, I would appreciate a short update from Nigel. As Nigel agreed that it makes sense to codify this either way, I would like to continue with this proposal normally. Richard From richih.mailinglist at gmail.com Sat Mar 30 01:00:49 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 01:00:49 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN" In-Reply-To: <5155FD93.6000108@netability.ie> References: <5155FD93.6000108@netability.ie> Message-ID: On Fri, Mar 29, 2013 at 9:46 PM, Nick Hilliard wrote: > Does this need to be a policy? Could we not just ask the RIPE NCC kindly > to implement this rather than spending the next 6 months arguing, nodding > sagely or violently disagreeing about this? This is an operational detail; > nothing to do with policy. It's my understanding that this is the proper way to do it. Also, asking about this via various ways in the past didn't get me anywhere. I honestly don't care which way is chosen to achieve this as long as it's achieved. Richard From sander at steffann.nl Sat Mar 30 09:48:03 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 30 Mar 2013 09:48:03 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git" In-Reply-To: References: Message-ID: Hi Richard, > A pony for Sander \o/ Sander From philipp.kern at kit.edu Sat Mar 30 12:06:25 2013 From: philipp.kern at kit.edu (Philipp Kern) Date: Sat, 30 Mar 2013 12:06:25 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: Message-ID: <20130330110625.GB29987@spike.0x539.de> Richard, am Fri, Mar 29, 2013 at 05:06:05PM +0100 hast du folgendes geschrieben: > The canonical and binding format of all policy documents is plain > text in ISO-8859-1 encoding. Author names and references may be > encoded in UTF-8. ISO-8859-1 *and* UTF-8 content seems a tad ridiculous and backwards. Kind regards Philipp Kern From nick at netability.ie Sat Mar 30 13:10:50 2013 From: nick at netability.ie (Nick Hilliard) Date: Sat, 30 Mar 2013 12:10:50 +0000 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <20130330110625.GB29987@spike.0x539.de> References: <20130330110625.GB29987@spike.0x539.de> Message-ID: <5156D64A.5090402@netability.ie> On 30/03/2013 11:06, Philipp Kern wrote: > ISO-8859-1 *and* UTF-8 content seems a tad ridiculous and backwards. Would be cool to have them in the same document, though. I love this idea. It's so ... european. But having said that, if Richi wants to aim towards IETF style document processing with text and revisions and all that, could he at least go the whole way and start out with a properly formulated problem statement so that we can look at creating a BoF at RIPE66, which can be used as the basis for creating a working group, which can then aim towards a framework for solving the entire problem of document processing for RIR policy publication. I'm very much in favour of this multiple-incompatible-encoding-per-document idea, but it's clear to me at this stage that we can only solve the problem properly by handling it with a framework specification. Lots of XML too, because we all know that without a functional markup system, free text has plenty of irksome limitations which are frankly a pain in the bum. Structure is a necessity. Honestly, I see scope for an entire stream of RFC style documents, which has the added advantage that we could look at getting research funding for the project and maybe get a couple of uni postgrads in on the act to make sure we're fully buzzword compliant. There's so much scope for argument that College professors will fall over themselves in the rush to get involved. And I've no doubt either that we'll end up having to rewrite git to improve the front-end and ensure that we don't end up with the sort of back-end problems that recently almost trashed the KDE distribution. Reliability is king here. These are important documents which should be enshrined for all eternity, full revision history included, and it would be a gross abnegation of our duty to posterity if we we were to aim for anything other than a 100% solution. This is serious stuff we're discussing, no doubt about it. Careers could be made or broken on the basis of these suggestions. Lives could be lost and someone might not think of the children. Or alternatively, as Randy and Jim suggested, we could drop the whole goddamned thing and concentrate on policy that's important rather than pointlessly wasting time on window dressing, zomg. Nick From richih.mailinglist at gmail.com Sat Mar 30 13:24:56 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 13:24:56 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <20130330110625.GB29987@spike.0x539.de> References: <20130330110625.GB29987@spike.0x539.de> Message-ID: On Sat, Mar 30, 2013 at 12:06 PM, Philipp Kern wrote: > ISO-8859-1 *and* UTF-8 content seems a tad ridiculous and backwards. I should have explained the rationale behind this suggestion, sorry. What it boils down to is that normal text would use the standard ASCII chars and only names and references would be allowed to use UTF-8. A different, and maybe better, way to put this is "UTF-8 for the document, but use only ASCII chars within the main text". Richard From tore at fud.no Sat Mar 30 13:39:46 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 30 Mar 2013 13:39:46 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All PDP emails, documents and websites should come with unified diff" In-Reply-To: References: Message-ID: <5156DD12.4020007@fud.no> * Richard Hartmann > All PDP-related emails, web pages, and other documents published by > RIPE NCC will either carry a unified diff (diff -ruN) or directly link > to a page which shows said unified diff. > > Other formats, like full text, old/new text, etc are encouraged as > well, but the diff is the binding format in which PDPs are published, > documented, and discussed. As discussed on IRC, during the preparation of 2013-03 I submitted a last-minute amendment. This amendment made it into the complete new policy document[1], but not in the side-by-side diff[2]. [1] http://www.ripe.net/ripe/docs/other-documents/ipv4-address-allocation-and-assignment-policies-for-the-ripe-ncc-service-region-new [2] http://www.ripe.net/ripe/docs/other-documents/ipv4-address-allocation-and-assignment-policies-for-the-ripe-ncc-service-region-current I noticed this myself, and it was corrected shortly after. This is not a complaint - I have only myself to blame for changing the proposal after all the documentation had been produced. That said, if both the current and the new proposed policy was written in a standardised plain-text[ish] format, creating the side-by-side diff page could have been a fully automated task with no risk of omissions, rather than a manual one. Just a data point... Tore From randy at psg.com Sat Mar 30 13:59:16 2013 From: randy at psg.com (Randy Bush) Date: Sat, 30 Mar 2013 21:59:16 +0900 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: <5156D64A.5090402@netability.ie> References: <20130330110625.GB29987@spike.0x539.de> <5156D64A.5090402@netability.ie> Message-ID: side note: the ietf currently allows other formats, e.g. pdf. and the ietf is considering further and more extreme heresies. randy From dr at cluenet.de Sat Mar 30 15:39:17 2013 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 30 Mar 2013 15:39:17 +0100 Subject: [ncc-services-wg] Pre-PDP discussion: "All RIPE documents should be plain text" In-Reply-To: References: <20130330110625.GB29987@spike.0x539.de> <5156D64A.5090402@netability.ie> Message-ID: <20130330143917.GA17354@srv03.cluenet.de> On Sat, Mar 30, 2013 at 09:59:16PM +0900, Randy Bush wrote: > side note: the ietf currently allows other formats, e.g. pdf. and the > ietf is considering further and more extreme heresies. The IETF also adopted utterly nonsensical marketing terms like "Carrier Grade NAT", so... what to expect? :) SCNR, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0