Re: Question about the normative nature of IETF RFCs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]