Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05401; 1 Jul 93 10:18 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05397; 1 Jul 93 10:18 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08778; Thu, 1 Jul 93 09:53:22 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 1 Jul 1993 09:53:21 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ub-gate.UB.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08770; Thu, 1 Jul 93 09:53:16 -0400 Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA25059; Thu, 1 Jul 93 06:54:16 PDT Received: from psycho.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA04261; Thu, 1 Jul 93 09:54:14 EDT Received: by psycho.andr.UB.com (4.1/SMI-4.1) id AA02302; Thu, 1 Jul 93 09:53:37 EDT Date: Thu, 1 Jul 93 09:53:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: M J Kaycee Message-Id: <9307011353.AA02302@psycho.andr.UB.com> To: eah@pau.synnet.com, arneson@ctron.com Subject: Re: Re- Comments on Chassis Mib Cc: chassismib@cs.utk.edu, kaycee@andr.ub.com Dave Arneson writes: > I summary I agree with Ed's requests in location, module, resource, entity > mappings, with a few modifications. Same here...agreed. > > I also feel that we need to get a better understanding of what we need in > MIB views. Does anybody have any additional thoughts? I have something I'd like to discuss, but will wait until I get some time to think about it within the next day or two. mjk   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05418; 1 Jul 93 10:18 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05414; 1 Jul 93 10:18 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08559; Thu, 1 Jul 93 09:50:45 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 1 Jul 1993 09:50:44 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from apache.telebit.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA08545; Thu, 1 Jul 93 09:50:42 -0400 Received: from sharps.UUCP by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930310) id AA14209 to chassismib@cs.utk.edu; Thu, 1 Jul 93 06:51:46 PDT Received: from speedy. by sharps (4.1/SMI-4.1) id AA01302; Thu, 1 Jul 93 09:21:56 EDT Date: Thu, 01 Jul 1993 09:24:31 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: pat Gili To: chassismib@cs.utk.edu Subject: Chassis MIB Message-Id: Could you please send me a copy of the latest draft of the chassis MIB? Thank you, Patrick Gili Telebit Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10641; 6 Jul 93 15:28 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa10637; 6 Jul 93 15:28 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA09524; Tue, 6 Jul 93 15:05:33 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 6 Jul 1993 15:05:31 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA09512; Tue, 6 Jul 93 15:05:29 -0400 Received: by xap.xyplex.com id ; Tue, 6 Jul 93 15:04:51 -0500 Date: Tue, 6 Jul 93 15:04:51 -0500 Message-Id: <9307062004.AA19836@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: chassismib@cs.utk.edu Subject: Working Group Status July 5 was our deadline to have a document ready for recommendation as a Proposed Standard. The volume of discussion on the list lately has improved, but I must apologize that I have not had time to follow it either to moderate or contribute, and as such I have little idea as to where the document stands. Yes, that means I've not been a good chair. Real Life intruded. Anyway... *** Call for Consensus *** Assuming that we have a relatively up-to-date draft, I propose that we drop it in the laps of the Network Management Area Director and his Directorate. They may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair that will actually help, and ask that it be improved in specific ways, c) terminate the working group, or d) do something else they think of. Noting that we have little other choice, do I hear strong objections or alternatives? Also please note that I will not be able to even look at replies until Friday (Real Life). At least this provides an organized topic for yelling, and some of the Directorate people are surely listening. *** No-Meeting Announcement *** We are on the agenda for Amsterdam. This was a bit unusual, as our schedule defines us as done by then. Due to the aforementioned intrusion of Real Life, I will not be in Amsterdam. There will be no Chassis MIB meeting there. I apologize for this late notice. See previous excuses. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12933; 6 Jul 93 17:31 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa12928; 6 Jul 93 17:31 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA16187; Tue, 6 Jul 93 16:48:04 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 6 Jul 1993 16:48:03 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA16158; Tue, 6 Jul 93 16:47:59 -0400 Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA06590; Tue, 6 Jul 93 13:47:25 PDT Received: by donatello (4.1/2.0N) id AA09044; Tue, 6 Jul 93 13:47:24 PDT Message-Id: <9307062047.AA09044@donatello> Date: Tue, 6 Jul 93 13:47:24 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Bierman To: chassismib@cs.utk.edu, rlstewart@eng.xyplex.com Subject: Re: Working Group Status > July 5 was our deadline to have a document ready for recommendation as a > Proposed Standard. The volume of discussion on the list lately has improved, > but I must apologize that I have not had time to follow it either to moderate > or contribute, and as such I have little idea as to where the document stands. > Yes, that means I've not been a good chair. Real Life intruded. Anyway... > > *** Call for Consensus *** > > Assuming that we have a relatively up-to-date draft, I propose that we drop it > in the laps of the Network Management Area Director and his Directorate. They > may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair > that will actually help, and ask that it be improved in specific ways, c) > terminate the working group, or d) do something else they think of. > > Noting that we have little other choice, do I hear strong objections or > alternatives? Also please note that I will not be able to even look at > replies until Friday (Real Life). At least this provides an organized topic > for yelling, and some of the Directorate people are surely listening. > > *** No-Meeting Announcement *** > > We are on the agenda for Amsterdam. This was a bit unusual, as our schedule > defines us as done by then. Due to the aforementioned intrusion of Real Life, > I will not be in Amsterdam. There will be no Chassis MIB meeting there. I > apologize for this late notice. See previous excuses. > > Bob > this is most unfortunate... I feel that the MIB was pretty close, and that there was a good chance of reaching consensus at the amsterdam meeting...it seems an almost done deal that the WG will be disbanded... is the meeting definately cancelled...because I have to change my travel plans and I won't be able to change them twice (if a meeting is added back to the schedule) --andy;   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13217; 6 Jul 93 18:15 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa13211; 6 Jul 93 18:15 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20557; Tue, 6 Jul 93 17:57:17 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 6 Jul 1993 17:57:16 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from chipcom.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA20544; Tue, 6 Jul 93 17:57:14 -0400 Received: from teach.stealth ([151.104.9.58]) by chipcom.com (4.1/SMI-4.0) id AA18112; Tue, 6 Jul 93 17:55:06 EDT Received: by teach.stealth (4.1/SMI-4.1) id AA00828; Tue, 6 Jul 93 17:57:31 EDT Date: Tue, 6 Jul 93 17:57:31 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Horowitz Message-Id: <9307062157.AA00828@teach.stealth> To: chassismib@cs.utk.edu Subject: Re: Working Group Status I am concerned about the possibility of the chassis mib dropping on the floor since this mib was used as one of the arguments for dropping the repeater ID object from the hubmib. Is this really a possibility ? If so, how are we to manage (in a standard way), multiple repeaters per agent ? -- Steve H. > From owner-chassismib@CS.UTK.EDU Tue Jul 6 17:31:22 1993 > Return-Path: > Received: from CS.UTK.EDU by chipcom.com (4.1/SMI-4.0) > id AA17957; Tue, 6 Jul 93 17:31:02 EDT > Errors-To: owner-chassismib@CS.UTK.EDU > Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) > id AA16187; Tue, 6 Jul 93 16:48:04 -0400 > X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 6 Jul 1993 16:48:03 EDT > Errors-To: owner-chassismib@CS.UTK.EDU > Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) > id AA16158; Tue, 6 Jul 93 16:47:59 -0400 > Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1) > id AA06590; Tue, 6 Jul 93 13:47:25 PDT > Received: by donatello (4.1/2.0N) > id AA09044; Tue, 6 Jul 93 13:47:24 PDT > Message-Id: <9307062047.AA09044@donatello> > Date: Tue, 6 Jul 93 13:47:24 PDT > From: Andrew Bierman > To: chassismib@cs.utk.edu, rlstewart@eng.xyplex.com > Subject: Re: Working Group Status > Content-Length: 1853 > X-Lines: 39 > Status: RO > > > > July 5 was our deadline to have a document ready for recommendation as a > > Proposed Standard. The volume of discussion on the list lately has improved, > > but I must apologize that I have not had time to follow it either to moderate > > or contribute, and as such I have little idea as to where the document stands. > > Yes, that means I've not been a good chair. Real Life intruded. Anyway... > > > > *** Call for Consensus *** > > > > Assuming that we have a relatively up-to-date draft, I propose that we drop it > > in the laps of the Network Management Area Director and his Directorate. They > > may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair > > that will actually help, and ask that it be improved in specific ways, c) > > terminate the working group, or d) do something else they think of. > > > > Noting that we have little other choice, do I hear strong objections or > > alternatives? Also please note that I will not be able to even look at > > replies until Friday (Real Life). At least this provides an organized topic > > for yelling, and some of the Directorate people are surely listening. > > > > *** No-Meeting Announcement *** > > > > We are on the agenda for Amsterdam. This was a bit unusual, as our schedule > > defines us as done by then. Due to the aforementioned intrusion of Real Life, > > I will not be in Amsterdam. There will be no Chassis MIB meeting there. I > > apologize for this late notice. See previous excuses. > > > > Bob > > > this is most unfortunate... > I feel that the MIB was pretty close, and that there was a good > chance of reaching consensus at the amsterdam meeting...it seems > an almost done deal that the WG will be disbanded... > > is the meeting definately cancelled...because I have to change > my travel plans and I won't be able to change them twice > (if a meeting is added back to the schedule) > > --andy; >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13578; 6 Jul 93 18:53 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa13574; 6 Jul 93 18:53 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22712; Tue, 6 Jul 93 18:34:16 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 6 Jul 1993 18:34:16 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from atlas.xylogics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA22704; Tue, 6 Jul 93 18:34:09 -0400 Received: from spock.xylogics.com by atlas.xylogics.com with SMTP id AA27124 (5.65c/UK-2.1-930202); Tue, 6 Jul 1993 18:35:39 -0400 Received: by spock.xylogics.com id AA06480 (4.1/UK-2.1-921215); Tue, 6 Jul 93 18:33:54 EDT Message-Id: <6480.9307062233@spock.xylogics.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Barnes Date: Tue, 6 Jul 1993 18:33:53 EDT X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chassismib@cs.utk.edu Subject: Re: Working Group Status > *** No-Meeting Announcement *** > > We are on the agenda for Amsterdam. This was a bit unusual, as our schedule > defines us as done by then. Due to the aforementioned intrusion of Real Life, > I will not be in Amsterdam. There will be no Chassis MIB meeting there. I > apologize for this late notice. See previous excuses. If there is still interest in having a session, why not have one of the document authors or other interested parties substitute for Bob next week? Jim Barnes (barnes@xylogics.com)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22246; 7 Jul 93 1:26 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa22242; 7 Jul 93 1:26 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA14944; Wed, 7 Jul 93 01:00:00 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 00:59:54 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from relay.conware.de by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA14928; Wed, 7 Jul 93 00:59:44 -0400 Received: from slc_2.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0oDRWr-000CLbC; Wed, 7 Jul 93 06:54 MET DST Received: by slc_2.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Wed, 7 Jul 93 06:55 MET DST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Guenter Roeck Subject: Re: Working Group Status To: chassismib@cs.utk.edu Date: Wed, 7 Jul 93 6:55:44 MET DST X-Mailer: ELM [version 2.3 PL11] Hello, > > I am concerned about the possibility of the chassis mib dropping on > the floor since this mib was used as one of the arguments for > dropping the repeater ID object from the hubmib. > > Is this really a possibility ? If so, how are we to manage (in a standard > way), multiple repeaters per agent ? > This matter about dropping the chassis MIB concerns us quite a bit as well. We mostly waited for the MIB going to Draft/Proposed Standard to start implementing it in one of our systems. Actually, the implementation work will start in July, since we don't want to wait any longer. Since we will need such a kind of MIB, dropping the chassis MIB would actually mean for us to just use it in our enterprise tree. As for the current state of the MIB - the MIB does quite exactly what we want it to do (to give information about a chassis, and to manage the modules not using the chassis MIB, but using the SNMP agents on each module). > *** Call for Consensus *** > > Assuming that we have a relatively up-to-date draft, I propose that we drop it > in the laps of the Network Management Area Director and his Directorate. They > may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair > that will actually help, and ask that it be improved in specific ways, c) > terminate the working group, or d) do something else they think of. I strongly vote for a) after correcting any syntactical bugs in the MIB decription. I think this would be MUCH better than dropping the whole thing. If it might be necessary to add something at a later point - there is always a MIB-II... Guenter -------------------------------------------------------------------------- Guenter Roeck - Conware GmbH Phone: (0049) 721-9495-0 Internet: roeck@conware.de Fax: (0049) 721-9495-146 --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01080; 7 Jul 93 7:24 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa01076; 7 Jul 93 7:24 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA12901; Wed, 7 Jul 93 07:00:04 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 07:00:02 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA12869; Wed, 7 Jul 93 06:59:55 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA20594 (5.65c/IDA-1.4.4-910725 for ); Wed, 7 Jul 1993 03:59:52 -0700 Received: by gw.3Com.COM id AA21479 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 7 Jul 1993 03:59:50 -0700 Date: Wed, 7 Jul 93 11:58 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: RE: Working Group Status To: chassismib@cs.utk.edu Message-Id: <930707.035831@3Mail.3Com.COM> Msg-Date: 1993-07-07 Msg-Time: 11:58 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: RE: Working Group Status Date: 1993-07-07 11:54 Priority: Message ID: C3308B74 Conversation ID: C3308B74 ------------------------------------------------------------------------------ Bob, I too have been a bit to quiet for a couple of weeks, again because of real work pressure and being out of the office for a while. I thought this was fairly safe given that the list was fairly quiet and most things appeared to be agreed with the exception of the resource-entity relationship. I've just printed the June 24 draft from the archives. > *** Call for Consensus *** > > Assuming that we have a relatively up-to-date draft, I propose that we drop it > in the laps of the Network Management Area Director and his Directorate. They > may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair > that will actually help, and ask that it be improved in specific ways, c) > terminate the working group, or d) do something else they think of. I hardly recognised the current document! There was pressure to make the resource to entity mapping many to many, although I still think this is an over complication its something I can live with. However significant changes and complication seem to have taken place for which there is little explanation in the mail list and little justification. The resulting MIB cannot easily answer When I made my proposal at the Columbus meeting I was very careful to illustrate how the MIB could be used to manage boxes available now. I provided a number of examples to the list that showed this. I also put a great deal of effort into thinking in terms of a generic management application for a chassis. If a generic management application cannot be written then there is no point in having a standard MIB! Another important point was to be very clear as to definitions for the various elements used to describe the chassis. If these definitions are unclear then there will be confusion and multiple different interpretations. My definitions came from analogy with the real world and so were easy to understand. That is why my original proposal used the term 'component' rather than 'resource', because it means something to most people. My definitions were fairly tight: A chassis comprises a number of physical locations which may or may not be occupied by a module. Each module comprises a number of components or resources (one module contains multple components, each component resides on a single module). The resources of the chassis are organised into functional entities, such as repeaters, bridges, routers etc. I kept the relationship between resource and entity 1-to-1 for simplicity and accepted the more artificial desciption of some configurations. This last point seems to have caused people understandable problems, 1-to-1 is a real restriction. With a reasonable MIB i-resource-to-many-entities would be acceptable. The definitions and model have now changed. Now there appears to be a many to many relationship between a resource and a module! A resource can be part of several modules? What is a resource in the real world? There have been no examples of how this new model is to be used in example configurations (including actual MIB values). It appears that different things have changed within the MIB with no concern for the overall effect on the MIB. These changes also seem to have been driven almost entirely by chassis developers wanting a change to support, in the easiest way, their particular MIB with no thought to the generic management application. At Columbus I felt there was reasonable concensus between a reasoable number of people for the new model, accepting some of the limitations in favour of a practical solution. I think the current MIB changes that model in a number of fundamental ways and that the new model has not been presented, is not understood and is not really usable for an application. I'm disappointed in the current draft and would not recommend presenting it to the Directorate. If you're to forward anything I would suggest an earlier draft that has some of the new 'features' removed. Leaving the content aside the latest version is has more MIB errors than the previous versions which were more stable. The text at the front of the document bears no resemblance to the (Columbus) model or MIB, and very good text is required for a MIB of this complexity! I was hoping these concerns could be aired at the Amsterdam meeting and so I'm _very_ dissappointed it has been cancelled. Without that meeting I don't think we have anything in a fit state to send to draft standard. I was under the impression from the mail sent around by Marshall that we'd had a reprieve after the progress made at the last meeting to get something done by the Amsterdam meeting, I assumed this included a meeting in Amsterdam. As much as I hate to say this, and I've put a LOT of work into this MIB, we ought to admit defeat due to administrative problems (SNMPv2 taking the limelight, work pressures on the chair(s) resulting in lack of strong direction) and restart the group with a strong chairperson with a time to allocate to the group. I don't mean to critisise Bob by this statement, I know how real work pressures build up, I've been there, am there and have no doubt that I will be there again :-) I will be sending seperate comments on the actual MIB. Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07513; 7 Jul 93 11:51 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa07509; 7 Jul 93 11:51 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA29322; Wed, 7 Jul 93 11:19:21 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 11:19:20 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA29314; Wed, 7 Jul 93 11:19:18 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA21388 (5.65c/IDA-1.4.4-910725 for ); Wed, 7 Jul 1993 08:19:15 -0700 Received: by gw.3Com.COM id AA28126 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 7 Jul 1993 08:19:14 -0700 Date: Wed, 7 Jul 93 16:14 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: Comments. To: chassismib@cs.utk.edu Message-Id: <930707.081754@3Mail.3Com.COM> Msg-Date: 1993-07-07 Msg-Time: 16:14 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: Comments. Date: 1993-07-07 16:07 Priority: Message ID: EE9B04D8 Conversation ID: EE9B04D8 ------------------------------------------------------------------------------ I'm quite surprised by the level of changes in the chassis MIB since the last revision.Some immediate comments are: The model has changed, without anyone describing the new model. The last change was backed up by a presentation and examples so that the model could be understood and hopefully accepted. That proposal specified a simple model: o A chassis contains a number of physical locations. o Each physical location can contains a single module, or can be empty. o A module in the chassis contains a number of resources, or components. Resources are things like repeater port, bridge relays, router relays. Things that need to be visible to the chassis for the purpose of identifying configuration. o The components in the chassis are grouped together to implement functional entities, such as repeaters, bridges. It is not the intention of this MIB to replace other standard MIBs, but simply to provide additional control and information about an entity that is outside the scope of the MIB for that device. One major example, and in some ways the most important is the configuration of resources together into entities. For example a chassis can provide the means of switching individual repeater ports between one of a number of repeater entities. This functionality is outside the scope of the standard repeater MIB. Once a repeater port is switched to one of the repeater entities though, it is managed through the correct instance of the repeater MIB. Problems with the current draft (June 24). 1) Resources are no longer part of a module, so what are they? Remember at some point it will be necessary to describe the model we are using. Examples etc are required and everyone needs to think of the APPLICATION that has to use the MIB, NOT the agent. The MIB is for the manager, not the agent! 2) Resources are identified by some chassis unique value, an integer. One common case where resources are useful is to map per-port-switching Ethernet or Token Ring ports to one of a number of chassis repeaters. Each switchable port is a resource. Now as far as the user is concerned these ports are numbered 1 thru n on each card. With the previous draft the resource numbering on that card could also be 1 thru n and so the mapping is clear! Now port 1 may map to resource 52, port 2 to 55 etc. If I want to switch the user on port 1 from repeater entity X to repeater Y, how do I know which resource to switch? I don't from the current MIB. I strongly recommend dropping this idea of divorcing the resource from the module. 3) The current draft does not allow for the assignment of resources to entities, something I maintain is a MUST for this MIB, it is outside the scope of any specific MIB. In the previous draft of the MIB I believe there was a physical resource table which had an entity assignment column which contained the (single) entity to which this resource belongs. This column allows a particular resource to be currently unassigned. An additional column contained the OID entity type to which this resource could be assigned.This was a hint to an application but would work in almost every case. An application could be written for that MIB that could generically determine the chassis configuration that would be understandable to the user, even if some of the semantics were missing to the application. 4) The previous draft allowed for the creation of a new entity. This may seem strange but consider a multi-repeater chassis. Say I have a box that can sub-divide users into different repeated groups then use bridge or router security between groups. I believe there are products like this available now. If I've partitioned my network into 3 repeated networks then decide for either load or security reasons that another group is required the old MIB allowed this: create a new repeater entity assign the repeater ports to that entity that I'm interested in. assign a spare bridge repeater port to that repeater for security. easy. Again this is a chassis problem, because the logical configuration of port outside of a chassis is not possible. The generic repeater and bridge MIBs do not and should not do this. Now this is another feature that seems to have been removed from the MIB. Remember in the original Columbus proposal I showed how all these requirements could be met and how a large number of configurations could be modelled. Before making changes to that MIB I'd like it demonstrated that we are not loosing ability simply because of a lack of a few minutes thought. I think the onus should be on a proposer of a change such as many-to-many to demostrate that the MIB does not break in other areas. That resources can be configured, that entities can be created etc. In summary I think the MIB was much better a couple of drafts ago. It seems to have lost a lot of functionality for the sake of a more complex, but less useful MIB. I don't believe there are a majority of people supporting the changes and I don't think all the consequences have been thought through. I would NOT BE HAPPY presenting this MIB to the IETF as a standard. If we have to present something then use the previous draft which was at least consistent and held together and was capable of supporting a generic application. We can then work the many-to-many resource/entity relationship correctly into that MIB with compromising all the other benefits of the MIB! Pete Wilson.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10251; 7 Jul 93 14:30 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa10247; 7 Jul 93 14:30 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13100; Wed, 7 Jul 93 14:02:54 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 14:02:53 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA13090; Wed, 7 Jul 93 14:02:50 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA22355 (5.65c/IDA-1.4.4-910725 for ); Wed, 7 Jul 1993 11:02:47 -0700 Received: by gw.3Com.COM id AA06918 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 7 Jul 1993 11:02:46 -0700 Date: Wed, 7 Jul 93 18:59 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: One more go at the many-to-many mapping To: chassismib@cs.utk.edu Message-Id: <930707.110126@3Mail.3Com.COM> Msg-Date: 1993-07-07 Msg-Time: 18:56 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: One more go at the many-to-many mapping (resource/entity) Date: 1993-07-07 18:52 Priority: Fixed Font: 0001 Message ID: 8AFF2C93 Conversation ID: 8AFF2C93 ------------------------------------------------------------------------------ I want one last attempt to persuade everyone that the many-to-many maping is NOT required before I have a go at merging the many-to-many MIB with the configuration requirements that it does not currently meet :-) The sticking point seems really to be the bridge/router card so I'll use this for illustration purposes. Some assumptions: - The chassis MIB only provides configuration reporting and chassis type configuration control (ie moving a port to a different repeater). - This means ALL bridge or router control is provided by the MIB for that kind of device, NOT the chassis MIB. - As an example a bridge/router card comprises: - A bridge element with its own MIB. - A router element with its own MIB. - 2 bridge ports through which bridge traffic is forwarded - 2 router ports through which router traffic is forwarded - 2 physical _repeater_ ports onto backplane Ethernets. The  internal bridge and router ports share these ports for traffic. - The chassis MIB allows the _physical_ ports  to be switched to one of 3 ethernet segments. - The bridge/router ports are unimportant as far as the chassis MIB is concerned, they are entirely encapsulated in the specific MIB. Now in this situation the resource table contains the following entries for this card: Resource 1: Repeater Port Resource 2: Repeater Port Resource 3: Bridge Relay Resource 4: Router Engine The entities that exist in this chassis are: Entity 1: Repeater, backplane 1 Entity 2: Repeater, backplane 2 Entity 3: Repeater, backplane 3 Entity 4: Bridge Entity 5: Router Now when the bridge/router card is connected to ethernet backplanes 1 and 2, the resource to entity mapping is as follows: Resource 1: Repeater Port  Entity 1 Resource 2: Repeater Port  Entity 2 Resource 3: Bridge Relay  Bridge Resource 4: Router Engine  Router This information allows the view of each entity to be obtained and so the system can be managed. There are a couple of important features of this example which should be considered: 1. Resource to Entity mapping is one to one! 2. Allows a simple way of switching one of the ports to one of the backplanes. 3. Does not use a 'brouter' entity. One question raised at the Columbus meeting was: 'I don't no to which repeater port bridge interface 1 is connected' This was discussed at considerable length and the conclusion was that while this is useful information: a) By analogy this information would not be available in a MIB if the repeaters and bridges were not in a chassis. b) This is a general network topology issue that cannot be answered by the chassis MIB. c) It wasn't worth complicating the proposal by overloading these tables with topology information. If this to be covered by this MIB then a sensible place is to create a seperate MIB group with a topology table. A lot of the many to many map seems to be trying to answer this last point, and everything just gets too complicated. Leave the existing tables alone and deal with the topology elsewhere. eg a 'interconnection link' table: TABLE:  thing-X, interface 1 'connects to' thing-Y It is actually possible to generate such a table that is generic enough not to be restricted to a chassis and so could help the general topology problem! I'll try to put together a fairly simple example MIB section you may like to think about. SUMMARY!!! The simple mappings _can_ be used to describe any chassis configuration provided the tables are not overloaded with too many different concepts. Keep the basic tables one-to-one (resource-entity) and one-to-one (resource to module). If you want to map the interconnection of logical devices in your chassis then a different MIB group should be proposed. Remember ISO try to have one solution that does everything! If we try to we'll never finished. I would like to propose that the simpler version of the MIB be presented to the IETF as a draft standard and that if people want additional information we can add that information in a later version as seperate groups. Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11629; 7 Jul 93 15:31 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa11625; 7 Jul 93 15:31 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA17853; Wed, 7 Jul 93 15:07:05 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 15:07:03 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from aristo.tau.ac.il by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA17839; Wed, 7 Jul 93 15:06:59 -0400 Received: from gandalf.lannet.com ([192.114.33.2]) by aristo.tau.ac.il with SMTP id AA23439 (5.65c/IDA-1.4.4 for ); Wed, 7 Jul 1993 22:06:25 +0300 Received: from moon.lannet.com by gandalf.lannet.com (4.1/SMI-4.1) id AA03362; Wed, 7 Jul 93 11:57:07 IDT Received: from gandalf.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA10205; Wed, 7 Jul 93 11:58:17 IDT Date: Wed, 7 Jul 93 11:58:17 IDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascanu Message-Id: <9307070858.AA10205@moon.lannet.com> To: chassismib@cs.utk.edu Subject: Working Group Status > > July 5 was our deadline to have a document ready for recommendation as a > > Proposed Standard. The volume of discussion on the list lately has improved, > > but I must apologize that I have not had time to follow it either to moderate > > or contribute, and as such I have little idea as to where the document stands. > > Yes, that means I've not been a good chair. Real Life intruded. Anyway... > > > > *** Call for Consensus *** > > > > Assuming that we have a relatively up-to-date draft, I propose that we drop it > > in the laps of the Network Management Area Director and his Directorate. They > > may a) pass it on as a Proposed Standard, b) extend our charter, pick a chair > > that will actually help, and ask that it be improved in specific ways, c) > > terminate the working group, or d) do something else they think of. > > > > Noting that we have little other choice, do I hear strong objections or > > alternatives? Also please note that I will not be able to even look at > > replies until Friday (Real Life). At least this provides an organized topic > > for yelling, and some of the Directorate people are surely listening. > > > > *** No-Meeting Announcement *** > > > > We are on the agenda for Amsterdam. This was a bit unusual, as our schedule > > defines us as done by then. Due to the aforementioned intrusion of Real Life, > > I will not be in Amsterdam. There will be no Chassis MIB meeting there. I > > apologize for this late notice. See previous excuses. > > > > Bob > > > this is most unfortunate... > I feel that the MIB was pretty close, and that there was a good > chance of reaching consensus at the amsterdam meeting...it seems > an almost done deal that the WG will be disbanded... > > is the meeting definately cancelled...because I have to change > my travel plans and I won't be able to change them twice > (if a meeting is added back to the schedule) > > --andy; > OK, Bob, here is a strong objection! It would really be a pitty to abandon the effort, when we are so close to a workable solution. In fact in my opinion we must only do some cleaning and make some small adjustments. Abandoning now would mean remaining with a bunch of unsolved problems. One of them is connected to the Repeater ID subject which was left by the the Repetear MIB WG on the assumption that Chassis MIB will be used to manage multiple repeaters in the same chassis. I also strongly object to the No-Meeting Announcement, two days before boarding the plane to Amsterdam. I do not know what rules say, but my opinion is that the WG should meet in the programmed spot in Amsterdam, the meeting may be chaired by one of the draft authors: Keith, Pete Wilson, Dave Arneson. We should make the last corrections, give the absents the time to comment and then, a.s.a.p. pass it as a Proposed Standard. Dan Romascanu, LANNET Data Communications Ltd., Tel Aviv, ISRAEL Voice: 972-3-6458-414, Fax: 972-3-5447-416   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13556; 7 Jul 93 16:38 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa13552; 7 Jul 93 16:38 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA23758; Wed, 7 Jul 93 16:18:01 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 16:18:00 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA23750; Wed, 7 Jul 93 16:17:55 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA23341; Wed, 7 Jul 93 13:17:16 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mrose.ietf@dbc.mtview.ca.us Reply-To: chassismib@cs.utk.edu To: chassismib@cs.utk.edu Subject: Re: Working Group Status Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Wed, 07 Jul 1993 13:17:15 -0700 Message-Id: <23340.742076235@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Speaking as the Area Director (note the From: line)... On April 14th, a message was sent to the Chassis MIB WG indicating that it had exceeded its lifetime and was being granted an extension until July 5th. By that time, it was to have achieved concensus on a document. As such, any meeting of the working group in Amsterdam would be inappropriate. Yesterday's note from the chair was to determine if there was concensus on the current draft. I am waiting to hear about the outcome. - If there is concensus that the current draft is the WG's completed output, then, as with any MIB module finished by a WG, the draft will be reviewed by the NM Directorate. - If there is not concensus that the current draft is the WG's completed output, then, the WG will be considered concluded until such time as resources permit the charter of a new WG effort. Meeting in Amsterdam is not an option. "Fair warning" was given twelve weeks ago, and there have been no complaints in the interim... /mtr ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" ------- =_aaaaaaaaaa1 To: chassismib@cs.utk.edu Subject: A message from the new Area Director MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Apr 1993 08:45:37 -0700 Message-ID: <103.734802337@dbc.mtview.ca.us> From: Marshall Rose Greetings. First, I want to congratulate the working group for making some real progress in modeling last week at the IETF meeting. Second, I regret to inform you that Jeff Case has asked to withdraw as co-chair of the working group. As you probably know, Jeff has been heavily involved with many IETF-related activities such as the IAB/IESG nomination process, and now needs some time for other activities. Bob Stewart, formerly co-chair, is now sole-chair of the working group. Third, after reviewing the charter, I find that the working group is three months past its chartered lifetime. This concerns me quite a bit. After having seen the progress last week, I do not want to terminate the working group. On the other hand, I can not let this effort continue indefinitely. In reviewing the charter of the working group, three tasks are discussed: - to develop MIB objects relating the physical resources and logical functions within a chassis device; - to develop MIB objects instrumenting the operational state of a power supply in a chassis device; and, - to develop MIB objects representing aggregated information about collections of network devices. The first was a mandatory task, the other two are optional. After attending last week's meeting, it appears that the working group has a handle on the first two tasks, but has not yet begun work on the third task. So, in order to allow for the working group to reach a successful conclusion: - the working group is directed to focus its efforts on the first two tasks; - if, by July 5, 1993, the working group has not achieved consensus on a document and indicated this to the area director, then I will ask the IESG to terminate the working group; and, - the third task is now considered out of scope for the working group. The members of the working group should appreciate that I have provided this three month extension because it is my hope that it will allow the working group to focus and reach consensus. However, at the end of this extension, the working group will be six months over due. If it has not completed its work by that time, then I feel that continuation of this effort will not be of service to the community. Thank you for your understanding, /mtr ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16009; 7 Jul 93 18:42 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa16005; 7 Jul 93 18:42 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA02311; Wed, 7 Jul 93 18:28:25 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 7 Jul 1993 18:28:24 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA02302; Wed, 7 Jul 93 18:28:21 -0400 Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA11625; Wed, 7 Jul 93 15:27:50 PDT Received: by donatello (4.1/2.0N) id AA21260; Wed, 7 Jul 93 15:27:49 PDT Message-Id: <9307072227.AA21260@donatello> Date: Wed, 7 Jul 93 15:27:49 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Bierman To: chassismib@cs.utk.edu Subject: Re: Working Group Status > > Speaking as the Area Director (note the From: line)... > > On April 14th, a message was sent to the Chassis MIB WG indicating that > it had exceeded its lifetime and was being granted an extension until > July 5th. By that time, it was to have achieved concensus on a > document. As such, any meeting of the working group in Amsterdam would > be inappropriate. > > ... > Meeting in Amsterdam is not an option. "Fair warning" was given twelve > weeks ago, and there have been no complaints in the interim... > > /mtr > I am one of the guilty ones...guilty of assuming there was to be a chassis MIB WG meeting simply because every version of the agenda for the this IETF (that I've seen) included a Chassis MIB WG meeting on July 14. Why wasn't it removed from the agenda before this week? Why was it on the final agenda? final comments -- chassis MIB WG --------------------------------- Depending on what one wanted out of the chassis MIB in the first place, one can decide how close the current draft is to meeting those expectations. There seems to be two camps: 1) those who want to use the chassis MIB to retrieve inventory data and 'point' to other agents in the chassis 2) those who want to use the chassis MIB to manage arbitrary logical and physical entities within the chassis I don't think the two camps ever reconciled on the model because we never reconciled on the goals. I am in the first camp and think there is enough solid work there to achieve the stated objective. I can't say the same for the objectives of the second camp. In either case, a meeting next week would have helped... --andy; abierman@synoptics.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00804; 8 Jul 93 4:15 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa00800; 8 Jul 93 4:15 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA04276; Thu, 8 Jul 93 03:55:16 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 8 Jul 1993 03:55:16 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA04263; Thu, 8 Jul 93 03:55:13 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA25904 (5.65c/IDA-1.4.4-910725 for ); Thu, 8 Jul 1993 00:55:09 -0700 Received: by gw.3Com.COM id AA06864 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Thu, 8 Jul 1993 00:55:07 -0700 Date: Thu, 8 Jul 93 08:12 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: Amsterdam Meeting To: chassismib@cs.utk.edu Message-Id: <930708.001614@3Mail.3Com.COM> Msg-Date: 1993-07-08 Msg-Time: 08:10 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: Amsterdam Meeting Date: 1993-07-08 08:07 Priority: Message ID: B8F9B06C Conversation ID: B8F9B06C ------------------------------------------------------------------------------ Any reason why we can't have an informal meeting to discuss what, if anything, to present as a standard? We all thought there was going to be a meeting anyway. Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00985; 8 Jul 93 5:01 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa00981; 8 Jul 93 5:01 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10573; Thu, 8 Jul 93 04:36:37 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 8 Jul 1993 04:36:36 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from relay.conware.de by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10565; Thu, 8 Jul 93 04:36:27 -0400 Received: from slc_2.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0oDr1v-000Ci3C; Thu, 8 Jul 93 10:08 MET DST Received: by slc_2.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Thu, 8 Jul 93 10:09 MET DST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Guenter Roeck Subject: Re: Amsterdam Meeting To: {3COM/PDD/PeteW}@pdd.3mail.3com.com Date: Thu, 8 Jul 93 10:09:26 MET DST Cc: chassismib@cs.utk.edu In-Reply-To: <930708.001614@3Mail.3Com.COM>; from "{3COM/PDD/PeteW}@pdd.3mail.3com.com" at Jul 8, 93 8:12 am X-Mailer: ELM [version 2.3 PL11] > > Any reason why we can't have an informal meeting to discuss what, if > anything, to present as a standard? We all thought there was going to be a > meeting anyway. > I would suggest to do the same thing. Unfortunately, I will be in holiday next week. I checked all the drafts (00..02) in the meantime. For me, draft 00 fits best to our needs, and I think it is the simplest and best to implement. Guenter -------------------------------------------------------------------------- Guenter Roeck - Conware GmbH Phone: (0049) 721-9495-0 Internet: roeck@conware.de Fax: (0049) 721-9495-146 --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01138; 8 Jul 93 6:28 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa01134; 8 Jul 93 6:28 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05237; Thu, 8 Jul 93 04:06:15 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 8 Jul 1993 04:06:13 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from relay.conware.de by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05195; Thu, 8 Jul 93 04:05:48 -0400 Received: from slc_2.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0oDqug-000Ci5C; Thu, 8 Jul 93 10:01 MET DST Received: by slc_2.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Thu, 8 Jul 93 10:01 MET DST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Guenter Roeck Subject: Re: Working Group Status To: Andrew Bierman Date: Thu, 8 Jul 93 10:01:54 MET DST Cc: chassismib@cs.utk.edu In-Reply-To: <9307072227.AA21260@donatello>; from "Andrew Bierman" at Jul 7, 93 3:27 pm X-Mailer: ELM [version 2.3 PL11] > > final comments -- chassis MIB WG > --------------------------------- > Depending on what one wanted out of the chassis MIB in the first place, > one can decide how close the current draft is to meeting those > expectations. There seems to be two camps: > > 1) those who want to use the chassis MIB to retrieve inventory data > and 'point' to other agents in the chassis > > 2) those who want to use the chassis MIB to manage arbitrary logical > and physical entities within the chassis > > I don't think the two camps ever reconciled on the model because we > never reconciled on the goals. > > I am in the first camp and think there is enough solid work there > to achieve the stated objective. I'm in the first camp as well. Actually, when I reviewed the draft this week, I did not have the newest version; thus my mail earlier in this week does not reflect my statement to the current MIB. I don't know which one I looked into, but it is totally different to the current one. In the meantime, I checked the newest version as well. I think it is just unusable for us; I don't know what a lot of objects (and groups) are supposed to mean and how to implement those objects, and furthermore there are a lot of groups I don't know what to do with (in real life, not theoretically). From our point of view, the MIB made a long step backwards in the last two months. Guenter -------------------------------------------------------------------------- Guenter Roeck - Conware GmbH Phone: (0049) 721-9495-0 Internet: roeck@conware.de Fax: (0049) 721-9495-146 --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07704; 8 Jul 93 11:25 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa07700; 8 Jul 93 11:25 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28555; Thu, 8 Jul 93 09:05:28 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 8 Jul 1993 09:05:27 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from nic.near.net by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA28547; Thu, 8 Jul 93 09:05:26 -0400 Received: from ctron.com by nic.near.net id aa16130; 8 Jul 93 9:05 EDT Received: from stealth.ctron.com ([134.141.6.107]) by ctron.com (4.1/SMI-4.1) id AA11987; Thu, 8 Jul 93 09:05:22 EDT Received: from cardinals.ctron by stealth.ctron.com (4.1/SMI-4.1) id AA06346; Thu, 8 Jul 93 09:05:14 EDT Received: from yeti.ctron by cardinals.ctron (4.1/SMI-4.1) id AA12374; Thu, 8 Jul 93 09:03:47 EDT Date: Thu, 8 Jul 93 09:03:47 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David L. Arneson" Message-Id: <9307081303.AA12374@cardinals.ctron> To: chassismib@cs.utk.edu Subject: Talk about MIB As Pete Wilson stated I don't see any reason why we can not hold an informal meeting to discuss the current MIB and where we need it to transition. Since we were all planning to meet at 1:30 on Wednesday why don't we plan to meet at the same time. I think the time would be best spent trying to understand where we need to go with this MIB. Perhaps we can organize a new working group closer to November time frame. This time we can be prepared with a MIB that is almost finished. /David Arneson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12669; 8 Jul 93 14:30 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa12665; 8 Jul 93 14:30 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA16718; Thu, 8 Jul 93 13:35:39 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Thu, 8 Jul 1993 13:35:37 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA16700; Thu, 8 Jul 93 13:35:32 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA03064; Thu, 8 Jul 93 10:34:44 -0700 To: "David L. Arneson" Reply-To: chassismib@cs.utk.edu Cc: chassismib@cs.utk.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IETF Area Director for Network Management Subject: Re: Talk about MIB In-Reply-To: Your message of "Thu, 08 Jul 1993 09:03:47 EDT." <9307081303.AA12374@cardinals.ctron> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Jul 1993 10:34:43 -0700 Message-Id: <3063.742152883@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us > Since we were all planning to meet at 1:30 on Wednesday > why don't we plan to meet at the same time. There will be no meeting relating to the Chassis MIB effort at Amsterdam. I refer you to my message of yesterday which details the options open to the WG. Meeting next week isn't one of them. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00660; 9 Jul 93 3:40 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa00656; 9 Jul 93 3:40 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03499; Fri, 9 Jul 93 03:11:20 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 9 Jul 1993 03:11:16 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from relay.conware.de by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03439; Fri, 9 Jul 93 03:10:52 -0400 Received: from slc_1.conware.de by relay.conware.de with smtp (Smail3.1.28.1 #2) id m0oECY8-000CnHC; Fri, 9 Jul 93 09:07 MET DST Received: by slc_1.conware.de (/\==/\ Smail3.1.25.1 #25.8) id ; Fri, 9 Jul 93 09:08 MET DST Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Guenter Roeck Subject: Re: Talk about MIB To: chassismib@cs.utk.edu Date: Fri, 9 Jul 93 9:08:02 MET DST In-Reply-To: <3063.742152883@dbc.mtview.ca.us>; from "IETF Area Director for Network Management" at Jul 8, 93 10:34 am X-Mailer: ELM [version 2.3 PL11] > > > Since we were all planning to meet at 1:30 on Wednesday > > why don't we plan to meet at the same time. > > There will be no meeting relating to the Chassis MIB effort at > Amsterdam. I refer you to my message of yesterday which details the > options open to the WG. Meeting next week isn't one of them. > It seems to me that Marshal does not like to see that the group meets and meets and meets... I attended the two chassis MIB meetings last year, and I hoped it would be no problem to get the MIB out at the march meeting this year. Unfortunately, there seems to be much talk in the group at IETF meetings, but not much more. Furthermore, since I have seen the results (draft #1 and #2) of the last meeting, it seems to me that the MIB gets further and further away of what we talked about last year. Thus, I agree with Marshal at this point - I do not see any possible success for a meeting in Amsterdam. It would probably cause more talk, more changes and nothing else. For my feeling, the MIB got much too complicated in the meantime. Please remember what happened to the Ethernet MIB - it gets stripped more and more, and has now reached a point where it is very easy to implement it. Why should we do the same thing with the chassis MIB ? I strongly suggest to take the chassis MIB draft #0 and put it to the standards track, without more than syntactical changes, if this should be necessary. As far as I can see it, this would be the only way to keep the MIB alive, since all other drafts are much more incomplete. It also would be the only way to get a MIB that is really usable and implementable. Guenter -------------------------------------------------------------------------- Guenter Roeck - Conware GmbH Phone: (0049) 721-9495-0 Internet: roeck@conware.de Fax: (0049) 721-9495-146 --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09026; 9 Jul 93 17:54 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa09022; 9 Jul 93 17:54 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07464; Fri, 9 Jul 93 17:32:21 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Fri, 9 Jul 1993 17:32:18 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07456; Fri, 9 Jul 93 17:32:16 -0400 Received: from engtwomac.synoptics.com by synoptics.com (4.1/SMI-4.1) id AA19926; Fri, 9 Jul 93 14:31:42 PDT Message-Id: <9307092131.AA19926@synoptics.com> Date: 9 Jul 1993 14:31:44 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Geoff Thompson Subject: Re: Talk about MIB To: chassismib@cs.utk.edu, Marshall Rose Cc: Vint Cerf , Phil Gross Reply to: RE>>Talk about MIB <> Since we were all planning to meet at 1:30 on Wednesday >> why don't we plan to meet at the same time. >There will be no meeting relating to the Chassis MIB effort at >Amsterdam. I refer you to my message of yesterday which details the >options open to the WG. Meeting next week isn't one of them. > >/mtr Marshall- Your quote of David Arneson's message was taken out of context. The complete text is quoted above. He clearly asked for an INFORMAL meeting. I don't think that there was any assertion that the result of any such gathering would have any greater weight than the sum of individual opinions. Are you asserting that you get to decide whether folks of an interest group can have an informal meeting on a common topic of interest at an IETF meeting? Ifso, then there is a much larger issue being opened here about free speech and the open use of mailing lists. I think you are overstepping your authority. Geoff Thompson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11850; 11 Jul 93 10:05 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa11846; 11 Jul 93 10:05 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25314; Sun, 11 Jul 93 09:43:22 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Sun, 11 Jul 1993 09:43:21 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25306; Sun, 11 Jul 93 09:43:17 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA13041; Sun, 11 Jul 93 06:42:26 -0700 To: Geoff Thompson Cc: chassismib@cs.utk.edu, Vint Cerf , Phil Gross Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IETF Area Director for Network Management Subject: Re: Talk about MIB In-Reply-To: Your message of "09 Jul 1993 14:31:44 +0800." <9307092131.AA19926@synoptics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jul 1993 06:42:23 -0700 Message-Id: <13040.742398143@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us Geoff - this isn't a free speech issue. It is unclear to me what you mean by an "INFORMAL" meeting. - Meeting slots at an IETF meeting are controlled by the IETF Secretariat in coordination with the appropriate Area Director. The Chassis MIB WG is not qualified to meet at Amsterdam. My note specifically said that. - If some people want to meet in a hallway, a bar, or a restaurant, as long as they don't call it a WG meeting, that's fine. My note did not prohibit that. This latter kind of gathering is not an IETF meeting, as it is neither a WG or BOF meeting. If you wish to discuss this matter further, you can raise it at either the NM Area open meeting (tuesday morning) or the IETF open plenary (thursday evening). If you still are not satisifed, there is a specific appeals process available, which has been repeatedly published. In future, you might perhaps try following the procedure instead of invoking the IETF chair and the ISOC president all in one shot. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02674; 13 Jul 93 9:24 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa02670; 13 Jul 93 9:24 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10217; Tue, 13 Jul 93 08:56:10 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Tue, 13 Jul 1993 08:56:09 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA10209; Tue, 13 Jul 93 08:56:06 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA17564 (5.65c/IDA-1.4.4-910725 for ); Tue, 13 Jul 1993 05:56:02 -0700 Received: by gw.3Com.COM id AA20060 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Tue, 13 Jul 1993 05:56:00 -0700 Date: Tue, 13 Jul 93 13:43 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: Inter-entity connections. To: chassismib@cs.utk.edu Message-Id: <930713.055544@3Mail.3Com.COM> Msg-Date: 1993-07-13 Msg-Time: 13:40 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: Inter-entity connections. Date: 1993-07-13 13:37 Priority: Fixed Font: 0001 Message ID: 24D88EC5 Conversation ID: 24D88EC5 ------------------------------------------------------------------------------ This text proposes one way in which the chassis MIB one resource to one module and one resource to one entity relationships can be maintained but also how the MIB can be enhanced to include information that allows entity interconnection information to be made visible in the MIB. Basically the configuration MIB groups already available are augmented by a interconnection group. The interconnection group contains 'link definitions'. Each link definition describes a connection between two entities in the chassis. I'll describe this by means of an example. Consider a 3 port bridge which has two Ethernet and one 802.5 port. The chassis also contains three other entities, a token ring and two Ethernet. The bridge ports are connected to these entities. Now the configuration groups describe the equipement in the chassis as follows: Discrete equivalent of the chassis configuration. +----------+ | Bridge | +-+--+--+--+ | | | | | +---------------+ +--+--+----+ | | +-+--------+ | +-----+------+ |Repeater 1|<---+ +--->|Repeater 2| +->|Token Ring 1| +----------+ +-+--------+ +-----+------+ The MIB to represent this configuration would be as follows: Module Table: +----------------------------------------------------------+ |location type | instance | Contents OID | Description |...| +==========================================================+ | backplane | 1 | multiServBp | "" | | | modularSlot | 1 | repeaterMod | ".3 RLC..." | | | modularSlot | 2 | repeaterMod | ".3 RLC..." | | | modularSlot | 3 | tokenRingMod| ".5 RLC..." | | | modularSlot | 9 | bridgeMod | "Bridge" | | +--------------+----------+--------------+-------------+---+ Entity Table: Indexed by a unique integer. +----------+-------------+----------------------+---+ |Entity Id | Entity OID | Description |...| +===================================================+ | 1 | repeater | ".3 Rptr B'plane 1" | | | 2 | repeater | ".3 Rptr B'plane 2" | | | 3 | tokenRing | ".5 Token Ring" | | | 4 | bridge | "3 port .3/.5 Bridge"| | +----------+-------------+----------------------+---+ The physical resource table provides information regarding all the resources in the system. It also provides the mapping of resource to module and from resource to entity. The resource table is indexed on location type, instance and a resource number within that module. The location type and instance provide the map to the module table. The assignment column contains the id of the single entity to which this resource is currently assigned. map |<---- map to module ---->| |<-to entity->| +--------------+----------+----------+-------------+--------------+ |location type | instance | Resource | (Entity Id) | Resource OID | +=================================================================+ | backplane | 1 | 1 | 1 | rptrBplane | | backplane | 1 | 2 | 2 | rptrBplane | | backplane | 1 | 3 | 3 | tkBplane | | modularSlot | 1 | 1 | 1 | rptrGroup | | modularSlot | 2 | 1 | 2 | rptrGroup | | modularSlot | 3 | 1 | 3 | trGroup | | modularSlot | 9 | 1 | 1 | rptrPort | | modularSlot | 9 | 2 | 2 | rptrPort | | modularSlot | 9 | 3 | 3 | trPort | | modularSlot | 9 | 4 | 4 | bridge | +--------------+----------+----------+-------------+--------------+ The logical resource table describes the same relationships but using the entity relationship as the SNMP index to provide direct entity to resource mappings. Now with reference to the picture above the MIB so far has not specified the interconnection of entities. It is suggested that this information be kept in a seperate optional MIB group. The new group will provide a 'entity, connected to entity' mapping. There are several ways this information can be maintained, for example resource to resource, entity to resource, resource to entity or straight entity to entity. Consider an entity to entity table. This could simply contain the following information: Link Index from to ------------------------------------------------------ 1 entity 1 connects to entity 4 2 entity 2 connects to entity 4 3 entity 3 connects to entity 4 4 entity 4 connects to entity 1 5 entity 4 connects to entity 2 6 entity 4 connects to entity 3 This is not the most useful way of representing the information. There is no way to ask which entities are connected without reading the whole table. Neither is it possible to say by which resources the entities are connected. Perhaps a better way is to use a resource to resource mapping. This does however create the need to have some additional resources simply to complete the mapping. Consider the bridge card as being described as 7 resources: |<---- map to module ---->| |<-to entity->| +--------------+----------+----------+-------------+--------------+ |location type | instance | Resource | (Entity Id) | Resource OID | +=================================================================+ | ... | ... | ... | ... | ... | | modularSlot | 9 | 1 | 1 | rptrPort | | modularSlot | 9 | 2 | 2 | rptrPort | | modularSlot | 9 | 3 | 3 | trPort | | modularSlot | 9 | 4 | 4 | bridgePort |* | modularSlot | 9 | 5 | 4 | bridgePort |* | modularSlot | 9 | 6 | 4 | bridgePort |* | modularSlot | 9 | 7 | 4 | bridge | +--------------+----------+----------+-------------+--------------+ The bridge ports have been introduced for the purpose of providing a complete mapping. They are not required unless the interconnection information is to be supported. Note that the bridge ports are part of the bridge entity, but that they actually transmit traffic via the .3 and .5 physical ports. Now the interconnection table looks like this: Link Index from resource to resource ------------------------------------------------------ 1 modSlot.4.1 connects to modSlot.4.4 1 modSlot.4.2 connects to modSlot.4.5 1 modSlot.4.3 connects to modSlot.4.6 1 modSlot.4.4 connects to modSlot.4.1 1 modSlot.4.5 connects to modSlot.4.2 1 modSlot.4.6 connects to modSlot.4.3 Note that no other resources need to be present in the mapping table. These are the only inter-entity connections! Note that in the 02 draft, there is now actually 2 ways of describing a resource, either by it's (locType, loc, index) fixed triplet, or by the (entity, resource-subindex) pair. The second description changes will change when a resource is switched from one entity to another. Most of the interconnection relationships are best defined in terms of entity/sub- index. It is the entities that are interconnected, not the modules. THE POINT ========= As discussed at the Columbus meeting, the interconnection information is important but it is too difficult to try to have one set of tables describe everything. It just does not work. The configuration tables should be just that. Interconnection should be represented in a seperate table or group. The recommendation then is to take the fairly stable draft-ietf-chassis- mib-01.txt as the basis of a standard and build on that. Forget the ever more complex overloading of the same tables and the ever more complex and fuzzy definitions of entities, resources and modules. Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27417; 19 Jul 93 12:04 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa27413; 19 Jul 93 12:04 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA27587; Mon, 19 Jul 93 11:27:08 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Mon, 19 Jul 1993 11:27:07 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from xap.xyplex.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA27579; Mon, 19 Jul 93 11:27:04 -0400 Received: by xap.xyplex.com id ; Mon, 19 Jul 93 11:26:02 -0500 Date: Mon, 19 Jul 93 11:26:02 -0500 Message-Id: <9307191626.AA03987@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: mrose.iesg@dbc.mtview.ca.us, chassismib@cs.utk.edu Subject: Working Group Status To the Area Director and the Working Group, from the Working Group Chair. Although several individuals want to see the work completed, and a few were willing to work hard to that end, the Chassis MIB Working Group was unable to reach consensus by its 5 July 1993 deadline. I regret that this work did not complete, especially considering my own lack of contribution. I continue to believe that a Chassis MIB is needed to resolve the problem of identifying multiple instances of MIBs such as the Repeater MIB. I also believe that a Chassis MIB that enables a general chassis drawing application might have encouraged general-purpose application development, but there has been little success in encouraging such work with any MIB other than RMON. Bob   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05158; 19 Jul 93 21:22 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23331; 19 Jul 93 21:22 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05142; 19 Jul 93 21:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05090; 19 Jul 93 21:18 EDT Received: from excelsior.cnri.reston.va.us by CNRI.Reston.VA.US id aa23205; 19 Jul 93 21:18 EDT Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: IESG Secretary To: IETF-Announce: ; cc: chassismib@cs.utk.edu Subject: WG ACTION: Chassis MIB (chassis) to Conclude Date: Mon, 19 Jul 1993 21:19:13 -0400 X-Orig-Sender: jstewart@CNRI.Reston.VA.US Message-ID: <9307192118.aa23205@CNRI.Reston.VA.US> The Chassis MIB Working Group (chassis) of the IETF has concluded. The Working Group is over six months beyond its charter; it failed to meet consensus by a deadline set by the Area Director; and, the Network Management Area lacks the senior technical resources required to continue this effort. At the beginning of 1994, a determination will be made to see if a new working group should be chartered. The mailing list will remain active. The IESG contact person is Marshall Rose. John Stewart IESG Secretary   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23365; 21 Jul 93 1:48 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa23361; 21 Jul 93 1:48 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA21546; Wed, 21 Jul 93 01:25:17 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 01:25:11 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from vivaldi.fibronics.co.il by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA21493; Wed, 21 Jul 93 01:24:28 -0400 Received: by vivaldi.fibronics.co.il id AA05219 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 21 Jul 1993 08:23:20 +0300 Date: Wed, 21 Jul 1993 08:23:20 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joseph Zur Message-Id: <199307210523.AA05219@vivaldi.fibronics.co.il> To: chassismib@cs.utk.edu Subject: Re: WG ACTION: Chassis MIB (chassis) to conclude Hi all, I read the last two messages from Bob Stewart and from the IESG Secretary and somehow I feel that it is not the case of "we can't do it", but rather, "we don't want to do it". After waiting for the chassis MIB for more then a year I don't want to wait another year for it. I call upon the AD and the IESG to reactivate this working group before 1994. I personally believe that a call for vote on one of the drafts published will show that there is more of a consensus than pepole think. I call upon the working group members who want to see this MIB become a standard to express this "loud and clear" on the mailing list so that the AD and the IESG see that public opinion is not in favour of their decision. --- Joseph Zur Fibronics Inc. Haifa, Israel Voice : INTL-972-4-313679 Fax : INTL-972-4-313342 Email : zur@Fibronics.co.il   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03978; 21 Jul 93 11:03 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa03972; 21 Jul 93 11:03 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA00838; Wed, 21 Jul 93 10:43:53 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 10:43:52 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from aristo.tau.ac.il by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA00829; Wed, 21 Jul 93 10:43:48 -0400 Received: from gandalf.lannet.com ([192.114.33.2]) by aristo.tau.ac.il with SMTP id AA05103 (5.65c/IDA-1.4.4 for ); Wed, 21 Jul 1993 17:42:45 +0300 Received: from moon.lannet.com by gandalf.lannet.com (4.1/SMI-4.1) id AA04197; Wed, 21 Jul 93 17:45:21 IDT Received: from gandalf.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA25025; Wed, 21 Jul 93 17:46:39 IDT Date: Wed, 21 Jul 93 17:46:39 IDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascanu Message-Id: <9307211446.AA25025@moon.lannet.com> To: chassismib@cs.utk.edu Subject: WG ACTION: Chassis MIB (chassis) to conclude Hi everybody, Joseph Zur writes: Hi all, I read the last two messages from Bob Stewart and from the IESG Secretary and somehow I feel that it is not the case of "we can't do it", but rather, "we don't want to do it". After waiting for the chassis MIB for more then a year I don't want to wait another year for it. I call upon the AD and the IESG to reactivate this working group before 1994. I personally believe that a call for vote on one of the drafts published will show that there is more of a consensus than pepole think. I call upon the working group members who want to see this MIB become a standard to express this "loud and clear" on the mailing list so that the AD and the IESG see that public opinion is not in favour of their decision. --- Joseph Zur LOUD AND CLEAR: We do want this MIB to become a standard. But, as Marshal wrote in his last message concerning this subject, it seems that the WG is procedurally dead. In Amsterdam, an open meeting of the NM Area Directorate was held. A moratorium on new WGs was declared untill the end of 1993, 'due to lack of senior technical resources'. This would mean that in order to have the process of standardisation revived, we should not only clearly articulate our wish in this direction, but also have somebody consequently assuming the task of chairing this effort. I do not think that we lack the resources on this regard. According to what I heard in Amsterdam, I am not optimistic upon the chances of reversing this decision before the end of 1993. There might be an apeal procedure, but I bet you would rather use the time in building an implementation than in finding out how to use the apeal procedure. Dan Romascanu, LANNET Data Communications Ltd., Tel Aviv, ISRAEL, Voice: 972-3-6458-414 Fax: 972-3-5447-146   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05514; 21 Jul 93 12:07 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05503; 21 Jul 93 12:07 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA04829; Wed, 21 Jul 93 11:40:42 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 11:40:40 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA04814; Wed, 21 Jul 93 11:40:36 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA13822 (5.65c/IDA-1.4.4-910725 for ); Wed, 21 Jul 1993 08:40:33 -0700 Received: by gw.3Com.COM id AA15312 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 21 Jul 1993 08:40:30 -0700 Date: Wed, 21 Jul 93 16:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: RE: WG ACTION: Chassis MIB (chassis) to To: chassismib@cs.utk.edu Message-Id: <930721.084058@3Mail.3Com.COM> Msg-Date: 1993-07-21 Msg-Time: 16:35 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: RE: WG ACTION: Chassis MIB (chassis) to conc Date: 1993-07-21 16:30 Priority: Message ID: 5BE7E386 Conversation ID: 5BE7E386 ------------------------------------------------------------------------------ >> I personally believe that a call for vote on one of the drafts >> published will show that there is more of a consensus than pepole >> think. I call upon the working group members who want to see this MIB >> become a standard to express this "loud and clear" on the mailing list >> so that the AD and the IESG see that public opinion is not in favour of >> their decision. >LOUD AND CLEAR: We do want this MIB to become a standard. > > But, as Marshal wrote in his last message concerning this subject, it seems > that the WG is procedurally dead. > > In Amsterdam, an open meeting of the NM Area Directorate was held. A > moratorium on new WGs was declared untill the end of 1993, 'due to lack > of senior technical resources'. This would mean that in order to have the > process of standardisation revived, we should not only clearly articulate > our wish in this direction, but also have somebody consequently assuming > the task of chairing this effort. I do not think that we lack the resources > on this regard. > > According to what I heard in Amsterdam, I am not optimistic upon the chances >of reversing this decision before the end of 1993. There might be an apeal >procedure, but I bet you would rather use the time in building an >implementation than in finding out how to use the apeal procedure. There does still seem to be quite a lot of work to do. The mailing list is still working so its probably a good idea to use this list to discuss and refine the current work ready for the working group to be reformed next year. By that time I'd hope we could go straight to work with a MIB we are all fairly happy with and almost finish as soon as we start. A couple of comments I heard in Amsterdam suggested that people are unclear that there is enough experience with new 'multi-service' chassis at the present time to come to any kind of concensus. Certainly the way the group is splitting at the moment with regards to the model into two directions would seem to support this view. It would also appear that different vendors have radically different approaches to chassis management. For example I expect the chassis MIB to provide configuration information AND configuration control (so I can move ports between entities). This seems sensible to me, otherwise who else is going to do it? Other people want a chassis MIB that only reports configuration and have a seperate activity to control configuration, again probably swayed by their experience. Given these comments it seems to me that we are unlikely to reach any real concensus in the immediate future. As I said I think we use this mail group for discussion and HOPE we can work something out in the next few months so we can restart the WG. Comments? Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05688; 21 Jul 93 12:21 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05684; 21 Jul 93 12:21 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05788; Wed, 21 Jul 93 11:54:56 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 11:54:55 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from gatekeeper.3Com.COM by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05778; Wed, 21 Jul 93 11:54:51 -0400 Received: from gw.3Com.COM by gatekeeper.3Com.COM with SMTP id AA13922 (5.65c/IDA-1.4.4-910725 for ); Wed, 21 Jul 1993 08:54:43 -0700 Received: by gw.3Com.COM id AA16132 (5.65c/IDA-1.4.4 for chassismib@cs.utk.edu); Wed, 21 Jul 1993 08:54:41 -0700 Date: Wed, 21 Jul 93 16:53 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: {3COM/PDD/PeteW}@pdd.3mail.3com.com Subject: RE: WG ACTION: Chassis MIB (chassis) to To: chassismib@cs.utk.edu Message-Id: <930721.085509@3Mail.3Com.COM> Msg-Date: 1993-07-21 Msg-Time: 16:51 Microsoft Mail v3.0 IPM.Microsoft Mail.Note From: Wilson, Peter To: Chassis MIB Subject: RE: WG ACTION: Chassis MIB (chassis) to conc Date: 1993-07-21 16:46 Priority: Message ID: C3346EA0 Conversation ID: C3346EA0 ------------------------------------------------------------------------------ Some more thoughts... Before we get any further it would be very useful to come to some agreement about what we are and what we are not going to try to solve. That is what are our requirements of the MIB. If we have to start a new working group then we get to rewrite the charter. We can rule out managing the state of Texas once and for all! Here are a few initial thoughts: 1) Represent a 'physical' inventory of a network multi-service chassis type device. ie a real network chassis, not some arbitrarily complex container! The physical configuration of the chassis is represented by 'modules' which reside in 'module locations'. 2) Represent a 'logical' inventory of entities in the chassis. An enity being a 'logical device' within the chassis. You get these by imagining the function of the chassis configuration without the chassis, that is in terms of discrete devices. The logical configuration information identifies the means of identifying an agent (through addressing information) that provides specific MIBs for that entity. 3) To provide a mapping of parts of physical modules to logical entities. The mapping will be by means of a resource. A resource is a 'component' of a module. 4) To allow the flexible reallocation of resources between different entities in the chassis. Without this the main benefit of the chassis is lost, that of flexibility! 5) To provide an optional MIB group that provides topology information describing the interconnection of the logical devices within the chassis. For example, Router port A connects to Ethernet segment X. Note that keeping this seperate makes both the agent and the management application simpler. The problem is broken down into smaller, more manageable chunks. 6) To provide a MIB that can be used to implement a generic chassis management application. Note that PSUs, sensors etc are outside the scope of this MIB at the present time. Lets get the model correct and then worry about devices in the chassis. A PSU is no different to a repeater, its still an entity in the chassis! Pete   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05749; 21 Jul 93 12:26 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05744; 21 Jul 93 12:26 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA06037; Wed, 21 Jul 93 11:57:18 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 21 Jul 1993 11:57:10 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA05979; Wed, 21 Jul 93 11:57:06 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA22482; Wed, 21 Jul 93 08:55:57 -0700 To: Joseph Zur Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IETF Area Director for Network Management Cc: chassismib@cs.utk.edu Subject: Re: WG ACTION: Chassis MIB (chassis) to conclude In-Reply-To: Your message of "Wed, 21 Jul 1993 08:23:20 +0300." <199307210523.AA05219@vivaldi.fibronics.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jul 1993 08:55:49 -0700 Message-Id: <22472.743270149@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us You can appeal this to the IESG if you like. The issue is not whether the MIB is important. Of course it is. The problem is that there aren't any senior people available who can bring the WG effort to a successful close. In fact, I don't even have any senior resources available to provide consultation to new WGs, hence the moratorium on new WGs for the remainder of the calendar year. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04843; 24 Jul 93 21:19 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa04839; 24 Jul 93 21:19 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03698; Sat, 24 Jul 93 20:59:18 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Sat, 24 Jul 1993 20:59:17 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from pobox.synoptics.com by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA03690; Sat, 24 Jul 93 20:59:15 -0400 Received: from engtwomac.synoptics.com by synoptics.com (4.1/SMI-4.1) id AA11477; Sat, 24 Jul 93 17:58:14 PDT Message-Id: <9307250058.AA11477@synoptics.com> Date: 24 Jul 1993 18:05:48 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Geoff Thompson Subject: FWD>Returned Mail re Talk a To: Marshall Rose Cc: Vint Cerf , Phil Gross , Chassis MIB Mail*Link(r) SMTP FWD>Returned Mail re Talk about MIB Marshall- This evidently didn't get out last weekend so I am resending it. Geoff -------------------------------------- Date: 7/18/93 5:57 PM From: Mail Delivery Subsystem -------------- Special condition follows -------------- Unable to deliver mail after 1 day(s). Recipient(s): mrose.iesg@dbc.mtview.ca.us, vcerf@cnri.reston.va.us, Geoff_Thompson.ENGIN#u#THREE@engtwomac.synoptics.com, chassismib@cs.utk.edu, pgross@ans.net -------------- Message follows -------------- Date: 17 Jul 1993 17:52:45 U From: "Geoff Thompson" Subject: Re: Talk about MIB To: "IETF Area Director for Network" , "Geoff Thompson" , chassismib@cs.utk.edu, "Vint Cerf" , "Phil Gross" Reply to: RE>>Talk about MIB Marshall- As written I saw it as a free speech issue. It is not my definition of informal here because that wasn't my term nor was I proposing the "informal meeting". Those were the words of David Arneson. (ref: Message-Id: <9307081303.AA12374@cardinals.ctron>) Therefore it is my belief that they were not proposing to call it a WG meeting. You made it perfectly clear that there would not be one in your message Message-ID: <103.734802337@dbc.mtview.ca.us> Your wording in Message-Id: <3063.742152883@dbc.mtview.ca.us> specifically precluded any kind of "meeting". <There will be no meeting relating to the Chassis MIB effort at >Amsterdam. I refer you to my message of yesterday which details the >options open to the WG. Meeting next week isn't one of them. Perhaps it was due to Arneson's lack of care in choosing the precisely (politically) correct term. If he had said "gathering" instead of "informal meeting" would your response have been different? As you probably know by now, I was not able to attend the Amsterdam meeting to lodge my protest in the open meeting. I copied this to higher levels because I wanted to get the issue addressed instead of getting involved in an extended flame session that these lists are famous for. I'm willing to reduce the audience any time. Geoff -------------------------------------- Date: 7/11/93 6:57 AM To: Geoff Thompson From: IETF Area Director for Network Geoff - this isn't a free speech issue. It is unclear to me what you mean by an "INFORMAL" meeting. - Meeting slots at an IETF meeting are controlled by the IETF Secretariat in coordination with the appropriate Area Director. The Chassis MIB WG is not qualified to meet at Amsterdam. My note specifically said that. - If some people want to meet in a hallway, a bar, or a restaurant, as long as they don't call it a WG meeting, that's fine. My note did not prohibit that. This latter kind of gathering is not an IETF meeting, as it is neither a WG or BOF meeting. If you wish to discuss this matter further, you can raise it at either the NM Area open meeting (tuesday morning) or the IETF open plenary (thursday evening). If you still are not satisifed, there is a specific appeals process available, which has been repeatedly published. In future, you might perhaps try following the procedure instead of invoking the IETF chair and the ISOC president all in one shot. /mtr ------------------ RFC822 Header Follows ------------------ Received: by engtwomac.synoptics.com with SMTP;11 Jul 1993 06:57:53 U Received: from CS.UTK.EDU by synoptics.com (4.1/SMI-4.1) id AA22516; Sun, 11 Jul 93 06:45:44 PDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25314; Sun, 11 Jul 93 09:43:22 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Sun, 11 Jul 1993 09:43:21 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA25306; Sun, 11 Jul 93 09:43:17 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA13041; Sun, 11 Jul 93 06:42:26 -0700 To: Geoff_Thompson.ENGIN#u#THREE@engtwomac.synoptics.com (Geoff Thompson) Cc: chassismib@cs.utk.edu, Vint Cerf , Phil Gross From: IETF Area Director for Network Management Subject: Re: Talk about MIB In-Reply-To: Your message of "09 Jul 1993 14:31:44 +0800." <9307092131.AA19926@synoptics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jul 1993 06:42:23 -0700 Message-Id: <13040.742398143@dbc.mtview.ca.us> Sender: mrose@dbc.mtview.ca.us ------------------ RFC822 Header Follows ------------------ Date: 18 Jul 1993 17:57:36 U From: "Mail Delivery Subsystem" To: geoff_thompson.engin#u#three@engtwomac.synoptics.com Subject: Returned Mail   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05122; 24 Jul 93 22:03 EDT Received: from CS.UTK.EDU by IETF.CNRI.Reston.VA.US id aa05118; 24 Jul 93 22:03 EDT Received: from localhost by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07522; Sat, 24 Jul 93 21:47:24 -0400 X-Resent-To: chassismib@CS.UTK.EDU ; Sat, 24 Jul 1993 21:47:23 EDT Errors-To: owner-chassismib@CS.UTK.EDU Received: from ppp.dbc.mtview.ca.us by CS.UTK.EDU with SMTP (5.61+IDA+UTK-930125/2.8s-UTK) id AA07513; Sat, 24 Jul 93 21:47:14 -0400 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA22442; Sat, 24 Jul 93 18:46:07 -0700 To: Geoff Thompson Cc: Vint Cerf , Phil Gross , Chassis MIB Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IETF Area Director for Network Management Subject: Re: FWD>Returned Mail re Talk a In-Reply-To: Your message of "24 Jul 1993 18:05:48 +0800." <9307250058.AA11477@synoptics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Jul 1993 18:46:04 -0700 Message-Id: <22437.743564764@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us Given that we both agree that I did not intend my note to imply that there couldn't be a meeting outside of the IETF process to discuss the chassis MIB, why don't we chalk this up as an e-mail misunderstanding? /mtr