Subject: Question about the normative nature of IETF RFCs

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 28 Sep 2005 09:41:35 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Sep 2005 16:16:58 -0400

> 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

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 28 Sep 2005 16:36:14 -0400

> implementations (i.e., running code) were what was considered to be

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Sep 2005 16:36:45 -0400

> 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