Re: Multicast in draft version 5 comments

[Alan Bartky <[e-mail]>]

Caralyn and fellow mibbers -

My Comments are edited in below:

- Alan

> From: Caralyn Brown <omni!baynetworks.com!cbrown>
> To: Alan Bartky <omni!alan>
> Cc: [e-mail]
> Subject: Re: Multicast in draft version 5 comments
> Content-Length: 3600
> 
> 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.  
> 

From my reading the only object in RFC1315 that had anything to
do with multicast was:

         frDlcmiMulticast OBJECT-TYPE
             SYNTAX   INTEGER {
                         nonBroadcast (1),
                         broadcast (2)
                         }
             ACCESS   read-write
             STATUS   mandatory
             DESCRIPTION
                "This indicates whether the Frame Relay  inter-
                face is using a multicast service."
            ::= { frDlcmiEntry 10 }


The frCircuitMulticast object, although it has been in multiple draft
versions is not in RFC1315 (the last published RFC for Frame
Relay DTEs).  So it should be legal to
"make it right" as far as values and read-write status.
We should be able to make any valid correction up
until the point the MIB is an RFC.  Even then some RFCs have
been published that have had immediate corrections (for
example RFC 1666 and RFC 1665 for SNA NAU MIB).



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

It should be, for example the DS1 MIB changed some read-only objects to
read-write (excerpt text describing changes below):

        (6)  The ACCESS for objects in the dsx1ConfigTable has been
             set to read-write for items that are configurable.

The DS1 MIB also changed Counter to Gauge32 for many objects.

I think the key as far as changes goes is to try and
preserve backwards compatibility.  Since we are working on
a draft, the only thing we should be concerned with are changes
from RFC 1315.

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