Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08665; 3 Jun 96 3:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08661; 3 Jun 96 3:48 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa03072; 3 Jun 96 3:48 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA238327791; Mon, 3 Jun 1996 00:43:11 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA108757775; Mon, 3 Jun 1996 00:42:55 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA202667774; Mon, 3 Jun 1996 00:42:54 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Mon, 3 Jun 96 00:38:56 -0800 Message-Id: <8298B13101660C00@mail.madge.com> Date: Sun, 2 Jun 96 10:08:54 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com Subject: Test! Please Ignore! X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Sorry for this message, but I suspect I was disconnected from the WG mail list. Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14508; 4 Jun 96 9:50 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09213; 4 Jun 96 9:50 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14305; 4 Jun 96 9:50 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13524; 4 Jun 96 9:33 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: hubmib@hprnd.rose.hp.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-hubmib-mau-mib-02.txt Date: Tue, 04 Jun 96 09:33:09 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9606040933.aa13524@IETF.CNRI.Reston.VA.US> --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 IEEE 802.3 Medium Attachment Units (MAUs) Author(s) : D. Romascanu, K. de Graaf Filename : draft-ietf-hubmib-mau-mib-02.txt Pages : 44 Date : 06/03/1996 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. This memo does not specify a standard for the Internet community. 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-mau-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-mau-mib-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-mau-mib-02.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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960603114351.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-mau-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-mau-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960603114351.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27175; 4 Jun 96 16:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27171; 4 Jun 96 16:19 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa15945; 4 Jun 96 16:19 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA214349153; Tue, 4 Jun 1996 13:12:34 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA036099136; Tue, 4 Jun 1996 13:12:17 -0700 Received: from ISD.3Com.com (chipcom.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA052339132; Tue, 4 Jun 1996 13:12:12 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA12845; Tue, 4 Jun 96 16:09:18 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA5533; Tue, 04 Jun 96 16:09:47 -0700 Message-Id: <9606042309.AA5533@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 663FE7C0F38F0A028525633F00663628; Tue, 4 Jun 96 16:09:41 EDT To: pagliaro Cc: hubmib Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kathy deGraaf/US/3Com Date: 4 Jun 96 16:00:28 EDT Subject: Re: MAU MIB draft 02 Mime-Version: 1.0 Content-Type: Text/Plain Hi Rich, As you point out, there are two possible ways to define the MIB for setting MAU type: 1. Keep ifMauAutoNegTechnologyInUse for the purpose of reflecting the results of auto-negotiation. If A-N is turned on, this is the object that an NMS should look at to see what's going on. At that point, ifMauType is writeable but may not match the operating value; rather it will show the type that the MAU will be in future whenever A-N is turned off. If A-N is turned off, an NMS should look at ifMauType to see what type the MAU is actually operating at. _OR_ 2. Ditch ifMauAutoNegTechnologyInUse, and use ifMauType to show the result of A-N. This allows an NMS to look in a single place (ifMauType) for the operational value at any time. BUT it means that ifMauType is effectively read-only while A-N is turned on, and read-write if A-N is turned off. After disabling auto-negotiation, an NMS must write to ifMauType if it wants to set the operational value to something new. In other words, there is no place to tell the system what value to use automatically when A-N is turned off--no place to "remember" the manually-set value. In the latest draft, I took the second approach. I did it that way because it seemed simpler from an NMS's point of view. This comes at the expense of slightly more complexity in the agent firmware, however. The hardware spec says that the manually-set speed value is remembered and re-used once A-N is disabled. So in order to make this work in software, an agent processing a set request to disable auto-negotiation must also set up the necessary register(s) in order to make sure the MAU continues to operate at the type that was auto-negotiated (until the NMS writes to ifMauType to tell it otherwise). (BTW--ifMauAutoNegTechnologyInUse was something that I added in the December draft because of concerns that there was no object to provide the result of auto-negotiation. It doesn't have any parallel in the IEEE doc, which gave me some doubts about its usefulness.) I'd like to get this right in the MIB, but it's not clear to me which approach is best. Would anyone else like to comment on this issue? Thanks, Kathy ----- Previous Message ---------------------------------------------------- To: kdegraaf @ isd.3com.com @ SMTP1 cc: pagliaro @ dechub.lkg.dec.com @ SMTP1 From: pagliaro @ dechub.lkg.dec.com (------------------------------------------------------------------) @ SMTP1 Date: Tuesday June 4, 1996 02:08 PM Subject: Re: MAU MIB draft 02 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hi Kathy, I reviewed the new draft MAU MIB which you destributed. I really only concentrated on the Basic Interface MAU Table, the Jack Table, and ifMauAutoNegTable. It looks great and seems to resolve all of the issues you and I discussed. I do have a question regarding removing ifMauAutoNegTechnologyInUse and incorporating its function into ifMauType. The ifMauType description states "If auto-negotiation is present and enabled on this MAU, a set to this object has no effect, AND THE VALUE OF THIS OBJECT REFLECTS THE RESULT OF THE AUTO-NEGOTIATION FUNCTION." The ifMauAutoNegAdminStatus description states that "If the value of this object is disabled(2) then the interface will act as it would if it had no auto-negotiation signalling. UNDER THESE CONDITIONS, AND IEEE 802.3 MAU WILL IMMEDIATELY BE FORCED TO THE STATE INDICATED BY A WRITE TO THE OBJECT IFMAUTYPE." So what would happen, for example, if auto-negotiation was enabled on a given MAU. The ifMauType object would reflect the technology currently in use. If the ifMauType object is then set to something other than the technology in use, the set operation would not return an error, but subsequent reads of that object would continue to report the technology currently in use (instead of the previously set value). Now let's say that the ifMauAutoNegAdminStatus object is then set to disabled. Would the MAU be forced into the state previously written into ifMauType (but never reported)? Or would it be forced to continue to use the previous technology in use until the ifMauType is set again. If I am interpreting the MIB correctly, this behaviour seems a bit wierd to me. In my opinion, it seems less confusing to keep the technology-in-use reporting function separate from the manual MAU type selection function. That is, let ifMauType be used to manually select the MAU type and use a ifMauTechnologyInUse object to report the current technology in use. If auto-neg is in operation, the auto-negotiated type has priority over the manually selected type, but you still preserve the previous manual setting. Am I misunderstanding something or is this simply the preferred operation? Thanks, Rich ------------------------------------------------------------------ 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 ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08236; 5 Jun 96 2:21 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08232; 5 Jun 96 2:21 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa02313; 5 Jun 96 2:21 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA237715214; Tue, 4 Jun 1996 23:13:34 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA088855203; Tue, 4 Jun 1996 23:13:23 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA289735203; Tue, 4 Jun 1996 23:13:23 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Tue, 4 Jun 96 23:09:08 -0800 Message-Id: <292EB53101660C00@mail.madge.com> In-Reply-To: <222DB53101660C00> Date: Wed, 5 Jun 96 9:08:53 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: pagliaro , Kathy deGraaf/US/3Com Cc: hubmib Subject: Re: MAU MIB draft 02 X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway My fingers were on the keyboard to write the Call for Consensus for the Repeater MIB and MAU MIB when I saw this! Rich writes: >Would the MAU be forced into the state >previously written into ifMauType (but never reported)? Sets while A/N is enabled have no effect on the link . The draft clearly says in the ifMauType description: 'If auto-negociation is present and enabled on this MAU, a set to this object has no effect...' This seems to be consistent with the IEEE spec (see Kathy's message, around 5/15). However, Kathy writes: >This comes at the expense of slightly more complexity in the agent firmware, >however. The hardware spec says that the manually-set speed value is >remembered and re-used once A-N is disabled. So in order to make this work in >software, an agent processing a set request to disable auto-negotiation must >also set up the necessary register(s) in order to make sure the MAU continues >to operate at the type that was auto-negotiated (until the NMS writes to >ifMauType to tell it otherwise). Is that your reading of the IEEE spec? If true, there seems to be a contradiction. What I found is: " When Auto-Negotiation is enabled, bit 0.13 can be read or written, but the state of bit 0.13 has no effect on the link configuration, and it is not necessary for bit 0.13 to reflect the operating speed of the link when it is read." There is nothing here about the transition back to non_A/N status. Is this a) the last MANUALLY SET type or b) the last AUTO-NEGOCIATED type that needs to be activated at the time when A-N is disabled? If b) is true, our draft is OK, if a) is true we might need something like ifMauLastManuallySetType. Otherwise, how would a manager understand the consequences of disabling A/N from the point of view of speed? Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19461; 5 Jun 96 11:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19457; 5 Jun 96 11:10 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa08575; 5 Jun 96 11:10 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA083606768; Wed, 5 Jun 1996 07:59:29 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA100216718; Wed, 5 Jun 1996 07:58:39 -0700 Received: from mail13.digital.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA091546716; Wed, 5 Jun 1996 07:58:36 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA04602; Wed, 5 Jun 1996 10:39:30 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09204; Wed, 5 Jun 1996 10:38:52 -0400 Received: from pe2k3.hpn.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA14866; Wed, 5 Jun 1996 10:38:37 -0400 Received: by pe2k3.hpn.lkg.dec.com (5.65/4.7) id AA22568; Wed, 5 Jun 1996 10:37:16 -0400 Message-Id: <9606051437.AA22568@pe2k3.hpn.lkg.dec.com> To: dromasca@madge.com Cc: pagliaro@dechub.lkg.dec.com, kdegraaf@isd.3com.com, hubmib@hprnd.rose.hp.com Subject: Re: MAU MIB draft 02 In-Reply-To: Your message of "Wed, 05 Jun 96 09:08:53 +0300." <292EB53101660C00@mail.madge.com> X-Mailer: exmh version 1.5beta 8/10/94 Date: Wed, 05 Jun 96 10:37:15 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ------------------------------------------------------------------ Dan writes: > Is that your reading of the IEEE spec? If true, there seems to be a > contradiction. > What I found is: > " When Auto-Negotiation is enabled, bit 0.13 can be read or written, but > the state of bit 0.13 has no effect on the link configuration, and it is not > necessary for bit 0.13 to reflect the operating speed of the link when it is > read." This behavior is defined in section 22.2.4.1.3 of IEEE 802.3u-1995 and section 22.2.4.1.8 defines similar behavior for duplex mode setting (bit 0.8). Section 22.4.1.4 (Auto-Negotiation Enable) states "The Auto-Negotiation process shall be made enabled by setting bit 0.12 to a logic one. If bit 0.12 is set to a logic one, then bits 0.13 and 0.8 shall have no effect on the link configuration, and the Auto-Negotiation process will determine the link configuration. IF BIT 0.12 IS CLEARED TO A LOGIC ZERO, THEN BITS 0.13 AND 0.8 WILL DETERMINE THE LINK CONFIGURATION, REGARDLESS OF THE PRIOR STATE OF THE LINK CONFIGURATION AND THE AUTO-NEGOTIATION PROCESS." > There is nothing here about the transition back to non_A/N status. > Is this > a) the last MANUALLY SET type or > b) the last AUTO-NEGOCIATED type > that needs to be activated at the time when A-N is disabled? If b) is > true, our draft is OK, > if a) is true we might need something like ifMauLastManuallySetType. > Otherwise, how > would a manager understand the consequences of disabling A/N from the > point of view > of speed? My interpretation of Section 22.4.1.4 indicates that the answer to the above question is (a). This is why in my previous message I favored keeping the ifMauTechnologyInUse object. I did, however, tell Kathy off line that I can go along with the current draft as long as this interaction between ifMauType and ifMauAutoNegAdminStatus was more clearly defined in the MIB. There could be some value added in hiding some hardware details from the network management user. However, IF we feel it is important for the MIB to more faithfully represent the hardware standard, I'd like to offer a slightly different proposal. In Kathy's previous message she pointed out that with the existence of the previously defined ifMauAutoNegTechnologyInUse object, the object that an NMS would have to read in order to determine the MAU type would depend upon whether or not Auto-Negotiation was enabled. This is sub-optimal. What if we moved the mauTechnologyInUse object from the ifMauAutoNegotiationTable into the ifMauTable. This object would always report the current technology in use whether it was manually configured or auto-negotiated, and the NMS could always inspect the same object to determine the MAU type. As an example, we could make ifMauType read-only again and use this as the technology-in-use object. A new read-write object called something like ifMauTypeManualSetting could be used to configure the MAU type when auto-neg is not supported/enabled. Of course, ifMauType and ifMauTypeManualSetting would be somewhat redundant objects in those implementations which do not support auto-negotiation or the ability to modify their MAU type. Also, this proposal deviates somewhat from the IEEE 802.3u management model. But some holes do appear to exist in that model (at least in the version published in the October 25, 1995 standard). ------------------------------------------------------------------ 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 ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19681; 5 Jun 96 11:13 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19677; 5 Jun 96 11:13 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa08634; 5 Jun 96 11:13 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA100196990; Wed, 5 Jun 1996 08:03:11 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA100346966; Wed, 5 Jun 1996 08:02:48 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA298616966; Wed, 5 Jun 1996 08:02:46 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: arvind@dechub.lkg.dec.com Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA05636; Wed, 5 Jun 1996 10:45:07 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09228; Wed, 5 Jun 1996 10:44:35 -0400 Received: from agnt69.dechub.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA14949; Wed, 5 Jun 1996 10:44:10 -0400 Received: by agnt69.dechub.lkg.dec.com (5.65/4.7) id AA25644; Wed, 5 Jun 1996 10:44:08 -0400 Date: Wed, 5 Jun 1996 10:44:08 -0400 Message-Id: <9606051444.AA25644@agnt69.dechub.lkg.dec.com> To: hubmib@hprnd.rose.hp.com Cc: arvind@dechub.lkg.dec.com, pagliaro%netcad.dnet@dechub.lkg.dec.com Subject: Re: MAU MIB draft 02 I believe that the correct sequence of operations before auto-negotiation is disabled should be the following: Order A ======= 1. Define the mode in which the link should operate as soon as auto-negotiation is disabled. 2. Disable auto-negotiation. The other order suggested in Kathy's message (as I understand it): (>So in order to make this >work in software, an agent processing a set request >to disable auto-negotiation must also set up the necessary >register(s) in order to make sure the MAU >continues to operate at the type that was auto-negotiated >(until the NMS writes to ifMauType to tell it otherwise). Order B ======= 1. Disable auto-negotiation. 2. Define the mode in which the link should operate as soon as auto-negotiation is disabled. forces the link to operate in the last negotiated mode (or in some default mode if we specify it that way) between the time auto-negotiation is disabled and the new mode is defined. This mode may not always be what the network manager intended during this transition period. I think it is best to have separate objects for control and monitoring. The control object is a read-write object that is used to define the mode of operation in the absence of auto-negotiation. The other object is a read-only object that provides information about the current mode of operation. Since information about the current mode of operation is available through the read-write object, in the absence of auto-negotiation, the read-only object need provide information only about the currently NEGOTIATED mode of operation (i.e., it need be supported only if auto-negotiation is supported - it can be part of the auto-negotiation group). There are different ways to implement the above objects: 1. As suggested by Rich and as originally defined by Kathy, the ifMauType could serve as the read-write object above and the technologyInUse object serve as the read-only object. 2. As suggested by Dan, a new object called ifMauLastManuallySetType could serve as the read-write object, and ifMauType could be made a read-only object that serves the function of the read-only object specified above. Of course, ifMauType could still be made read-write with the caveat that writes to this object will not be permitted when auto-negotiation is in effect. I prefer (1), since it seems to be closer to the IEEE spec (ifMauType is always writeable), and since the read-only object need be implemented only when auto-negotiation is supported. Thanks, Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20023; 5 Jun 96 11:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20019; 5 Jun 96 11:23 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa08755; 5 Jun 96 11:23 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA149627615; Wed, 5 Jun 1996 08:13:35 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA101847570; Wed, 5 Jun 1996 08:12:50 -0700 Received: from mail12.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA011197569; Wed, 5 Jun 1996 08:12:49 -0700 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA26392; Wed, 5 Jun 1996 11:02:54 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09283; Wed, 5 Jun 1996 11:02:03 -0400 Received: from pe2k3.hpn.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA15218; Wed, 5 Jun 1996 11:01:57 -0400 Received: by pe2k3.hpn.lkg.dec.com (5.65/4.7) id AA23107; Wed, 5 Jun 1996 11:00:37 -0400 Message-Id: <9606051500.AA23107@pe2k3.hpn.lkg.dec.com> To: dromasca@madge.com Cc: pagliaro@dechub.lkg.dec.com, kdegraaf@isd.3com.com, hubmib@hprnd.rose.hp.com Subject: Re: MAU MIB draft 02 X-Mailer: exmh version 1.5beta 8/10/94 Date: Wed, 05 Jun 96 11:00:36 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ------------------------------------------------------------------ Minor correction to my previous (attached) message. "Section 22.4.1.4 (Auto-Negotiation Enable)..." should read "Section 22.2.4.1.4 (Auto-Negotiation Enable)..." -Rich ------- Forwarded Message Dan writes: > Is that your reading of the IEEE spec? If true, there seems to be a > contradiction. > What I found is: > " When Auto-Negotiation is enabled, bit 0.13 can be read or written, but > the state of bit 0.13 has no effect on the link configuration, and it is not > necessary for bit 0.13 to reflect the operating speed of the link when it is > read." This behavior is defined in section 22.2.4.1.3 of IEEE 802.3u-1995 and section 22.2.4.1.8 defines similar behavior for duplex mode setting (bit 0.8). Section 22.4.1.4 (Auto-Negotiation Enable) states "The Auto-Negotiation process shall be made enabled by setting bit 0.12 to a logic one. If bit 0.12 is set to a logic one, then bits 0.13 and 0.8 shall have no effect on the link configuration, and the Auto-Negotiation process will determine the link configuration. IF BIT 0.12 IS CLEARED TO A LOGIC ZERO, THEN BITS 0.13 AND 0.8 WILL DETERMINE THE LINK CONFIGURATION, REGARDLESS OF THE PRIOR STATE OF THE LINK CONFIGURATION AND THE AUTO-NEGOTIATION PROCESS." > There is nothing here about the transition back to non_A/N status. > Is this > a) the last MANUALLY SET type or > b) the last AUTO-NEGOCIATED type > that needs to be activated at the time when A-N is disabled? If b) is > true, our draft is OK, > if a) is true we might need something like ifMauLastManuallySetType. > Otherwise, how > would a manager understand the consequences of disabling A/N from the > point of view > of speed? My interpretation of Section 22.4.1.4 indicates that the answer to the above question is (a). This is why in my previous message I favored keeping the ifMauTechnologyInUse object. I did, however, tell Kathy off line that I can go along with the current draft as long as this interaction between ifMauType and ifMauAutoNegAdminStatus was more clearly defined in the MIB. There could be some value added in hiding some hardware details from the network management user. However, IF we feel it is important for the MIB to more faithfully represent the hardware standard, I'd like to offer a slightly different proposal. In Kathy's previous message she pointed out that with the existence of the previously defined ifMauAutoNegTechnologyInUse object, the object that an NMS would have to read in order to determine the MAU type would depend upon whether or not Auto-Negotiation was enabled. This is sub-optimal. What if we moved the mauTechnologyInUse object from the ifMauAutoNegotiationTable into the ifMauTable. This object would always report the current technology in use whether it was manually configured or auto-negotiated, and the NMS could always inspect the same object to determine the MAU type. As an example, we could make ifMauType read-only again and use this as the technology-in-use object. A new read-write object called something like ifMauTypeManualSetting could be used to configure the MAU type when auto-neg is not supported/enabled. Of course, ifMauType and ifMauTypeManualSetting would be somewhat redundant objects in those implementations which do not support auto-negotiation or the ability to modify their MAU type. Also, this proposal deviates somewhat from the IEEE 802.3u management model. But some holes do appear to exist in that model (at least in the version published in the October 25, 1995 standard). - ------------------------------------------------------------------ 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 ------- End of Forwarded Message   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24094; 5 Jun 96 13:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24088; 5 Jun 96 13:28 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa10837; 5 Jun 96 13:28 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA092535233; Wed, 5 Jun 1996 10:20:34 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA129265202; Wed, 5 Jun 1996 10:20:03 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA159055200; Wed, 5 Jun 1996 10:20:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: arvind@dechub.lkg.dec.com Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id NAA17783; Wed, 5 Jun 1996 13:05:45 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA10016; Wed, 5 Jun 1996 13:05:14 -0400 Received: from agnt69.dechub.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA17086; Wed, 5 Jun 1996 13:05:12 -0400 Received: by agnt69.dechub.lkg.dec.com (5.65/4.7) id AA25856; Wed, 5 Jun 1996 13:05:11 -0400 Date: Wed, 5 Jun 1996 13:05:11 -0400 Message-Id: <9606051705.AA25856@agnt69.dechub.lkg.dec.com> To: hubmib@hprnd.rose.hp.com Subject: MIB object to determine if autonegotiation is supported. I was wondering if it is useful to include an object in the ifMauTable that indicates whether a MAU supports auto-negotiation. Of course, one way to check if auto-negotiation is supported is by trying to retrieve one of the ifMauAutoNegTable objects - failure with a noSuchName error status could be interpreted to mean auto-negotiation is not supported. Would it be better to get a positive indication rather than rely on an error status? Or is there already a MIB object for this purpose that I overlooked? Thanks. Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27717; 5 Jun 96 14:58 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27713; 5 Jun 96 14:58 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa12402; 5 Jun 96 14:58 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA173840645; Wed, 5 Jun 1996 11:50:46 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA138210632; Wed, 5 Jun 1996 11:50:33 -0700 Received: from ISD.3Com.com (chipcom.com) by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA262340632; Wed, 5 Jun 1996 11:50:32 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA13152; Wed, 5 Jun 96 14:47:40 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA0388; Wed, 05 Jun 96 14:48:10 -0700 Message-Id: <9606052148.AA0388@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id E65658C6E0CB7B82852563400066ABCC; Wed, 5 Jun 96 14:48:06 EDT To: arvind Cc: hubmib Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kathy deGraaf/US/3Com Date: 5 Jun 96 14:45:23 EDT Subject: Re: MIB object to determine if autonegotiation is supported. Mime-Version: 1.0 Content-Type: Text/Plain Hi Arvind, The preferred method is the one that you described: try and get one of the A-N objects and if you get a noSuchName error then you can infer that it's not supported. I don't think we'd gain anything by having an extra object there to confirm what a properly-functioning agent is already saying. --Kathy ----- Previous Message ---------------------------------------------------- To: hubmib @ hprnd.rose.hp.com @ SMTP1 cc: From: arvind @ dechub.lkg.dec.com @ SMTP1 Date: Wednesday June 5, 1996 01:05 PM Subject: MIB object to determine if autonegotiation is supported. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I was wondering if it is useful to include an object in the ifMauTable that indicates whether a MAU supports auto-negotiation. Of course, one way to check if auto-negotiation is supported is by trying to retrieve one of the ifMauAutoNegTable objects - failure with a noSuchName error status could be interpreted to mean auto-negotiation is not supported. Would it be better to get a positive indication rather than rely on an error status? Or is there already a MIB object for this purpose that I overlooked? Thanks. Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28364; 5 Jun 96 15:15 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28359; 5 Jun 96 15:15 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa12739; 5 Jun 96 15:15 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA253961769; Wed, 5 Jun 1996 12:09:30 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA140461747; Wed, 5 Jun 1996 12:09:08 -0700 Received: from ISD.3Com.com (chipcom.com) by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA283131746; Wed, 5 Jun 1996 12:09:06 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA13492; Wed, 5 Jun 96 15:06:20 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA0577; Wed, 05 Jun 96 15:06:50 -0700 Message-Id: <9606052206.AA0577@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 016B60E2E2F624428525634000678002; Wed, 5 Jun 96 15:06:47 EDT To: arvind Cc: hubmib Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kathy deGraaf/US/3Com Date: 5 Jun 96 14:57:35 EDT Subject: Re: MAU MIB draft 02 Mime-Version: 1.0 Content-Type: Text/Plain If we need a separate object, then I agree with Arvind, let's put back ifMauAutoNegTechnologyInUse. The only thing I don't like about that approach is that we now have an object called ifMauType that doesn't always reflect the ifMauType. But I think we can work around that problem with proper documentation in the object description. --Kathy ----- Previous Message ---------------------------------------------------- To: hubmib @ hprnd.rose.hp.com @ SMTP1 cc: arvind @ dechub.lkg.dec.com @ SMTP1 pagliaro%netcad.dnet @ dechub.lkg.dec.com @ SMTP1 From: arvind @ dechub.lkg.dec.com @ SMTP1 Date: Wednesday June 5, 1996 10:44 AM Subject: Re: MAU MIB draft 02 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I believe that the correct sequence of operations before auto-negotiation is disabled should be the following: Order A ======= 1. Define the mode in which the link should operate as soon as auto-negotiation is disabled. 2. Disable auto-negotiation. The other order suggested in Kathy's message (as I understand it): (>So in order to make this >work in software, an agent processing a set request >to disable auto-negotiation must also set up the necessary >register(s) in order to make sure the MAU >continues to operate at the type that was auto-negotiated >(until the NMS writes to ifMauType to tell it otherwise). Order B ======= 1. Disable auto-negotiation. 2. Define the mode in which the link should operate as soon as auto-negotiation is disabled. forces the link to operate in the last negotiated mode (or in some default mode if we specify it that way) between the time auto-negotiation is disabled and the new mode is defined. This mode may not always be what the network manager intended during this transition period. I think it is best to have separate objects for control and monitoring. The control object is a read-write object that is used to define the mode of operation in the absence of auto-negotiation. The other object is a read-only object that provides information about the current mode of operation. Since information about the current mode of operation is available through the read-write object, in the absence of auto-negotiation, the read-only object need provide information only about the currently NEGOTIATED mode of operation (i.e., it need be supported only if auto-negotiation is supported - it can be part of the auto-negotiation group). There are different ways to implement the above objects: 1. As suggested by Rich and as originally defined by Kathy, the ifMauType could serve as the read-write object above and the technologyInUse object serve as the read-only object. 2. As suggested by Dan, a new object called ifMauLastManuallySetType could serve as the read-write object, and ifMauType could be made a read-only object that serves the function of the read-only object specified above. Of course, ifMauType could still be made read-write with the caveat that writes to this object will not be permitted when auto-negotiation is in effect. I prefer (1), since it seems to be closer to the IEEE spec (ifMauType is always writeable), and since the read-only object need be implemented only when auto-negotiation is supported. Thanks, Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01635; 5 Jun 96 17:03 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01631; 5 Jun 96 17:03 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa14585; 5 Jun 96 17:03 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA123518083; Wed, 5 Jun 1996 13:54:43 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA152208063; Wed, 5 Jun 1996 13:54:24 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA097348056; Wed, 5 Jun 1996 13:54:17 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA31947; Wed, 5 Jun 1996 16:39:23 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11169; Wed, 5 Jun 1996 16:38:47 -0400 Received: from pe2k3.hpn.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA20047; Wed, 5 Jun 1996 16:38:42 -0400 Received: by pe2k3.hpn.lkg.dec.com (5.65/4.7) id AA24264; Wed, 5 Jun 1996 16:37:22 -0400 Message-Id: <9606052037.AA24264@pe2k3.hpn.lkg.dec.com> To: kdegraaf@isd.3com.com Cc: arvind@dechub.lkg.dec.com, hubmib@hprnd.rose.hp.com Subject: Re: MAU MIB draft 02 In-Reply-To: Your message of "Wed, 05 Jun 96 15:36:46 EDT." <9606051937.AA22923@servir.hpn.lkg.dec.com> X-Mailer: exmh version 1.5beta 8/10/94 Date: Wed, 05 Jun 96 16:37:21 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ------------------------------------------------------------------ Kathy writes: > If we need a separate object, then I agree with Arvind, let's put back > ifMauAutoNegTechnologyInUse. I posted my last reply to this string before receiving Arvind's response. I would like to reiterate the opinions I expressed in my last posting by saying that I agree with Arvind but I favor his option #2 (with a read-only ifMauType) when he wrote: > There are different ways to implement the above objects: > > 1. As suggested by Rich and as originally defined by Kathy, the > ifMauType could serve as the read-write object above and the > technologyInUse object serve as the read-only object. > > 2. As suggested by Dan, a new object called ifMauLastManuallySetType > could serve as the read-write object, and ifMauType could be made > a read-only object that serves the function of the read-only object > specified above. Of course, ifMauType could still be made read-write > with the caveat that writes to this object will not be permitted > when auto-negotiation is in effect. > > I prefer (1), since it seems to be closer to the IEEE spec (ifMauType > is always writeable), and since the read-only object need be implemented > only when auto-negotiation is supported. > Option (2) permits an NMS to always read the same object to determine the current technology-in-use, regardless of whether A/N is supported/unsupported or enabled/disabled. This seems more efficient than option (1). Option (2) also addresses Kathy's concern about "...an object called ifMauType that doesn't always reflect the ifMauType." With option (1) it seems that an NMS would first have to perform a read operation to determine if A/N is supported and enabled. Based on that result, the NMS would then have to decide to read either ifMauType or ifMauAutoNegTechnologyInUse to determine the technology in use. On a device with multiple interface/MAU instances each MAU instance could, of course, be configured differently. I agree that option (1) is closer to IEEE 802.3u. However, as I wrote earlier, the IEEE management model in this area has some deficiencies. In my opinion, providing an efficient, useful solution takes precedence over the literal mapping of SNMP object to the IEEE. Most of my implementation experience is in embedded agent development. As such I agree that option 1 imposes less of a burden to those devices which do not support A/N. But, it seems to me that option (2) could result in less overall network traffic and a more straight forward NMS implementation. Perhaps someone with more NMS development experience than me can provide better data. Regards. ------------------------------------------------------------------ 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 ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11809; 6 Jun 96 7:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11802; 6 Jun 96 7:00 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa05033; 6 Jun 96 7:00 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA037178394; Thu, 6 Jun 1996 03:53:14 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA195968379; Thu, 6 Jun 1996 03:52:59 -0700 Received: from radmail.rad.co.il by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA045118377; Thu, 6 Jun 1996 03:52:57 -0700 Received: from suri.rad.co.il ([192.114.32.57]) by radmail.rad.co.il (post.office MTA v1.9.3 ID# 0-12126) with SMTP id AAA26945 for ; Thu, 6 Jun 1996 13:51:52 +0300 Date: Thu, 6 Jun 96 13:49:36 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Uri Shabi X-Orig-Sender: uri@suri.rad.co.il To: hubmib@hprnd.rose.hp.com X-Priority: 3 (Normal) X-Mailer: Chameleon 4.6, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe hubmib-request   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11892; 6 Jun 96 7:05 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11888; 6 Jun 96 7:05 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa05096; 6 Jun 96 7:05 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA042818642; Thu, 6 Jun 1996 03:57:22 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA196008631; Thu, 6 Jun 1996 03:57:12 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA046888630; Thu, 6 Jun 1996 03:57:10 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: arvind@dechub.lkg.dec.com Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id GAA09048; Thu, 6 Jun 1996 06:46:46 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13671; Thu, 6 Jun 1996 06:46:12 -0400 Received: from agnt69.dechub.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA22738; Thu, 6 Jun 1996 06:45:33 -0400 Received: by agnt69.dechub.lkg.dec.com (5.65/4.7) id AA27345; Thu, 6 Jun 1996 06:45:32 -0400 Date: Thu, 6 Jun 1996 06:45:32 -0400 Message-Id: <9606061045.AA27345@agnt69.dechub.lkg.dec.com> To: hubmib@hprnd.rose.hp.com Cc: pagliaro%netcad.dnet@dechub.lkg.dec.com, kdegraaf@isd.3com.com, arvind@dechub.lkg.dec.com Subject: RE: MAU MIB draft 02 >Kathy writes: > >> If we need a separate object, then I agree with Arvind, let's put back >> ifMauAutoNegTechnologyInUse. > >I posted my last reply to this string before receiving Arvind's response. I >would like to reiterate the opinions I expressed in my last posting by saying >that I agree with Arvind but I favor his option #2 (with a read-only >ifMauType) when he wrote: > >> There are different ways to implement the above objects: >> >> 1. As suggested by Rich and as originally defined by Kathy, the >> ifMauType could serve as the read-write object above and the >> technologyInUse object serve as the read-only object. >> >> 2. As suggested by Dan, a new object called ifMauLastManuallySetType >> could serve as the read-write object, and ifMauType could be made >> a read-only object that serves the function of the read-only object >> specified above. Of course, ifMauType could still be made read-write >> with the caveat that writes to this object will not be permitted >> when auto-negotiation is in effect. >> >> I prefer (1), since it seems to be closer to the IEEE spec (ifMauType >> is always writeable), and since the read-only object need be implemented >> only when auto-negotiation is supported. >> > >Option (2) permits an NMS to always read the same object to determine the >current technology-in-use, regardless of whether A/N is supported/unsupported >or enabled/disabled. This seems more efficient than option (1). Option (2) >also addresses Kathy's concern about "...an object called ifMauType that >doesn't always reflect the >ifMauType." > >With option (1) it seems that an NMS would first have to perform a read >operation to determine if A/N is supported and enabled. Based on that result, >the NMS would then have to decide to read either ifMauType or >ifMauAutoNegTechnologyInUse to determine the technology in use. On a device >with multiple interface/MAU instances each MAU instance could, of course, be >configured differently. > >I agree that option (1) is closer to IEEE 802.3u. However, as I wrote earlier, >the IEEE management model in this area has some deficiencies. In my opinion, >providing an efficient, useful solution takes precedence over the literal >mapping of SNMP object to the IEEE. > >Most of my implementation experience is in embedded agent development. As such >I agree that option 1 imposes less of a burden to those devices which do not >support A/N. But, it seems to me that option (2) could result in less overall >network traffic and a more straight forward NMS implementation. Perhaps >someone with more NMS development experience than me can provide better data. My reply was sent out before I received Rich's response. I see Rich's point. Even though scheme (1) may be close to the IEEE spec, it requires the retrieval of 3 pieces of information each time an NMS wants to identify the current mode of operation of a MAU: (a) Is auto-negotiation supported on a MAU? (This cannot be always determined at init time, e.g., when hot swapping of interfaces/MAUs is supported). (b) Is auto-negotiation enabled on the MAU? (This again can change with time, since there may be multiple network managers and/or a console). (c) The current mode of operation or the manually configured mode of operation depending on the presence/state of auto-negotiation. It may not be always possible to retrieve all 3 pieces of information simultaneously because the object involved in (b) may not be supported at all if auto-negotiation is not supported, and (c) is conditional on (a) and (b). It will require at least 2 separate requests, even if a separate object is defined for (a) (rather than rely on a noSuchName error status to determine whether auto-negotiation is supported or not). This will at least double mauType-related traffic originated by an NMS. The resulting increase in traffic may be felt if the NMS is in a polling mode, and there are a large number of high port density switches being managed. On the other hand, if there is an object that always provides information about the current mode of operation, this will require a little bit of extra agent implementation effort on devices that don't plan to support auto-negotiation. But the extra effort is a one time hit and is so small (one read-only object) that nobody is likely to complain. I have no problem in going with scheme (2). I have one suggestion though - perhaps we could use object names that convey their function more precisely (if deviation from names used in the IEEE spec is acceptable for the purpose of clarity): ifMauCurrentMode - instead of ifMauType ifMauDefaultMode - instead of ifMauLastManuallySetType Thanks, Regards, Arvind   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12069; 6 Jun 96 7:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12065; 6 Jun 96 7:18 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa05250; 6 Jun 96 7:18 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA060709358; Thu, 6 Jun 1996 04:09:19 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA196069346; Thu, 6 Jun 1996 04:09:06 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA052739345; Thu, 6 Jun 1996 04:09:05 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: arvind@dechub.lkg.dec.com Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id GAA06212; Thu, 6 Jun 1996 06:58:35 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13695; Thu, 6 Jun 1996 06:58:02 -0400 Received: from agnt69.dechub.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA22766; Thu, 6 Jun 1996 06:57:59 -0400 Received: by agnt69.dechub.lkg.dec.com (5.65/4.7) id AA27352; Thu, 6 Jun 1996 06:57:57 -0400 Date: Thu, 6 Jun 1996 06:57:57 -0400 Message-Id: <9606061057.AA27352@agnt69.dechub.lkg.dec.com> To: Kathy_deGraaf/US/3Com%3COM@smtp1.isd.3com.com Cc: hubmib@hprnd.rose.hp.com Subject: Re: MIB object to determine if autonegotiation is supported. Kathy, I think there may actually be some advantage to supporting a separate object to determine if autonegotiation is supported or not. If we were to use a 'noSuchName' error status to determine if autoneg is supported, then an NMS will necessarily have to use a separate request for this purpose. If we define a separate object, then a request for the value of this object can be piggy-backed with requests for other objects on the same PDU, thus saving on network traffic. Besides, there may be sloppy implementations that return a genErr instead of a noSuchName when a request is made for a non-existent row (hole) in a table. These implementations will not work with all NMS's. Thanks, Regards, Arvind. Received: from tayhub.dechub.lkg.dec.com by newhub.dechub.lkg.dec.com with SMTP id AA05324; Wed, 5 Jun 1996 14:59:11 -0400 Received: from mail1.digital.com by tayhub.dechub.lkg.dec.com with SMTP id AA18566; Wed, 5 Jun 1996 14:59:02 -0400 Received: from chipcom.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA14981; Wed, 5 Jun 1996 11:52:58 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA13149; Wed, 5 Jun 96 14:47:37 EDT Return-Path: Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA0386; Wed, 05 Jun 96 14:48:07 -0700 Message-Id: <9606052148.AA0386@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id E65658C6E0CB7B82852563400066ABCC; Wed, 5 Jun 96 14:48:06 EDT To: arvind Cc: hubmib From: Kathy deGraaf/US/3Com Date: 5 Jun 96 14:45:23 EDT Subject: Re: MIB object to determine if autonegotiation is supported. Mime-Version: 1.0 Content-Type: Text/Plain Hi Arvind, The preferred method is the one that you described: try and get one of the A-N objects and if you get a noSuchName error then you can infer that it's not supported. I don't think we'd gain anything by having an extra object there to confirm what a properly-functioning agent is already saying. --Kathy ----- Previous Message ---------------------------------------------------- To: hubmib @ hprnd.rose.hp.com @ SMTP1 cc: From: arvind @ dechub.lkg.dec.com @ SMTP1 Date: Wednesday June 5, 1996 01:05 PM Subject: MIB object to determine if autonegotiation is supported. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- I was wondering if it is useful to include an object in the ifMauTable that indicates whether a MAU supports auto-negotiation. Of course, one way to check if auto-negotiation is supported is by trying to retrieve one of the ifMauAutoNegTable objects - failure with a noSuchName error status could be interpreted to mean auto-negotiation is not supported. Would it be better to get a positive indication rather than rely on an error status? Or is there already a MIB object for this purpose that I overlooked? Thanks. Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21075; 6 Jun 96 12:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21071; 6 Jun 96 12:32 EDT Received: from [15.254.56.2] by CNRI.Reston.VA.US id aa09888; 6 Jun 96 12:32 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA109578252; Thu, 6 Jun 1996 09:24:13 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA217318214; Thu, 6 Jun 1996 09:23:36 -0700 Received: from ISD.3Com.com (chipcom.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA162888212; Thu, 6 Jun 1996 09:23:32 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA05316; Thu, 6 Jun 96 12:20:43 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA4719; Thu, 06 Jun 96 12:21:13 -0700 Message-Id: <9606061921.AA4719@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 9F6D8CE6DA7FF8558525634100557C32; Thu, 6 Jun 96 12:21:01 EDT To: arvind Cc: hubmib Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kathy deGraaf/US/3Com Date: 6 Jun 96 12:17:50 EDT Subject: Re: MIB object to determine if autonegotiation is supported. Mime-Version: 1.0 Content-Type: Text/Plain > I think there may actually be some advantage to supporting a > separate object to determine if autonegotiation is supported or not. > If we were to use a 'noSuchName' error status to determine if autoneg > is supported, then an NMS will necessarily have to use a separate > request for this purpose. If we define a separate object, then a > request for the value of this object can be piggy-backed with requests > for other objects on the same PDU, thus saving on network traffic. This issue has historically been a FAQ--one of the guidelines that working groups have tried to follow when defining standard MIBs is to keep the number of objects to a minimum, and not define objects that are duplicates of other objects (even total counters were controversial in the past). It's usually a judgement call, of course: we balance the cost of an additional object per MAU vs. a maximum of one additional round-trip request per MAU. In the past, with a few exceptions, we've leaned towards putting the load on the network rather than on the agent. I don't know whether current thinking has changed on this subject, but that's been the party line. 8-) > Besides, there may be sloppy implementations that return a genErr > instead of a noSuchName when a request is made for a non-existent row > (hole) in a table. These implementations will not work with all > NMS's. I disagree that an additional variable will solve that problem. I also disagree that it is the responsibility of standard MIBs to provide workarounds for incorrect implementations. --Kathy   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01282; 6 Jun 96 19:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01278; 6 Jun 96 19:34 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa17471; 6 Jun 96 19:34 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA146603768; Thu, 6 Jun 1996 16:29:29 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA268513759; Thu, 6 Jun 1996 16:29:19 -0700 Received: from feta.cisco.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA229113759; Thu, 6 Jun 1996 16:29:19 -0700 Received: (jjohnson@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA02369; Thu, 6 Jun 1996 16:26:48 -0700 Date: Thu, 6 Jun 1996 16:26:48 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jeffrey T. Johnson" Message-Id: <199606062326.QAA02369@feta.cisco.com> To: hubmib@hprnd.rose.hp.com Subject: couple of hubmib questions Cc: jjohnson@cisco.com I'm passing on a couple of questions/comments from a coworker... >There is an {if|rp}JackTable to deal with multi-connector interfaces, >but oddly enough, there isn't a status column in the table, with >active/dormant/down statuses or some other scheme, to identify which >connector is configured for use (if any). my question: can there really be multiple jacks per MAU? I thought it was a 1-to-1 relationship. If it were 1-to-1, then {if|rp}MauStatus would do the trick, but if not, looks like there should be a status column. >Also, I don't see MII in the {if|rp}MauType list or in the >{if|rp}JackTable, but maybe it's in a form I don't recognize? Clues? thanks /jeff   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15420; 7 Jun 96 10:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15416; 7 Jun 96 10:11 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa00477; 7 Jun 96 10:11 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA161606060; Fri, 7 Jun 1996 07:01:00 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA295566045; Fri, 7 Jun 1996 07:00:46 -0700 Received: from mail13.digital.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA032496043; Fri, 7 Jun 1996 07:00:43 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: arvind@dechub.lkg.dec.com Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id JAA14920; Fri, 7 Jun 1996 09:37:29 -0400 (EDT) Received: from newhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA19333; Fri, 7 Jun 1996 09:31:55 -0400 Received: from bugbug.dechub.lkg.dec.com by newhub.dechub.lkg.dec.com with SMTP id AA02157; Fri, 7 Jun 1996 09:28:13 -0400 Received: by bugbug.dechub.lkg.dec.com (5.65/4.7) id AA15923; Fri, 7 Jun 1996 09:26:55 -0400 Date: Fri, 7 Jun 1996 09:26:55 -0400 Message-Id: <9606071326.AA15923@bugbug.dechub.lkg.dec.com> To: Kathy_deGraaf/US/3Com%3COM@smtp1.isd.3com.com Cc: hubmib@hprnd.rose.hp.com, arvind@dechub.lkg.dec.com Subject: Re: MIB object to determine if autonegotiation is supported. Hi Kathy, >> Besides, there may be sloppy implementations that return a genErr >> instead of a noSuchName when a request is made for a non-existent row >> (hole) in a table. These implementations will not work with all >> NMS's. > >I disagree that an additional variable will solve that problem. I also >disagree that it is the responsibility of standard MIBs to provide >workarounds for incorrect implementations. I agree with you here, Kathy. It is definitely the responsibility of standard MIBs to try to accommodate potentially incorrect implementations. So this cannot be the primary reason for including the object in question. If we do decide to include such an object, we will be able to accommodate incorrect implementations as a side-benefit. >> I think there may actually be some advantage to supporting a >> separate object to determine if autonegotiation is supported or not. >> If we were to use a 'noSuchName' error status to determine if autoneg >> is supported, then an NMS will necessarily have to use a separate >> request for this purpose. If we define a separate object, then a >> request for the value of this object can be piggy-backed with requests >> for other objects on the same PDU, thus saving on network traffic. > >This issue has historically been a FAQ--one of the guidelines that working >groups have tried to follow when defining standard MIBs is to keep the number >of objects to a minimum, and not define objects that are duplicates of other >objects (even total counters were controversial in the past). It's usually a >judgement call, of course: we balance the cost of an additional object per >MAU vs. a maximum of one additional round-trip request per MAU. In the past, >with a few exceptions, we've leaned towards putting the load on the network >rather than on the agent. I don't know whether current thinking has changed >on this subject, but that's been the party line. 8-) Yes, agent implementations have to be simpler, and as much of the complexity and burden as is required to manage a device should reside in management stations (whose "power" can be matched to network management needs), since management is not the primary function of the managed device that hosts an agent. So one should avoid redundant objects that are duplicates of others or that can be derived from other objects - so only "primitive" objects should be supported. However, I still think an object to determine whether auto-neg. is supported on a MAU will be useful for the following reasons: (1) The object is not really a duplicate or derivative of another object because there is no real object that provides information about support for auto-neg. In the absence of this object, the management station has to rely on an indirect means (the failure of a transaction) to deduce the information that this object would otherwise provide. Of course, one can argue that the object is redundant because the information provided by this object can be deduced through some other means, although it may not be through another object. But I would feel more comfortable with retrieving a real object rather than with trying to check if an object is absent - so this is a personal preference. (2) I thought the partyline was about shifting the management burden to management stations, not to the network. In any case, I believe that supporting management is not the primary function of a network, and so transport of management messages should have a minimal impact on the core functions of a network (transporting user data). So one cannot overload the network without restraint in order to make agents absolutely slim. There has to be a balance based on a judgement call, as you have pointed out. I think the judgement should favor supporting a separate object for auto-neg for the following reason. In the presence of high port-density devices (24 port switches are common today, 64-128 port switches will probably be common in a couple of years), and multiple network managers operating in polling mode, minimizing the number of transactions may make sense. A separate object to determine if auto-neg. is supported will be helpful for this. Again, this is just based on common sense reasoning, not on any measured data. If someone could provide information about how management of high density devices impacts available useful bandwidth, based on measurements done in real-life environments, that would be very helpful. Regards, Arvind.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14637; 10 Jun 96 9:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14633; 10 Jun 96 9:49 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa07810; 10 Jun 96 9:49 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA142204221; Mon, 10 Jun 1996 06:43:41 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA221484135; Mon, 10 Jun 1996 06:42:15 -0700 Received: from IETF.cnri.reston.VA.US by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA002724134; Mon, 10 Jun 1996 06:42:14 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14096; 10 Jun 96 9:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ;, CNRI.Reston.VA.US@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: hubmib@hprnd.rose.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-hubmib-etherif-mib-00.txt Date: Mon, 10 Jun 96 09:39:38 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9606100939.aa14096@IETF.CNRI.Reston.VA.US> --NextPart A New 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-00.txt Pages : 22 Date : 06/07/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-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-etherif-mib-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-00.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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960607135302.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960607135302.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20637; 10 Jun 96 13:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20633; 10 Jun 96 13:23 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa11745; 10 Jun 96 13:23 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA258576927; Mon, 10 Jun 1996 10:15:28 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA254326889; Mon, 10 Jun 1996 10:14:49 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA218606888; Mon, 10 Jun 1996 10:14:48 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Mon, 10 Jun 96 10:06:59 -0800 Message-Id: <8C62BC3101660C00@mail.madge.com> Date: Mon, 10 Jun 96 20:07:20 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com Subject: (Almost) Last Call X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway HubMIB-ers, I think we are almost done, and I would like to call soon for consensus regarding our work items. 1. Hub MIB Draft 02 It looks stable and I did not hear any objections in the last weeks. 2. MAU MIB Draft 02 We had some discussions in the last couple of weeks on two items: - behavior of ifMauType at transitions of AutoNegociation from ON to OFF. The exact behavior seems to be somehow vaguely defined by the IEEE MAU spec, and the MAU MIB reflects this. My experience is that we can go along with the present MIB structure, maybe add some explanatory text. I would like however to leave place for other people with implementation experience express their concers in the case that this solution seems completly broken from their point of view. - the need for an object that explicitely describes the fact that the device supports AutoNegociation or not. I would agree with Kathy's argument that this should be left out. 3. 100 BaseT extensions for Ethernet interfaces - Draft 00 Thanks to Jeff Johnson for the brand new Internet Draft. I would propose to leave it open for comments on the list for a few weeks. I invite everybody to discuss the above open items or any other open questions in the next days. If no special problems arise, I will make the (Final) Last Call at the end of the week. Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06584; 11 Jun 96 1:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06580; 11 Jun 96 1:02 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa01945; 11 Jun 96 1:02 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA044659340; Mon, 10 Jun 1996 22:02:20 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA089289299; Mon, 10 Jun 1996 22:01:40 -0700 Received: from hclhprnd.hclt.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA122929295; Mon, 10 Jun 1996 22:01:35 -0700 Received: from utopia.hclt.com by hclhprnd.hclt.com with SMTP id AA12151 (5.67c/IDA-1.5 for ); Tue, 11 Jun 1996 10:30:19 +0530 Received: by utopia.hclt.com (4.1/1.36) id AA17170; Tue, 11 Jun 96 10:26:03 IST Message-Id: <9606110456.AA17170@utopia.hclt.com> Subject: MIB Object For Link Status of Ports. To: hubmib@hprnd.rose.hp.com Date: Tue, 11 Jun 1996 10:26:02 +0530 (IST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Murugan R." X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 200 Hello, Pardon me if this is a very basic question. Why isn't there a MIB object to get the Link Status (up/down), of a port, in the Repeater MIB? Murugan Rajagopal, HCL Technologies Limited, India.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab07651; 11 Jun 96 2:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab07647; 11 Jun 96 2:38 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa02952; 11 Jun 96 2:38 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA105785102; Mon, 10 Jun 1996 23:38:23 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA097655030; Mon, 10 Jun 1996 23:37:11 -0700 Received: from spider.lloyd.com (www.lloyd.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA177195030; Mon, 10 Jun 1996 23:37:10 -0700 Received: from donna by spider.lloyd.com with smtp (Smail3.1.29.1 #5) id m0uTMxo-002Wj5C; Mon, 10 Jun 96 23:30 PDT X-Mailer: InterCon TCP/Connect II 2.3.1 Mime-Version: 1.0 Message-Id: <9606102333.AA26203@donna> Date: Mon, 10 Jun 1996 23:33:26 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Donna McMaster To: "Murugan R." Cc: hubmib@hprnd.rose.hp.com Subject: Re: MIB Object For Link Status of Ports. Content-Type: Multipart/Mixed;boundary=part_ADE26145000B959900000002 --part_ADE26145000B959900000002 Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline Murugan, > Why isn't there a MIB object to get the Link Status (up/down), > of a port, in the Repeater MIB? Link Status applies to a link (e.g., 10BASE-T) between the MAU attached to the repeater port and the MAU attached to the device at the other end of the link. As such, the link status information is kept in the MAU MIB. repeater port - MAU -------link-------- MAU - device If this seems like an odd separation, note that (1) Not all repeater ports are connected to 10BASE-T links. AUI, BNC, and fiber optic links have different characteristics (2) A single repeater port can be connected to two different MAUs (for example a hub with an "uplink" that can be switched between AUI and 10BASE-T) Regards, Donna ---------------- Donna McMaster, Coloma Communications Email: donna@coloma.com (916) 642-2402 voice Web: http://www.coloma.com/ (916) 642-0273 fax --part_ADE26145000B959900000002--   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18754; 11 Jun 96 12:20 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18749; 11 Jun 96 12:20 EDT Received: from hp.com by CNRI.Reston.VA.US id aa13111; 11 Jun 96 12:20 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA023889256; Tue, 11 Jun 1996 09:07:37 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA114689193; Tue, 11 Jun 1996 09:06:33 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA209519178; Tue, 11 Jun 1996 09:06:18 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA24135; Tue, 11 Jun 1996 11:48:34 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08202; Tue, 11 Jun 1996 11:48:07 -0400 Received: from pe2k3.hpn.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA28695; Tue, 11 Jun 1996 11:47:29 -0400 Received: by pe2k3.hpn.lkg.dec.com (5.65/4.7) id AA04464; Tue, 11 Jun 1996 11:46:00 -0400 Message-Id: <9606111546.AA04464@pe2k3.hpn.lkg.dec.com> To: dromasca@madge.com Cc: hubmib@hprnd.rose.hp.com, arvind@dechub.lkg.dec.com, pagliaro@dechub.lkg.dec.com Subject: Re: (Almost) Last Call (MAU MIB Draft 02) In-Reply-To: Your message of "Mon, 10 Jun 96 13:37:33 EDT." <9606101738.AA19462@servir.hpn.lkg.dec.com> X-Mailer: exmh version 1.5beta 8/10/94 Date: Tue, 11 Jun 96 11:46:00 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ------------------------------------------------------------------ Dan, On behalf of Arvind and myself I would like to summarize our position on the behavior of ifMauType in MAU MIB Draft 02. We propose that the MAU MIB draft be modified to split the current functions of ifMauType between two different MIB objects. One MIB object reports the currently used MAU technology while the other MIB object manually selects the default MAU type to be used when auto-negotiation is not functioning. Such MIB objects might be named: ifMauCurrentType - read-only ifMauDefaultType - read-write Our reasoning is as follows: 1. This proposed method provides the ability to specify the default/manual MAU type WHILE AUTO-NEGOTIATION IS CURRENTLY ACTIVE. - This gives the user the flexibility to pre-define the MAU type to be used after auto-negotiation is disabled. This is desirable to ensure that the new operational mode after auto-negotiation is disabled is fully under the control of the user. - IEEE 802.3u sections 22.2.4.1.3 and 22.2.4.1.8 clearly define the ability to configure manual speed and duplex mode settings (which translates to default/manual MAU type), even when auto-negotiation is enabled. Section 22.2.4.1.3 states that "When Auto-Negotiation is enabled, bit 0.13 CAN BE READ OR WRITTEN, but the state of bit 0.13 has no effect on the link configuration...". Section 22.2.4.1.8 contains a similar clause relating to bit 0.8 (duplex mode). The only time the IEEE spec mentions ignoring attempts to change these settings is when an attempt is made to select a mode which the hardware is physically not able to support. 2. This proposed method clearly delinks the current MAU type from the default/manual MAU type. - This separation of functions mirrors the MII management interface hardware standard, resulting in straight forward agent implementations. - IEEE 802.3u sections 22.2.4.1.3 and 22.2.4.1.8 clearly delink bits 0.13 and 0.8 from the current mode of operation (" ... bit 0.13 can be read or written, but the state of bit 0.13 has no effect on the link configuration, and it is not necessary for bit 0.13 to reflect the operating speed of the link when it is read" - 802.3u, October 26, 1995 defines similar behavior for bit 0.8). 3. We disagree with you that the IEEE spec is vague about the behavior of MAU type at transitions of auto-negotiation. - As argued in (1), the standard allows for specifying the default mode even when auto-negotiation is active, and also specifies that the mode should be restored to this default mode when auto-negotiation is disabled. - Section 22.2.4.1.4 explicitly states that when auto-negotiation is not active, the manual speed and duplex mode settings alone determine the PHY configuration "...REGARDLESS OF THE PRIOR STATE OF THE LINK CONFIGURATION AND THE AUTO-NEGOTIATION PROCESS." 4. The behavior of ifMauType as defined in MAU MIB Draft 02 seems awkward because, effectively, the MAX-ACCESS of the object changes depending upon the value (or presence) of an object in a different MIB group (i.e. ifMauAutoNegAdminStatus). - While this my not violate SMI, this doesn't seem to be the preferred method to define a MIB object. Kathy wrote on June 4th: >> 2. Ditch ifMauAutoNegTechnologyInUse, and use ifMauType to show >> the result of A-N. This allows an NMS to look in a single >> place (ifMauType) for the operational value at any time. But >> it means that ifMauType is effectively read-only while A-N is >> turned on, and read-write if A-N is turned off. After >> disabling auto-negotiation, an NMS must write to ifMauType if >> it wants to set the operational value to something new. In >> other words, there is no place to tell the system what value >> to use automatically when A-N is turned off--no place to >> "remember" the manually-set value. 5. The new proposal makes it easy for an NMS to determine the MAU type. - If the hypothetical ifMauCurrentType object is defined in the ifMauTable then an NMS would only ever have to look at one object to determine the MAU type. The NMS would not have to first check for the value (or existence of) ifMauAutoNegTechnologyInUse. Regards. ------------------------------------------------------------------ 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 ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22824; 11 Jun 96 14:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22820; 11 Jun 96 14:31 EDT Received: from hp.com by CNRI.Reston.VA.US id aa16394; 11 Jun 96 14:31 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA250227060; Tue, 11 Jun 1996 11:17:41 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA158867013; Tue, 11 Jun 1996 11:16:54 -0700 Received: from lightning.synoptics.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA096387013; Tue, 11 Jun 1996 11:16:53 -0700 Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA25063; Tue, 11 Jun 96 11:14:03 PDT Received: from by pobox (4.1/SMI-4.1) id AB28450; Tue, 11 Jun 96 11:13:58 PDT X-Sender: gthompso@sc-mail1.corpwest.baynetworks.com Message-Id: In-Reply-To: <9606110456.AA17170@utopia.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Jun 1996 17:27:39 +0100 To: "Murugan R." , hubmib@hprnd.rose.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Geoff Thompson Subject: Re: MIB Object For Link Status of Ports. Because repeater ports dont hook to links, they hook to MAUs. The IEEE model of a 10 Mb/s repeater is a number of ports that have AUIs either explicit or buried. The IEEE spec for repeaters was developed before 10BASE-T or any of the fiber specs. The link status appears in the MAU MIB. That way you have link status at both the repeater end and the DTE end (unless, of course, you are using coax) Hope this helps, Geoff Thompson At 10:26 AM +0530 6/11/96, Murugan R. wrote: >Hello, > >Pardon me if this is a very basic question. >Why isn't there a MIB object to get the Link Status (up/down), >of a port, in the Repeater MIB? > >Murugan Rajagopal, >HCL Technologies Limited, >India. Geoff Thompson Chair IEEE 802.3 Bay Networks, Inc. 4401 Great America Parkway P. O. Box 58185 Santa Clara, CA 95052-8185 USA Phone: +1 408 764 1339 Fax: +1 408 988 5525   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00467; 11 Jun 96 23:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00463; 11 Jun 96 23:11 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa00310; 11 Jun 96 23:12 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA260909119; Tue, 11 Jun 1996 20:12:00 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA210069105; Tue, 11 Jun 1996 20:11:46 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA048939519; Tue, 11 Jun 1996 20:18:39 -0700 Message-Id: <199606120318.AA048939519@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com Subject: HP Search Addr Patent Grant Date: Tue, 11 Jun 1996 20:18:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Flick For those who are not on the ietf-announce list, I am forwarding the following announcement. This document is now officially in the RFC Editor's queue awaiting publication as an Informational RFC. John ------- Forwarded Message Received: from hprnd.rose.hp.com by hprnljf.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.4 ) id AA048698864; Tue, 11 Jun 1996 20:07:45 -0700 Return-Path: Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA192418329; Tue, 11 Jun 1996 20:00:49 -0700 Received: from IETF.cnri.reston.VA.US by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA110458185; Tue, 11 Jun 1996 19:56:25 -0700 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26675; 11 Jun 96 16:09 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa26637; 11 Jun 96 16:08 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18835; 11 Jun 96 16:08 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa26630; 11 Jun 96 16:08 EDT To: IETF-Announce:;@IETF.CNRI.Reston.VA.US Cc: RFC Editor Cc: Internet Architecture Board Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: The IESG Subject: Document Action: Conditional Grant of Rights to Specific HP Patents In Conjunction With the IETF's Internet-Standard Network Management Framework to Informational Date: Tue, 11 Jun 96 16:08:03 -0400 X-Orig-Sender: scoya@CNRI.Reston.VA.US Message-Id: <9606111608.aa26630@IETF.CNRI.Reston.VA.US> The IESG has reviewed the Internet-Draft "Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework" and recommends that it be published by the RFC Editor as an Informational RFC. The IESG contact person is Deirdre Kostick. ------- End of Forwarded Message   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10328; 12 Jun 96 3:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10324; 12 Jun 96 3:48 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa03752; 12 Jun 96 3:48 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA271495697; Wed, 12 Jun 1996 00:48:17 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA147845687; Wed, 12 Jun 1996 00:48:08 -0700 Received: from hclhprnd.hclt.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA262925682; Wed, 12 Jun 1996 00:48:02 -0700 Received: from utopia.hclt.com by hclhprnd.hclt.com with SMTP id AA03701 (5.67c/IDA-1.5 for ); Wed, 12 Jun 1996 13:17:10 +0530 Received: by utopia.hclt.com (4.1/1.36) id AA22482; Wed, 12 Jun 96 13:12:48 IST Message-Id: <9606120742.AA22482@utopia.hclt.com> Subject: Re: MIB Object For Link Status of Ports. To: Geoff Thompson Date: Wed, 12 Jun 1996 13:12:47 +0530 (IST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Murugan R." Cc: hubmib@hprnd.rose.hp.com In-Reply-To: from "Geoff Thompson" at Jun 11, 96 05:27:39 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 956 Thanks for your clarification. But look at this scenario. Almost all the network manageable ethernet hubs implement the repeater MIB. These hubs will have more ports (8, 12, 16.. TP ports) than AUI (only one in most cases). And these TP ports have link status. So I think link status should be provided considering the large number of TP ports against the only AUI port. From Geoff_Thompson@baynetworks.com Tue Jun 11 23:44 IST 1996 > > Because repeater ports dont hook to links, they hook to MAUs. The IEEE > model of a 10 Mb/s repeater is a number of ports that have AUIs either > explicit or buried. The IEEE spec for repeaters was developed before > 10BASE-T or any of the fiber specs. > > The link status appears in the MAU MIB. That way you have link status at > both the repeater end and the DTE end (unless, of course, you are using > coax) > > Hope this helps, > > Geoff Thompson Murugan Rajagopal, HCL Technologies Limited, India.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14219; 12 Jun 96 7:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14215; 12 Jun 96 7:59 EDT Received: from [15.254.56.2] by CNRI.Reston.VA.US id aa06692; 12 Jun 96 7:59 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA033870718; Wed, 12 Jun 1996 04:58:39 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA150330706; Wed, 12 Jun 1996 04:58:26 -0700 Received: from ISD.3Com.com (chipcom.com) by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA198070704; Wed, 12 Jun 1996 04:58:24 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA10372; Wed, 12 Jun 96 07:55:33 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA1365; Wed, 12 Jun 96 07:56:06 -0700 Message-Id: <9606121456.AA1365@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 35C54C6F3DE3F79C8525634700407F36; Wed, 12 Jun 96 07:56:02 EDT To: "Murugan R." Cc: Geoff Thompson , hubmib Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kathy deGraaf/US/3Com Date: 12 Jun 96 7:48:27 EDT Subject: Re: MIB Object For Link Status of Ports. Mime-Version: 1.0 Content-Type: Text/Plain Hi Muragan, The answer to your question is that hub vendors should implement the MAU MIB. That's where the object for link status is already defined. (And that's also where the objects for managing auto-negotiation are now defined.) Kathy de Graaf kdegraaf@isd.3com.com ----- Previous Message ---------------------------------------------------- To: Geoff_Thompson @ BayNetworks.COM @ SMTP1 cc: hubmib @ hprnd.rose.hp.com @ SMTP1 From: murugan @ utopia.hclt.com ("Murugan R.") @ SMTP1 Date: Wednesday June 12, 1996 01:12 PM Subject: Re: MIB Object For Link Status of Ports. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Thanks for your clarification. But look at this scenario. Almost all the network manageable ethernet hubs implement the repeater MIB. These hubs will have more ports (8, 12, 16.. TP ports) than AUI (only one in most cases). And these TP ports have link status. So I think link status should be provided considering the large number of TP ports against the only AUI port. From Geoff_Thompson@baynetworks.com Tue Jun 11 23:44 IST 1996 > > Because repeater ports dont hook to links, they hook to MAUs. The IEEE > model of a 10 Mb/s repeater is a number of ports that have AUIs either > explicit or buried. The IEEE spec for repeaters was developed before > 10BASE-T or any of the fiber specs. > > The link status appears in the MAU MIB. That way you have link status at > both the repeater end and the DTE end (unless, of course, you are using > coax) > > Hope this helps, > > Geoff Thompson Murugan Rajagopal, HCL Technologies Limited, India.   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05537; 12 Jun 96 18:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05533; 12 Jun 96 18:11 EDT Received: from hp.com by CNRI.Reston.VA.US id aa17632; 12 Jun 96 18:11 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA285216817; Wed, 12 Jun 1996 15:00:18 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA286526794; Wed, 12 Jun 1996 14:59:54 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA063757208; Wed, 12 Jun 1996 15:06:49 -0700 Message-Id: <199606122206.AA063757208@hprnljf.rose.hp.com> To: Dan Romascano ESD-Tel Cc: hubmib@hprnd.rose.hp.com Subject: Re: (Almost) Last Call In-Reply-To: Your message of "Mon, 10 Jun 1996 20:07:20 +0300." <8C62BC3101660C00@mail.madge.com> Date: Wed, 12 Jun 1996 15:06:48 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Flick >HubMIB-ers, > >I think we are almost done, and I would like to call soon >for consensus regarding our work items. > It seems to me like we have a very stable Repeater MIB draft, a MAU MIB draft on which we haven't quite reached consensus and a completely new Interface MIB draft that needs some time for review an comments. These three documents don't seem to really depend on each other. Would it make sense to advance them separately? It seems like we could forward the Repeater MIB draft today (or after some brief last call period), but that we still have some issues to work out on the other documents. I don't see any reason to delay the Repeater MIB draft while we work out the issues on the other documents. John   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05806; 12 Jun 96 18:21 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05802; 12 Jun 96 18:21 EDT Received: from hp.com by CNRI.Reston.VA.US id aa17850; 12 Jun 96 18:21 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA297987371; Wed, 12 Jun 1996 15:09:32 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA298977349; Wed, 12 Jun 1996 15:09:09 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA064097763; Wed, 12 Jun 1996 15:16:03 -0700 Message-Id: <199606122216.AA064097763@hprnljf.rose.hp.com> To: pagliaro@dechub.lkg.dec.com Cc: hubmib@hprnd.rose.hp.com Subject: Re: (Almost) Last Call (MAU MIB Draft 02) In-Reply-To: Your message of "Tue, 11 Jun 1996 11:46:00 EDT." <9606111546.AA04464@pe2k3.hpn.lkg.dec.com> Date: Wed, 12 Jun 1996 15:16:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Flick >Dan, > >On behalf of Arvind and myself I would like to summarize our position >on the behavior of ifMauType in MAU MIB Draft 02. We propose that the >MAU MIB draft be modified to split the current functions of ifMauType >between two different MIB objects. One MIB object reports the >currently used MAU technology while the other MIB object manually >selects the default MAU type to be used when auto-negotiation is not >functioning. Such MIB objects might be named: > > ifMauCurrentType - read-only > ifMauDefaultType - read-write I think I agree with this, with the exception that it seems that the existing ifMauType could be used as ifMauCurrentType. I don't think this changes the RFC 1515 meaning of ifMauType, since in pre-802.3u implementations, the ifMauType was fixed. Therefore ifMauType was always the current MAU type. I am really uncomfortable with the idea of making ifMauType read-write, and I'm not sure it is kosher from the SMI point of view. (Any comments from directorate folks?) John   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07549; 13 Jun 96 0:43 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07545; 13 Jun 96 0:43 EDT Received: from hp.com by CNRI.Reston.VA.US id aa01639; 13 Jun 96 0:43 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA257920442; Wed, 12 Jun 1996 21:34:03 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA192170306; Wed, 12 Jun 1996 21:31:46 -0700 Received: from mail.madge.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA254820305; Wed, 12 Jun 1996 21:31:45 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Wed, 12 Jun 96 14:47:13 -0800 Message-Id: Date: Wed, 12 Jun 96 12:01:07 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com Subject: Hub MIB Call for Consensus X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway This is a call for consensus of the WG for proposing that the Internet Draft 'draft-ietf-hubmib-repeater-dev-02.txt' will be advanced to the NMArea Directorate in order to become a Proposed Standard. If you have serious technical or other kind of concerns related to this proposal, please express them on the mailing list. Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12698; 13 Jun 96 6:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12694; 13 Jun 96 6:39 EDT Received: from hp.com by CNRI.Reston.VA.US id aa05749; 13 Jun 96 6:39 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA253971895; Thu, 13 Jun 1996 03:31:36 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA208401789; Thu, 13 Jun 1996 03:29:49 -0700 Received: from mail.madge.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA252701787; Thu, 13 Jun 1996 03:29:47 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Wed, 12 Jun 96 14:47:04 -0800 Message-Id: In-Reply-To: <6866BE3101660C00> Date: Wed, 12 Jun 96 11:48:35 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: "------------------------------------------\ ------------------------" Cc: arvind@dechub.lkg.dec.com, hubmib@hprnd.rose.hp.com Subject: Re: (Almost) Last Call (MAU MIB Draft 02) X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway We will delay the last call for the MAU MIB until we reach consensus on this subject. To address the specific subject that you are raising, I would observe the following: 1. The change you propose also implies that ifMauType needs to be deprecated. It still needs to be kept inside the MIB, for the purpose of backward compatibility with existing implementations of RFC 1515. 2. I do agree that the solution you propose looks more complete from an operational point of view. However, it does not conform with the management interface proposed by the IEEE standard. I further wonder if by following your proposal we do not imply a behavior that is not necessarely the one the standard mandates. Are you sure that by writing in the standard that 'When Auto-Negociation is enabled, bit 0.13 can be read or written', the authors mandated that a MAUs MUST present a management interface that allows for this? Further, why do you think that the quotation you provide describes the behavior in the case of transition from Auto-Negociation ON to OFF? It looks to me that the IEEE standard was on purpose vague and avoided clearly solving the issue. I can see no practical value for the behavior you describe. When I change the Auto-Negociation from ON to OFF I might not want to see a simultaneous change in speed, if this happens the link was unfunctional either before or after the transition. The logical think to do is to keep the last value that was decided by Auto-Negociation, which should be the functional speed on the link and further allow for changes by manual programming (that's why you put the Auto Negociation OFF). I would be glad to hear more opinions either from implementors or from people that were involved in the IEEE MAU standard writing. >4. The behavior of ifMauType as defined in MAU MIB Draft 02 seems > awkward because, effectively, the MAX-ACCESS of the object changes > depending upon the value (or presence) of an object in a different > MIB group (i.e. ifMauAutoNegAdminStatus). > > - While this my not violate SMI, this doesn't seem to be the > preferred method to define a MIB object. Does anybody else think that there is a problem with this approach? Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29415; 14 Jun 96 13:45 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29411; 14 Jun 96 13:45 EDT Received: from hp.com by CNRI.Reston.VA.US id aa14487; 14 Jun 96 13:45 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA071823552; Fri, 14 Jun 1996 10:32:32 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA112213530; Fri, 14 Jun 1996 10:32:11 -0700 Received: from mail13.digital.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA093553528; Fri, 14 Jun 1996 10:32:08 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id JAA06237; Fri, 14 Jun 1996 09:09:37 -0400 (EDT) Received: from tayhub.dechub.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA26248; Fri, 14 Jun 1996 09:09:15 -0400 Received: from pe2k3.hpn.lkg.dec.com by tayhub.dechub.lkg.dec.com with SMTP id AA23432; Fri, 14 Jun 1996 09:09:08 -0400 Received: by pe2k3.hpn.lkg.dec.com (5.65/4.7) id AA06752; Fri, 14 Jun 1996 09:07:35 -0400 Message-Id: <9606141307.AA06752@pe2k3.hpn.lkg.dec.com> To: dromasca@madge.com Cc: pagliaro@dechub.lkg.dec.com, arvind@dechub.lkg.dec.com, hubmib@hprnd.rose.hp.com Subject: Re: (Almost) Last Call (MAU MIB Draft 02) In-Reply-To: Your message of "Wed, 12 Jun 96 11:48:35 +0300." X-Mailer: exmh version 1.5beta 8/10/94 Date: Fri, 14 Jun 96 09:07:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ------------------------------------------------------------------ Dan, >> 1. The change you propose also implies that ifMauType needs to be >> deprecated. It still needs to be kept inside the MIB, for the >> purpose of backward compatibility with existing implementations >> of RFC 1515. Not necessarily. As John Flick suggested, we can make ifMauType read-only and use that object as the "ifMauCurrentType" object. This preserves the RFC 1515 meaning of ifMauType better than the current draft. It is also consistent with a read-only rpMauType. >> >> 2. I do agree that the solution you propose looks more complete >> from an operational point of view. However, it does not conform >> with the management interface proposed by the IEEE standard. I >> further wonder if by following your proposal we do not imply a >> behavior that is not necessarely the one the standard >> mandates. Yes the solution proposed by Arvind and myself does not strictly conform to the layer management interface described in section 30 of the IEEE standard. Does the IETF require such absolute conformance? The behavior currently described by DRAFT 02 also does not strictly conform to that mandated by the IEEE. Draft 02 states that when Auto-Negotiation is operational, ifMauType can only be set to its current value. Sets of this object to any other value are to be ignored. According to the IEEE spec, mauTypeList defines the set of values to which mauType can be set (with no conditions on the operational state of Auto-Negotiation). The IEEE also mandates that a set to mauType when Auto-Negotiation is operable should result in the side effect of modifying the auto-negotiation advertised capability and forcing a link re-negotiation. As IEEE 802.3u section 30.5.1.1.2 states: "A SET operation [of aMAUType] to one of the possible enumerations indicated by aMAUTypeList will force the MAU into the new operating mode. ...If clause 28, Auto-Negotiation, is operational, then this will change the advertised ability to the single enumeration specified in the SET operation, and cause an immediate link renegotiation." If conformance to IEEE is required, what level of conformance is needed? >> Are you sure that by writing in the standard that 'When >> Auto-Negociation is enabled, bit 0.13 can be read or >> written', the authors mandated that a MAUs MUST present a >> management interface that allows for this? I did not intend to assert that MAU Layer Management (clause 30) MUST directly map to the MII Management function hardware interface (clause 22). I AM interested in knowing why they do conflict. I first raised this issue with Kathy deGraaf in early May. She forwarded the questions on to Geoff Thompson, chair of the 802.3u working group, and Paul Woodruff. I never received a response back. >> Further, why do you think that the quotation you provide >> describes the behavior in the case of transition from >> Auto-Negociation ON to OFF? It looks to me that the IEEE >> standard was on purpose vague and avoided clearly solving the >> issue. I agree that the Layer Management specification of the auto-negotiation transition from ON to OFF is vague. However I feel that the MII Management Function specification is quite explicit. To repeat section 22.2.4.1.4, "If bit 0.12 is cleared to a logic zero, then bits 0.13 and 0.8 will determine the link configuration, REGARDLESS OF THE PRIOR STATE OF THE LINK CONFIGURATION AND THE AUTO-NEGOTIATION PROCESS." It seems clear, to me anyway, that in the transition of auto-negotiation from ON to OFF, the prior auto-negotiated link configuration is disregarded and the manual speed and duplex mode register bit settings dictate the link configuration (and therefore the MAU type). This is consistent with my experiences with one vendor's PHY chip implementation. Will you please tell me specifically what you find vague about this so that I may better understand your point of view? >> I can see no practical value for the behavior you describe. When >> I change the Auto-Negociation from ON to OFF I might not want >> to see a simultaneous change in speed, if this happens the link >> was unfunctional either before or after the transition. The >> logical think to do is to keep the last value that was decided >> by Auto-Negociation, which should be the functional speed on the >> link and further allow for changes by manual programming (that's >> why you put the Auto Negociation OFF). The ability to unambiguously define the MAU type to be used after auto-negotiation is disabled can be very practical. An issue with the behavior described by Draft 02 is the case where auto-negotiation is disabled before the auto-negotiation process completed successfully. This can happen when link partners are not advertising common capabilities (or there is no link partner). What type of MAU should then be used? The behavior I described addresses this issue. The behavior I describe is flexible enough so that I don't have to try to predict what a user might and might not want to do. It is true that some users might not want to see a simultaneous change in speed, but some might want to see that simultaneous change (see above). The behavior I describe is flexible enough to accommodate either case because the user can always set the manual/default configuration to the current auto-negotiated settings before disabling auto-negotiation. No loss of service need occur. >> I would be glad to hear more opinions either from implementors or from >> people that were involved in the IEEE MAU standard writing. I would also like to hear from someone involved in the IEEE MAU standard writing. (For what it's worth, I am an implementor). Regards. ------------------------------------------------------------------ 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 ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29303; 20 Jun 96 15:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29299; 20 Jun 96 15:52 EDT Received: from hp.com by CNRI.Reston.VA.US id aa15826; 20 Jun 96 15:52 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA112079521; Thu, 20 Jun 1996 12:38:42 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA266859497; Thu, 20 Jun 1996 12:38:17 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA006899496; Thu, 20 Jun 1996 12:38:16 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Thu, 20 Jun 96 11:50:36 -0800 Message-Id: Date: Thu, 20 Jun 96 7:44:55 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: kostick@qsun.ho.att.com Cc: hubmib@hprnd.rose.hp.com Subject: Hub MIB to Proposed Standard X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Deidre, The IEEE 802.3 Repeater MIB WG reached consensus to propose that the Internet Draft 'draft-ietf-hubmib-repeater-dev-02.txt' be advanced as a Proposed Standard. Please take the appropriate actions as NMArea Director in order to receive the necessary IESG approvals. We respectfully request a few extra weeks in order to reach the final consensus regarding the two other pending working items of the WG: - the MAU MIB - the Extensions to the Ethernet-like Interfaces MIB for 100 M Ethernet Best Regards, Dan Romascanu, IEEE 802.3 Repeater MIB WG Chair, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02626; 20 Jun 96 17:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02622; 20 Jun 96 17:26 EDT Received: from hp.com by CNRI.Reston.VA.US id aa17710; 20 Jun 96 17:26 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA237235176; Thu, 20 Jun 1996 14:12:56 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA275425166; Thu, 20 Jun 1996 14:12:47 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA274805601; Thu, 20 Jun 1996 14:20:01 -0700 Message-Id: <199606202120.AA274805601@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com Subject: TopN Table Date: Thu, 20 Jun 1996 14:20:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Flick I just spent the last 2 days implementing the rptrTopNPortInfo group and had a few comments. I realize that this is a bit late, given that we have already issued our recommendation to the AD to advance the current draft. However, there are some things you don't find until you actually start implementing. Also, the AD will most likely appoint someone from the directorate to review the draft. This typically results in some review comments and a new I-D which is then forwarded on to the IESG. I suggest that these comments could be rolled in with the directorate review comments. 1. The MIB doesn't specify what happens when the repeater specified by rptrTopNPortRepeaterId in an active row goes away. This can happen in systems where a group may have segments that can be isolated or attached to the backplane. For example, if you have an existing, active entry in the table, and set rptrTopNPortTimeRemaining to initiate a new report, and discover the specified repeater no longer exists, what is the expected behaviour? Does it nuke the row? Move it to notInService? Generate an empty report? (I'd say nuke the row. This is consistent with the behaviour of the RMON alarm table when it discovers that the monitored variable is no longer accessible.) 2. What happens when rptrTopNPortRemaining is set to zero when there is a running report? I assume the running report is aborted, but the MIB doesn't say. 3. What value should be returned for rptrTopNPortStartTime before any reports have been requested for the entry? I assume 0, but I suppose it could also be noSuchInstance. The MIB doesn't say. 4. What happens to the associated entries in the rptrTopNPortTable when a control table entry leaves the 'active' state (to 'destroy' or 'notInService')? I assume they are deleted, since this would be consistent with the definition of the RMON hostTopN group in RFC 1757. However, the MIB should probably state this (and could probably just use the text from the description of hostTopNStatus in 1757). For the most part, these issues are just clarifications of places where things are not clearly specified in the draft. However, they could lead to interoperability problems unless they are clarified. John   Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07093; 23 Jun 96 2:09 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07089; 23 Jun 96 2:09 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa02219; 23 Jun 96 2:09 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA179009294; Sat, 22 Jun 1996 22:54:54 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA021089251; Sat, 22 Jun 1996 22:54:12 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA178779251; Sat, 22 Jun 1996 22:54:11 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Sat, 22 Jun 96 22:45:10 -0800 Message-Id: <08EACC3101660C00@mail.madge.com> In-Reply-To: Date: Sun, 23 Jun 96 8:39:05 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: hubmib@hprnd.rose.hp.com, John Flick Subject: Re: TopN Table X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway John, My guesses are very close to yours. We probably assumed similarity with the RMON MIB behavior, but some more explanatory text would not harm. I assume we can catch those in the review period. Deidre just sent me a mail that says that somebody will be noninated to make a technical review of this work. I sugest that you, Kathy, Leon and other people from the group who are interested, meet unformally in Montreal to try to reach agreement on those and on the other pending items, especially those from the MAU MIB. Unfortunately, I will not be at this IETF - breaking my nice 14 consecutive meetings recors - but I am sure you all will work successfully to reach agreement. To all of you, have a good IETF meeting, Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----