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