Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt

Fred Baker <fred@cisco.com> Tue, 09 May 1995 19:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08782; 9 May 95 15:35 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08778; 9 May 95 15:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14764; 9 May 95 15:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08762; 9 May 95 15:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08758; 9 May 95 15:34 EDT
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa14750; 9 May 95 15:34 EDT
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 MAA28975; Tue, 9 May 1995 12:33:55 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v02120c12abd573106e49@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 9 May 1995 12:33:59 -0700
To: John Shriver <jas@shiva.com>
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: comments on draft-ietf-iplpdn-frmib-dte-04.txt
Cc: cbrown@wellfleet.com, carvalho@cisco.com, iplpdn@CNRI.Reston.VA.US

At 3:20 PM 5/9/95, John Shriver wrote:
>The object:
>
>    frDlcmiState OBJECT-TYPE
>        SYNTAX INTEGER      {
>            noLmiConfigured (1),
>            lmiRev1         (2),
>            ansiT1_617_D    (3),  -- ANSI T1.617 Annex D
>            ansiT1_617_B    (4),  -- ANSI T1.617 Annex B
>            ccitt_933_A     (5)   -- CCITT Q933 Annex A
>        }
>        MAX-ACCESS   read-write
>        STATUS   current
>        DESCRIPTION
>           "This variable states which Data  Link  Connec-
>           tion Management scheme is active (and by impli-
>           cation, what DLCI it uses) on the  Frame  Relay
>           interface."
>       REFERENCE
>          "Draft American National Standard T1.617-1991"
>      ::= { frDlcmiEntry 2 }
>
>Is missing one value, in my reckoning.  ANSI T1.617a-1994 revises
>Annex D in an incompatible way.  (Thanks, ANSI!  The "element
>identifier" of "Link integrity verification information element" is
>changed from 0x19 to 0x03.)

What idiot did that? Did they do anything useful with the protocol (tell
you the Bc/Be/throughput values, perhaps) that would justify implementing
it?

>I'd say it should be revised to:
>
>    frDlcmiState OBJECT-TYPE
>        SYNTAX INTEGER      {
>            noLmiConfigured   (1),
>            lmiRev1           (2),  -- Interim LMI Revision 1
>            ansiT1_617_D      (3),  -- ANSI T1.617-1991 Annex D
>            ansiT1_617_B      (4),  -- ANSI T1.617-1991 Annex B
>            ccitt_933_A       (5),  -- CCITT Q933 Annex A
>            ansiT1_617_1994_D (6)   -- ANSI T1.617a-1994 Annex D
>        }
>        MAX-ACCESS   read-write
>        STATUS   current
>        DESCRIPTION
>           "This variable states which Data  Link  Connec-
>           tion Management scheme is active (and by impli-
>           cation, what DLCI it uses) on the  Frame  Relay
>           interface."
>        REFERENCE
>           "American National Standard T1.617-1991.
>           American National Standard T1.617a-1994.
>           ITU-T Recommendation Q.933 (03/93)."
>
>(Note also that many of the ANSI standard references are outdated.)

Caralyn, Charles, your opinions? Anyone else?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run