Comments to version 5.0 of Frame Relay DTE MIB

[Alan Bartky <[e-mail]>]

To Frame Relay MIBbers -

Thanks to Nipun Basil of Develcon (who was kind enough
to respond to my email), I now have a copy of the July
1995, Version 5 Frame Relay Draft MIB.  I have edited
my last contribution to bring it "up to date".  Most
of my comments still apply to the current version.

I have also removed comments for changes/additions that I
considered to be OK.



******************
General Comments:
******************

1) The "frErr" section is missing.  Looks like a typo by
the editor of the document in that there is a .ro command at the
end of an object as follows:

>             If it is not so defined, as would be the case with an
>             ipAddrEntry, it should be of type Other."
>         ::= { frCircuitEntry 20 }.so frErrTable.v2

I have kept the comments on the frErrTable section in this
contribution based on Version 4 of the draft.

2) The RFC must be drafted in accordance to RFC1573 which states
that new MIBs must state things such as how the Interface 
MIB for this sub layer is handled (e.g. Which octects are
counted for ifInOctects).  A lot of this text and
guidelines can be borrowed from RFC 1604 (The Frame Relay
DCE MIB).  RFC1573 should also be mentioned in the text
and added to the Reference section of the document.  RFC1604
probably deserves a reference also.

3) This may seem like a nit, but it makes comparison harder.
Many of the description fields are now indented/formatted differently.
This makes it difficult to see what real changes have occurred
using a "diff -w" Unix command between the two MIBs (RFC 1315
and the current draft).

4. In the example showing the relation of ifIndex for frame
relay and lower devices, I would use (and also reference)
the latest RS-232 MIB (RFC 1659) since it would be the one most
agents would use in conjuction with RFC 1573 Interface MIB
layering table.


*******************
Specific Comments:
*******************

<                  ansiT1-617-D    (3),  -- ANSI T1.617 Annex D
<                  ansiT1-617-B    (4)   -- ANSI T1.617 Annex B

Was changed to:

>              ansiT1-617D      (3),  -- ANSI T1.617 Annex D
>              ansiT1-617B      (4),  -- ANSI T1.617 Annex B
>              ituT-933A        (5),  -- CCITT Q933 Annex A
>              ansiT1-617-1994D (6)   -- ANSI T1.617a-1994 Annex D

Currently RFC 1604 has a similar object and is:

 frLportVCSigProtocol OBJECT-TYPE
     SYNTAX  INTEGER {
               none(1),
               lmi(2),
               ansiT1617D(3),
               ansiT1617B(4),
               ccittQ933A(5)
             }

Comment: I would suggest that to make it consistent between RFC 1604 and the 
current draft Frame Relay DTE MIB that the same names be used from
frLportVCSigProtocol in RFC 1604 (even though the CCITT is now 
the ITU-T, it is better to keep things consistent where possible
between the two RFCs).  Other MIBs have also gotten rid of dash '-'
characters as I believe they cause problems with some MIB compilers.

Also are there any differences between T1.617D and T1.617a-1994 Annex D??
If so what are they??  Do they merit a separate MIB Object value??

frDlcmiStatus was added:

> 
>      frDlcmiStatus OBJECT-TYPE
>          SYNTAX   INTEGER    {
>                      running      (1),    -- init complete, system running
>                      fault        (2),    -- error threshold exceeded
>                      initializing (3)     -- system start up
>                      }
>          MAX-ACCESS   read-only
>          STATUS   current
>          DESCRIPTION
>             "This indicates the status of the Frame Relay interface
>             as determined by the performance of the dlcmi.  If no
>             dlcmi is running, the Frame Relay interface will stay
>             in the running state indefinately."
>          ::= { frDlcmiEntry 11 }
> 
Comment: change "indefinately" to "indefinitely" (spelling).


For frDlcimAddressLen

<                      two-octets (2),
<                      three-octets (3),
<                      four-octets (4)

was changed to:

>                 twoOctets (2),
>                 threeOctets (3),
>                 fourOctets (4)

rfc 1604 has a similar object:

 frLportAddrDLCILen OBJECT-TYPE
     SYNTAX  INTEGER {
      twoOctets10Bits(1),
      threeOctets10Bits(2),
      threeOctets16Bits(3),
      fourOctets17Bits(4),
      fourOctets23Bits(5)
    }


Comment: With the widespread use of RFC1315, and the imcompatibilities
between the two sets of values, it does not make
sense to align the two sets of values.  However it
is important to at least comment on how many bits per
byte is meant in the replacement for RFC1315.  This
is important because for three octet and four octet
values there are two bit length options.

 
Text for frCircuitState was changed:

<                 temporarily disable a given circuit."
---
>            temporarily disable a given circuit.
> 
>            The use of 'invalid' is deprecated in this SNMP
>            Version 2 MIB, in favor of frCircuitRowStatus."

The full object and text in the new draft are as follows
(Note this text is actually from the previous draft,
only the indentation/formatting of the text is different):

   frCircuitState OBJECT-TYPE
        SYNTAX   INTEGER    {
                    invalid (1),
                    active (2),
                    inactive (3)
                 }
        MAX-ACCESS   read-write
        STATUS   current
        DESCRIPTION
           "Indicates whether the particular virtual  cir-
           cuit  is operational.  In the absence of a Data
           Link Connection Management  Interface,  virtual
           circuit  entries  (rows) may be created by set-
           ting virtual  circuit  state  to  'active',  or
           deleted by changing Circuit state to 'invalid'.

           Whether or not the row actually  disappears  is
           left  to the implementation, so this object may
           actually read as 'invalid' for  some  arbitrary
           length  of  time.   It is also legal to set the
           state of a virtual  circuit  to  'inactive'  to
           temporarily disable a given circuit.

           The use of 'invalid' is deprecated in this SNMP
           Version 2 MIB, in favor of frCircuitRowStatus."
       DEFVAL { active }
       ::= { frCircuitEntry 3 }


Comments:  If Invalid is truly drepecated (is it??) for
both read and write than first the  line:

                    invalid (1),

Should be changed (as in other updated MIBs) to:

                    invalid (1), -- deprecated

And the Description text needs to be properly reworded.

If it is still possible to use invalid for writes, or to
get invalid for reads, then it is not really deprecated.

We must state how invalid applys (if at all).



New frCircuitEntry objects were added.  Comments added
below within the text:

>     frCircuitMulticast OBJECT-TYPE
>         SYNTAX   INTEGER    {
>                     unicast   (1),
>                     multicast (2)
>                     }
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "This indicates whether this VC is  used  as  a
>            multicast VC or a single destination"
>        ::= { frCircuitEntry 15 }

Comments: Currently the Frame Relay Forum Multicast Implementation
agreement defines several types of Multicast.  You might want to
change this to:
                      unicast         (1),
                      oneWayMulticast (2)
                      twoWayMulticast (3),
                      nWayMulticast   (4)

> 
>     frCircuitType OBJECT-TYPE
>         SYNTAX   INTEGER    {
>                     static  (1),
>                     dynamic (2)
>                  }
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "Indication of  whether  the  VC  was  manually
>            created   (static),   or   dynamically  created
>            (dynamic) via the data link  control  managment
>            interface."
>        ::= { frCircuitEntry 16 }
>

Comments: You might want to change "created" to "created or
configured by a network management entity".  Also "managment"
should be changed to "management" (spelling).

> 
>     frCircuitDiscards OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "The number of inbound frames  dropped  because
>            of  format  errors,  or because the VC is inac-
>            tive."
>        ::= { frCircuitEntry 17 }
> 
> 
>     frCircuitRowStatus OBJECT-TYPE
>         SYNTAX   RowStatus
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "The SNMP Status of the row, used in row  crea-
>            tion."
>        ::= { frCircuitEntry 18 }
>

Comments: I would make this the last object (#19). 
> 
> 
>     frCircuitReceivedDEs OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "Number of frames received from the network in-
>            dicating  that  they  were eligible for discard
>            since the virtual circuit  was  created.   This
>            occurs when the remote DTE sets the DE flag, or
>            when in remote DTE's switch  detects  that  the
>            frame was received as Excess Burst data."
>        REFERENCE
>           "American National  Standard  T1.618-1991,
>           Section 3.3.4"
>       ::= { frCircuitEntry 19 }
> 
> 
>


Comments: Change to object #18 (so Row status is last).

NOTE the comments below are for frErrType.  Apparently due
to the .so frErrTable.v2 NROFF command being ignored (see above)
it was not in version 5 (July version).  Therefore I am
keeping my comments in based on the last posting.


For frErrType:
<                          unknownDLCI(5),
<                          dlcmiProtoErr(6),
<                          dlcmiUnknownIE(7),
<                          dlcmiSequenceErr(8),
<                          dlcmiUnknownRpt(9),
<                          noErrorSinceReset(10)

Was changed to:

>                     dlcmiProtoErr(5),
>                     dlcmiUnknownIE(6),
>                     dlcmiSequenceErr(7),
>                     dlcmiUnknownRpt(8),
>                     noErrorSinceReset(9)

Comments: To keep backwards compatible with RFC1315, you cannot
delete unknownDLCI(5) and renumber the others.  You must deprecate
it as follows:

<                          unknownDLCI(5),       -- deprecated
<                          dlcmiProtoErr(6),
<                          dlcmiUnknownIE(7),
<                          dlcmiSequenceErr(8),
<                          dlcmiUnknownRpt(9),
<                          noErrorSinceReset(10)

and you should state why it was deprecated.(Why was it deprecated??
I'd sure like to know.)

for frErrData

<              SYNTAX   OCTET STRING
<              ACCESS   read-only
<              STATUS   mandatory

Was changed to:

>         SYNTAX   OCTET STRING (SIZE(1..1600))
>         MAX-ACCESS   read-only
>         STATUS   current

Comments: Is specifying this size for the manager?  Because
I would think it would be impractical to have systems with
multiple ports of frame relay to store large frames for every 
port in the system. 1600 bytes per port adds up very quickly.


**********************
End specific comments
************************

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer          Voice:[phone]
XYLAN Corporation                    FAX:  [phone]
15707 Rockfield Avenue Suite 155F
Irvine CA. 92718
**********************************************************