Re: Multicast in draft version 5 comments

Caralyn Brown <cbrown@baynetworks.com> Tue, 02 January 1996 20:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15339; 2 Jan 96 15:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15332; 2 Jan 96 15:38 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26361; 2 Jan 96 15:38 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15292; 2 Jan 96 15:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15285; 2 Jan 96 15:37 EST
Received: from lobster.corpeast.baynetworks.com by CNRI.Reston.VA.US id aa25884; 2 Jan 96 15:37 EST
Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21965; Tue, 2 Jan 96 15:35:59 EST
Received: from godiva.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA01537; Tue, 2 Jan 96 15:36:53 EST
Date: Tue, 2 Jan 96 15:36:53 EST
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Caralyn Brown <cbrown@baynetworks.com>
Message-Id: <9601022036.AA01537@pobox.BayNetworks.com>
Received: by godiva.engeast (4.1/SMI-4.1) id AA01611; Tue, 2 Jan 96 15:36:36 EST
To: Alan Bartky <alan@xylan.com>
Cc: iplpdn@CNRI.Reston.VA.US
Subject: Re: Multicast in draft version 5 comments
In-Reply-To: <9601021444.AA03378@irvine.XYLAN.COM>
References: <9601021444.AA03378@irvine.XYLAN.COM>

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 (alan@xylan.com) 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:alan@xylan.com
> Principal Software Engineer
> XYLAN Corporation                    Voice:(714) 597-8042
> 15707 ROCKFIELD BLVD STE 155F        FAX:  (714) 597-8342
> 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: cbrown@baynetworks.com
2 Federal Street
Billerica, MA 01821
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++