[Tools-discuss] On the "replaced by / replaces" status of drafts ...

Martin Vigoureux <martin.vigoureux@alcatel-lucent.com> Thu, 02 August 2012 18:13 UTC

Return-Path: <martin.vigoureux@alcatel-lucent.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8DF21F8618 for <tools-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 11:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.174
X-Spam-Level:
X-Spam-Status: No, score=-110.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPON4NOPOojV for <tools-discuss@ietfa.amsl.com>; Thu, 2 Aug 2012 11:13:37 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55821F85A0 for <tools-discuss@ietf.org>; Thu, 2 Aug 2012 11:13:36 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q72IDWw9020485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tools-discuss@ietf.org>; Thu, 2 Aug 2012 20:13:33 +0200
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Aug 2012 20:13:33 +0200
Received: from [135.244.3.197] (135.5.27.12) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 2 Aug 2012 14:13:29 -0400
Message-ID: <501AC332.90604@alcatel-lucent.com>
Date: Thu, 02 Aug 2012 20:13:06 +0200
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "tools-discuss@ietf.org" <tools-discuss@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [135.5.27.12]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: [Tools-discuss] On the "replaced by / replaces" status of drafts ...
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tools-discuss>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 18:13:38 -0000

Hello,

first, sorry for the long e-mail.
I am trying to do some clean-up regarding the above mentioned status
of various drafts of the mpls wg and some elements are quite puzzling.

A good complete example of what I would view as a proper situation is 
for draft-ietf-mpls-oam-frmwk:
1/ at http://tools.ietf.org/wg/mpls we can see 
draft-allan-mpls-oam-frmwk being struck through and followed by 
"replaced by draft-ietf-mpls-oam-frmwk"
2/ http://tools.ietf.org/html/draft-allan-mpls-oam-frmwk shows in the 
header that it is replaced by draft-ietf-mpls-oam-frmwk
3/ http://tools.ietf.org/html/draft-ietf-mpls-oam-frmwk shows in the 
header that it replaces draft-allan-mpls-oam-frmwk
4/ it also shows that itself is replaced by RFC4378
5/ and http://tools.ietf.org/html/rfc4378 shows that it replaces 
draft-ietf-mpls-oam-frmwk
6/ the information on the tracker is exactly the same (see 
https://datatracker.ietf.org/doc/draft-allan-mpls-oam-frmwk/ 
https://datatracker.ietf.org/doc/draft-ietf-mpls-oam-frmwk/ and 
https://datatracker.ietf.org/doc/rfc4378/ )

However, there are cases when this is not as ideal. For example:

http://tools.ietf.org/html/draft-ietf-mpls-ldp-survey2002 shows 
draft-thomas-mpls-ldp-survey2002 as an ancestor but
http://tools.ietf.org/html/draft-thomas-mpls-ldp-survey2002 does not 
show draft-ietf-mpls-ldp-survey2002 as a descendant

There is an even stranger case:
http://tools.ietf.org/html/draft-davie-mpls-rsvp indicates 
http://tools.ietf.org/html/draft-ietf-mpls-rsvp as a descendant but this 
latter indicates http://tools.ietf.org/html/draft-viswanathan-mpls-rsvp 
as an ancestor and this latter does not show anything for descendants.

So, is the "replaced by / replaces" status bidirectional or not?
My belief was that yes it is, as we only to ask the secretariat to
mark A as replaced by B and we normally get it in both directions but 
some examples make me doubt.


Also, on http://tools.ietf.org/wg/mpls, shows drafts replaced by others 
and does so by having the draft title struck through and by indicating 
"replaced by ...". But, for example:
draft-raggarwa-mpls-rsvp-upstream is not struck through and indeed
http://tools.ietf.org/html/draft-raggarwa-mpls-rsvp-upstream shows no 
descendant but it is in fact the ancestor of 
http://tools.ietf.org/html/draft-ietf-mpls-rsvp-upstream as indicated in 
the header of this latter.
So again, it seems possible to have a unidirectional replacement status 
and on top of that drafts titles seem to be struck through only if 
drafts are replaced by another one but not if the other one replaces them.

Finally, there are some discrepancies between the replacement statuses 
indicated in the datatracker and on the tools pages. As an example (but
there are others):
http://tools.ietf.org/html/draft-ietf-mpls-ipv6-pw-lsp-ping
https://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/
On the tools page the replacement status (with 
draft-chen-mpls-ipv6-pw-lsp-ping) is defined and is bidirectional but 
there is no such status
in the tracker.


In relation to the replacement topic, yet not directly linked:
http://tools.ietf.org/wg/mpls shows a long list of documents (Related 
Active Documents) but a good proportion of them have in fact expired a 
(very) long time ago.
I noticed that all of the expired documents in that list are documents 
which carry the same name than a working group document (except for the 
prefix draft-ietf/draft-myname). This seems to be the reason for them 
appearing in that list, regardless of any replacement status.
The glitch that leads me to that conclusion is the presence of
draft-liu-mpls-tp-ring-protection in the list.
This document has expired and is not replaced by any WG document.
It is draft-weingarten-mpls-tp-linear-protection which is replaced by 
draft-ietf-mpls-tp-linear-protection, and this is correctly shown.

There is another glitch, which I can't explain, which is the presence of 
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext. This is a ccamp document.
The reason is not because it carries mpls in its file name because ccamp
has other such documents and they do not appear here. Also it is 
identified as expired, dating 2010, version 01, but the document is 
alive at version 08.

So,
1/ I would definitely welcome explanations regarding the strange 
replacement statuses and how to fix these. I can ask the secretariat for 
resetting the replacement status for each, but just want to make
sure the desired effect will happen.

2/ How are the datatracker and the tools pages synchronized with regards 
to the replacement status and how can we make sure that there are no 
discrepancies?

2/ Would it be possible that the conditions for listing documents in the 
"Related Active Documents" list be such that
only working-group-associated-active documents be listed
or that working-group-associated-active documents together with 
working-group-associated-expired-documents-but-replaced-by-active-wg-documents 
be listed?
I insist on active, because a bunch of expired documents in the current 
list are effectively replaced by working group documents but these have 
expired, and in my opinion these docs should thus not appear in the list.

Thank you.
Martin