Re: Question about the normative nature of IETF RFCs

"C. M. Heard" <heard@pobox.com> Thu, 29 September 2005 16:44 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1Wi-0005TM-QL; Thu, 29 Sep 2005 12:44:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1Wg-0005TH-6F for ietf@megatron.ietf.org; Thu, 29 Sep 2005 12:44:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21900 for <ietf@ietf.org>; Thu, 29 Sep 2005 12:44:50 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1eJ-00073R-H3 for ietf@ietf.org; Thu, 29 Sep 2005 12:52:51 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8TGiXBT001864 for <ietf@ietf.org>; Thu, 29 Sep 2005 09:44:33 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8TGiQ3d001042 for <ietf@ietf.org>; Thu, 29 Sep 2005 09:44:26 -0700
Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8TGiQXR001038 for <ietf@ietf.org>; Thu, 29 Sep 2005 09:44:26 -0700
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Thu, 29 Sep 2005 09:44:26 -0700
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: ietf@ietf.org
In-Reply-To: <6.2.3.4.2.20050929014422.046d1bb0@mail.jefsey.com>
Message-ID: <Pine.LNX.4.10.10509290927020.28649-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: Re: Question about the normative nature of IETF RFCs
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

"JFC (Jefsey) Morfin" wrote:
> Interestingly, Transpac, the French X.25/Minitel network (by then the
> largest data network in the world, so acting as a kind of reference)
> "published" a test machine (probably around 1982?) everyone could use
> to verify his conformance to the (stringent) network requirments. At
> the Den Hague ISIS Club (1984?) the Dutch PTTs proposed to extend that
> pratice to the whole International Network, standardising the running
> test program concept (for OSI, DECNET, IBM/SNA, Swift, Sita, etc..
> then supported protocols). . This was further discussed within the
> CEPT (European Public Operators Club) for OSI services, but I did not
> heard of any decision or CCITT (ITU-T) proposition. This kind of
> standardisation by the "running test" was a standard question when
> discussing a new root name interconect. But I do not think it was used
> by any other OSI operators ?
> 
> The concept is however appealing: to add a test running code to an
> RFC, as a way to document, check and enforce its standard?

My experience with this sort of thing was pretty negative.  I worked
on an X.25 DTE implementation in the early 1980s, and we had to get
it certified by a US government agency in order to be allowed on one
of the government networks.  The certification code appeared to have
had been written by a junior engineer, and it required behaviour that
was inconsistent with the written standards and would have caused
significant interoperability problems.  So we did what everyone else
did:  we submitted hacked code for the certification test, got the
certification paper, and then deployed our original code (which was
compliant with the standard and was known to interoperate with the
equipment we had to talk to).

My hazy recollection of the Transpac certification tests is that
their test machine actually did a relatively good job, but that they
did not require certification to connect to their network.  IIRC
they didn't believe that non-conforming behaviour from a DTE would
harm the network ... if it failed to interoperate, it the
customer/vendor would be motivated to fix it.

//cmh


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf