[mpls] Discuss of EXP field

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 20 August 2008 10:17 UTC

Return-Path: <mpls-bounces@ietf.org>
X-Original-To: mpls-archive@megatron.ietf.org
Delivered-To: ietfarch-mpls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3AF3A6B65; Wed, 20 Aug 2008 03:17:43 -0700 (PDT)
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26793A6BAE for <mpls@core3.amsl.com>; Wed, 20 Aug 2008 03:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.229
X-Spam-Level:
X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoG7rep5uGqW for <mpls@core3.amsl.com>; Wed, 20 Aug 2008 03:17:41 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id CE5383A6AAA for <mpls@ietf.org>; Wed, 20 Aug 2008 03:17:40 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7KAH3C5011324 for <mpls@ietf.org>; Wed, 20 Aug 2008 11:17:04 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7KAH3GY011313 for <mpls@ietf.org>; Wed, 20 Aug 2008 11:17:03 +0100
Message-ID: <03b001c902ad$e3e76400$0300a8c0@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: mpls@ietf.org
References: <C4CF528C.612B%swallow@cisco.com><F4B742FA-3A43-429E-A53C-B82A8074B347@cisco.com><941D5DCD8C42014FAF70FB7424686DCF039B013A@eusrcmw721.eamcs.ericsson.se> <CF46696C-9B82-4E1B-910F-C03A108CDA9B@cisco.com>
Date: Wed, 20 Aug 2008 11:14:15 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Subject: [mpls] Discuss of EXP field
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mpls-bounces@ietf.org
Errors-To: mpls-bounces@ietf.org

Hi,

I'm finally tempted out of my cave to join in this cycle-burning 
extravaganza.

I just want to point out that marking a new RFC as "Updates" a whole series 
of other RFCs has only limited effect on how those other RFCs are read.

Thus, *if* the reader collects the older RFC from the RFC repository 
(http://www.ietf.org/iesg/1rfc_index.txt) or from the MPLS charter page 
(http://www.ietf.org/html.charters/mpls-charter.html) they will see a note 
saying something like "updated by RFC wxyz". The wise reader will get a copy 
of that newer RFC to find out what the update is.

But most RFC reading comes direct. I need to know about LDP; I get RFC 5036 
and read it. And the RFC itself carries no indication that it has been 
updated.

The effect of this in our particular case is that changing the name of a 
field in a new RFC will have only limited affect on how people perceive the 
name of that field.
- they will continue to read the old RFCs
- they will continue to read the many books that are out there
- they might not even read the new RFC as it seems
   uninteresting from its title.

We could use the RFC eratum system, but frankly, hardly anyone ever looks at 
that.

A slightly more sure way to drive the message home would be to respin all of 
the updated RFCs with the correct (new) naming of the bits. This is what 
most publishing organisations would do.

Of course, we only mark the old RFCs as obsoleted in exactly the same way as 
we mark them as updated. This means that they are still around and still 
easy to pick up and read (witness the recent email on the list about RFC 
3036).

So...

All this effort and what effect?


There now. I, too, have wasted my time on this thread.

Adrian


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls