Re: musings

Fred Baker <fred@cisco.com> Thu, 16 May 1996 19:09 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22093; 16 May 96 15:09 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22086; 16 May 96 15:09 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00879; 16 May 96 15:09 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-23) id <AA02045>; Thu, 16 May 1996 11:45:25 -0700
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id <AA02038>; Thu, 16 May 1996 11:45:23 -0700
Received: from stilton.cisco.com by venera.isi.edu (5.65c/5.61+local-23) id <AA09132>; Thu, 16 May 1996 11:45:22 -0700
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA10115; Thu, 16 May 1996 11:45:03 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v02140b1cadc1228d2d1a@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 16 May 1996 11:45:06 -0700
To: braden@isi.edu
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: musings
Cc: rreq@isi.edu, braden@isi.edu
X-Orig-Sender: owner-rreq@isi.edu
Precedence: bulk

At 3:30 PM 5/15/96, braden@ISI.EDU wrote:
>The Internet has succeeded because its gurus were willing to be
>pragmatic, doing what worked.  You have to balance the (probably
>significant) benefits in the real world of making rreq a full Standard
>against the improvements in it that may result from holding out for
>interoperable implementations.
>
>But it is not clear to me that there is a
>non-trivial content in DEMONSTRATING interoperability of two
>rreq-conformant routers.

My problem is finding rreq-conformant routers. I don't think anything
should be a full standard that doesn't at least have one fully conformant
implementation for each thing that it specifies.

I will have to go through my router and 1812 side by side to answer my own
question thoroughly, but off-hand I can tell you that Cisco does not and
cannot claim full compliance (and depending on how you read the following
paragraph, may not be able to claim conditional compliance) because the
consensus of the working group that went into the document was
non-pragmatic in some respects. Specifically, the spec says

   PPP MUST be supported on all general purpose serial interfaces on a
   router.  The router MAY allow the line to be configured to use point
   to point line protocols other than PPP.  Point to point interfaces
   SHOULD either default to using PPP when enabled or require
   configuration of the link layer protocol before being enabled.
   General purpose serial interfaces SHOULD require configuration of the
   link layer protocol before being enabled.

This is toned down from RFC 1716, the historical predecessor to 1812; that
document said:

   PPP MUST be supported on all general purpose serial interfaces on
   a router.  The router MAY allow the line to be configured to use
   serial line protocols other than PPP, all general purpose serial
   interfaces MUST default to using PPP.

Cisco routers, if you enable point to point interface and don't specify an
encapsulation, use a proprietary protocol that predates PPP. If we change
that default, we unilaterally change the configuration of our customer's
routers. Guess what, they would report that as a bug.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Meddle not in the affairs of dragons, for you are crunchy and taste
good with ketchup.