Re: RFC 1209 (IP over SMDS) advancement to Draft Standard

Andy Malis <malis@maelstrom.timeplex.com> Mon, 13 February 1995 15:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02112; 13 Feb 95 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02108; 13 Feb 95 10:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06839; 13 Feb 95 10:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02007; 13 Feb 95 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02003; 13 Feb 95 10:05 EST
Received: from maelstrom.acton.timeplex.com by CNRI.Reston.VA.US id aa06791; 13 Feb 95 10:05 EST
Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id KAA07710; Mon, 13 Feb 1995 10:01:17 -0500
Received: from maelstrom.timeplex.com (malis@localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id KAA15948; Mon, 13 Feb 1995 10:01:14 -0500
Message-Id: <199502131501.KAA15948@enigma.acton.timeplex.com>
To: stev@ftp.com
cc: malis@maelstrom.timeplex.com, iesg@CNRI.Reston.VA.US, iplpdn@CNRI.Reston.VA.US, malis@maelstrom.acton.timeplex.com, dave@corecom.com, jcl@mail.bellcore.com, clapp@ameris.center.il.ameritech.com, stev+iesg@ftp.com
Subject: Re: RFC 1209 (IP over SMDS) advancement to Draft Standard
In-reply-to: Your message of "Fri, 10 Feb 1995 14:32:49 EST." <9502101932.AA13502@mailserv-D.ftp.com>
Date: Mon, 13 Feb 1995 10:01:13 -0500
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andy Malis <malis@maelstrom.timeplex.com>

Stev,

> this is an interesting message. is there one implementation that does 
> *everything* in the RFC?

It's interesting that XID came up, because the text in the RFC is
fairly innocuous concerning it:

   While not necessary for supporting IP and ARP, all implementations
   MUST support IEEE 802.2 standard Class I service in order to be
   compliant with IEEE 802.2.  Some of the functions are not related
   directly to the support of the SNAP SAP (e.g., responding to XID and
   TEST commands directed to the null or global SAP addresses), but are
   part of a general LLC implementation.  Both [4] and [5] describe the
   minimum functionality necessary for a conformant station.
   Implementors should also consult IEEE Std. 802.2 [14] for details.

So, in this case at least, XID support is really a question of IEEE
and SMDS conformance rather than RFC 1209 conformance.

To answer Stev's question more directly, I specifically asked what
features weren't supported in each implementation, and in most cases
the indication, either explicit or implied, was that it was a full
implementation.  In my message, I listed the reported exceptions.

Cheers,
Andy