Re: Multicast in draft version 5 comments

[Caralyn Brown <[e-mail]>]

This brings up an interesting question.  This has been a part of the MIB 
from the beginning.  I'm not sure that we can just change it as you have
suggested.  When this was written, there was no one-way, two-way etc.  
We could add those as additional enumerations and change the description
accordingly.  The multicast value (2) could be used for those who don't  care
whether it is one-way, two-way or n-way.  

Those more MIB-literate than I am will have to help me decide whether it is 
legal or not to change a read-only to a read-write.

 
c

On Tue,  2 January, Alan Bartky ([e-mail]) wrote:

> 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.
> 
> 
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Caralyn Brown             Voice: 508-436-3835
Bay Networks              Internet: [e-mail]
2 Federal Street
Billerica, MA 01821
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++