- ncc-services-wg - mailman.ripe.net

Plan to discontinue email signing from certain addresses
by Alex Band 09 Apr '13

09 Apr '13

Dear colleagues, One of the goals of the RIPE NCC is to simplify and streamline our infrastructure and internal processes. Over the years, we have taken great strides in making our infrastructure easier to maintain and more cost effective. However, there are a couple of legacy scripts and tools that are entangled deeply in our workflows and are very hard to phase out on the short term. One of these legacy tools is our ticketing system. The infrastructure we need and the resources it costs is disproportionate to the amount of value that it offers. Migrating away from it in one go is proving to be very complicated. This is why we have decided on a phased approach. One element of the ticketing system that will be affected in the first phase is PGP Authentication: https://www.ripe.net/lir-services/resource-management/contact/pgp-authentic… Signing emails from hostmaster(a)ripe.net, lir-help(a)ripe.net, new-lir(a)ripe.net and enum(a)ripe.net is one of the first pieces that we need to remove in order to phase out all the legacy software. While we realise that it is a best practice to sign such emails and are aware of the value it offers, we are planning to discontinue email signing from just these addresses starting 1 January 2014. It will allow us to phase out a part of our infrastructure that makes future migration a lot easier, while saving cost in the mean time. Please note that this change will not affect email interaction with the RIPE Database. As soon as we have replaced our current ticketing system, we will re-evaluate email signing. As we may have overlooked some potential issues that certain members of our Community might have if we discontinue this functionality, naturally we are open to your feedback. Kind regards, Alex Band Product Manager RIPE NCC

10 14

Status of 2012-07
by Lindqvist Kurt Erik 05 Apr '13

05 Apr '13

All, We wanted to provide an update on the next steps for 2012-07. The document will be moved to the next Phase (Review phase), this will be done with a version 3 of the document. The changes between version 2 and version 3 are non-significant, and we believe they do not justify a complete re-run of Phase 2. The changes to the document are in-line with the requests made by the community. Last, the RIPE NCC are working on the Impact study for this proposal and will post this to the list as soon as it's available. Best regards, Kurtis & Bijal

2 1

[news] Phase 1 Update: Abuse Contact Management in the RIPE Database
by Kaveh Ranjbar 03 Apr '13

03 Apr '13

[Apologies for duplicate emails] Dear colleagues, Phase 1 of ripe-563 "Abuse Contact Management in the RIPE Database" is now being implemented, as announced on 19 March 2013. According to ripe-563, all resources allocated or assigned by the RIPE NCC will need to have an abuse contact email address included in their RIPE Database registration. During the first six months of implementation (phase 1), all Local Internet Registries (LIRs) must add an abuse contact attribute ("abuse-c:") to their LIR's ORGANISATION object to provide abuse contact information for all of the allocated address space under their LIR. Since the initial announcement two weeks ago, we are pleased to report that 24.8% of the RIPE NCC's allocated IPv4 address space is already covered with an abuse contact. More statistics will be sent to the RIPE Anti-Abuse Working Group mailing list. In phase 1, we will send notifications to LIRs that haven't added abuse contact information to their LIR's ORGANISATION object. If this information is not added by the LIR by the end of phase 1, we will automatically add the LIR's contact email address (which is already publicly listed at: <https://www.ripe.net/membership/indices/>) as their abuse contact. LIRs can always change this information as needed. More information on the implementation plan, including phase 2 (covering PI space and ASNs) is available on RIPE Labs at: <https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201…> ------------------------------- How to add "abuse-c" ------------------------------- An explanation of how to add "abuse-c:" to an LIR's ORGANISATION object as well as how to fine-tune abuse contact information for sub-allocations and assignments is outlined here: <https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-…> Please kindly consider adding abuse contact information as soon as possible to the ORGANISATION object(s) you control or maintain in the RIPE Database. Kind Regards, Kaveh Ranjbar, RIPE NCC Database Group Manager

1 0

Pre-PDP discussion: "Yearly list of services by RIPE"
by Richard Hartmann 02 Apr '13

02 Apr '13

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.

7 14

Pre-PDP discussion: "All RIPE documents should be plain text"
by Richard Hartmann 30 Mar '13

30 Mar '13

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

10 20

Pre-PDP discussion: "All PDP emails, documents and websites should come with unified diff"
by Richard Hartmann 30 Mar '13

30 Mar '13

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

2 2

Pre-PDP discussion: "All published documents and PDPs are maintained with git"
by Richard Hartmann 30 Mar '13

30 Mar '13

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 ;)

6 26

Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN"
by Richard Hartmann 30 Mar '13

30 Mar '13

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

9 13

2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders)
by Emilio Madaio 28 Mar '13

28 Mar '13

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

4 4

Improving Data Quality on the FTP Site
by Laura Cobley 28 Mar '13

28 Mar '13

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 <ncc(a)ripe.net> before then. Kind regards, Laura Cobley RIPE NCC Customer Services Manager

3 5