Re: Multicast in draft version 5 comments

Keith McCloghrie <kzm@cisco.com> Thu, 04 January 1996 04:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01371; 3 Jan 96 23:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01367; 3 Jan 96 23:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00591; 3 Jan 96 23:44 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01060; 3 Jan 96 23:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01056; 3 Jan 96 23:42 EST
Received: from foxhound.cisco.com by CNRI.Reston.VA.US id aa00544; 3 Jan 96 23:42 EST
Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id UAA11512; Wed, 3 Jan 1996 20:42:03 -0800
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <199601040442.UAA11512@foxhound.cisco.com>
Subject: Re: Multicast in draft version 5 comments
To: Alan Bartky <alan@xylan.com>
Date: Wed, 03 Jan 1996 20:42:03 -0800
Cc: james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com
In-Reply-To: <9601031737.AA05935@irvine.XYLAN.COM>; from "Alan Bartky" at Jan 3, 96 9:37 am
X-Mailer: ELM [version 2.3 PL11]

>      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 }
 
On the usage of DEFVAL, RFC 1442 says:

          7.9.  Mapping of the DEFVAL clause

          The DEFVAL clause, which need not be present, defines an
          acceptable default value which may be used at the discretion
          of a SNMPv2 entity acting in an agent role when an object
          instance is created.

Note that it is specified for usage when an instance is *created* via
SNMP.  Thus, DEFVAL is only appropriate when the MAX-ACCESS clause is
read-create.  For read-only/read-write objects, any mention of a default
value should go in the DESCRIPTION clause.

Keith.