Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09569; 2 Jan 96 10:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09565; 2 Jan 96 10:32 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17589; 2 Jan 96 10:32 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09515; 2 Jan 96 10:32 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09511; 2 Jan 96 10:30 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa17544; 2 Jan 96 10:29 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA06587; Tue, 2 Jan 96 07:29:49 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA15781; Tue, 2 Jan 96 07:29:49 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA03378; Tue, 2 Jan 96 06:44:36 PST Date: Tue, 2 Jan 96 06:44:35 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601021444.AA03378@irvine.XYLAN.COM> To: iplpdn@CNRI.Reston.VA.US Subject: Multicast in draft version 5 comments Cc: alan@xylan.com 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.   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 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 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17635; 2 Jan 96 18:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17631; 2 Jan 96 18:07 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05481; 2 Jan 96 18:07 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17615; 2 Jan 96 18:07 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17611; 2 Jan 96 18:05 EST Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa04941; 2 Jan 96 18:05 EST Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA28578; Tue, 2 Jan 1996 18:05:19 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma028569; Tue Jan 2 18:05:17 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id SAA05095; Tue, 2 Jan 1996 18:05:16 -0500 Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA27663; Tue, 2 Jan 1996 18:05:15 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <199601022305.SAA27663@thor.ca.newbridge.com> Subject: Re: Multicast in draft version 5 comments To: Caralyn Brown Date: Tue, 2 Jan 1996 18:05:14 -0500 (EST) Cc: alan@xylan.com, iplpdn@CNRI.Reston.VA.US In-Reply-To: <9601022036.AA01537@pobox.BayNetworks.com> from "Caralyn Brown" at Jan 2, 96 03:36:53 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5734 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 (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 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17711; 2 Jan 96 18:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17707; 2 Jan 96 18:13 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07541; 2 Jan 96 18:13 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17700; 2 Jan 96 18:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17696; 2 Jan 96 18:12 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa07355; 2 Jan 96 18:12 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA08388; Tue, 2 Jan 96 15:12:23 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA24691; Tue, 2 Jan 96 15:12:25 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA04443; Tue, 2 Jan 96 14:38:03 PST Date: Tue, 2 Jan 96 14:38:03 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601022238.AA04443@irvine.XYLAN.COM> To: omni!baynetworks.com!cbrown@xylan.com Subject: Re: Multicast in draft version 5 comments Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com Caralyn and fellow mibbers - My Comments are edited in below: - Alan > From: Caralyn Brown > To: Alan Bartky > Cc: iplpdn@CNRI.Reston.VA.US > 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 (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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18373; 2 Jan 96 19:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18369; 2 Jan 96 19:31 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16172; 2 Jan 96 19:31 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18358; 2 Jan 96 19:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18354; 2 Jan 96 19:30 EST Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa15781; 2 Jan 96 19:30 EST Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id QAA28348; Tue, 2 Jan 1996 16:30:37 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Jan 1996 16:30:40 -0800 To: James Watt , Caralyn Brown X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: Multicast in draft version 5 comments Cc: alan@xylan.com, iplpdn@CNRI.Reston.VA.US At 6:05 PM 1/2/96, James Watt wrote: >|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. This is one of those things that gets lost in lore. As the SNMP MIB was originally developed, almost everything was read-only, under the assumption the MIB specified the minimum, and that a system that wanted to write stuff would do more than the minimum. Obvious examples are in the ipRouteTable, which is entirely read-only, but folks routinely install (write - or even worse, create) static routes. That was by no means a universal position, though, and the other extreme was that the MIB specified the maximum set of things someone could do; a read-write variable might be implemented read-only. The statement was that the MIB should specify what makes "protocol sense" and a subsetting implementation might use a lower access class. This became the consensus over time, and is canonized in SNMP V2's MIN-ACCESS and MAX-ACCESS clauses. This MIB was originally set up under the first set of rules; with the change in consensus, yes, it sounds like [if this is the only change we are making] this variable can/should be made read-write. I can point to plenty of instances in MIB-II itself where this change has been made. If you were removing a capability, we would have to deprecate and add; we preserve the correctness of the existing implementation. If you are adding capabilities in an updated version, I would argue that it is not necessary to deprecate and add to get new capabilities in an updated draft, as the existing implementation never claimed compliance to the update, and all the capabilities it claims to offer are in fact defined. An example: how many times have we added a value to ifType? And what was the impact of taking MIB-II Row Status objects and giving them the RowStatus TC? We can make it read-write without deprecating and adding. As Alan points out, the change in values is also a change in the internet draft, not a change to RFC 1315, so there is nothing in 1315 to obsolete; yes, there are implementations to the draft, but we already did them in when we renumbered the MIB a couple of months ago. |> 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. An implementation is always permitted to reply "badValue" to things it doesn't think make any sense. A unicast-only implementation would accept a write of unicast, and replay badValue to any other. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06266; 3 Jan 96 1:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06262; 3 Jan 96 1:50 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19108; 3 Jan 96 1:50 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06244; 3 Jan 96 1:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06240; 3 Jan 96 1:47 EST Received: from foxhound.cisco.com by CNRI.Reston.VA.US id aa17984; 3 Jan 96 1:47 EST Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id WAA06394; Tue, 2 Jan 1996 22:47:48 -0800 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199601030647.WAA06394@foxhound.cisco.com> Subject: Re: Multicast in draft version 5 comments To: Fred Baker Date: Tue, 2 Jan 96 22:47:48 PST Cc: james@ca.newbridge.com, cbrown@baynetworks.com, alan@xylan.com, iplpdn@CNRI.Reston.VA.US In-Reply-To: ; from "Fred Baker" at Jan 2, 96 4:30 pm X-Mailer: ELM [version 2.3 PL11] > From: Fred Baker > Date: Tue, 2 Jan 1996 16:30:40 -0800 > > At 6:05 PM 1/2/96, James Watt wrote: > >|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. > > This is one of those things that gets lost in lore. As the SNMP MIB was > originally developed, almost everything was read-only, under the assumption > the MIB specified the minimum, and that a system that wanted to write stuff > would do more than the minimum. Obvious examples are in the ipRouteTable, > which is entirely read-only, but folks routinely install (write - or even > worse, create) static routes. > > That was by no means a universal position, though, and the other extreme > was that the MIB specified the maximum set of things someone could do; a > read-write variable might be implemented read-only. The statement was that > the MIB should specify what makes "protocol sense" and a subsetting > implementation might use a lower access class. This became the consensus > over time, and is canonized in SNMP V2's MIN-ACCESS and MAX-ACCESS clauses. Right, and note that SNMPv2's AGENT-CAPABILITIES and MODULE-CONFORMANCE specify that implicitly referenced objects are implemented/to be implemented according to the MAX-ACCESS clause. Thus, modifying an object's MAX-ACCESS clause would potentially invalidate AGENT-CAPABILITIES and MODULE-CONFORMANCE macros referencing a group containing that object. That's why 1442 disallows a change to the MAX-ACCESS value. > We can make it read-write without deprecating and adding. As Alan points > out, the change in values is also a change in the internet draft, not a > change to RFC 1315, so there is nothing in 1315 to obsolete; yes, there are > implementations to the draft, but we already did them in when we renumbered > the MIB a couple of months ago. I agree (especially since renumbering the MIB is equivalent to obsoleting and adding everything in it). Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12758; 3 Jan 96 10:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12754; 3 Jan 96 10:46 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12084; 3 Jan 96 10:46 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12722; 3 Jan 96 10:46 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12716; 3 Jan 96 10:43 EST Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa10552; 3 Jan 96 10:43 EST Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA07571; Wed, 3 Jan 1996 10:42:35 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma007541; Wed Jan 3 10:42:08 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id KAA23408; Wed, 3 Jan 1996 10:42:08 -0500 Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id KAA22621; Wed, 3 Jan 1996 10:42:07 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <199601031542.KAA22621@thor.ca.newbridge.com> Subject: Re: Multicast in draft version 5 comments To: Keith McCloghrie Date: Wed, 3 Jan 1996 10:42:05 -0500 (EST) Cc: fred@cisco.com, james@ca.newbridge.com, cbrown@baynetworks.com, alan@xylan.com, iplpdn@CNRI.Reston.VA.US In-Reply-To: <199601030647.WAA06394@foxhound.cisco.com> from "Keith McCloghrie" at Jan 2, 96 10:47:48 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1632 Keith McCloghrie writes: +--------- |> At 6:05 PM 1/2/96, James Watt wrote: |> >|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. |> |> This is one of those things that gets lost in lore. As the SNMP MIB was |> originally developed, almost everything was read-only, under the assumption |> the MIB specified the minimum, and that a system that wanted to write stuff |> would do more than the minimum. Obvious examples are in the ipRouteTable, |> which is entirely read-only, but folks routinely install (write - or even |> worse, create) static routes. |> |> That was by no means a universal position, though, and the other extreme |> was that the MIB specified the maximum set of things someone could do; a |> read-write variable might be implemented read-only. The statement was that |> the MIB should specify what makes "protocol sense" and a subsetting |> implementation might use a lower access class. This became the consensus |> over time, and is canonized in SNMP V2's MIN-ACCESS and MAX-ACCESS clauses. +--------- Hmmm... Perhaps this should get pointed out in the SMI or co-existence document, i.e. when converting a MIB from V1->V2 SMI you are allowed certain latitude in mapping from the ACCESS to the MAX-ACCESS clause... Or perhaps a one page informational from the NM Directorate ? Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15518; 3 Jan 96 12:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15514; 3 Jan 96 12:20 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24869; 3 Jan 96 12:20 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15490; 3 Jan 96 12:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15486; 3 Jan 96 12:19 EST Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa24605; 3 Jan 96 12:19 EST Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA17684; Wed, 3 Jan 1996 12:19:39 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma017680; Wed Jan 3 12:19:37 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id MAA25898; Wed, 3 Jan 1996 12:19:37 -0500 Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id MAA25717; Wed, 3 Jan 1996 12:19:35 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <199601031719.MAA25717@thor.ca.newbridge.com> Subject: Re: Multicast in draft version 5 comments To: Alan Bartky Date: Wed, 3 Jan 1996 12:19:30 -0500 (EST) Cc: omni!baynetworks.com!cbrown@xylan.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com In-Reply-To: <9601022238.AA04443@irvine.XYLAN.COM> from "Alan Bartky" at Jan 2, 96 02:38:03 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1389 Folks: Dlcmi looks too much like Dlci for my over-rested eyes. Now that I'm unconfused: 1) frDlcmiMulticast was in RFC 1315 (and was read-write there) and doesn't need any changes. It basically tells you whether the attached network can be assumed to be able to do non-unicast VCs. 2) frCircuitMulticast was added this time round and is a per-VC object that tells you what the _particular_ VC will do with a frame. Alan's proposal is to make this new object match reality, viz: a) have values for unicast, p2mp and mp2mp (did I forget one ?) and b) have a MAX-ACCESS of read-write. As Fred pointed out, if a given DTE doesn't want to use anything but unicast, it can use the WRITE-SYNTAX clause to shrink the valid range. I suppose we should add a refeference clause pointing to the appropriate section of the document that defines the FR multicast support so other folks can figure out why this got done. Did I miss anything ? If not, this sounds like a reasonable change. Regards, -james ps I seem to have misplaced Alan's message with the updated object definition ready for Caralyn to cut and paste... ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15562; 3 Jan 96 12:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15558; 3 Jan 96 12:22 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25489; 3 Jan 96 12:22 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15546; 3 Jan 96 12:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15542; 3 Jan 96 12:21 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa25169; 3 Jan 96 12:21 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA10657; Wed, 3 Jan 96 09:21:13 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA07707; Wed, 3 Jan 96 09:21:12 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA05800; Wed, 3 Jan 96 08:22:31 PST Date: Wed, 3 Jan 96 08:22:31 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601031622.AA05800@irvine.XYLAN.COM> To: iplpdn@CNRI.Reston.VA.US Subject: Proposed changes to Draft Frame Relay MIB for multiprotocol support. Cc: alan@xylan.com Fellow Mibbers and Mibbettes - In doing a more detailed review of the MIB I would like to address some issues in regards to the latest draft and support for some functions of RFC1490 in the Frame Relay DTE MIB. I currently have two proposed changes. First I'll start with the easy one. In the guidelines of the current drafr of the Frame Relay DTE MIB there are recommendations for supporting RFC1573 ifTable objects. Most routers today support RFC1490 and multiple protocols but not necessarily all defined in RFC1490, FRF.3 or T1.617 Annex G. For a router or other Frame Relay DTE that follows RFC1490 formatting, one of the requirements is to ignore any frames that it doesn't support or understand. It would be usefull for the SNMP agent to use the ifInUnknownProtos to indicate the number of packets discarded due to an unknown or unsupported RFC1490 protocol. For the current draft MIB I propose the following change: Current text (in section 4.1) ifInUnknownProtos Always zero(0) as there is only one protocol (frame relay) and it is always understood. Proposed change: ifInUnknownProtos Number of unknown or unsupported upper layer protocol frames received and discarded. If only a single upper layer protocol is present (i.e. multiprotocol formatting is not used) then this counter would be always zero(0). Second for the more difficult one. The current method of mapping a single logical ifIndex in the frCircuit table will not work in all cases, especially with several protocols being supported in a router which map to different DLCIs where the sharing of DLCIs overlaps. Consider an example where a single central site router is communicating via Frame Relay to a remote IP/IPX router, a remote IP/IPX/Bridging router and a remote bridge. The DLCI mapping for this example is: DLCI 40: VC to a remote router that supports IP and IPX. DLCI 41: VC to a remote router that supports IP, IPX and bridging. DLCI 42: VC to a remote bridge that does not support IP or IPX routing. IPX IP Bridging |\ /| / | | \ / | / | | \/ | / | | /\ | / | | / \ | / | |/ \|/ | 40 41 42 In this case there would have to have 3 logical ifIndex values to support the three logical ports. Having a single ifIndex in the DLCI table is insufficient to support this case. Assuming the mapping for the logical ports needed was IPX: ifIndex.10 IP: ifIndex.11 Bridging: ifIndex.12 Then you would need the following mapping: DLCI 40: ifIndex.10 & ifIndex.11 DLCI 41: ifIndex.10, ifIndex.11 & ifIndex.12 DLCI 42: ifIndex.12 This problem of multiple ifIndex values relating to a lower layer is not new. It was recoginized in RFC1573. The proper way to map this is not from the lower layer looking up, but from the upper layer looking down. In order to solve the problem in the frame relay MIB, I believe we will need to have a new table for DLCI to virtual port mapping. The above example could be accomplished using a table with multiple entries as follows: Table Entry 1: ifIndex.10, DLCI 40 Table Entry 2: ifIndex.10, DLCI 41 Table Entry 3: ifIndex.11, DLCI 40 Table Entry 4: ifIndex.11, DLCI 41 Table Entry 5: ifIndex.12, DLCI 41 Table Entry 6: ifIndex.12, DLCI 42 I am willing to start drafting text on this proposal, but since this is more controversial I'll wait back for some responses first. Let me know what you think. 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. If we decide to add either of these changes we should have a references to RFC 1490, FRF.3.1 and T1.617 Annex G at the end of the document.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15648; 3 Jan 96 12:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15644; 3 Jan 96 12:27 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27670; 3 Jan 96 12:27 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15627; 3 Jan 96 12:27 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15623; 3 Jan 96 12:26 EST Received: from lobster.corpeast.baynetworks.com by CNRI.Reston.VA.US id aa27388; 3 Jan 96 12:26 EST Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA08705; Wed, 3 Jan 96 12:25:37 EST Received: from godiva.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA07773; Wed, 3 Jan 96 12:26:31 EST Date: Wed, 3 Jan 96 12:26:31 EST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9601031726.AA07773@pobox.BayNetworks.com> Received: by godiva.engeast (4.1/SMI-4.1) id AA01951; Wed, 3 Jan 96 12:26:05 EST To: James Watt Cc: Alan Bartky , omni!baynetworks.com!cbrown@xylan.com, iplpdn@CNRI.Reston.VA.US Subject: Re: Multicast in draft version 5 comments In-Reply-To: <199601031719.MAA25717@thor.ca.newbridge.com> References: <9601022238.AA04443@irvine.XYLAN.COM> <199601031719.MAA25717@thor.ca.newbridge.com> Indeed. This sounds right to me. I can fix up the Circuit multicast with no problem. I guess the daft update has been out there so long, I just assumed both were in the original. Thanks for pointing out that this is not the case. I'll fix the multicast thing. However, I don't have the exact reference from the forum at the moment so it will take me a while to come up with the correct reference. Prepare for rev 6!!! c On Wed, 3 January, James Watt (james@ca.newbridge.com) wrote: > Folks: > Dlcmi looks too much like Dlci for my over-rested eyes. Now that I'm > unconfused: > > 1) frDlcmiMulticast was in RFC 1315 (and was read-write there) and > doesn't need any changes. It basically tells you whether the > attached network can be assumed to be able to do non-unicast VCs. > > 2) frCircuitMulticast was added this time round and is a per-VC > object that tells you what the _particular_ VC will do with a frame. > > Alan's proposal is to make this new object match reality, viz: > a) have values for unicast, p2mp and mp2mp (did I forget one ?) and > b) have a MAX-ACCESS of read-write. > > As Fred pointed out, if a given DTE doesn't want to use anything but > unicast, it can use the WRITE-SYNTAX clause to shrink the valid range. > > I suppose we should add a refeference clause pointing to the appropriate > section of the document that defines the FR multicast support so other > folks can figure out why this got done. > > Did I miss anything ? If not, this sounds like a reasonable change. > > Regards, > -james > > ps I seem to have misplaced Alan's message with the updated object > definition ready for Caralyn to cut and paste... > ____________________________________________________________________________ > James W. Watt, james@newbridge.com Ph: +1 613 591-3600 > Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680 -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Caralyn Brown Voice: 508-436-3835 Bay Networks Internet: cbrown@baynetworks.com 2 Federal Street Billerica, MA 01821 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17042; 3 Jan 96 13:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17038; 3 Jan 96 13:13 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ab17802; 3 Jan 96 13:13 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17014; 3 Jan 96 13:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17010; 3 Jan 96 13:12 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa17576; 3 Jan 96 13:12 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA10943; Wed, 3 Jan 96 10:12:37 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA10531; Wed, 3 Jan 96 10:12:35 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA05935; Wed, 3 Jan 96 09:37:42 PST Date: Wed, 3 Jan 96 09:37:42 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601031737.AA05935@irvine.XYLAN.COM> To: james@newbridge.com Subject: Re: Multicast in draft version 5 comments Cc: cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com > -james > > ps I seem to have misplaced Alan's message with the updated object > definition ready for Caralyn to cut and paste... > ____________________________________________________________________________ > James W. Watt, james@newbridge.com Ph: +1 613 591-3600 > Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680 > James, Caralyn, et. al. Here is the text again 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 }   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17983; 3 Jan 96 13:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17979; 3 Jan 96 13:50 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03566; 3 Jan 96 13:50 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17971; 3 Jan 96 13:50 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17967; 3 Jan 96 13:50 EST Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa03243; 3 Jan 96 13:50 EST Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id KAA28750; Wed, 3 Jan 1996 10:49:59 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Jan 1996 10:50:02 -0800 To: Keith McCloghrie X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: Multicast in draft version 5 comments Cc: iplpdn@CNRI.Reston.VA.US At 10:47 PM 1/2/96, Keith McCloghrie wrote: >> We can make it read-write without deprecating and adding. As Alan points >> out, the change in values is also a change in the internet draft, not a >> change to RFC 1315, so there is nothing in 1315 to obsolete; yes, there are >> implementations to the draft, but we already did them in when we renumbered >> the MIB a couple of months ago. > >I agree (especially since renumbering the MIB is equivalent to obsoleting and >adding everything in it). well, that was actually correcting an error; the objects in the draft somehow came up with different numbers than 1315, and we renumbered back to 1315's numbering. But you're correct that in changing them we obsoleted any implementation that implemented to the draft. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24524; 3 Jan 96 17:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24518; 3 Jan 96 17:25 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11300; 3 Jan 96 17:25 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24499; 3 Jan 96 17:25 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24494; 3 Jan 96 17:24 EST Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa11277; 3 Jan 96 17:24 EST Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id RAA20956; Wed, 3 Jan 1996 17:20:24 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma020941; Wed Jan 3 17:20:15 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id RAA03155; Wed, 3 Jan 1996 17:20:14 -0500 Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id RAA07953; Wed, 3 Jan 1996 17:20:13 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <199601032220.RAA07953@thor.ca.newbridge.com> Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support. To: Alan Bartky Date: Wed, 3 Jan 1996 17:20:12 -0500 (EST) Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com In-Reply-To: <9601031622.AA05800@irvine.XYLAN.COM> from "Alan Bartky" at Jan 3, 96 08:22:31 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 769 Alan Bartky writes: +--------- |Proposed change: | | ifInUnknownProtos Number of unknown or unsupported | upper layer protocol frames received | and discarded. If only a single | upper layer protocol is present | (i.e. multiprotocol formatting is | not used) then this counter | would be always zero(0). +--------- This looks useful. I need to think more about the next one. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   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 Message-Id: <199601040442.UAA11512@foxhound.cisco.com> Subject: Re: Multicast in draft version 5 comments To: Alan Bartky Date: Wed, 3 Jan 96 20:42:03 PST 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.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10001; 4 Jan 96 7:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09997; 4 Jan 96 7:47 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05616; 4 Jan 96 7:47 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09989; 4 Jan 96 7:47 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09985; 4 Jan 96 7:46 EST Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa05598; 4 Jan 96 7:46 EST Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id HAA00786; Thu, 4 Jan 1996 07:25:26 -0500 Received: from phish.nexen.com (phish.nexen.com [204.249.99.14]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id HAA04577; Thu, 4 Jan 1996 07:40:48 -0500 Received: from [204.249.97.32] (malis.nexen.com [204.249.97.32]) by phish.nexen.com (8.6.12/8.6.12) with SMTP id HAA06963; Thu, 4 Jan 1996 07:46:11 -0500 X-Sender: malis@pop.nexen.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 07:46:48 -0500 To: Alan Bartky X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Andrew G. Malis" Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support. Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com Alan, >Proposed change: > > > ifInUnknownProtos Number of unknown or unsupported > upper layer protocol frames received > and discarded. If only a single > upper layer protocol is present > (i.e. multiprotocol formatting is > not used) then this counter > would be always zero(0). I like this change. >Second for the more difficult one. >... >Table Entry 1: ifIndex.10, DLCI 40 >Table Entry 2: ifIndex.10, DLCI 41 >Table Entry 3: ifIndex.11, DLCI 40 >Table Entry 4: ifIndex.11, DLCI 41 >Table Entry 5: ifIndex.12, DLCI 41 >Table Entry 6: ifIndex.12, DLCI 42 Sounds like in this case, you're not modeling the FR interface as a multiaccess interface, but as a collection of virtual point-point interfaces, one for each DLC. If you then give each virtual interface (DLC) its own ifIndex, you can do the mapping in the ifStack table, right? >P.S. If we decide to add either of these changes we should >have a references to RFC 1490, FRF.3.1 and T1.617 Annex G >at the end of the document. Absolutely. Andy __________________________________________________________________________ Andrew G. Malis Ascom Nexion voice: +1 508 266-4522 malis@nexen.com 289 Great Rd., Acton MA 01720 USA FAX: +1 508 266-2300   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17123; 4 Jan 96 14:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17119; 4 Jan 96 14:11 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12861; 4 Jan 96 14:11 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17074; 4 Jan 96 14:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17070; 4 Jan 96 14:10 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa12826; 4 Jan 96 14:10 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA16647; Thu, 4 Jan 96 11:10:11 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA14581; Thu, 4 Jan 96 11:10:01 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA08384; Thu, 4 Jan 96 10:34:07 PST Date: Thu, 4 Jan 96 10:34:07 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601041834.AA08384@irvine.XYLAN.COM> To: kzm@cisco.com Subject: Re: Multicast in draft version 5 comments Cc: james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com Keith - I have read your response and also review RFC 1442 and reviewed previous work in other MIBs (particualary RFC 1747 which I co-authored). As far as the use of read-write versus read-create, I have never quite understood when to use one versus the other. I do know that we published RFC 1747 with read-write objects that had DEFVAL clauses for them. In the SDLC MIB we did this for all objects related to the SDLC port level. The port level table did not have a RowStatus object and was therefore note createable via SNMP. The SDLC Link Station Level did have a RowStatus object, and all "writeable" objects had read-create with a DEFVAL clause. Although I was not directly involved in the "SNMP Details" in editing the RFC, my recollection was that objects at the port level were read-write since the port level table for SDLC could not be "created", whereas the link station table entries had to be created by the SNMP manager since SDLC link stations had to be configured and could not be learned via the network (certanly the case for primary SDLC which initiates the polling). In the SDLC MIB we had DEFVAL for both read-write and read-create objects. If this is not valid, then it made it all the way through the RFC process without being corrected. When we were drafting the MIB, we felt it very important for the agent and the manager to have proper default values to insure proper operation and interoperability of the protocol. This is why we had DEFVALs for every protocol specific read-write and read-create objects. As far as the current draft of the Frame Relay MIB is concerned it has no read-create objects, and it has many read-write objects with DEFVALs defined. It also has RowStatus defined for both the port level (frDlcmi) and for the virtual circuit level (frCircuit). It also has the additional complexity of a virtual circuit either learned automatically from the network (dynamic type, where the row must created by the SNMP agent) or configured by a user (static type, where the row is created using Row Creation and SNMP Set commands). It appears as though at a minimum the frCircuit table objects that are currently all read-write, should be changed to read-create (although since I am not an SNMP V2 syntax expert this may obviously not be correct). If that were true than the object should be changed to: frCircuitMulticast OBJECT-TYPE SYNTAX INTEGER { unicast (1), oneWay (2), twoWay (3), nWay (4) } MAX-ACCESS read-create 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 {unicast} -- the default value of frCircuitMulticast is -- "unicast" (not a multicast VC). ::= { frCircuitEntry 15 } Other objects in the frCircuit table that are read-write, have DEFVAL defined and may have to get changed to read-create are: frCircuitState frCircuitCommittedBurst frCircuitThroughput Entries defined in the frDlcmi table that are read-write, have DEFVAL defined and may have to get changed to read-create are: frDlcmiPollingInterval frDlcmiFullEnquiryInterval frDlcmiErrorThreshold frDlcmiMonitoredEvents In summary, it looks like the MIB could use a good "going over" by someone more knowledgeable about the details of SNMP V2 syntax and conventions. 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 ********************************************************** Excerpt from my original message and Keith's response is below: > > 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. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17936; 4 Jan 96 14:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17932; 4 Jan 96 14:41 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13401; 4 Jan 96 14:41 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17894; 4 Jan 96 14:41 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17890; 4 Jan 96 14:40 EST Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa13366; 4 Jan 96 14:40 EST Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA04899; Thu, 4 Jan 1996 11:40:45 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Jan 1996 11:40:48 -0800 To: Keith McCloghrie X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: Multicast in draft version 5 comments Cc: iplpdn@CNRI.Reston.VA.US At 8:42 PM 1/3/96, Keith McCloghrie wrote: >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. the point being, if there is a RowStatus variable, the objects should be read-create, not read-write. right? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23641; 4 Jan 96 18:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23637; 4 Jan 96 18:12 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17145; 4 Jan 96 18:12 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23625; 4 Jan 96 18:11 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23621; 4 Jan 96 18:11 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa17135; 4 Jan 96 18:11 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA18139; Thu, 4 Jan 96 15:11:14 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA29880; Thu, 4 Jan 96 15:11:10 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA08798; Thu, 4 Jan 96 14:27:20 PST Date: Thu, 4 Jan 96 14:27:20 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601042227.AA08798@irvine.XYLAN.COM> To: malis@nexen.com Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support. Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com Andy - My responses are edited in below: >... > >Second for the more difficult one. > >... > >Table Entry 1: ifIndex.10, DLCI 40 > >Table Entry 2: ifIndex.10, DLCI 41 > >Table Entry 3: ifIndex.11, DLCI 40 > >Table Entry 4: ifIndex.11, DLCI 41 > >Table Entry 5: ifIndex.12, DLCI 41 > >Table Entry 6: ifIndex.12, DLCI 42 > > Sounds like in this case, you're not modeling the FR interface as a > multiaccess interface, but as a collection of virtual point-point > interfaces, one for each DLC. If you then give each virtual interface > (DLC) its own ifIndex, you can do the mapping in the ifStack table, right? > My intent in suggesting a change is that it looks like the current draft MIB is attempting to perform the grouping function of virtual circuits as is necessary for RFC 1490 for bridging and routing functions. The ifStack table does not specifically perform this function as it only points between logical layers and does cannot perform the internal mapping/grouping of DLCIs to a "virtual port" that a bridge or router can use. As you know, in frame relay it is often necessary (or at least desirable) to group DLCIs together. The current draft MIB currently has a new object for as follows: frCircuitLogicalIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-write STATUS current DESCRIPTION "Normally the same value as frDlcmiIfIndex, but different when an implementation associates a virtual ifEntry with a DLC or set of DLCs in order to associate higher layer objects such as the ipAddrEntry with a subset of the virtual circuits on a Frame Relay interface. The type of such ifEntries is defined by the higher layer object; for example, if PPP/Frame Relay is implemented, the ifType of this ifEntry would be PPP. If it is not so defined, as would be the case with an ipAddrEntry, it should be of type Other." ::= { frCircuitEntry 20 } This object allows grouping of one or more virtual circuits into a logical interface available for upper layer protocols. The problem as I see it is since it is the virtual circuit table specifying a single upper layer ifIndex, it does not allow any "overlap" of the grouping. In the example in the current draft it shows IP using an ifIndex of 2 and then using the DLCI as an physical address field. The only time IP would need a LogicalIfIndex other than the one defined for the port was if there was a layer between IP and Frame Relay (again as shown in the diagram). The text of the description talks about PPP over Frame Relay where IP actually connects to PPP which happens to run over its own DLCI (I also think the example is not very good since it shows PPP over Frame Relay which has never gotten much support and also goes against RFC 1490 which uses direct IP encapsulation over Frame Relay). My main concern was that a RFC1490 based bridge/router has to support IP, IPX, and Bridging and probably other protocols in the future. Up until now there has been no way in the standard MIBs to have DLCI grouping and I am concerned about having a single upward pointer for logical interfaces from per virtual circuit table entry. It would be nice to have a standard method of grouping DLCIs (for example to support DLCIs grouped together for bridging applications) that had the potential of more than one Logical Interface Index per DLCI. The text I submitted was a first stab proposal in order to try an accomplish this (I am willing to listen for alternate proposals, and to see if this affects anyone else). >... > > > Andy > > __________________________________________________________________________ > Andrew G. Malis Ascom Nexion voice: +1 508 266-4522 > malis@nexen.com 289 Great Rd., Acton MA 01720 USA FAX: +1 508 266-2300 > 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 **********************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08503; 5 Jan 96 3:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08498; 5 Jan 96 3:31 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03320; 5 Jan 96 3:31 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08447; 5 Jan 96 3:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08443; 5 Jan 96 3:29 EST Received: from foxhound.cisco.com by CNRI.Reston.VA.US id aa03287; 5 Jan 96 3:29 EST Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id AAA25074; Fri, 5 Jan 1996 00:28:30 -0800 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199601050828.AAA25074@foxhound.cisco.com> Subject: Re: Multicast in draft version 5 comments To: Fred Baker Date: Fri, 5 Jan 96 0:28:30 PST Cc: kzm@cisco.com, iplpdn@CNRI.Reston.VA.US In-Reply-To: ; from "Fred Baker" at Jan 4, 96 11:40 am X-Mailer: ELM [version 2.3 PL11] > At 8:42 PM 1/3/96, Keith McCloghrie wrote: > >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. > > the point being, if there is a RowStatus variable, the objects should be > read-create, not read-write. right? Yes. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08512; 5 Jan 96 3:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08504; 5 Jan 96 3:31 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03322; 5 Jan 96 3:31 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08441; 5 Jan 96 3:31 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08436; 5 Jan 96 3:28 EST Received: from foxhound.cisco.com by CNRI.Reston.VA.US id aa03277; 5 Jan 96 3:28 EST Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id AAA25058; Fri, 5 Jan 1996 00:27:59 -0800 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <199601050827.AAA25058@foxhound.cisco.com> Subject: Re: Multicast in draft version 5 comments To: Alan Bartky Date: Fri, 5 Jan 96 0:27:59 PST Cc: kzm@cisco.com, james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com In-Reply-To: <9601041834.AA08384@irvine.XYLAN.COM>; from "Alan Bartky" at Jan 4, 96 10:34 am X-Mailer: ELM [version 2.3 PL11] Alan, I had not previously looked at the MIB, until seeing your message. It is certainly true that the two RowStatus objects must be read-create, since RFC 1442 says: 7.7.1. Creation and Deletion of Conceptual Rows For newly-defined conceptual rows which allow the creation of new object instances and the deletion of existing object instances, there should be one columnar object with a SYNTAX clause value of RowStatus (a textual convention defined in [3]) and a MAX-ACCESS clause value of read-create. By convention, this is termed the status column for the conceptual row. and all the other columnar objects in the those two tables which are read-write should be read-create, since 1442 says: 7.3. Mapping of the MAX-ACCESS clause ... If any columnar object in a conceptual row has "read-create" as its maximal level of access, then no other columnar object of the same conceptual row may have a maximal access of "read-write". (Note that "read-create" is a superset of "read-write".) For the tables which do not have a RowStatus column, presumably they cannot have new rows created via SNMP. The relevant paragraph from 1442 for DEFVAL says: 7.9. Mapping of the DEFVAL clause ... During conceptual row creation, if an instance of a columnar object is not present as one of the operands in the correspondent management protocol set operation, then the value of the DEFVAL clause, if present, indicates an acceptable default value that a SNMPv2 entity acting in an agent role might use. i.e., the DEFVAL clause is used when a set operation cause a "conceptual row creation". One could argue that 1442 doesn't state the inverse, i.e., that a DEFVAL is only used when doing "conceptual row creation", but I believe that is the intent. Keith. > From: alan@xylan.com (Alan Bartky) > Date: Thu, 4 Jan 96 10:34:07 PST > Message-Id: <9601041834.AA08384@irvine.XYLAN.COM> > To: kzm@cisco.com > Subject: Re: Multicast in draft version 5 comments > Cc: james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, > alan@xylan.com > > Keith - > > I have read your response and also review RFC 1442 and reviewed > previous work in other MIBs (particualary RFC 1747 which I > co-authored). > > As far as the use of read-write versus read-create, I have > never quite understood when to use one versus the other. > I do know that we published RFC 1747 with read-write objects > that had DEFVAL clauses for them. In the SDLC MIB we did this > for all objects related to the SDLC port level. The port level > table did not have a RowStatus object and was therefore > note createable via SNMP. The SDLC Link Station Level did > have a RowStatus object, and all "writeable" objects had > read-create with a DEFVAL clause. > > Although I was not directly involved in the "SNMP Details" > in editing the RFC, my recollection was that objects at the > port level were read-write since the port level table for > SDLC could not be "created", whereas the link station table > entries had to be created by the SNMP manager since SDLC > link stations had to be configured and could not be learned > via the network (certanly the case for primary SDLC which > initiates the polling). > > In the SDLC MIB we had DEFVAL for both read-write and read-create > objects. If this is not valid, then it made it all the way > through the RFC process without being corrected. When we > were drafting the MIB, we felt it very important for the > agent and the manager to have proper default values to > insure proper operation and interoperability of the protocol. > This is why we had DEFVALs for every protocol specific read-write > and read-create objects. > > As far as the current draft of the Frame Relay MIB is concerned > it has no read-create objects, and it has many read-write objects > with DEFVALs defined. It also has RowStatus defined for both the > port level (frDlcmi) and for the virtual circuit level (frCircuit). > It also has the additional complexity of a virtual circuit either > learned automatically from the network (dynamic type, where the > row must created by the SNMP agent) or configured by a user (static > type, where the row is created using Row Creation and SNMP Set > commands). > > It appears as though at a minimum the frCircuit table objects > that are currently all read-write, should be changed to > read-create (although since I am not an SNMP V2 syntax expert > this may obviously not be correct). If that were true than > the object should be changed to: > > frCircuitMulticast OBJECT-TYPE > SYNTAX INTEGER { > unicast (1), > oneWay (2), > twoWay (3), > nWay (4) > } > MAX-ACCESS read-create > 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 {unicast} -- the default value of frCircuitMulticast is > -- "unicast" (not a multicast VC). > ::= { frCircuitEntry 15 } > > Other objects in the frCircuit table that are read-write, have > DEFVAL defined and may have to get changed to read-create are: > > frCircuitState > frCircuitCommittedBurst > frCircuitThroughput > > > Entries defined in the frDlcmi table that are read-write, > have DEFVAL defined and may have to get changed to read-create are: > > frDlcmiPollingInterval > frDlcmiFullEnquiryInterval > frDlcmiErrorThreshold > frDlcmiMonitoredEvents > > In summary, it looks like the MIB could use a good "going over" > by someone more knowledgeable about the details of > SNMP V2 syntax and conventions. > > 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 > ********************************************************** > > Excerpt from my original message and Keith's response is below: > > > > 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. > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09737; 12 Jan 96 8:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09733; 12 Jan 96 8:20 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06147; 12 Jan 96 8:20 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09721; 12 Jan 96 8:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09717; 12 Jan 96 8:18 EST Received: from lobster.corpeast.baynetworks.com by CNRI.Reston.VA.US id aa06123; 12 Jan 96 8:18 EST Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04655; Fri, 12 Jan 96 08:17:17 EST Received: from godiva.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA29478; Fri, 12 Jan 96 08:18:09 EST Date: Fri, 12 Jan 96 08:18:09 EST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9601121318.AA29478@pobox.BayNetworks.com> Received: by godiva.engeast (4.1/SMI-4.1) id AA16384; Fri, 12 Jan 96 08:18:02 EST To: iplpdn@CNRI.Reston.VA.US Subject: frame relay MIB -- I'm still working on the frame relay mib. It's interesting how this thing sat for so long and now has come back to life. 8-) Anyway, so far, I put in the suggested change for the multicast in the circuit table and am going to make the change to the ifInUnknownProtos shortly. I assume there is no problem with these. The rest of the suggested changes in Alan Bartky's mail of Jan 3rd, I'm holding off on. I have not had time to review it and I have heard very little discussion (either favorable or unfavorable) about this suggestion. I'll work to review it today. Could others also make an effort, please? Thanks. c ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Caralyn Brown Voice: 508-436-3835 Bay Networks Internet: cbrown@baynetworks.com 2 Federal Street Billerica, MA 01821 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11904; 12 Jan 96 12:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11900; 12 Jan 96 12:12 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08926; 12 Jan 96 12:12 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11868; 12 Jan 96 12:12 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab11864; 12 Jan 96 12:10 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa08893; 12 Jan 96 12:10 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA14818; Fri, 12 Jan 96 09:10:30 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA25352; Fri, 12 Jan 96 09:10:23 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA25628; Fri, 12 Jan 96 08:49:01 PST Date: Fri, 12 Jan 96 08:49:01 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601121649.AA25628@irvine.XYLAN.COM> To: james@newbridge.com, cbrown@baynetworks.com Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support. Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com Caralyn - My comments are edited in below: > I was just fixing up a portion of the mib and really looked at this > definition: > > -- ifInUnknownProtos Number of unknown or unsupported > upper layer protocol frames received > and discarded. If only a single > upper layer protocol is present > (i.e. multiprotocol formatting is > not used) then this counter > would be always zero(0). > > > At first this made sense to me, but now I'm having second thoughts. If > there is only a single upper layer on the side doing the counter, but the > other side is sending other stuff, this could be non-zero. My main objective for this counter was for implementations that support frame relay RFC 1490 encapsulations, whether they are single or multi-protocol. If you have an RFC 1490 implementation you must discard and not process any messages that you do not support or understand. Since this MIB is for Frame Relay DTEs, I am assuming that most of the implementations that are not proprietary will support RFC1490 encapsulation, but there is no MIB for the Protocol multiplexing/demultiplexing function for multi-protocol. > Let's say > for example that I'm supporting 1490 encaps and I have IP and AppleTalk > supported. What if the other side sends me an IPX frame. Would that > increase the counter? Yes. > What if I support only IP with no encaps and the > other side sends me a 1490 encapsulated frame? I might not be able to > identify this situation. That was my intent of saying (multiprotocol formatting is not used) in the comment. In that situation there is no protocol multiplexing/demultiplexing function at the "frame relay" layer. In that case the counter would always be 0. > I'm not entirely sure how to nail down the use of > this object using this definition. > > If we stop after the first sentence it leaves a lot of room for interpretation. > Is this a good thing or a bad thing? > I think we want to be specific. Maybe rewording would help. How about: -- ifInUnknownProtos For implementations that use RFC 1490 Multiprotocol over Frame Relay, this counts the number of frames received but not delivered to an upper layer due to unknown or unsupported protocols. If RFC 1490 Multiprotocol encapsulation is not used, then this counter would be always zero(0). And of course we'll need a reference to RFC 1490 in the reference section. > c > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Caralyn Brown Voice: 508-436-3835 > Bay Networks Internet: cbrown@baynetworks.com > 2 Federal Street > Billerica, MA 01821 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 **********************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26713; 15 Jan 96 21:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26706; 15 Jan 96 21:19 EST Received: from [132.151.1.35] by CNRI.Reston.VA.US id aa16951; 15 Jan 96 21:19 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26487; 15 Jan 96 21:17 EST Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa26483; 15 Jan 96 21:13 EST Received: from [192.75.23.67] by CNRI.Reston.VA.US id aa15977; 15 Jan 96 21:12 EST Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id VAA13958; Mon, 15 Jan 1996 21:10:41 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma013953; Mon Jan 15 21:10:32 1996 Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id VAA11327; Mon, 15 Jan 1996 21:10:31 -0500 Received: from fields.newbridge (fields.ca.newbridge.com [138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id VAA19788; Mon, 15 Jan 1996 21:10:30 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James Watt Message-Id: <199601160210.VAA19788@thor.ca.newbridge.com> Subject: Re: Proposed changes to Draft Frame Relay MIB for multiprotocol support. To: Alan Bartky Date: Mon, 15 Jan 1996 21:10:29 -0500 (EST) Cc: james@newbridge.com, cbrown@baynetworks.com, iplpdn@CNRI.Reston.VA.US, alan@xylan.com In-Reply-To: <9601121649.AA25628@irvine.XYLAN.COM> from "Alan Bartky" at Jan 12, 96 08:49:01 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1340 Alan Bartky writes: +----------- |I think we want to be specific. Maybe rewording would help. How about: | | -- ifInUnknownProtos For implementations that | use RFC 1490 Multiprotocol | over Frame Relay, this counts | the number of frames received | but not delivered to an | upper layer due to unknown | or unsupported protocols. | If RFC 1490 Multiprotocol encapsulation | is not used, then this counter | would be always zero(0). | |And of course we'll need a reference to RFC 1490 in the |reference section. +-------- One dumb question: what happens if some VCs on an interface are using RFC 1490 and others aren't ? I'm not sure this would be a too common occurrence but I couldn't find anywhere that we said the interface had to be homogenous in encapsulation within the FR frame ? Having said that, I think the words cited above will work just fine. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17614; 19 Jan 96 15:47 EST Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa17610; 19 Jan 96 15:47 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09654; 19 Jan 96 15:46 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17546; 19 Jan 96 15:46 EST Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa17541; 19 Jan 96 15:43 EST Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa08278; 19 Jan 96 15:43 EST Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA07097; Fri, 19 Jan 96 11:11:24 PST Received: from canary.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA15996; Fri, 19 Jan 96 11:11:23 PST Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA12695; Fri, 19 Jan 96 10:36:23 PST Date: Fri, 19 Jan 96 10:36:23 PST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alan Bartky Message-Id: <9601191836.AA12695@irvine.XYLAN.COM> To: iplpdn@CNRI.Reston.VA.US Subject: Questions on LOS ANGELES IETF and RFC status Cc: alan@xylan.com Fellow Frame Relay Mibbers and Mibbettes - I just got this email (included below) in from the Trunk Mib (DS1 & DS3) working group. Will there be any meeting for the Frame Relay MIB? What is the possibility of getting the MIB published as an RFC and if so when could it be done by? 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 ********************************************************** ----- Begin Included Message ----- From omni!cisco.com!fred Fri Jan 19 09:15:46 1996 X-Sender: fred@stilton.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jan 1996 08:40:35 -0800 To: trunk-mib@cisco.com From: omni!cisco.com!fred (Fred Baker) Subject: Re: LOS ANGELES IETF: TRUNKMIB Content-Length: 382 At 4:36 PM 1/17/96, Marcia Beaulieu wrote: >This is to confirm 1 session for TRUNKMIB as follows: > > Monday, March 4 - 3:30-5:30pm (opposite cat,dhc,rolc,rps) > >Marcia >IETF Meeting Coordinator =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Suppose you were an idiot. And suppose you were a [politician]. But I repeat myself. -- Mark Twain ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14483; 22 Jan 96 15:54 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14479; 22 Jan 96 15:54 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16002; 22 Jan 96 15:54 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14436; 22 Jan 96 15:53 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14430; 22 Jan 96 15:51 EST Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa15940; 22 Jan 96 15:51 EST Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id MAA27178; Mon, 22 Jan 1996 12:51:07 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jan 1996 12:51:10 -0800 To: Alan Bartky X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Subject: Re: Questions on LOS ANGELES IETF and RFC status Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com At 10:36 AM 1/19/96, Alan Bartky wrote: >What is the possibility of getting the MIB published as >an RFC and if so when could it be done by? if we are all happy with Caralyn's latest draft, I (it somehow falls under PPP's purview, don't ask me why) can forward it to the Area Director. Are we all happy campers? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Suppose you were an idiot. And suppose you were a [politician]. But I repeat myself. -- Mark Twain   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16554; 23 Jan 96 14:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16550; 23 Jan 96 14:08 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15340; 23 Jan 96 14:08 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16478; 23 Jan 96 14:08 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16474; 23 Jan 96 14:06 EST Received: from lobster.corpeast.baynetworks.com by CNRI.Reston.VA.US id aa15308; 23 Jan 96 14:06 EST Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13693; Tue, 23 Jan 96 14:04:59 EST Received: from godiva.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA22821; Tue, 23 Jan 96 14:05:50 EST Date: Tue, 23 Jan 96 14:05:50 EST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9601231905.AA22821@pobox.BayNetworks.com> Received: by godiva.engeast (4.1/SMI-4.1) id AA19399; Tue, 23 Jan 96 14:05:40 EST To: iplpdn@CNRI.Reston.VA.US Subject: RFC 1315 -- Recently someone suggested that the update to 1315 should be wrapped up. I agree, but there is one small detail that has not yet been agreed upon and that is the ifIndex stuff (VC related). Until we figure that out, I don't think we should try to get it an RFC number. I have been a bit remiss in not taking the time to thoroughly looking at the suggested mapping table. It would help greatly if others reviewed this and commented. Thanks. c ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Caralyn Brown Voice: 508-436-3835 Bay Networks Internet: cbrown@baynetworks.com 2 Federal Street Billerica, MA 01821 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++