Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Dumb question: ping w/o icmp support?
Summary: We should be able to determine conformance
Message-ID: <25597@bu-cs.BU.EDU>
Date: 24 Oct 88 17:58:44 GMT
References: <Oct.20.21.31.00.1988.356@athos.rutgers.edu> <8810221819.AA10475@nsipo.arc.nasa.gov>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston Univ. Information Tech. Dept.
Lines: 31

In article <8810221819.AA10475@nsipo.arc.nasa.gov> 
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
>
>There are implementations out there that fail to support ICMP. [...]
>

>I personally know of several implementations which are broken in the
>above ways, but I'd probably get sued if I spoke up on the net.  
>							Milo


	I can practically guarantee that:
	a) those fingered vendors would fix their products
	b) you would get sued
What a shame.  The Host Req'ts RFC is a big step forward, even
contains an easily abused checklist (as all the authors will take
pains over the coming years to point out everytime they speak in
public :-), but there is no way anyone can actually *SAY* what their
research shows is true, ie vendor X is not in compliance with
paragraph 3.1.2.3. (Not without considerable risk.)

	Well, I shouldn't complain.  Just gives me an excuse to go to
a conference and have Milo tell me in person what a crock such and
such is.

	A year or so after the Host RFC, maybe we could share
LANalyzer (or your favorite Ethernet analyzer) programs that check all
the RFC points?  Let the LANalyzer do the talking!  Probably
impractical, but wouldn't be nice to plug a new box into a protocol
testing box and watch the red light and the green light?  (I know, I'm
lazy and no fun at all.)