Update regarding the proposals to improve the technical infrastructure supporting the RIPE Policy Development Process
Dear colleagues, Before the previous RIPE Meeting in Dublin, a number of proposals were brought forward in the RIPE NCC Services Working Group by members of the community, dealing with suggested updates to the technical infrastructure that supports the Policy Development Process. You can read the corresponding threads here: 1. "plain text" https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002154.ht... 2. "PDP names" https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002150.ht... 3. "unified diff" https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002151.ht... 4. "everything should use GIT" https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002152.ht... A lively discussion ensued on the mailing list, and it was also part of the agenda of the Working Group at the RIPE 66 Meeting in Dublin: https://ripe66.ripe.net/archives/steno/13/ Following feedback from the community, a group was formed to address the issue and agree on a problem statement that would approach the issue from a high level, without going into technical and implementation details. The group consisted of Richard Hartmann, Alex Le Heux, Ruediger Volk, Emilio Madaio and myself. The group had a number of remote conferences and email discussions over the summer, and would like to present to you a finalised version of the problem statement (attached below). Please let us know if you think the text can be improved in any way, sending your comments and any suggestions to the list. Once a consensus is reached by the community, the RIPE NCC will evaluate the feedback and propose possible solutions. Regards, Mihnea-Costin Grigore RIPE NCC [------------8<------------] Problem Statement -------------------- The RIPE PDP process is too complicated for everyone: outsiders, new members, experienced members, authors, and the RIPE NCC. Therefore, participation should be made easier, especially for new-comers. Main scope: - The initial focus and effort are on the RIPE PDP -- proposals, drafts and policy documents; if any progress is made here, then we can think of applying the same or similar solutions to other areas of RIPE documentation - Any solutions discussed should also work for non-techies Details of the problem: a) The meta-data provided is incomplete: - RIPE Policy Documents and Policy Proposals don't have unique and clearly identified global names/identifiers - There is no clear version and date for publication - There is no track of who and when requested and approved a certain change - There is no clear up to date succession and obsolescence information within documents - There is no canonical way to get an overview of all currently active documents b) There is no systematic access to all versions of a document: - There is no directly available history - There are no easy to use tools to correlate between versions - There are no tools for authors to submit new/corrected versions of a document as it evolves through the PDP c) There is no plain-text version of each document and version thereof in ASCII format [------------8<------------] -- Mihnea-Costin Grigore RIPE NCC Web Services Team Leader - http://www.ripe.net/
Hi, On Wed, Sep 25, 2013 at 06:12:08PM +0200, Mihnea-Costin Grigore wrote:
Problem Statement -------------------- The RIPE PDP process is too complicated for everyone: outsiders, new members, experienced members, authors, and the RIPE NCC. Therefore, participation should be made easier, especially for new-comers.
Main scope: - The initial focus and effort are on the RIPE PDP -- proposals, drafts and policy documents; if any progress is made here, then we can think of applying the same or similar solutions to other areas of RIPE documentation - Any solutions discussed should also work for non-techies
Details of the problem:
a) The meta-data provided is incomplete: - RIPE Policy Documents and Policy Proposals don't have unique and clearly identified global names/identifiers - There is no clear version and date for publication - There is no track of who and when requested and approved a certain change - There is no clear up to date succession and obsolescence information within documents - There is no canonical way to get an overview of all currently active documents
b) There is no systematic access to all versions of a document: - There is no directly available history - There are no easy to use tools to correlate between versions - There are no tools for authors to submit new/corrected versions of a document as it evolves through the PDP
c) There is no plain-text version of each document and version thereof in ASCII format
[------------8<------------]
I find this a fairly impressive piece of work - it follows the rule "a document is perfect if there is no longer something to take away", which is much harder than writing a 50 page document. And I agree with the problem statement :-) Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear Mihnea-Costin, once again, thanks for your work on this. Also thanks for Marco Schmidt. As bad luck would have it, I now realize that I made a few grammar mistakes; those can be fixed once we all agree on a problem statement. Also, at least in part due to my own oversight when re-reading the final draft, there are two other points which didn't make it into this text: * There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents As they are not part of the draft, I would appreciate a distinct +/-1 on both of them from anyone who comments so we can judge if they should be included. Thanks to anyone who reads this and cares to answer, Richard
Hi, On Wed, Sep 25, 2013 at 10:38:04PM +0200, Richard Hartmann wrote:
* There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents
+1 Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Richard,
As bad luck would have it, I now realize that I made a few grammar mistakes; those can be fixed once we all agree on a problem statement.
Also, at least in part due to my own oversight when re-reading the final draft, there are two other points which didn't make it into this text:
* There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents
As they are not part of the draft, I would appreciate a distinct +/-1 on both of them from anyone who comments so we can judge if they should be included.
+1 to both of them, and also a +1 on the draft itself. Sander
* Richard Hartmann
* There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents
+1, and also to the problem statement itself. I've got recent experience with the first point you mention in particular, as changes I request going into a new version of a proposal got ever so slightly changed - not in a significant way (a word going away here, "the" turning into "their" there, ...), and I have no reason to believe it was intentional or anything like that - but it's very hard to spot with the current lack of tools. That it is possible for these bugs to sneak in in the first place is also a tell-tale sign that the tools aren't good enough - I'm suspecting manual transcribing from e-mails to internal work documents is what's going on here. So assuming we get C in order first: All the points under B, the two additional points above, plus the third point under A, could all be solved in one fell swoop by using a proper version control system. It would be super nice to be able to clone the ripe-document-store repo, make a proposal branch, work on it and finally tag MyProp v1, push to the PDO, merging in any other unrelated proposals from the main branch as they get accepted, repeat, until (hopefully) merging back to the main branch....but I guess I'm not supposed to define solutions at this point, so I'll stop there. ;-) Tore
On 09/25/2013 10:38 PM, Richard Hartmann wrote:
* There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents
As they are not part of the draft, I would appreciate a distinct +/-1 on both of them from anyone who comments so we can judge if they should be included.
A very enthusiastic +1 to both the original text and the additional points raised by Richard. Thanks to all involved for making this happen, I'm looking forward to the implementation. Gerry
* Richard Hartmann <richih.mailinglist@gmail.com> [2013-09-25 22:39]:
* There is no way to ensure that what authors send in is exactly, i.e. no more, no less, what makes it into new versions. * There is no canonical way to keep an up to date local copy of all documents
+1 to this and the original text. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Hi, [...]
c) There is no plain-text version of each document and version thereof in ASCII format
Is ASCII format a synonym for plain text or is the proposal actually to force the use of ASCII rather than a more modern character encoding? Thanks, Leo Vegoda
On Wed, Sep 25, 2013 at 11:45 PM, Leo Vegoda <leo.vegoda@icann.org> wrote:
Is ASCII format a synonym for plain text or is the proposal actually to force the use of ASCII rather than a more modern character encoding?
As of right now, it really does mean ASCII as full UTF-8 was too controversial and there was no hard need for it. FWIW, IETF is moving towards having the actual text in ASCII-only and allowing UTF-8 in metadata like author names. This allows easing in something new while still remaining 100% backwards-compatible. For the record, I am fine with all three of those options and will not push towards any of those. Whichever has the highest likelihood of reaching consensus has my support. There already has been a _lot_ of effort behind the scenes and I would like to see this implemented ASAP :) -- Richard
participants (8)
-
Gerry Demaret -
Gert Doering -
Leo Vegoda -
Mihnea-Costin Grigore -
Richard Hartmann -
Sander Steffann -
Sebastian Wiesinger -
Tore Anderson