Re: Multicast in draft version 5 comments

[Keith McCloghrie <[e-mail]>]

Alan,

I had not previously looked at the MIB, until seeing your message.
It is certainly true that the two RowStatus objects must be read-create,
since RFC 1442 says:

          7.7.1.  Creation and Deletion of Conceptual Rows

          For newly-defined conceptual rows which allow the creation of
          new object instances and the deletion of existing object
          instances, there should be one columnar object with a SYNTAX
          clause value of RowStatus (a textual convention defined in
          [3]) and a MAX-ACCESS clause value of read-create.  By
          convention, this is termed the status column for the
          conceptual row.

and all the other columnar objects in the those two tables which are
read-write should be read-create, since 1442 says:
 
          7.3.  Mapping of the MAX-ACCESS clause
          ...
          If any columnar object in a conceptual row has "read-create"
          as its maximal level of access, then no other columnar object
          of the same conceptual row may have a maximal access of
          "read-write".  (Note that "read-create" is a superset of
          "read-write".)

For the tables which do not have a RowStatus column, presumably they cannot
have new rows created via SNMP.  The relevant paragraph from 1442 for 
DEFVAL says:

          7.9.  Mapping of the DEFVAL clause
          ...
          During conceptual row creation, if an instance of a columnar
          object is not present as one of the operands in the
          correspondent management protocol set operation, then the
          value of the DEFVAL clause, if present, indicates an
          acceptable default value that a SNMPv2 entity acting in an
          agent role might use.

i.e., the DEFVAL clause is used when a set operation cause a "conceptual
row creation".  One could argue that 1442 doesn't state the inverse,
i.e., that a DEFVAL is only used when doing "conceptual row creation",
but I believe that is the intent.

Keith.

> From: [e-mail] (Alan Bartky)
> Date: Thu, 4 Jan 96 10:34:07 PST
> Message-Id: <[e-mail]>
> To: [e-mail]
> Subject: Re: Multicast in draft version 5 comments
> Cc: [e-mail], [e-mail], [e-mail],
>         [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.
> > 
>