Re: Multicast in draft version 5 comments

[Alan Bartky <[e-mail]>]

Keith  -

I have read your response and also review RFC 1442 and reviewed
previous work in other MIBs (particualary RFC 1747 which I
co-authored).

As far as the use of read-write versus read-create, I have
never quite understood when to use one versus the other.
I do know that we published RFC 1747 with read-write objects
that had DEFVAL clauses for them.  In the SDLC MIB we did this
for all objects related to the SDLC port level.  The port level
table did not have a RowStatus object and was therefore
note createable via SNMP.  The SDLC Link Station Level did
have a RowStatus object, and all "writeable" objects had
read-create with a DEFVAL clause.

Although I was not directly involved in the "SNMP Details"
in editing the RFC, my recollection was that objects at the
port level were read-write since the port level table for
SDLC could not be "created", whereas the link station table
entries had to be created by the SNMP manager since SDLC
link stations had to be configured and could not be learned
via the network (certanly the case for primary SDLC which
initiates the polling).

In the SDLC MIB we had DEFVAL for both read-write and read-create
objects.  If this is not valid, then it made it all the way
through the RFC process without being corrected.  When we
were drafting the MIB, we felt it very important for the 
agent and the manager to have proper default values to
insure proper operation and interoperability of the protocol.
This is why we had DEFVALs for every protocol specific read-write
and read-create objects.

As far as the current draft of the Frame Relay MIB is concerned
it has no read-create objects, and it has many read-write objects
with DEFVALs defined.  It also has RowStatus defined for both the
port level (frDlcmi) and for the virtual circuit level (frCircuit).
It also has the additional complexity of a virtual circuit either
learned automatically from the network (dynamic type, where the
row must created by the SNMP agent) or configured by a user (static
type, where the row is created using Row Creation and SNMP Set
commands).

It appears as though at a minimum the frCircuit table objects
that are currently all read-write, should be changed to 
read-create (although since I am not an SNMP V2 syntax expert
this may obviously not be correct).  If that were true than
the object should be changed to:

      frCircuitMulticast OBJECT-TYPE
          SYNTAX   INTEGER    {
                      unicast   (1),
                      oneWay    (2),
                      twoWay    (3),
                      nWay      (4)
                      }
          MAX-ACCESS   read-create
          STATUS   current
          DESCRIPTION
             "This indicates whether this VC is used as a unicast
             VC (i.e. not multicast) or the type of multicast
             service subscribed to"
          REFERENCE
             "Frame Relay PVC Multicast Service and Protocol
              Description Implementation: FRF.7
              Frame Relay Forum Technical Committe
              October 21, 1994"
          DEFVAL {unicast}  -- the default value of frCircuitMulticast is
                            -- "unicast" (not a multicast VC).
          ::= { frCircuitEntry 15 }
  
Other objects in the frCircuit table that are read-write, have
DEFVAL defined and may have to get changed to read-create are:

frCircuitState
frCircuitCommittedBurst
frCircuitThroughput


Entries defined in the frDlcmi table that are read-write,
have DEFVAL defined and may have to get changed to read-create are:

frDlcmiPollingInterval
frDlcmiFullEnquiryInterval
frDlcmiErrorThreshold
frDlcmiMonitoredEvents

In summary, it looks like the MIB could use a good "going over"
by someone more knowledgeable about the details of
SNMP V2 syntax and conventions.

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer
XYLAN Corporation                    Voice:[phone]
15707 ROCKFIELD BLVD STE 155F        FAX:  [phone]
IRVINE CA 92718-2830
**********************************************************

Excerpt from my original message and Keith's response is below:

> >      frCircuitMulticast OBJECT-TYPE
> >          SYNTAX   INTEGER    {
> >                      unicast   (1),
> >                      oneWay    (2),
> >                      twoWay    (3),
> >                      nWay      (4)
> >                      }
> >          MAX-ACCESS   read-write
> >          STATUS   current
> >          DESCRIPTION
> >             "This indicates whether this VC is used as a unicast
> >             VC (i.e. not multicast) or the type of multicast
> >             service subscribed to"
> >          REFERENCE
> >             "Frame Relay PVC Multicast Service and Protocol
> >              Description Implementation: FRF.7
> >              Frame Relay Forum Technical Committe
> >              October 21, 1994"
> >          DEFVAL {1}  -- the default value of frCircuitMulticast is
> >                      -- "unicast" (not a multicast VC).
> >          ::= { frCircuitEntry 15 }
>  
> On the usage of DEFVAL, RFC 1442 says:
> 
>           7.9.  Mapping of the DEFVAL clause
> 
>           The DEFVAL clause, which need not be present, defines an
>           acceptable default value which may be used at the discretion
>           of a SNMPv2 entity acting in an agent role when an object
>           instance is created.
> 
> Note that it is specified for usage when an instance is *created* via
> SNMP.  Thus, DEFVAL is only appropriate when the MAX-ACCESS clause is
> read-create.  For read-only/read-write objects, any mention of a default
> value should go in the DESCRIPTION clause.
> 
> Keith.
>