Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN"
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
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
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
On 2013-03-16 15:32 , "Sander Steffann" <sander@steffann.nl> 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
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
On Sat, Mar 16, 2013 at 5:51 PM, Sascha Luck <lists-ripe@c4inet.net> 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
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@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Sat, Mar 16, 2013 at 3:32 PM, Sander Steffann <sander@steffann.nl> 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
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
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.
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
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
On 29 Mar 2013, at 20:46, Nick Hilliard <nick@netability.ie> 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. :-)
On Fri, Mar 29, 2013 at 9:46 PM, Nick Hilliard <nick@netability.ie> 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
participants (9)
-
Alex Le Heux
-
Daniel Roesen
-
Gerry Demaret
-
Gert Doering
-
Jim Reid
-
Nick Hilliard
-
Richard Hartmann
-
Sander Steffann
-
Sascha Luck