Re: Multicast in draft version 5 comments

[James Watt <[e-mail]>]

Caralyn Brown writes:
+---------
|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.
+---------
The text from RFC 1442 is reproduced below.  As far as I can tell we are
_not_ allowed to change the object - we would have to deprecated it and
define a new one.

Regards
-james

From RFC 1442:

          10.2.  Object Definitions
 
          An object definition may be revised in any of the following
          ways:
 
          (1)  A SYNTAX clause containing an enumerated INTEGER may have
               new enumerations added or existing labels changed.
 
          (2)  A STATUS clause value of "current" may be revised as
               "deprecated" or "obsolete".  Similarly, a STATUS clause
               value of "deprecated" may be revised as "obsolete".
 
          (3)  A DEFVAL clause may be added or updated.
 
          (4)  A REFERENCE clause may be added or updated.
 
          (5)  A UNITS clause may be added.
 
          (6)  A conceptual row may be augmented by adding new columnar
               objects at the end of the row.
 
          (7)  Entirely new objects may be defined, named with
               previously unassigned OBJECT IDENTIFIER values.
 
          Otherwise, if the semantics of any previously defined object
          are changed (i.e., if a non-editorial change is made to any
          clause other those specifically allowed above), then the
          OBJECT IDENTIFIER value associated with that object must also
          be changed.
 
          Note that changing the descriptor associated with an existing
          object is considered a semantic change, as these strings may
          be used in an IMPORTS statement.
 
          Finally, note that if an object has the value of its STATUS
          clause changed, then the value of its DESCRIPTION clause
          should be updated accordingly.

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

____________________________________________________________________________
James W. Watt,     [e-mail]                   Ph: [phone]
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:[phone]