Re: Question about the normative nature of IETF RFCs

Keith Moore <moore@cs.utk.edu> Wed, 28 September 2005 22:05 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKk3F-0002fN-4s; Wed, 28 Sep 2005 18:05:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKk3C-0002fF-E2 for ietf@megatron.ietf.org; Wed, 28 Sep 2005 18:05:18 -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 SAA15386 for <ietf@ietf.org>; Wed, 28 Sep 2005 18:05:15 -0400 (EDT)
Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKkAi-0005AW-Oi for ietf@ietf.org; Wed, 28 Sep 2005 18:13:06 -0400
Received: from localhost (ka [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 0A38D23588; Wed, 28 Sep 2005 18:05:11 -0400 (EDT)
Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15459-02; Wed, 28 Sep 2005 18:05:10 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ka.cs.utk.edu (Postfix) with ESMTP id 055E523584; Wed, 28 Sep 2005 18:05:09 -0400 (EDT)
Date: Wed, 28 Sep 2005 18:05:08 -0400
From: Keith Moore <moore@cs.utk.edu>
To: "Fleischman, Eric" <eric.fleischman@boeing.com>
Message-Id: <20050928180508.3c1bae08.moore@cs.utk.edu>
In-Reply-To: <474EEBD229DF754FB83D256004D02108BBC978@XCH-NW-6V1.nw.nos.boeing.com>
References: <474EEBD229DF754FB83D256004D02108BBC978@XCH-NW-6V1.nw.nos.boeing.com>
X-Mailer: Sylpheed version 2.0.0rc (GTK+ 2.6.7; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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

> Keith,
> 
> I resonate with your points except that the earliest IETF standards
> (i.e., IP itself, TCP itself, others) were incompletely specified by
> RFCs. Therefore, interoperable implementations could only occur with
> reference to the reference implementations.

I don't know what reference implementations you are talking about.  The
ARPAnet was quite diverse in terms of host architectures and operating
systems, and at least for the protocols whose early implementations I
have seen, high-level languages were rarely used.  Which platform's
implementation would serve as a reference?

Nor do I believe your conclusion follows.  In particular, the "be
conservative in what you send, be liberal in what you accept" rule
would allow for some degree of interoperability even in the case of
incomplete specifications.  Of course, just as today, when people found
that their implementations wouldn't interoperate, they'd try to fix
them.

> However, the actual motivation for my query is the following: the IETF
> didn't accept the existence of middleboxes until 2000 - 2002. Thus, I am
> trying to convince a middlebox implementor that they misunderstood a
> standards track RFC originally written in 1995 and re-published in 1998.
> That RFC said "hosts do X" and other devices (which in that era meant
> routers) do Y. They do Y because they are not hosts -- rather than
> correctly behaving as middleboxes are supposed to do.

Most protocols weren't designed to operate with middleboxes. In the
absence of a provision in a protocol specification for a middlebox,
any middlebox that  interferes with interoperation of a protocol is
inherently violating the protocol standards.

In general, protocol specifications don't (and shouldn't) try to
explicitly enumerate "don't do X" for every possible "X" that is
harmful.  And middleboxes are generally harmful.

Keith

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