Re: Question about the normative nature of IETF RFCs
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
RE: Question about the normative nature of IETF RFCs
On Wed, 2005-09-28 at 16:50, Fleischman, Eric wrote: 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 -- 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
On 9/29/05 1:24 PM, Bill Sommerfeld [EMAIL PROTECTED] wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Question about the normative nature of IETF RFCs
Friends, When did we in the IETF first begin to view our standards track RFCs to be normative? Specifically, when I first became associated with you all in 1992, the RFCs of most IETF standards were incomplete and the reference implementations (i.e., running code) were what was considered to be normative. At a certain point (very late 90s??) the IETF began to reference the text of its standards track RFCs as if the RFC texts themselves were normative (e.g., in an OSI or ITU-like manner). When did that transition occur? Was there a specific event that marked that transition (e.g., a POISED WG)?? Did we formally document this evolution somewhere? Do we currently consider today the reference implementations to be more (or less??) normative than the RFC texts themselves? Thanks! --Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
Specifically, when I first became associated with you all in 1992, the RFCs of most IETF standards were incomplete and the reference implementations (i.e., running code) were what was considered to be normative. I've been involved with IETF since circa 1990 and have always been of the impression that standards-track RFCs - not implementations - were intended to be normative. Frankly I don't see how it could be any other way. While a discrepancy between an implementation and a specification _might_ be due to a flaw in the specification, it is at least as likely to be due to a flaw in the implementation - and the specification is the primary definition of the protocol, whereas any particular implementation is merely an artifact. Also, every single attempt I have seen to try to derive a normative specification of a protocol from an implementation has produced a document which failed to adequately specify the protocol. 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. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
On Wed, 2005-09-28 at 12:41, Fleischman, Eric wrote: Specifically, when I first became associated with you all in 1992, the RFCs of most IETF standards were incomplete and the reference implementations (i.e., running code) were what was considered to be normative. I didn't get directly involved in the IETF until a few years after 1992 but I've never encountered an attitude from any old-timer that any single reference implementation of any protocol could be considered as more normative than the spec. Indeed, I recall lots of complaints in the late 80's about specific commonly used implementations as being broken in various ways. The closest thing to that was more of a sense that the collective behavior of the environment/ecosystem/community/... of interoperable implementations present on the Internet, *considered as a whole*, filled in gaps in the specs, and that when in doubt, you should ask a bunch of implementers how they interpreted the spec. I do recall a passing comment from Jeff Schiller -- probably in late 1988 or early 1989, but I may be off by a year in either direction -- that the IETF was attempting to move towards less wiggle room in the specs -- in particular, describing higher-level behavior in addition to packet layouts and the semantics of packet fields -- and I think that was around the time of the Host Requirements RFC's (1122 and 1123). So I'd split your statement in half: the specs are incomplete? Yes. (And they always will be, because it's always possible that someone will come along and find some dark corner or some unanticpated way to use them). But the reference implementation as normative? never. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
On Wednesday, September 28, 2005 04:16:58 PM -0400 Keith Moore moore@cs.utk.edu wrote: Specifically, when I first became associated with you all in 1992, the RFCs of most IETF standards were incomplete and the reference implementations (i.e., running code) were what was considered to be normative. I've been involved with IETF since circa 1990 and have always been of the impression that standards-track RFCs - not implementations - were intended to be normative. Frankly I don't see how it could be any other way. While a discrepancy between an implementation and a specification _might_ be due to a flaw in the specification, it is at least as likely to be due to a flaw in the implementation - and the specification is the primary definition of the protocol, whereas any particular implementation is merely an artifact. Also, every single attempt I have seen to try to derive a normative specification of a protocol from an implementation has produced a document which failed to adequately specify the protocol. 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. Absolutely. Some protocols do have a de-facto reference implementation, but that's just something to test against; it doesn't override the spec. However, in the real world, it would be foolish for an implementor _not_ to do interoperability testing against other well-known implementations, and to at least consider fixing any problems that are found. Sometimes, that means being prepared to accept behavior not permitted by the spec. Similarly, any IETF effort to update or extend a protocol should take into account behavior of deployed implementations, even if they are non-compliant. The goal here is to build and maintain a working, stable, interoperable Internet, not to be protocol lawyers. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about the normative nature of IETF RFCs
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 PROTECTED] 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
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
Re: Question about the normative nature of IETF RFCs
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 PROTECTED] 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
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 At 00:05 29/09/2005, Keith Moore wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
