Received: from cnri by ietf.org id aa15063; 5 Nov 96 8:34 EST Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa09061; 5 Nov 96 8:34 EST Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA062700355; Tue, 5 Nov 1996 05:25:56 -0800 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA255910336; Tue, 5 Nov 1996 05:25:36 -0800 Received: from mail11.digital.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA129890335; Tue, 5 Nov 1996 05:25:35 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA25440; Tue, 5 Nov 1996 08:17:55 -0500 (EST) Received: from servir.hpn.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15322; Tue, 5 Nov 1996 08:18:01 -0500 Received: from norton.hpn.lkg.dec.com by servir.hpn.lkg.dec.com with SMTP id AA17194; Tue, 5 Nov 1996 08:16:55 -0500 Received: by norton.hpn.lkg.dec.com (5.65v3.2/4.7) id AA03023; Tue, 5 Nov 1996 08:16:56 -0500 Message-Id: <9611051316.AA03023@norton.hpn.lkg.dec.com> To: hubmib@hprnd.rose.hp.com Cc: pagliaro@hpn.lkg.dec.com Subject: Status of MAU MIB X-Mailer: exmh version 1.5beta 8/10/94 Date: Tue, 05 Nov 96 08:16:55 GMT From: ------------------------------------------------------------------ Does anyone have an idea when the latest MAU MIB draft will be assigned an RFC number? I haven't seen much activity on this mailing list regarding the MAU MIB since late August. Thanks. ------------------------------------------------------------------ Rich Pagliaro | Digital Equipment Corporation Voice: 508/486-5613 | 550 King Street, LKG1-2/F15 Fax: 508/486-7417 | Littleton, Massachusetts 01460 E-Mail: pagliaro@hpn.lkg.dec.com | USA   Received: from cnri by ietf.org id aa22535; 10 Nov 96 2:53 EST Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa03702; 10 Nov 96 2:52 EST Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA140131956; Sat, 9 Nov 1996 23:45:56 -0800 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA085231936; Sat, 9 Nov 1996 23:45:37 -0800 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA100711935; Sat, 9 Nov 1996 23:45:36 -0800 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Sat, 9 Nov 96 23:41:04 -0800 Message-Id: <7022883201660C00@mail.madge.com> In-Reply-To: <6695853201660C00> Date: Sun, 10 Nov 96 9:34:53 +0200 From: Dan Romascano LAN-Tel Sender: Dan Romascano LAN-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com, "--------------------\ ----------------------------------------------" Cc: bstewart@cisco.com Subject: Re: Status of MAU MIB X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Rich, The last draft of the MAU MIB was forwarded to the Area Director, for review. Bob Stewart was assigned by the Area Director to do the review, and as far as I understand, it should be on his working pad this week. It is only after the review, and performing of the recomended changes - if any will be required - that we can forward the I-D to the IESG, in order to be consider for Proposed Standard status. Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from cnri by ietf.org id aa23611; 12 Nov 96 13:29 EST Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa17893; 12 Nov 96 13:29 EST Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA110522126; Tue, 12 Nov 1996 10:08:46 -0800 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA042742100; Tue, 12 Nov 1996 10:08:21 -0800 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA225092095; Tue, 12 Nov 1996 10:08:15 -0800 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Tue, 12 Nov 96 10:10:43 -0800 Message-Id: <58AC883201660C00@mail.madge.com> Date: Tue, 12 Nov 96 19:24:56 +0200 From: Dan Romascano LAN-Tel Sender: Dan Romascano LAN-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com Cc: bstewart@cisco.com, kostick@qsun.ho.att.com Subject: Fwd: Review of Ethernet MIB Extensions X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway HubMIB-ers, Here is the review of the 100M Ethernet MIB Extensions (draft-ietf-hubmib-etherif-mib-00.txt), performed by Bob Stewart, at the request of the NM Area Director. It looks like we are OK, with one single minor issue, that might need some editing. If nobody objects to this assesment, I would kindly ask Jeff Johnson - our editor - to resissue the draft, (it expires in December!) so that we can forward it to the IESG to get the approval for the Proposed Standard Status. Dan Romascanu, Systems Architecture Team Manager, LAN Bussiness Unit, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ---- Return-Path: Received: from puli.cisco.com by mail.madge.com via Connect2-SMTP 4.00 (0000213); Mon, 11 Nov 96 14:22:56 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id OAA29772; Mon, 11 Nov 1996 14:18:48 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <3266B0F5.1FB4@qsun.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Mon, 11 Nov 1996 17:18:34 -0500 To: kostick@qsun.ho.att.com From: Bob Stewart Subject: Review of Ethernet MIB Extensions Cc: dromasca@madge.com Deirdre and Dan, Here are my comments on the 100-Mbit Ethernet extensions. >This section enumerates changes made to RFC 1650 to produce this >document. > > (1) The MODULE-IDENTITY has been updated to reflect the changes > in the MIB. > > (2) A new object, dot3StatsSymbolErrors, has been added. > > (3) The description of the object dot3StatsSQETestErrors has > been updated to reflect the fact that this object is not > applicable to 100Base-T interfaces. > > (4) The definition of the object dot3StatsIndex has been > converted to use the SMIv2 OBJECT-TYPE macro. > > (5) A new conformance group, etherStats100MbsGroup, has been > added. > > (6) A new compliance statement, ether100MbsCompliance, has > been added. > > (7) The Acknowledgements were extended to provide a more > complete history of the origin of this document. This was quite helpful in telling me where to look. It looks OK to me with a few nits to pick. I wondered why dot3StatsSQETestErrors needed a statement in its DESCRIPTION that you can leave it out but there's no such statement in the DESCRIPTION for dot3StatsSymbolErrors. That seems inconsistent. Since what's required is stated in the compliance section I'd say that's enough. If compliance information is to go in the DESCRIPTIONs, it seems it should be consistent among the DESCRIPTIONs. Bob   Received: from cnri by ietf.org id aq29057; 13 Nov 96 9:13 EST Received: from hp.com by CNRI.Reston.VA.US id aa04268; 13 Nov 96 3:22 EST Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA240202850; Wed, 13 Nov 1996 00:14:10 -0800 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA290022817; Wed, 13 Nov 1996 00:13:38 -0800 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA028352816; Wed, 13 Nov 1996 00:13:36 -0800 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Wed, 13 Nov 96 00:16:37 -0800 Message-Id: Date: Wed, 13 Nov 96 8:11:01 +0200 From: Dan Romascano LAN-Tel Sender: Dan Romascano LAN-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com Subject: Fwd: [Fwd: Mau MIB Review] X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway HubMIB-ers, Here is BobS's review of the MAU MIB. There are several remarks / questions, none of them looks critical, but we probably need to do some editing and issue a new Internet Draft before going to the IESG for the final blessing. I invite people to express their opinions, if any, before Kathy proceeds to editing. Dan Romascanu, Systems Architecture Team Manager, LAN Bussiness Unit, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ---- Return-Path: Received: from cagw2.att.com by mail.madge.com via Connect2-SMTP 4.00 (0000213); Tue, 12 Nov 96 08:36:20 -0800 Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id LAA26726; Tue, 12 Nov 1996 11:35:03 -0500 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA26928; Tue, 12 Nov 96 11:32:14 EST Received: from kostick.qsun.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA25005; Tue, 12 Nov 1996 11:32:12 -0500 Message-Id: <3288A642.7F92@qsun.att.com> Date: Tue, 12 Nov 1996 11:30:58 -0500 From: Deirdre Kostick Reply-To: kostick@qsun.ho.att.com X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: Dan Romascano LAN-Tel Subject: [Fwd: Mau MIB Review] Content-Type: multipart/mixed; boundary="------------6AD73D0F7564" Reply-To: kostick@qsun.ho.att.com Dan -- Attached is a copy of Bob Stewart's review of the MAU MIB. Deirdre -------------[ MIME content-type: message/rfc822 ]----------- Return-Path: Received: from hoig1.att.att.com ([135.16.156.3]) by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA25349; Tue, 12 Nov 96 11:05:36 EST Received: by hoig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id LAA19410; Tue, 12 Nov 1996 11:03:40 -0500 Received: by hogw1.att.com; Tue Nov 12 11:03 EST 1996 Received: by hogw1.att.com; Tue Nov 12 11:03 EST 1996 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id IAA27728 for ; Tue, 12 Nov 1996 08:05:18 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <3266B0F5.1FB4@qsun.att.com> Mime-Version: 1.0 X-Pression: awestruck amazement Date: Tue, 12 Nov 1996 11:05:01 -0500 To: kostick@qsun.ho.att.com From: Bob Stewart Subject: Mau MIB Review Content-Type: text/plain; charset="us-ascii" Deirdre and Dan, Here are my comments on the MAU MIB. > o management of 100 Mb/s devices > > o auto-negotiation > > o jack management > ifMauType OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object identifies the 10 or 100 Mb/s > baseband MAU type. So where does broadband show up? The comment for dot3MauType10Broad36 says it goes with interfaces. > ifMauTypeList OBJECT-TYPE > SYNTAX Integer32 This appears to be a new object, so I'll be picky. Why doesn't it apply to repeater MAUs? It should be SYNTAX BITS. > ifMauDefaultType OBJECT-TYPE Why doesn't this apply to repeater MAUs? > ifJackType OBJECT-TYPE > SYNTAX INTEGER { > other(1), > rj45(2), > rj45S(3), -- rj45 shielded > db9(4), > bnc(5), > fAUI(6), -- female aui > mAUI(7), -- male aui > fiberSC(8), > fiberMIC(9), > fiberST(10), > telco(11) > } The list appears to be identical to the one for rpJackType. There's something to be said for defining the list once as a textual convention so it's clear they're identical. > ifMauAutoNegTable OBJECT-TYPE I take it repeater MAUs don't autonegotiate? > ifMauAutoNegCapability OBJECT-TYPE > SYNTAX Integer32 Again this looks like a place to use SYNTAX BITS. > GROUP mauRpGrp100Mbs > DESCRIPTION > "Implementation of this optional group is > recommended for MAUs which have 100Mb/s > capability." Are we comfortable with completely optional groups? In the past we've strongly avoided that. It's not at all clear why this and other optional groups should be optional. Bob   Received: from cnri by ietf.org id aa22212; 24 Nov 96 0:51 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa02794; 24 Nov 96 0:51 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id VAA11219; Sat, 23 Nov 1996 21:37:48 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA134863822; Sat, 23 Nov 1996 21:37:03 -0800 Received: from hubbub.cisco.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA002523819; Sat, 23 Nov 1996 21:36:59 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id VAA19364 for ; Sat, 23 Nov 1996 21:34:08 -0800 (PST) Message-Id: <3297DCDC.703C@cisco.com> Date: Sat, 23 Nov 1996 21:27:56 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: hubmib@hprnd.rose.hp.com Subject: Re: Fwd: Review of Ethernet MIB Extensions References: <58AC883201660C00@mail.madge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In addition to the comment from Bob, as well as a private comment I received which pointed out a spelling error, the other change/addition that would be nice is expansion of the chip set OIDs. If folks could provide a list of 100 MB and new 10 MB chipsets, I could incorporate new OIDs in the draft. /jeff Dan Romascano LAN-Tel wrote: > > HubMIB-ers, > > Here is the review of the 100M Ethernet MIB Extensions > (draft-ietf-hubmib-etherif-mib-00.txt), performed by Bob Stewart, at the > request of the NM Area Director. It looks like we are OK, with one single > minor issue, that might need some editing. > > If nobody objects to this assesment, I would kindly ask Jeff Johnson - > our editor - to resissue the draft, (it expires in December!) so that we > can forward it to the IESG to get the approval for the Proposed Standard > Status. > > Dan Romascanu, > Systems Architecture Team Manager, > LAN Bussiness Unit, > Madge Networks (Israel) Ltd., > Voice: 972-3-645-8414, e-mail: dromasca@madge.com > > -------------------------------------------------------------------------- > ---- > Return-Path: > Received: from puli.cisco.com by mail.madge.com > via Connect2-SMTP 4.00 (0000213); Mon, 11 Nov 96 14:22:56 -0800 > Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by > puli.cisco.com (8.6.12/8.6.5) with ESMTP id OAA29772; Mon, 11 Nov 1996 > 14:18:48 -0800 > X-Sender: bstewart@puli.cisco.com > Message-Id: > In-Reply-To: <3266B0F5.1FB4@qsun.att.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > X-pression: awestruck amazement > Date: Mon, 11 Nov 1996 17:18:34 -0500 > To: kostick@qsun.ho.att.com > From: Bob Stewart > Subject: Review of Ethernet MIB Extensions > Cc: dromasca@madge.com > > Deirdre and Dan, > > Here are my comments on the 100-Mbit Ethernet extensions. > > >This section enumerates changes made to RFC 1650 to produce this > >document. > > > > (1) The MODULE-IDENTITY has been updated to reflect the changes > > in the MIB. > > > > (2) A new object, dot3StatsSymbolErrors, has been added. > > > > (3) The description of the object dot3StatsSQETestErrors has > > been updated to reflect the fact that this object is not > > applicable to 100Base-T interfaces. > > > > (4) The definition of the object dot3StatsIndex has been > > converted to use the SMIv2 OBJECT-TYPE macro. > > > > (5) A new conformance group, etherStats100MbsGroup, has been > > added. > > > > (6) A new compliance statement, ether100MbsCompliance, has > > been added. > > > > (7) The Acknowledgements were extended to provide a more > > complete history of the origin of this document. > > This was quite helpful in telling me where to look. > > It looks OK to me with a few nits to pick. > > I wondered why dot3StatsSQETestErrors needed a statement in its > DESCRIPTION > that you can leave it out but there's no such statement in the > DESCRIPTION > for dot3StatsSymbolErrors. That seems inconsistent. Since what's > required > is stated in the compliance section I'd say that's enough. If compliance > information is to go in the DESCRIPTIONs, it seems it should be > consistent > among the DESCRIPTIONs. > > Bob   Received: from cnri by ietf.org id aa01291; 24 Nov 96 13:47 EST Received: from inet1.tek.com by CNRI.Reston.VA.US id aa25149; 24 Nov 96 13:47 EST Received: from vndad-sun.vndad.tek.com by inet1.tek.com id ; Sun, 24 Nov 1996 10:37:31 -0800 Received: (from daemon@localhost) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) id KAA27444 for if-mib-outgoing; Sun, 24 Nov 1996 10:37:28 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.48.24]) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) with ESMTP id KAA27438; Sun, 24 Nov 1996 10:37:27 -0800 (PST) Received: from inet2.tek.com (inet2.tek.com [134.62.48.22]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id KAA25953; Sun, 24 Nov 1996 10:40:00 -0800 (PST) Received: from ns.newbridge.com by inet2.tek.com id ; Sun, 24 Nov 1996 10:37:18 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id NAA06949; Sun, 24 Nov 1996 13:37:18 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma006931; Sun Nov 24 13:37:04 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id NAA00183; Sun, 24 Nov 1996 13:37:04 -0500 Received: from fields.newbridge (fields [138.120.136.143]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id NAA04032; Sun, 24 Nov 1996 13:37:02 -0500 From: James Watt Message-Id: <199611241837.NAA04032@thor.ca.newbridge.com> Subject: Re: ethernet if questions To: "Ted Brunner 503.627.1317" Date: Sun, 24 Nov 1996 13:37:01 -0500 (EST) Cc: if-mib@mda.vndad.tek.com, tedb@vndad.tek.com, sonishi@baynetworks.com, hubmib@hprnd.rose.hp.com In-Reply-To: <199611222321.PAA11191@icebox.vndad.tek.com> from "Ted Brunner 503.627.1317" at Nov 22, 96 03:21:32 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: if-mib-owner@vndad.tek.com Precedence: bulk Ted Brunner 503.627.1317 writes: +----------- |Steve- | |> for a full duplex ethernet interface, should the ifSpeed be double the |> base rate (20Mbps, 200 Mbps, etc.)? If not, then won't utilization |> computations be garbage? Or should each half of the connection be |> modeled as a separate 10/100 Mbps interface? | |Perhaps we could learn something from already existing |bi-directional or full-duplex interfaces about modeling. |For instance, do I recall correctly that T1 lines |are full bitrate in both directions? |Yet I think they are generally modelled as a single ifIndex. |Utilization counters for ingress and egress simply go up |independently without confusion. |(On the other hand, the ds1/3 mib has these funny 15 minute bins |for all sorts of line errors.) | |Is the problem that a utilization calculation |that works on a plain old ethernet interface would get confused |on a full-duplex ethernet - and equally get confused on an |interface following the existing T1 model? |Is the calculation inherently half-duplex? +--------- Most code I've seen already "knows" about Ethernets (etc.) being half-duplex and serial interfaces being full duplex. The calculation is usually selected with the ifType so I I suspect there is some concern that if the ifType is simply ethernet-csmacd and ifSpeed is 10Mbps, then when the interface is running full duplex, the numbers would be wrong. It would seem we need a single bit somewhere to say whether the interface is running full-duplex or not. That bit could be a change in the ifSpeed (10 vs 20, 100 vs 200) or it could be a different interface type. In either case, I suspect that it will be easy to convince most utilization code to "do the right thing." Sounds like something that might best be covered in the Ethernet MIB, i.e. what to do with full-duplex Ethernet interfaces... Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from cnri by ietf.org id aa26063; 25 Nov 96 4:57 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa10190; 25 Nov 96 4:57 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id BAA06972; Mon, 25 Nov 1996 01:47:09 -0800 (PST) Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA108625191; Mon, 25 Nov 1996 01:46:32 -0800 Received: from hubbub.cisco.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA052505191; Mon, 25 Nov 1996 01:46:31 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id BAA05546; Mon, 25 Nov 1996 01:43:38 -0800 (PST) Message-Id: <329968EB.66C3@cisco.com> Date: Mon, 25 Nov 1996 01:37:47 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: if-mib@tek.com, hubmib@hprnd.rose.hp.com Subject: Re: ethernet if questions References: <199611222321.PAA11191@icebox.vndad.tek.com> <199611241837.NAA04032@thor.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Watt wrote: > It would seem we need a single bit somewhere to say whether the interface > is running full-duplex or not. That bit could be a change in the ifSpeed > (10 vs 20, 100 vs 200) or it could be a different interface type. In > either case, I suspect that it will be easy to convince most utilization > code to "do the right thing." > > Sounds like something that might best be covered in the Ethernet MIB, i.e. > what to do with full-duplex Ethernet interfaces... is ifMauType (from the MAU MIB) insufficient for this purpose? /jeff   Received: from cnri by ietf.org id aa16573; 25 Nov 96 11:44 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa08014; 25 Nov 96 11:44 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id IAA01958; Mon, 25 Nov 1996 08:34:10 -0800 (PST) Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA116819615; Mon, 25 Nov 1996 08:33:37 -0800 Received: from ns.newbridge.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA142449604; Mon, 25 Nov 1996 08:33:24 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id LAA01646; Mon, 25 Nov 1996 11:29:47 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma001306; Mon Nov 25 11:28:38 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id LAA02832; Mon, 25 Nov 1996 11:28:37 -0500 Received: from fields.newbridge (fields [138.120.136.143]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id LAA11075; Mon, 25 Nov 1996 11:28:36 -0500 From: James Watt Message-Id: <199611251628.LAA11075@thor.ca.newbridge.com> Subject: Re: [Fwd: Re: ethernet if questions] To: "Jeffrey T. Johnson" Date: Mon, 25 Nov 1996 11:28:31 -0500 (EST) Cc: if-mib@mda.vndad.tek.com, hubmib@hprnd.rose.hp.com In-Reply-To: <32996B05.42FA@cisco.com> from "Jeffrey T. Johnson" at Nov 25, 96 01:46:45 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jeffrey T. Johnson writes: +-------- |James Watt wrote: |> It would seem we need a single bit somewhere to say whether the interface |> is running full-duplex or not. That bit could be a change in the ifSpeed |> (10 vs 20, 100 vs 200) or it could be a different interface type. In |> either case, I suspect that it will be easy to convince most utilization |> code to "do the right thing." |> |> Sounds like something that might best be covered in the Ethernet MIB, i.e. |> what to do with full-duplex Ethernet interfaces... | |is ifMauType (from the MAU MIB) insufficient for this purpose? +------- The range of MAU types defined in the update to the MAU MIB should provide this information. My comment was more aimed at explanatory text than mechanism, i.e. there needs to be text in the Ethernet MIB explaining that this "bit" of information is contained in the MAU MIB. This does bring up an interesting conformance question - if we argue that one needs the MAU MIB to be certain that one is performing the correct utilization calculation, should the conformance groups in the EtherLike MIB "require" the appropriate MAU MIB object (s) ? Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from cnri by ietf.org id aa20175; 25 Nov 96 12:23 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa09023; 25 Nov 96 12:23 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id JAA06703; Mon, 25 Nov 1996 09:16:02 -0800 (PST) Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA122742152; Mon, 25 Nov 1996 09:15:52 -0800 Received: from southpass (ns3.BayNetworks.COM) by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA218372150; Mon, 25 Nov 1996 09:15:51 -0800 Received: from ns1 ([134.177.1.107]) by southpass (SMI-8.6/SMI-SVR4) with SMTP id JAA00183; Mon, 25 Nov 1996 09:09:05 -0800 for Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1 (SMI-8.6/SMI-SVR4) with SMTP id JAA15032; Mon, 25 Nov 1996 09:08:42 -0800 for Received: from mcgiffert.engeast by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA06565; Mon, 25 Nov 96 12:08:32 EST Received: from mcgiffert (localhost) by mcgiffert.engeast (4.1/SMI-4.1) id AA29242; Mon, 25 Nov 96 12:09:15 EST Sender: sonishi@baynetworks.com Message-Id: <3299D2BB.31D2DE92@BayNetworks.com> Date: Mon, 25 Nov 1996 12:09:15 -0500 From: Steve Onishi Organization: Embedded Agent Software Development X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: James Watt Cc: "Jeffrey T. Johnson" , if-mib@mda.vndad.tek.com, hubmib@hprnd.rose.hp.com Subject: Re: [Fwd: Re: ethernet if questions] References: <199611251628.LAA11075@thor.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Watt wrote: > | > |is ifMauType (from the MAU MIB) insufficient for this purpose? > +------- > The range of MAU types defined in the update to the MAU MIB should > provide this information. > The descr for ifMauAutoNegCapability says : "...For IEEE 802.3 MAUs, the half- and full-duplex value pairs each map to a single MAU type. For example, 10BASE-T and 10BASE-T Full Duplex each use a MAU type of dot3MauType10BaseT...." was there a reason for this? > My comment was more aimed at explanatory text than mechanism, i.e. > there needs to be text in the Ethernet MIB explaining that this "bit" > of information is contained in the MAU MIB. > > This does bring up an interesting conformance question - if we argue that > one needs the MAU MIB to be certain that one is performing the correct > utilization calculation, should the conformance groups in the EtherLike > MIB "require" the appropriate MAU MIB object (s) ? > > Regards, > -james > perhaps the easiest solution is to keep Tx/Rx utilization calcs separate (don't sum ifInOctets and ifOutOctets and divide by ifSpeed). Rather derive a utilization from Tx and Rx utilization. The question then becomes is this useful? If the Tx pipe is 60% utilized and the Rx pipe 5% utilized, is a derived utilization (33%) even useful? I'm still unclear about what to do with ifType for a 10/100 autoneg if. /StO   Received: from cnri by ietf.org id aa22930; 25 Nov 96 12:51 EST Received: from [15.253.88.10] by CNRI.Reston.VA.US id aa09932; 25 Nov 96 12:51 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel3.hp.com with ESMTP (8.7.5/8.7.3) id JAA24406; Mon, 25 Nov 1996 09:46:02 -0800 (PST) Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA128383941; Mon, 25 Nov 1996 09:45:42 -0800 Received: from ns.newbridge.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA259143940; Mon, 25 Nov 1996 09:45:40 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id MAA27240; Mon, 25 Nov 1996 12:41:40 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma027078; Mon Nov 25 12:41:16 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id MAA06973; Mon, 25 Nov 1996 12:41:15 -0500 Received: from fields.newbridge (fields [138.120.136.143]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id MAA16249; Mon, 25 Nov 1996 12:41:14 -0500 From: James Watt Message-Id: <199611251741.MAA16249@thor.ca.newbridge.com> Subject: Re: [Fwd: Re: ethernet if questions] To: Steve Onishi Date: Mon, 25 Nov 1996 12:41:13 -0500 (EST) Cc: james@ca.newbridge.com, jjohnson@cisco.com, if-mib@mda.vndad.tek.com, hubmib@hprnd.rose.hp.com In-Reply-To: <3299D2BB.31D2DE92@BayNetworks.com> from "Steve Onishi" at Nov 25, 96 12:09:15 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Steve Onishi writes: +-------- |> | |> |is ifMauType (from the MAU MIB) insufficient for this purpose? |> +------- |> The range of MAU types defined in the update to the MAU MIB should |> provide this information. |> | |The descr for ifMauAutoNegCapability says : | |"...For IEEE 802.3 MAUs, the half- and full-duplex |value pairs each map to a single MAU type. For |example, 10BASE-T and 10BASE-T Full Duplex each |use a MAU type of dot3MauType10BaseT...." | |was there a reason for this? +--------- I think this is fixed in the -03 draft +--------- |> My comment was more aimed at explanatory text than mechanism, i.e. |> there needs to be text in the Ethernet MIB explaining that this "bit" |> of information is contained in the MAU MIB. |> |> This does bring up an interesting conformance question - if we argue that |> one needs the MAU MIB to be certain that one is performing the correct |> utilization calculation, should the conformance groups in the EtherLike |> MIB "require" the appropriate MAU MIB object (s) ? |> |> Regards, |> -james |> +---------- |perhaps the easiest solution is to keep Tx/Rx utilization calcs separate |(don't sum ifInOctets and ifOutOctets and divide by ifSpeed). Rather |derive a utilization from Tx and Rx utilization. The question then becomes |is this useful? If the Tx pipe is 60% utilized and the Rx pipe 5% utilized, |is a derived utilization (33%) even useful? +------- I think there are two cases (half duplex and full duplex). I'm not sure the "overall" utilization is useful in the case of full-duplex but... In general, you need to look at least at ifType to figure out what you are dealing with. In the case of Ethernet-like interfaces, you need to to look at ifMauType -- there are separate values for half-duplex and full-duplex. My concern would be that the last step, looking at ifMauType, seems to make it require for Ethernet interfaces to report statistics that can be understood. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from cnri by ietf.org id aa26959; 25 Nov 96 13:38 EST Received: from [134.62.48.22] by CNRI.Reston.VA.US id aa11324; 25 Nov 96 13:38 EST Received: from vndad-sun.vndad.tek.com by inet2.tek.com id ; Mon, 25 Nov 1996 10:29:16 -0800 Received: (from daemon@localhost) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) id KAA29459 for if-mib-outgoing; Mon, 25 Nov 1996 10:28:49 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.48.24]) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) with ESMTP id KAA29453 for ; Mon, 25 Nov 1996 10:28:47 -0800 (PST) Received: from inet2.tek.com (inet2.tek.com [134.62.48.22]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id KAA16050 for ; Mon, 25 Nov 1996 10:31:23 -0800 (PST) Received: from southpass by inet2.tek.com id ; Mon, 25 Nov 1996 10:28:42 -0800 Received: from ns1 ([134.177.1.107]) by southpass (SMI-8.6/SMI-SVR4) with SMTP id KAA03342; Mon, 25 Nov 1996 10:21:56 -0800 for Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by ns1 (SMI-8.6/SMI-SVR4) with SMTP id KAA28595; Mon, 25 Nov 1996 10:21:52 -0800 for Received: from mcgiffert.engeast by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA13455; Mon, 25 Nov 96 13:21:53 EST Received: from mcgiffert (localhost) by mcgiffert.engeast (4.1/SMI-4.1) id AA29257; Mon, 25 Nov 96 13:22:29 EST Message-Id: <3299E3E5.69D8BD19@BayNetworks.com> Date: Mon, 25 Nov 1996 13:22:29 -0500 From: Steve Onishi Organization: Embedded Agent Software Development X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: James Watt Cc: jjohnson@cisco.com, if-mib@mda.vndad.tek.com, hubmib@hprnd.rose.hp.com Subject: Re: [Fwd: Re: ethernet if questions] References: <199611251741.MAA16249@thor.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: if-mib-owner@vndad.tek.com Precedence: bulk > |The descr for ifMauAutoNegCapability says : > | > |"...For IEEE 802.3 MAUs, the half- and full-duplex > |value pairs each map to a single MAU type. For > |example, 10BASE-T and 10BASE-T Full Duplex each > |use a MAU type of dot3MauType10BaseT...." > | > |was there a reason for this? > +--------- > I think this is fixed in the -03 draft oops. > I think there are two cases (half duplex and full duplex). I'm not sure > the "overall" utilization is useful in the case of full-duplex but... > > In general, you need to look at least at ifType to figure out what you > are dealing with. In the case of Ethernet-like interfaces, you need to > to look at ifMauType -- there are separate values for half-duplex and > full-duplex. > > My concern would be that the last step, looking at ifMauType, seems to > make it require for Ethernet interfaces to report statistics that can > be understood. I get it now. So it sounds like you'd always use the ifType ethernetCsmacd(6) or iso88023Csmacd(7) and not use fastEther(62) or fastEtherFX(69) if you could always depend on MAU MIB support. Should these ifTypes be deprecated? /StO   Received: from cnri by ietf.org id aa01955; 25 Nov 96 14:39 EST Received: from inet1.tek.com by CNRI.Reston.VA.US id aa13271; 25 Nov 96 14:39 EST Received: from vndad-sun.vndad.tek.com by inet1.tek.com id ; Mon, 25 Nov 1996 11:31:32 -0800 Received: (from daemon@localhost) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) id LAA29953 for if-mib-outgoing; Mon, 25 Nov 1996 11:30:59 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.48.24]) by vndad-sun.vndad.tek.com (8.7.5/8.7.3) with ESMTP id LAA29947 for ; Mon, 25 Nov 1996 11:30:57 -0800 (PST) Received: from inet2.tek.com (inet2.tek.com [134.62.48.22]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id LAA23267 for ; Mon, 25 Nov 1996 11:33:34 -0800 (PST) Received: from ns.newbridge.com by inet2.tek.com id ; Mon, 25 Nov 1996 11:30:53 -0800 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA29050; Mon, 25 Nov 1996 14:29:13 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma028938; Mon Nov 25 14:28:47 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id OAA13364; Mon, 25 Nov 1996 14:28:46 -0500 Received: from fields.newbridge (fields [138.120.136.143]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id OAA22636; Mon, 25 Nov 1996 14:28:43 -0500 From: James Watt Message-Id: <199611251928.OAA22636@thor.ca.newbridge.com> Subject: Re: [Fwd: Re: ethernet if questions] To: Steve Onishi Date: Mon, 25 Nov 1996 14:28:40 -0500 (EST) Cc: james@ca.newbridge.com, jjohnson@cisco.com, if-mib@mda.vndad.tek.com, hubmib@hprnd.rose.hp.com In-Reply-To: <3299E3E5.69D8BD19@BayNetworks.com> from "Steve Onishi" at Nov 25, 96 01:22:29 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: if-mib-owner@vndad.tek.com Precedence: bulk Steve Onishi writes: +--------- |oops. | |> I think there are two cases (half duplex and full duplex). I'm not sure |> the "overall" utilization is useful in the case of full-duplex but... |> |> In general, you need to look at least at ifType to figure out what you |> are dealing with. In the case of Ethernet-like interfaces, you need to |> to look at ifMauType -- there are separate values for half-duplex and |> full-duplex. |> |> My concern would be that the last step, looking at ifMauType, seems to |> make it require for Ethernet interfaces to report statistics that can |> be understood. | | |I get it now. So it sounds like you'd always use the ifType |ethernetCsmacd(6) or iso88023Csmacd(7) and not use fastEther(62) or |fastEtherFX(69) if you could always depend on MAU MIB support. |Should these ifTypes be deprecated? +---------- Good question - especially when more and more boxes can do some or all of 10 or 100, half or full duplex... Management stations will still have to "know" what all four mean, but the real information now seems to be in ifMauType. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680   Received: from ietf.org by ietf.org id aa23227; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19528; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: hubmib@hprnd.rose.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-hubmib-etherif-mib-01.txt Date: Tue, 26 Nov 1996 09:20:26 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19528@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IEEE 802.3 Hub MIB Working Group of the IETF. Title : Definitions of Managed Objects for the Ethernet-like Interface Types Author(s) : J. Johnson Filename : draft-ietf-hubmib-etherif-mib-01.txt Pages : 22 Date : 11/25/1996 This memo is an extension to the SNMP MIB. It specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. The origin of this memo is from RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2." This memo extends that specification by including management information useful for the management of 100-BaseT ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-etherif-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11520; 26 Nov 96 13:08 EST Received: from ietf.org by ietf.org id aa10619; 26 Nov 96 12:50 EST To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: hubmib@hprnd.rose.hp.com Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: Definitions of Managed Objects for IEEE 802.3 Repeater Devices to Proposed Standard Date: Tue, 26 Nov 1996 12:50:36 -0500 X-Orig-Sender: scoya@ietf.org Message-ID: <9611261250.aa10619@ietf.org> The IESG has approved the Internet-Draft "Definitions of Managed Objects for IEEE 802.3 Repeater Devices" as a Proposed Standard. This document is the product of the IEEE 802.3 Hub MIB Working Group. The IESG contact person is Deirdre Kostick. Technical Summary This document identifies the set of objects for use in managing Ethernet-like hubs. A hub is defined as a multiport repeater that conforms to Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE 802.3/ISO 8802-3 CSMA/CD standard, 1993 or to Section 27, "Repeater for 100 Mb / s Baseband Networks" in the IEEE Standard 802.3u (October 26, 1995). Working Group Summary The document is the result of the collective work of the IEEE 802.3 HUB MIB (hubmib) WG, which met four times in face-to-face meetings and cooperated intensively on the mailing list. There was no significant dissent in the WG to the proposed document. Protocol Quality The document was reviewed for the IETF NM Area by Bob Stewart (bstewart@cisco.com) and by Deirdre Kostick for the IESG. Several WG members reported that they are working on implementations.   Received: from cnri by ietf.org id aa27347; 26 Nov 96 17:17 EST Received: from palrel1.hp.com by CNRI.Reston.VA.US id aa25534; 26 Nov 96 17:17 EST Received: from hprnd.rose.hp.com (daemon@hprnd.rose.hp.com [15.29.43.139]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id OAA11425; Tue, 26 Nov 1996 14:08:44 -0800 (PST) Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA297996096; Tue, 26 Nov 1996 14:08:17 -0800 Received: from hubbub.cisco.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA082436096; Tue, 26 Nov 1996 14:08:16 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id OAA15892 for ; Tue, 26 Nov 1996 14:05:44 -0800 (PST) Message-Id: <329B6454.238C@cisco.com> Date: Tue, 26 Nov 1996 13:42:44 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: hubmib@hprnd.rose.hp.com Subject: [Fwd: I-D ACTION:draft-ietf-hubmib-etherif-mib-01.txt] Content-Type: multipart/mixed; boundary="------------3AF33F90338A" This is a multi-part message in MIME format. --------------3AF33F90338A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This incorporates the review comments from Bob Stewart as well as a few spelling corrections. This version does not include additional chipset definitions. /jeff --------------3AF33F90338A Content-Type: message/news Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: usenet.cisco.com!newsgate.cisco.com From: Internet-Drafts@ietf.org To: IETF-Announce:; Cc: hubmib@hprnd.rose.hp.com Newsgroups: cisco.external.ietf.announce Subject: I-D ACTION:draft-ietf-hubmib-etherif-mib-01.txt Message-ID: <9611260920.aa19528@ietf.org> Date: 26 Nov 96 14:20:26 GMT Sender: ietf-announce-request@ietf.org Reply-To: Internet-Drafts@ietf.org Organization: Internet-USENET Gateway at cisco Systems MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IEEE 802.3 Hub MIB Working Group of the IETF. Title : Definitions of Managed Objects for the Ethernet-like Interface Types Author(s) : J. Johnson Filename : draft-ietf-hubmib-etherif-mib-01.txt Pages : 22 Date : 11/25/1996 This memo is an extension to the SNMP MIB. It specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. The origin of this memo is from RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2." This memo extends that specification by including management information useful for the management of 100-BaseT ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-etherif-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125142616.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------3AF33F90338A--