Subject: RE: Question about the normative nature of IETF RFCs

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 28 Sep 2005 13:50:56 -0700

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.

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.

The reference implementations clearly demonstrate that their approach is
non-conformant even though their non-historically accurate
interpretation of that standard complies with the actual wording of that
RFC.

--Eric

From: Keith Moore [mailto:[email-masked]] 
>As far as IETF is concerned, running code should be 
>seen as a proof-of-concept and a test vehicle, not 
>as primary source material.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 29 Sep 2005 06:03:15 +0800

Hi, Eric,

For what it's worth, none of the slow-start/congestion avoidance stuff in 
TCP was documented in an RFC until RFC 2001 in 1997, which said

   Modern implementations of TCP contain four intertwined algorithms
   that have never been fully documented as Internet standards:  slow
   start, congestion avoidance, fast retransmit, and fast recovery.  [2]
   and [3] provide some details on these algorithms, [4] provides
   examples of the algorithms in action, and [5] provides the source
   code for the 4.4BSD implementation.  RFC 1122 requires that a TCP
   must implement slow start and congestion avoidance (Section 4.2.2.15
   of [1]), citing [2] as the reference, but fast retransmit and fast
   recovery were implemented after RFC 1122.  The purpose of this
   document is to document these four algorithms for the Internet.

and the references were to ACM articles and end-to-end mailing list postings 
from 1988-1990.

It's a darned good thing RFC 793 wasn't "normative" in the 1990s, because 
even the Arpanet was collapsing without these mechanisms in the late 1980s. 
RFC 1122 (1989) had this to say:

         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41

            The algorithm suggested in RFC-793 for calculating the
            retransmission timeout is now known to be inadequate; see
            Section 4.2.3.1 below.

            Recent work by Jacobson [TCP:7] on Internet congestion and
            TCP retransmission stability has produced a transmission
            algorithm combining "slow start" with "congestion
            avoidance".  A TCP MUST implement this algorithm.

with [TCP:7] being "Congestion Avoidance and Control," V. Jacobson, ACM 
SIGCOMM-88, August 1988.

So you are definitely remembering what I am remembering on at least one 
protocol.

Spencer

p.s. <obligatory newtrk rant> Oh, wait. STANDARD TCP is defined in STD 7/RFC 
793, and all of this newfangled stuff is Proposed Standard, so we're not 
supposed to deploy it anyway. "How many standards levels do you want today?" 
</obligatory newtrk rant>

From: "Fleischman, Eric" <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Sep 2005 18:05:08 -0400

> 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.

> 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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 29 Sep 2005 02:03:16 +0200

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?
jfc

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 29 Sep 2005 09:44:26 -0700 (PDT)

"JFC (Jefsey) Morfin" wrote:
> 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
> discussing a new root name interconect. But I do not think it was used
> by any other OSI operators ?
> 

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 29 Sep 2005 13:24:00 -0400

On Wed, 2005-09-28 at 16:50, Fleischman, Eric wrote:
> routers) do Y. They do Y because they are not hosts -- 

middleboxes are sometimes router-like, and sometimes host-like, and
sometimes both at the same time, and sometimes neither.

And this is just another instance whereby the specs are always
incomplete -- something new comes along which is neither host nor
router.  and, in such cases, implementors need to use their brains about
which behavior makes most sense given the context rather than
interpreting the words in the spec as if they were code.

> rather than correctly behaving as middleboxes are supposed to do.

except that I don't believe there's a single type of middlebox ...

					- Bill

---

From: Melinda Shore <[email-masked]>
Date: Thu, 29 Sep 2005 14:04:02 -0400

> except that I don't believe there's a single type of middlebox ...

There certainly isn't.  RFC 3234 created a middlebox taxonomy
based on what we knew at the time, and I think it's held up
pretty well over the past three years.  People worried about
middleboxes should probably give it a read.

Melinda