Multicast in draft version 5 comments

[Alan Bartky <[e-mail]>]

Fellow Frame Relay Mibbers and Mibbettes -

I have a comment concerning draft version 5 of the Frame Relay
DTE MIB concerning the multicast object for a virtual circuit.
It is currently defined in the draft as:


     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 }

The first problem (major) is that this is a read-only object.
It should be read-write.  This object doesn't do much good if
you can't manipulate it via an SNMP manager.

The second comment is that this object only has a simple yes/no
function concerning multicast.  The Frame Relay Forum Multicast
Service and Protocol Description Implementation Agreement
(FRF.7 October 21, 1994), defines a Multicast service as being
One-Way, Two-Way or N-Way.

I therefore propose the object to be changed as follows:


     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 }

Also since multicast is optional we should allow an
implementation to only allow a write of unicast(1) as
a value and to allow other values to be optional.

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
**********************************************************

P.S. Excellent work on the draft so far!  We have compiled
the draft MIB and it seems to meet of all of current needs.