Subject: [Fwd: Comments on DS0 MIB]

From: Dave Fowler <[email-masked]>
Date: Sun, 01 Feb 1998 12:51:52 -0500

All,

Enclosed are the comments that I have received from Keith on the ds0 and
ds0Bundle MIBs.
I plan to implement all of his comments as written below.  I've added
clarifications where
he raises a question.  

The whole discussion of creating ds0s and ds0Bundles will go
off into a different thread since this was discussed back in August and
no resolution was
reached.  Since no one has come forward with specific objects or MIB
text, the editor will take it upon himself to create and propose the
changes required based on his reading of the will of the group.  Any
volunteers who would like to help out with a proposal would be
appreciated.

If you have concerns about any of Keith's comments, I would ask that you
start a new thread
to keep the issues distinct.

Thanks,
David.

> 
> Dave,
> 
> Jeff Burgan asked me to review the DS0 MIB.  Below are my comments.
> 
> Keith.
> 
> ----------
> 
> > INTERNET-DRAFT                  DS0 MIB                        June 1997
> >
> >
> >                      Definitions of Managed Objects
> >                for the DS0 and DS0 Bundle Interface Type
> >
> >                       Mon Jun  2 14:52:40 EDT 1997
> >
> >
> >                    draft-ietf-trunkmib-ds0-mib-04.txt
> >
> >                          David Fowler (editor)
> >                            Newbridge Networks
> >                           [email-masked]
> >
> >  ...
> >
> > 3.2.  Use of ifTable for DS0 Layer
> >
> > The following items are defined in rfc1573 [5].
> >
> >
> >    Only the ifGeneralGroup needs to be supported.
> >
> >            ifTable Object    Use for DS0 Layer
> > ======================================================================
> >            ifIndex           Interface index.
> >
> >            ifDescr           See interfaces MIB [5]
> >
> >            ifType            ds0(81) or ds0Bundle (82)
> >
> >            ifSpeed           64000 for ds0 regardless of the setting
> >                              of robbed bit signalling
> >                              n * 64000 for ds0Bundle
> >
> >            ifPhysAddress     The value of the Circuit Identifier.
> >                              If no Circuit Identifier has been assigned
> >                              this object should have an octet string
> >                              with zero length.
> 
> I'm not a fan of putting the Circuit Identifier value in ifPhysAddress,
> since it's not an "address".  I note RFCs 1406 and 1407 derfine their
> own MIB objects to hold the Circuit Identifier.  Could that not be done
> here too ?

Yes.  We had plaaned to deprecate the circuit identifier objects in the
other
MIBS, but we are no longer doing that so I will make them all consistent
by
adding it here as well.

> 
> > ...
> >
> 
> It would be useful to include an additional section (between sections 3
> and 4) giving an "Overview of the MIB", saying:
> 
>   a. there are two MIB modules,
>   b. what groups are in each module, and their purpose.
> 
> >           ds0 MODULE-IDENTITY
> >               LAST-UPDATED "9609261755Z"
> 
> I suggest you update the date.
> 
> >           -- The DS0 Config Group
> >
> >           -- Implementation of this group is optional for all
> >           -- systems that use a DS0 Interface.
> 
> It doesn't make sense to have all objects in a MIB Module as optional.
> Something needs to be mandatory.
> 
> > ...
> >
> >         dsx0ConfigEntry OBJECT-TYPE
> >             SYNTAX  Dsx0ConfigEntry
> >             MAX-ACCESS  not-accessible
> >             STATUS  current
> >             DESCRIPTION
> >                     "An entry in the DS0 Configuration table."
> >             INDEX   { ifIndex }
> >             ::= { dsx0ConfigTable 1 }
> 
> You should state what each entry represents, i.e., add: "There is an
> entry in this table for each DS0 interface."
> 
> > ...
> >
> >           dsx0Ds0Number OBJECT-TYPE
> >               SYNTAX  INTEGER(1..31)
> >               MAX-ACCESS  read-write
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object indicates the channel number of the
> >                       ds0 on its ds1/e1."
> >               ::= { dsx0ConfigEntry 1 }
> 
> It would be clearer if this were  dsx0Ds0ChannelNumber
> 
> >           dsx0RobbedBitSignalling OBJECT-TYPE
> >               SYNTAX  TruthValue
> >               MAX-ACCESS  read-write
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object indicates if Robbed Bit Signalling is
> >                       turned on or off for a given ds0.  This only
> >                       applies to DS0s on a T1 link."
> >               ::= { dsx0ConfigEntry 2 }
> 
> Is the object present for DS0s which are not part of a T1 link ?  If so,
> what value does it have in such a case ?

This object does not apply to non-T1s, so I will specifically say that
the
object will return noSuchInstance for non-T1s.

> 
> > ...
> >
> >                   GROUP       ds0ConfigGroup
> >                   DESCRIPTION
> >                       "Implementation of this group is optional for all
> >                       systems that attach to a DS0 Interface."
> >               ::= { ds0Compliances 1 }
> 
> As above, something needs to be mandatory.
> 
> > ...
> >
> >           ds0Bundle MODULE-IDENTITY
> >               LAST-UPDATED "9609261755Z"
> 
> Update the date.
> 
> >           -- The DS0 Bonding Group
> >
> >           -- Implementation of this group is optional for all
> >           -- systems that use a DS0Bundle Interface.
> 
> As above, something in this MIB Module needs to be mandatory.

I struggled with this one a bit, but I basically agree that we need
"something" and
while BONDing doesn't apply to most bundles, the objects can then be set
to
none for mode and idle for status.  
> 
> > ...
> >
> >           dsx0BondingEntry OBJECT-TYPE
> >               SYNTAX  Dsx0BondingEntry
> >               MAX-ACCESS  not-accessible
> >               STATUS  current
> >               DESCRIPTION
> >                       "An entry in the DS0 Bonding table."
> >               INDEX   { ifIndex }
> >               ::= { dsx0BondingTable 1 }
> 
> You should state what each entry represents, i.e., add: "There is an
> entry in this table for each DS0 bundle interface."
> 
> >           dsx0BondMode OBJECT-TYPE
> >               SYNTAX  INTEGER {
> >                           dsx0BondModeNone(1),
> >                           dsx0BondModeOther(2),
> 
> It's unusual to have the table's prefix as the prefix for each label,
> particularly for 'none' and 'other'.
> 
> >           dsx0BondStatus OBJECT-TYPE
> >               SYNTAX  INTEGER {
> >                           dsx0BondIdle(1),
> >                           dsx0BondCallSetup(2),
> >                           dsx0BondDataTransfer(3)
> 
> Again, it's unusual to have the table's prefix as the prefix for each label.
> 
> >           dsx0BondRowStatus OBJECT-TYPE
> >               SYNTAX  RowStatus
> >               MAX-ACCESS  read-create
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object is used to create new rows in this
> >                       table, modify existing rows, and to delete
> >                       existing rows."
> >               ::= { dsx0BondingEntry 3 }
> 
> If there is an entry in this table for each DS0 bundle interface, then
> this object is not needed.  If there's not an entry in this table for
> each DS0 bundle interface, then you need to say why entries are created
> in this table and why they are deleted.

Given that we need "something" to be mandatory and this is the only
table, I
will remove the row status.

> 
> >           --
> >           -- The DS0 Bundle Stub Group
> >           --
> 
> Why is this named using the term "stub" ?

This was a proposal posted by Maria Greene in July of 1996.  There was,
unfortunately, no discussion on the list so I just stuck it in "as is",
hoping there would be some
comments.  Keith's are the first.  As I mentioned at the top of the
mail, the
creation of ds0s and ds0Bundles will go off into a different thread.  I
will include
a modified version of this table and it's objects in that mail.

> 
> >           dsx0BundleStubNextIndex OBJECT-TYPE
> >               SYNTAX  TestAndIncr
> >               MAX-ACCESS  read-write
> >               STATUS  current
> >               DESCRIPTION
> >                       "This object is used to assist the manager in
> >                       selecting a value for dsx0BundleStubIndex.
> >                       Because this object is of syntax TestAndIncr (see
> >                       the SNMPv2-TC document, RFC1903) it can also be
> >                       used to avoid race conditions with multiple
> >                       managers trying to create rows in the table. The
> >                       alorithm is:
> >                       while done == false
> >                           index = GET (dsx0BundleStubNextIndex.0)
> >                           SET (dsx0BundleStubNextIndex.0=index,
> >                                dsx0BundleStubRowStatus.index=createAndGo)
> >
> >                           if errorindex == 1 (failure was because of the
> >                                              TestAndIncr object)
> >                               done = false
> >                           else
> >                               done = true
> >                               other error handling"
> >               ::= { ds0Bundle 2 }
> 
> It would be better to specify the algorithm in a more protocol-independent
> manner, so that people (e.g., NM application developers) not familiar with
> the specifics of SNMP's error-index can understand it more easily.

Agreed.  I'll see what I can do.

> 
> > ...
> >
> >               MODULE  -- this module
> >                   GROUP       ds0BondingGroup
> >                   DESCRIPTION
> >                       "Implementation of this group is optional for all
> >                       systems that attach to a DS0Bundle Interface."
> >
> >                   GROUP       ds0BundleStubGroup
> >                   DESCRIPTION
> >                       "Implementation of this group is optional for all
> >                       systems that attach to a DS0Bundle Interface."
> >               ::= { ds0BundleCompliances 1 }
> 
> Again, something needs to be mandatory.
> 
> >
> >           ds0BundleStubGroup  OBJECT-GROUP
> >               OBJECTS { dsx0BundleStubNextIndex,
> >                         dsx0BundleStubIndex,
> >                         dsx0BundleStubIfIndex,
> >                         dsx0BundleStubRowStatus }
> >               STATUS  current
> >               DESCRIPTION
> 
> Don't include auxiliary objects (i.e., dsx0BundleStubIndex) in the group.

-- 
David Fowler                                   email:
[email-masked]
Newbridge Networks Corporation                 voice: (613) 599-3600 
ext.6559
600 March Rd, Kanata, Ontario, Canada K2K 2E6  fax:   (613) 599-3619

Subject: Comments on DS0 MIB
From: Keith McCloghrie <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked] (Keith McCloghrie)
Date: Mon, 15 Dec 1997 00:30:06 -0800 (PST)

Dave,

Jeff Burgan asked me to review the DS0 MIB.  Below are my comments.

Keith.

----------

> INTERNET-DRAFT                  DS0 MIB                        June 1997
> 
> 
>                      Definitions of Managed Objects
>                for the DS0 and DS0 Bundle Interface Type
> 
>                       Mon Jun  2 14:52:40 EDT 1997
> 
> 
>                    draft-ietf-trunkmib-ds0-mib-04.txt
> 
>                          David Fowler (editor)
>                            Newbridge Networks
>                           [email-masked]
> 
>  ...
> 
> 3.2.  Use of ifTable for DS0 Layer
> 
> The following items are defined in rfc1573 [5].
> 
>
>    Only the ifGeneralGroup needs to be supported.
> 
>            ifTable Object    Use for DS0 Layer
> ======================================================================
>            ifIndex           Interface index.
> 
>            ifDescr           See interfaces MIB [5]
> 
>            ifType            ds0(81) or ds0Bundle (82)
> 
>            ifSpeed           64000 for ds0 regardless of the setting
>                              of robbed bit signalling
>                              n * 64000 for ds0Bundle
> 
>            ifPhysAddress     The value of the Circuit Identifier.
>                              If no Circuit Identifier has been assigned
>                              this object should have an octet string
>                              with zero length.

I'm not a fan of putting the Circuit Identifier value in ifPhysAddress,
since it's not an "address".  I note RFCs 1406 and 1407 derfine their
own MIB objects to hold the Circuit Identifier.  Could that not be done
here too ?

> ...

It would be useful to include an additional section (between sections 3
and 4) giving an "Overview of the MIB", saying:

  a. there are two MIB modules,
  b. what groups are in each module, and their purpose.

>           ds0 MODULE-IDENTITY
>               LAST-UPDATED "9609261755Z"

I suggest you update the date.

>           -- The DS0 Config Group
> 
>           -- Implementation of this group is optional for all
>           -- systems that use a DS0 Interface.

It doesn't make sense to have all objects in a MIB Module as optional.
Something needs to be mandatory.

> ...
>
>         dsx0ConfigEntry OBJECT-TYPE
>             SYNTAX  Dsx0ConfigEntry
>             MAX-ACCESS  not-accessible
>             STATUS  current
>             DESCRIPTION
>                     "An entry in the DS0 Configuration table."
>             INDEX   { ifIndex }
>             ::= { dsx0ConfigTable 1 }

You should state what each entry represents, i.e., add: "There is an
entry in this table for each DS0 interface."

> ...
>
>           dsx0Ds0Number OBJECT-TYPE
>               SYNTAX  INTEGER(1..31)
>               MAX-ACCESS  read-write
>               STATUS  current
>               DESCRIPTION
>                       "This object indicates the channel number of the
>                       ds0 on its ds1/e1."
>               ::= { dsx0ConfigEntry 1 }

It would be clearer if this were  dsx0Ds0ChannelNumber

>           dsx0RobbedBitSignalling OBJECT-TYPE
>               SYNTAX  TruthValue
>               MAX-ACCESS  read-write
>               STATUS  current
>               DESCRIPTION
>                       "This object indicates if Robbed Bit Signalling is
>                       turned on or off for a given ds0.  This only
>                       applies to DS0s on a T1 link."
>               ::= { dsx0ConfigEntry 2 }

Is the object present for DS0s which are not part of a T1 link ?  If so,
what value does it have in such a case ?

> ...
>
>                   GROUP       ds0ConfigGroup
>                   DESCRIPTION
>                       "Implementation of this group is optional for all
>                       systems that attach to a DS0 Interface."
>               ::= { ds0Compliances 1 }

As above, something needs to be mandatory.

> ...
> 
>           ds0Bundle MODULE-IDENTITY
>               LAST-UPDATED "9609261755Z"

Update the date.

>           -- The DS0 Bonding Group
> 
>           -- Implementation of this group is optional for all
>           -- systems that use a DS0Bundle Interface.

As above, something in this MIB Module needs to be mandatory.

> ...
> 
>           dsx0BondingEntry OBJECT-TYPE
>               SYNTAX  Dsx0BondingEntry
>               MAX-ACCESS  not-accessible
>               STATUS  current
>               DESCRIPTION
>                       "An entry in the DS0 Bonding table."
>               INDEX   { ifIndex }
>               ::= { dsx0BondingTable 1 }

You should state what each entry represents, i.e., add: "There is an
entry in this table for each DS0 bundle interface."
 
>           dsx0BondMode OBJECT-TYPE
>               SYNTAX  INTEGER {
>                           dsx0BondModeNone(1),
>                           dsx0BondModeOther(2),

It's unusual to have the table's prefix as the prefix for each label,
particularly for 'none' and 'other'.
 
>           dsx0BondStatus OBJECT-TYPE
>               SYNTAX  INTEGER {
>                           dsx0BondIdle(1),
>                           dsx0BondCallSetup(2),
>                           dsx0BondDataTransfer(3)

Again, it's unusual to have the table's prefix as the prefix for each label.

>           dsx0BondRowStatus OBJECT-TYPE
>               SYNTAX  RowStatus
>               MAX-ACCESS  read-create
>               STATUS  current
>               DESCRIPTION
>                       "This object is used to create new rows in this
>                       table, modify existing rows, and to delete
>                       existing rows."
>               ::= { dsx0BondingEntry 3 }

If there is an entry in this table for each DS0 bundle interface, then
this object is not needed.  If there's not an entry in this table for
each DS0 bundle interface, then you need to say why entries are created
in this table and why they are deleted.

>           --
>           -- The DS0 Bundle Stub Group
>           --
 
Why is this named using the term "stub" ?

>           dsx0BundleStubNextIndex OBJECT-TYPE
>               SYNTAX  TestAndIncr
>               MAX-ACCESS  read-write
>               STATUS  current
>               DESCRIPTION
>                       "This object is used to assist the manager in
>                       selecting a value for dsx0BundleStubIndex.
>                       Because this object is of syntax TestAndIncr (see
>                       the SNMPv2-TC document, RFC1903) it can also be
>                       used to avoid race conditions with multiple
>                       managers trying to create rows in the table. The
>                       alorithm is:
>                       while done == false
>                           index = GET (dsx0BundleStubNextIndex.0)
>                           SET (dsx0BundleStubNextIndex.0=index,
>                                dsx0BundleStubRowStatus.index=createAndGo)
> 
>                           if errorindex == 1 (failure was because of the
>                                              TestAndIncr object)
>                               done = false
>                           else
>                               done = true
>                               other error handling"
>               ::= { ds0Bundle 2 }
 
It would be better to specify the algorithm in a more protocol-independent
manner, so that people (e.g., NM application developers) not familiar with
the specifics of SNMP's error-index can understand it more easily.

> ...
>
>               MODULE  -- this module
>                   GROUP       ds0BondingGroup
>                   DESCRIPTION
>                       "Implementation of this group is optional for all
>                       systems that attach to a DS0Bundle Interface."
> 
>                   GROUP       ds0BundleStubGroup
>                   DESCRIPTION
>                       "Implementation of this group is optional for all
>                       systems that attach to a DS0Bundle Interface."
>               ::= { ds0BundleCompliances 1 }

Again, something needs to be mandatory.

> 
>           ds0BundleStubGroup  OBJECT-GROUP
>               OBJECTS { dsx0BundleStubNextIndex,
>                         dsx0BundleStubIndex,
>                         dsx0BundleStubIfIndex,
>                         dsx0BundleStubRowStatus }
>               STATUS  current
>               DESCRIPTION
 
Don't include auxiliary objects (i.e., dsx0BundleStubIndex) in the group.