Received: from ietf.org by ietf.org id aa01182; 6 Aug 96 2:04 EDT Received: from cnri by ietf.org id aa01178; 6 Aug 96 2:04 EDT Received: from hp.com by CNRI.Reston.VA.US id aa02234; 6 Aug 96 2:04 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA115130951; Mon, 5 Aug 1996 22:55:51 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA205770932; Mon, 5 Aug 1996 22:55:32 -0700 Received: from megamegs.decisive.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA285390928; Mon, 5 Aug 1996 22:55:29 -0700 Received: from jamie.decisive.com ([206.171.43.189]) by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889) with SMTP id AAA149 for ; Mon, 5 Aug 1996 22:09:59 -0700 Received: by jamie.decisive.com with Microsoft Mail id <01BB8321.23A7CEA0@jamie.decisive.com>; Mon, 5 Aug 1996 22:55:03 -0700 Message-Id: <01BB8321.23A7CEA0@jamie.decisive.com> Sender:ietf-archive-request@ietf.org From: Network Education Center To: "'hubmib@hprnd.rose.hp.com.'" Subject: Survey on Continuing Education for Network Computing Professionals Date: Mon, 5 Aug 1996 18:30:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This survey is on behalf of an education center dedicated to the needs = of network computing professionals. We are asking your input to help us = create better education/training programs for you and your company. Your = responses will be completely confidential. If we receive your completed survey by Monday, August 12, 1996, we'll = automatically enter you in a contest for a prize of $1,000; one winner = will be chosen from among those who complete the survey. Thank you in = advance for your help.=20 (Authentication marker -- ~3%e%INTCADX%8%1%750%5CTJVlfE%39197& -- do not = remove.)=20 To respond, create a reply e-mail message that contains the survey. = Some e-mail systems require you to manually copy and paste the survey = into your reply. Make sure the reply contains the *entire* = authentication marker, including what looks like garbage. To answer a question, type an x between the brackets, like this: [ x ]. = For fill-in-the-blanks, type between the brackets like this: [ your = response ]. Please make no other changes to this survey. 1. If for any reason you do NOT want to be contacted in the future via = e-mail, please indicate after the first question by placing an "x" = within the brackets. You will be omitted from future e-mail surveys. [ ] a) Please omit me from future e-mail surveys. 2. What is your company's PRIMARY industry or business? Choose one: [ ] a) Aerospace [ ] b) Communications carrier (telco, broadband, internet) [ ] c) Financial services [ ] d) Healthcare [ ] e) Manufacturing: computer/software [ ] f) Manufacturing: non-computer [ ] g) Government/military [ ] h) Publishing/media/advertising/public relations [ ] i) Transportation/utilities [ ] j) Wholesale/retail: non-computer [ ] k) Education [ ] l) Entertainment [ ] m) Computer reseller/retailer/VAR [ ] n) Systems integration/consulting [ ] o) Other, please specify... [ ] 3. What is your job function? Choose one: [ ] a) IS/MIS/Data processing [ ] b) LAN/network systems [ ] c) Internet/Web [ ] d) Intranet (in-TRA-net) [ ] e) Data communications/telecommunications [ ] f) PC/microcomputer/information center [ ] g) Systems analyst/applications development [ ] h) Systems engineer/integration [ ] i) Other computer-related, please specify... [ ] [ ] j) Executive/corporate office [ ] k) Financial/accounting [ ] l) Engineering/R&D [ ] m) Sales/marketing [ ] n) Other administrative, please specify... [ ] [ ] o) Consulting (computer related) [ ] p) Training/education [ ] q) Other professional, please specify... [ ] 4. Please check the statements below that describe your involvement = with networks. Choose all that apply: [ ] a) I manage networks. [ ] b) I design networks. [ ] c) I install networks. [ ] d) I troubleshoot/fix networks. [ ] e) I train or support network users. [ ] f) I initiate the evaluation of new network technologies. [ ] g) I evaluate or specify brands of network products. [ ] h) I ensure that networks meet specific business or = organizational objectives. 5. What is the scope of your involvement with networking in your = organization? Choose one: [ ] a) Entire organization or enterprise [ ] b) Entire work location [ ] c) Multiple departments at more than one location [ ] d) For a single department only [ ] e) Other 6. How many servers do you have installed in your organization? Choose one: [ ] a) Over 50 [ ] b) 10 to 49 [ ] c) 1 to 9 [ ] d) None 7. How many LANS do you have installed in your organization? Choose one: [ ] a) Over 25 [ ] b) 5 to 24 [ ] c) 1 to 4 [ ] d) None 8. How many microcomputers/workstations are connected to LANS in your = organization? Choose one: [ ] a) 500 or more [ ] b) 25 to 499 [ ] c) 1 to 24 [ ] d) None 9. How many employees do you supervise? Choose one: [ ] a) Up to 3 people [ ] b) 4 to 10 people [ ] c) More than 10 people [ ] d) None 10. Do you yourself have responsibility for networking = education/training provided to employees in your company? Choose one: [ ] a) Yes [ ] b) No [ ] c) Don't know 11. What is the annual budget for education/training for yourself and = those you supervise? Please enter the amount within the following brackets. [ ] 12. During the last 12 months, where did you or those you supervise = receive education/training for networking? Choose all that apply: [ ] a) In-house [ ] b) University/college [ ] c) Seminars [ ] d) Internet [ ] e) Other [ ] f) No education/training on networking was received NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON = NETWORKING TECHNOLOGIES. For each of the following 10 course = descriptions, please indicate your level of interest. 13. A Network Technologies course covering circuits and fibers; = modulation and modems; LANs; WANs; frames; cell switching; wireless; = satellites; connection-oriented and connectionless service; = characteristics of each technology; addressing; media access; = comparisons. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 14. A Network Interconnection and Internetworking course covering = interconnection technologies; repeaters, bridges, and routers; internet = addressing; address binding; datagram forwarding; techniques to = accomodate heterogeneity (e.g. encapsulation and fragmentation). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 15. A Network Protocols and Protocol Design course covering protocol = layering; problems protocols solve; loss, reordering, corruption, = congestion, duplication, and replay; techniques such as framing, = checksumming, sliding window, and retransmission; focus on the transport = layer, but cover other layers. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 16. A Routing and Routing Protocols course covering packet forwarding; = route propagation; vector-distance and link-state algorithms; spanning = tree. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 17. A Distributed Programming and Applications course covering = client-server paradigm; socket API; middleware (e.g. RPC and CORBA); = building a server; multithread server execution; protection and = authorization; example applications. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 18. A Network and Protocol Performance Evaluation course covering = throughput and delay; measuring and tuning protocols; instrumentation of = protocol stacks; traffic analysis; self-similar behavior. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 19. A Networking and Protocol Support for Multimedia Applications = course covering high-speed networks; resource allocation and performance = guarantees; protocols for audio and video; techniques such as = compression and delayed playback. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 20. An Advanced Server Design and Implementation course covering = implementation of concurrent, parallel servers; large-scale designs; = proxy servers (e.g., SLIRP); techniques such as buffering, replication, = caching, and application gateways. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 21. An Advanced Routing course covering policy-based routing; = multicast; mobility; inter- and intra-layer encapsulation; longest = prefix forwarding table lookup algorithms; virtual LANS. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 22. An Advanced Network Applications course covering EDI; electronic = commerce; advanced Web techniques (e.g. Java). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 23. What would your level of interest be in taking a group of these = courses as a coordinated curriculum? Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF = EDUCATION PROGRAMS that could be made available for networking = technologies, please indicate which of the following would be important = to you. 24. A course curriculum leads to an advanced college degree. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 25. Each course generates a document of professional certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 26. Course curriculum leads to an overall certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 27. Course is available at your place of work. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 28. Course is available at a local university or college campus. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 29. Courses available at an industry event you already attend. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 30. Courses conducted by an advanced educational institute staffed by = networking experts. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 31. A core curriculum of a specified number of courses that would = follow a building educational sequence. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 32. A concentrated face-to-face education program conducted over = consecutive days. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 33. Ability to take class lessons, labs and tests over the Internet = from your desktop. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 34. What other thoughts do you have concerning what could be done to = improve educational or training programs on networking technologies? Please write within the brackets. [ ] 35. How many years have you been professionally involved in computing? Choose one: [ ] a) Less than 2 years [ ] b) 2 to 4 years [ ] c) 5 to 10 years [ ] d) More than 10 years 36. Which of the following ranges includes your age? Choose one: [ ] a) 18 to 34 [ ] b) 35 to 44 [ ] c) 45 to 54 [ ] d) 55 and older 37. Which of the following represents your highest level of education? Choose one: [ ] a) Attended high school [ ] b) Graduated high school [ ] c) Attended college [ ] d) Bachelor's degree [ ] e) Master's degree [ ] f) Doctorate degree 38. What do you estimate your total household income was last year? = (Please estimate total income for everyone in your household, including = salaries, wages, bonuses, interest, dividends, etc.) Choose one: [ ] a) Less than $15,000 [ ] b) $15,000 to $24,999 [ ] c) $25,000 to $34,999 [ ] d) $35,000 to $49,999 [ ] e) $50,000 to $74,999 [ ] f) $75,000 to $99,999 [ ] g) $100,000 to $149,999 [ ] h) $150,000 or more [ ] i) Don't know Thank you for participating in this survey.   Received: from ietf.org by ietf.org id aa01192; 6 Aug 96 2:05 EDT Received: from cnri by ietf.org id aa01188; 6 Aug 96 2:05 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa02258; 6 Aug 96 2:05 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA285420929; Mon, 5 Aug 1996 22:55:29 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA205740910; Mon, 5 Aug 1996 22:55:10 -0700 Received: from megamegs.decisive.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA285090907; Mon, 5 Aug 1996 22:55:07 -0700 Received: from jamie.decisive.com ([206.171.43.189]) by megamegs.decisive.com (post.office MTA v1.9.3 ID# 0-12889) with SMTP id AAA64 for ; Mon, 5 Aug 1996 22:09:37 -0700 Received: by jamie.decisive.com with Microsoft Mail id <01BB8321.185CB970@jamie.decisive.com>; Mon, 5 Aug 1996 22:54:44 -0700 Message-Id: <01BB8321.185CB970@jamie.decisive.com> Sender:ietf-archive-request@ietf.org From: Network Education Center To: "'hubmib@hprnd.rose.hp.com'" Subject: Survey on Continuing Education for Network Computing Professionals Date: Mon, 5 Aug 1996 18:30:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This survey is on behalf of an education center dedicated to the needs = of network computing professionals. We are asking your input to help us = create better education/training programs for you and your company. Your = responses will be completely confidential. If we receive your completed survey by Monday, August 12, 1996, we'll = automatically enter you in a contest for a prize of $1,000; one winner = will be chosen from among those who complete the survey. Thank you in = advance for your help.=20 (Authentication marker -- ~3%e%INTCADX%8%1%749%5CTJVlfE%4873& -- do not = remove.)=20 To respond, create a reply e-mail message that contains the survey. = Some e-mail systems require you to manually copy and paste the survey = into your reply. Make sure the reply contains the *entire* = authentication marker, including what looks like garbage. To answer a question, type an x between the brackets, like this: [ x ]. = For fill-in-the-blanks, type between the brackets like this: [ your = response ]. Please make no other changes to this survey. 1. If for any reason you do NOT want to be contacted in the future via = e-mail, please indicate after the first question by placing an "x" = within the brackets. You will be omitted from future e-mail surveys. [ ] a) Please omit me from future e-mail surveys. 2. What is your company's PRIMARY industry or business? Choose one: [ ] a) Aerospace [ ] b) Communications carrier (telco, broadband, internet) [ ] c) Financial services [ ] d) Healthcare [ ] e) Manufacturing: computer/software [ ] f) Manufacturing: non-computer [ ] g) Government/military [ ] h) Publishing/media/advertising/public relations [ ] i) Transportation/utilities [ ] j) Wholesale/retail: non-computer [ ] k) Education [ ] l) Entertainment [ ] m) Computer reseller/retailer/VAR [ ] n) Systems integration/consulting [ ] o) Other, please specify... [ ] 3. What is your job function? Choose one: [ ] a) IS/MIS/Data processing [ ] b) LAN/network systems [ ] c) Internet/Web [ ] d) Intranet (in-TRA-net) [ ] e) Data communications/telecommunications [ ] f) PC/microcomputer/information center [ ] g) Systems analyst/applications development [ ] h) Systems engineer/integration [ ] i) Other computer-related, please specify... [ ] [ ] j) Executive/corporate office [ ] k) Financial/accounting [ ] l) Engineering/R&D [ ] m) Sales/marketing [ ] n) Other administrative, please specify... [ ] [ ] o) Consulting (computer related) [ ] p) Training/education [ ] q) Other professional, please specify... [ ] 4. Please check the statements below that describe your involvement = with networks. Choose all that apply: [ ] a) I manage networks. [ ] b) I design networks. [ ] c) I install networks. [ ] d) I troubleshoot/fix networks. [ ] e) I train or support network users. [ ] f) I initiate the evaluation of new network technologies. [ ] g) I evaluate or specify brands of network products. [ ] h) I ensure that networks meet specific business or = organizational objectives. 5. What is the scope of your involvement with networking in your = organization? Choose one: [ ] a) Entire organization or enterprise [ ] b) Entire work location [ ] c) Multiple departments at more than one location [ ] d) For a single department only [ ] e) Other 6. How many servers do you have installed in your organization? Choose one: [ ] a) Over 50 [ ] b) 10 to 49 [ ] c) 1 to 9 [ ] d) None 7. How many LANS do you have installed in your organization? Choose one: [ ] a) Over 25 [ ] b) 5 to 24 [ ] c) 1 to 4 [ ] d) None 8. How many microcomputers/workstations are connected to LANS in your = organization? Choose one: [ ] a) 500 or more [ ] b) 25 to 499 [ ] c) 1 to 24 [ ] d) None 9. How many employees do you supervise? Choose one: [ ] a) Up to 3 people [ ] b) 4 to 10 people [ ] c) More than 10 people [ ] d) None 10. Do you yourself have responsibility for networking = education/training provided to employees in your company? Choose one: [ ] a) Yes [ ] b) No [ ] c) Don't know 11. What is the annual budget for education/training for yourself and = those you supervise? Please enter the amount within the following brackets. [ ] 12. During the last 12 months, where did you or those you supervise = receive education/training for networking? Choose all that apply: [ ] a) In-house [ ] b) University/college [ ] c) Seminars [ ] d) Internet [ ] e) Other [ ] f) No education/training on networking was received NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON = NETWORKING TECHNOLOGIES. For each of the following 10 course = descriptions, please indicate your level of interest. 13. A Network Technologies course covering circuits and fibers; = modulation and modems; LANs; WANs; frames; cell switching; wireless; = satellites; connection-oriented and connectionless service; = characteristics of each technology; addressing; media access; = comparisons. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 14. A Network Interconnection and Internetworking course covering = interconnection technologies; repeaters, bridges, and routers; internet = addressing; address binding; datagram forwarding; techniques to = accomodate heterogeneity (e.g. encapsulation and fragmentation). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 15. A Network Protocols and Protocol Design course covering protocol = layering; problems protocols solve; loss, reordering, corruption, = congestion, duplication, and replay; techniques such as framing, = checksumming, sliding window, and retransmission; focus on the transport = layer, but cover other layers. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 16. A Routing and Routing Protocols course covering packet forwarding; = route propagation; vector-distance and link-state algorithms; spanning = tree. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 17. A Distributed Programming and Applications course covering = client-server paradigm; socket API; middleware (e.g. RPC and CORBA); = building a server; multithread server execution; protection and = authorization; example applications. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 18. A Network and Protocol Performance Evaluation course covering = throughput and delay; measuring and tuning protocols; instrumentation of = protocol stacks; traffic analysis; self-similar behavior. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 19. A Networking and Protocol Support for Multimedia Applications = course covering high-speed networks; resource allocation and performance = guarantees; protocols for audio and video; techniques such as = compression and delayed playback. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 20. An Advanced Server Design and Implementation course covering = implementation of concurrent, parallel servers; large-scale designs; = proxy servers (e.g., SLIRP); techniques such as buffering, replication, = caching, and application gateways. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 21. An Advanced Routing course covering policy-based routing; = multicast; mobility; inter- and intra-layer encapsulation; longest = prefix forwarding table lookup algorithms; virtual LANS. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 22. An Advanced Network Applications course covering EDI; electronic = commerce; advanced Web techniques (e.g. Java). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 23. What would your level of interest be in taking a group of these = courses as a coordinated curriculum? Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF = EDUCATION PROGRAMS that could be made available for networking = technologies, please indicate which of the following would be important = to you. 24. A course curriculum leads to an advanced college degree. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 25. Each course generates a document of professional certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 26. Course curriculum leads to an overall certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 27. Course is available at your place of work. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 28. Course is available at a local university or college campus. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 29. Courses available at an industry event you already attend. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 30. Courses conducted by an advanced educational institute staffed by = networking experts. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 31. A core curriculum of a specified number of courses that would = follow a building educational sequence. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 32. A concentrated face-to-face education program conducted over = consecutive days. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 33. Ability to take class lessons, labs and tests over the Internet = from your desktop. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 34. What other thoughts do you have concerning what could be done to = improve educational or training programs on networking technologies? Please write within the brackets. [ ] 35. How many years have you been professionally involved in computing? Choose one: [ ] a) Less than 2 years [ ] b) 2 to 4 years [ ] c) 5 to 10 years [ ] d) More than 10 years 36. Which of the following ranges includes your age? Choose one: [ ] a) 18 to 34 [ ] b) 35 to 44 [ ] c) 45 to 54 [ ] d) 55 and older 37. Which of the following represents your highest level of education? Choose one: [ ] a) Attended high school [ ] b) Graduated high school [ ] c) Attended college [ ] d) Bachelor's degree [ ] e) Master's degree [ ] f) Doctorate degree 38. What do you estimate your total household income was last year? = (Please estimate total income for everyone in your household, including = salaries, wages, bonuses, interest, dividends, etc.) Choose one: [ ] a) Less than $15,000 [ ] b) $15,000 to $24,999 [ ] c) $25,000 to $34,999 [ ] d) $35,000 to $49,999 [ ] e) $50,000 to $74,999 [ ] f) $75,000 to $99,999 [ ] g) $100,000 to $149,999 [ ] h) $150,000 or more [ ] i) Don't know Thank you for participating in this survey.   Received: from ietf.org by ietf.org id aa03021; 16 Aug 96 17:45 EDT Received: from cnri by ietf.org id aa03017; 16 Aug 96 17:45 EDT Received: from paloalto.access.hp.com by CNRI.Reston.VA.US id aa14771; 16 Aug 96 17:45 EDT Received: from hprnd.rose.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA027971265; Fri, 16 Aug 1996 14:34:26 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA268211204; Fri, 16 Aug 1996 14:33:25 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA161991744; Fri, 16 Aug 1996 14:42:24 -0700 Message-Id: <199608162142.AA161991744@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com Subject: Search address patent RFC Date: Fri, 16 Aug 1996 14:42:24 -0700 Sender:ietf-archive-request@ietf.org From: John Flick For those not on the ietf-announce list, the following was just sent. The patent hurdle is now officially cleared. 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 AA159350030; Fri, 16 Aug 1996 14:13:51 -0700 Return-Path: Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA265759489; Fri, 16 Aug 1996 14:04:49 -0700 Received: from ietf.org by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA273999485; Fri, 16 Aug 1996 14:04:45 -0700 Received: from ietf.org by ietf.org id aa17603; 16 Aug 96 11:12 EDT Received: from zephyr.isi.edu by ietf.org id aa17588; 16 Aug 96 11:11 EDT Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Fri, 16 Aug 1996 08:11:31 -0700 Message-Id: <199608161511.AA00152@zephyr.isi.edu> To: IETF-Announce:;@ietf.org Subject: RFC1988 on Search Address Patent Use Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 16 Aug 96 08:14:11 PDT Sender: ietf-announce-request@ietf.org From: RFC Editor - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1988: Title: Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework Author: G. McAnally, D. Gilbert & J. Flick Date: August 1996 Mailbox: johnf@hprnd.rose.hp.com Pages: 2 Characters: 3,821 Updates/Obsoletes: none URL: ftp://ds.internic.net/rfc/rfc1988.txt This document is NOT a standard. It is an announcement to interested parties of a conditional grant by the Hewlett-Packard Company (HP) of certain rights to use autotopology network management technology covered by specific HP patents in conjunction with the Internet Engineering Task Force's (IETF's) Internet-standard network management framework. This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. HP is offering this search address technology to the IETF as a technique for mapping network devices. It should be noted that the confirmatory license mentioned is optional, since the grant of rights is automatic. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - --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: <960816081109.RFC@ISI.EDU> SEND /rfc/rfc1988.txt - --OtherAccess Content-Type: Message/External-body; name="rfc1988.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <960816081109.RFC@ISI.EDU> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message   Received: from ietf.org by ietf.org id aa12541; 22 Aug 96 16:17 EDT Received: from cnri by ietf.org id aa12537; 22 Aug 96 16:17 EDT Received: from hpcsos.col.hp.com by CNRI.Reston.VA.US id aa13229; 22 Aug 96 16:17 EDT Received: from hprnd.rose.hp.com by hpcsos.col.hp.com with ESMTP (1.37.109.16/15.5+IOS 3.14) id AA246444544; Thu, 22 Aug 1996 14:09:04 -0600 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA251714416; Thu, 22 Aug 1996 13:06:56 -0700 Received: from ISD.3Com.com (chipcom.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA222894323; Thu, 22 Aug 1996 13:05:23 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA13084; Thu, 22 Aug 96 16:02:15 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA8480; Thu, 22 Aug 96 16:03:16 -0700 Message-Id: <9608222303.AA8480@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 4FD085CD0E3B42B48525638E006A679A; Thu, 22 Aug 96 16:03:16 EDT To: hubmib Sender:ietf-archive-request@ietf.org From: Kathy deGraaf/US/3Com Date: 22 Aug 96 16:06:43 EDT Subject: Re: [Fwd: Hub MIB to Proposed Standard] Mime-Version: 1.0 Content-Type: Text/Plain Hi all, It has been pointed out, to my chagrin, that Bob sent his comments on the repeater MIB only to me, and didn't copy the list. I've appended his mail below. My sincere apologies for missing this and for not forwarding it sooner. I also have the agreed-upon updates to the MAU MIB in the pipe, and will be sending them to the list in the next day or so. Bob brought up some items that we should discuss. I can't recall now why we included a separate integer for indexing the various source addresses seen on a particular port (rptrExtAddrTrackTable)...why not index off the MAC address itself? As far as correlation between indices and MAC addresses in the table entries, I'm not sure it's an issue. I would expect an application to download the entire set of addresses for a particular port at one time, or, if we index it off of MAC address, to ask whether a particular address was seen on a port. I can't see the need for the integer index for a particular MAC address to be consistent over time. We have no lock or owner string on the rptrAddrTrackReset object, so maybe we need to highlight the fact that resetting the table isn't necessarily friendly in a multiple-manager situation. Do we need a lock/owner after all? I agree with the suggested name change to the topNPortRateBase. I can easily change the "restart version" wording, unless anyone is particularly attached to it? Any suggestions for substitute wording? I'm comfortable with the presence of so many optional functions...do we agree on this, as a group? It doesn't seem like as big an issue as it has been in the past, since there is more precedent for it these days (as Bob points out). --Kathy To: Kathy_deGraaf/US/3Com%3COM @ smtp1.isd.3com.com @ SMTP1 cc: kostick @ qsun.att.com @ SMTP1 From: bstewart @ cisco.com (Bob Stewart) @ SMTP1 Date: Thursday July 11, 1996 02:59 PM Subject: Re: [Fwd: Hub MIB to Proposed Standard] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Circa 5:30 PM -0400 7/9/96, Kathy deGraaf/US/3Com bitwhacked: >The latest draft is draft-ietf-hubmib-repeater-dev-02.txt and is dated May 14. >It should be in the Internet-Drafts directory. Got it. Here's my official review on behalf of the NM Area Director. I copied Deirdre so she can see that I did it and get the flavor of my comments. > goto try_again Tsk, tsk, tsk. A goto. Shameful. I forgot C allowed such things. > rptrExtAddrTrackMacIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The index of a source MAC address seen on > the port." > ::= { rptrExtAddrTrackEntry 1 } I assume that the relationship of this index and a given MAC address can't change without an indication of discontinuity. If that's true, it should probably say that here. If it's not, there's at least awkwardness with using the table. > rptrAddrTrackReset OBJECT-TYPE > SYNTAX INTEGER { > noReset(1), > reset(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Setting this object to reset(2) causes > the agent to empty the contents of the > rptrExtAddrTrackTable. The contents of > the rptrAddrTrackTable are not affected. > > Setting this object to noReset(1) has no effect. > The agent will always return the value noReset(1) > when this object is read." > ::= { rptrAddrTrackPortInfo 3 } Hmmmm. A built-in discontinuity creator. Ahhhh. I was about to complain about multiple managers conflicting, then realized that this is covered by the lock and the owner string. Or is it? That's not clear. > rptrTopNPortRateBase OBJECT-TYPE > SYNTAX INTEGER { > rptrMonitorPortReadableFrames(1), > rptrMonitorPortReadableOctets(2), > rptrMonitorPortFCSErrors(3), > rptrMonitorPortAlignmentErrors(4), > rptrMonitorPortFrameTooLongs(5), > rptrMonitorPortShortEvents(6), > rptrMonitorPortRunts(7), > rptrMonitorPortCollisions(8), > rptrMonitorPortLateEvents(9), > rptrMonitorPortVeryLongEvents(10), > rptrMonitorPortDataRateMismatches(11), > rptrMonitorPortAutoPartitions(12), > rptrMonitorPortTotalErrors(13), > rptrMonitorPortIsolates(14), > rptrMonitorPortSymbolErrors(15) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The monitored variable, which the rptrTopNPortRate > variable is based upon. > > The value of this object may not be modified if > the associated rptrTopNPortRowStatus object has > a value of active(1)." > ::= { rptrTopNPortControlEntry 3 } Although it seems elegant for the enumerations to match the object names, I'm not so sure that's a good idea. I can see it confusing an expression analyzer that can't tell whether I mean the constant value or the value of the object. I'd be happier if these didn't match so closely. It would be clean to remove the redundant "rptrMonitorPort" from the beginning of each one. I'd like to believe that's a change that could be made without otherwise disrupting stability. > snmpRptrGrpBasicRS OBJECT-GROUP > OBJECTS { rptrGroupIndex, > rptrGroupObjectID, > rptrGroupOperStatus, > rptrGroupPortCapacity, > > rptrPortGroupIndex, > rptrPortIndex, > rptrPortAdminStatus, > rptrPortAutoPartitionState, > rptrPortOperStatus, > rptrPortRptrId, > > rptrInfoId, > rptrInfoRptrType, > rptrInfoOperStatus, > rptrInfoReset, > rptrInfoPartitionedPorts, > rptrInfoLastChange } > STATUS current > DESCRIPTION > "Basic group for a system with one or more > repeater-units in restart version of the MIB > module." > ::= { snmpRptrModObjGrps 5 } I don't understand what "restart version of the MIB module means. Restart of what? Does it just mean this latest version? If so, I think we need clearer terminology. > "Implementation of this optional group is > recommended for systems which have the I'm somewhat uncomfortable with so much of this being optional. I understand the pressure to have a common definition, but I question whether this creates enough pressure for widespread implementation. On the other hand, I guess it's not any worse than RMON's optional groups... > 4. Topology Mapping > > The network mapping algorithm presented below takes > information available from network devices such as repeaters, > bridges, and switches, and creates a representation of the > physical topology of the network. We need more of this sort of application information in our MIBs. Good work! Overall the MIB looks to me like quality work. Bob   Received: from ietf.org by ietf.org id aa00688; 23 Aug 96 13:13 EDT Received: from cnri by ietf.org id aa00684; 23 Aug 96 13:13 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa10455; 23 Aug 96 13:13 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA174289408; Fri, 23 Aug 1996 09:56:49 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA049189376; Fri, 23 Aug 1996 09:56:17 -0700 Received: from ISD.3Com.com (chipcom.com) by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA173339370; Fri, 23 Aug 1996 09:56:10 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA28326; Fri, 23 Aug 96 12:52:54 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA1601; Fri, 23 Aug 96 12:53:53 -0700 Message-Id: <9608231953.AA1601@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id DA985ADBA899BE3C8525638F005CB7B4; Fri, 23 Aug 96 12:53:51 EDT To: hubmib Sender:ietf-archive-request@ietf.org From: Kathy deGraaf/US/3Com Date: 23 Aug 96 12:57:44 EDT Subject: updated MAU MIB draft Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="-- next item ----" This is the preamble of an RFC-1341 encoded, mixed message. ---- next item ---- Content-Type: Text/Plain Here is the updated version of the MAU MIB. I've made only the specific changes we discussed: 1. modified ifMauType to be read-only, and to describe its relationship with the new object ifMauDefaultType 2. added new read-write ifMauDefaultType, with a "note to implementors" 3. added new object ifMauAutoNegSupported 4. modified ifMauAutoNegAdminStatus to reflect the new object/behavior; also included here again the "note to implementors" 5. added the two new objects to the mauIfGrp100Mbs conformance group Actually, I made one additional change, to add back the names of the original authors of the document, as I believe precedent requires. My apologies to Donna, Keith, and Sam for leaving you off of the previous drafts. --Kathy ---- next item ---- Content-Type:Text/Plain; Name="MM.TXT" Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) 23 August 1996 Donna McMaster Livingston Enterprises Keith McCloghrie Cisco Systems Inc. Sam Roberts Farallon Computing, Inc. Dan Romascanu Madge Networks (Israel) Ltd. Kathryn de Graaf 3Com Corporation Internet Draft 802.3 MAU MIB 23 August 1996 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract 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. 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [6] - the mechanisms used for describing and naming objects for the purpose of management. Expires February 1997 [Page 2] Internet Draft 802.3 MAU MIB 23 August 1996 o the MIB-II, STD 17, RFC 1213 [5] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [10] and/or RFC 1905 [9] - the protocol used for accessing managed information. Textual conventions are defined in RFC 1903 [7], and conformance statements are defined in RFC 1904 [8]. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires February 1997 [Page 3] Internet Draft 802.3 MAU MIB 23 August 1996 2. Overview 2.1. Relationship to RFC 1515 This MIB is intended to be a superset of that defined by RFC 1515 [11], which will go to historic status. This MIB includes all of the objects contained in that MIB, plus several new ones which provide additional capabilities. Implementors are encouraged to support all applicable conformance groups in order to make the best use of the new functionality provided by this MIB. The new objects provide management support for: o management of 100 Mb/s devices o auto-negotiation o jack management 2.2. MAU Management Instances of these object types represent attributes of an IEEE 802.3 MAU. Several types of MAUs are defined in the IEEE 802.3 CSMA/CD standard [1] and [2]. These MAUs may be connected to IEEE 802.3 repeaters or to 802.3 (Ethernet-like) interfaces. For convenience this document refers to these devices as "repeater MAUs" and "interface MAUs." The definitions presented here are based on Section 30.5, "Layer Management for 10 & 100 Mb/s Medium Attachment Units (MAUs)", and Annex 30A, "GDMO Specifications for 802.3 managed objects" of IEEE Std 802.3u-1995. That specification includes definitions for both 10Mb/s and 100Mb/s devices, and is essentially a superset of the 10Mb/s definitions given by IEEE 802.3 Section 20. This specification is intended to serve the same purpose: to provide for management of both 10Mb/s and 100Mb/s MAUs. 2.3. Relationship to Other MIBs It is assumed that an agent implementing this MIB will also implement (at least) the 'system' group defined in MIB-II [5]. The following sections identify other MIBs that such an agent Expires February 1997 [Page 4] Internet Draft 802.3 MAU MIB 23 August 1996 should implement. 2.3.1. Relationship to the MIB-II 'interfaces' group The sections of this document that define interface MAU- related objects specify an extension to the 'interfaces' group of MIB-II. An agent implementing these interface-MAU related objects must also implement the 'interfaces' group of MIB-II. The value of the object ifMauIfIndex is the same as the value of 'ifIndex' used to instantiate the interface to which the given MAU is connected. It is expected that an agent implementing the interface-MAU related objects in this MIB will also implement the Ethernet- like Interfaces MIB, RFC 1650. (Note that repeater ports are not represented as interfaces in the sense of MIB-II's 'interfaces' group.) 2.3.2. Relationship to the 802.3 Repeater MIB The section of this document that defines repeater MAU-related objects specifies an extension to the 802.3 Repeater MIB defined in [4]. An agent implementing these repeater-MAU related objects must also implement the 802.3 Repeater MIB. The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to instantiate a repeater MAU variable shall be the same as the values of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the port to which the given MAU is connected. 2.4. Management of Internal MAUs In some situations, a MAU can be "internal" -- i.e., its functionality is implemented entirely within a device. For example, a managed repeater may contain an internal repeater- MAU and/or an internal interface-MAU through which management communications originating on one of the repeater's external ports pass in order to reach the management agent associated with the repeater. Such internal MAUs may or may not be managed. If they are managed, objects describing their attributes should appear in the appropriate MIB subtree: Expires February 1997 [Page 5] Internet Draft 802.3 MAU MIB 23 August 1996 dot3RpMauBasicGroup for internal repeater-MAUs and dot3IfMauBasicGroup for internal interface-MAUs. Expires February 1997 [Page 6] Internet Draft 802.3 MAU MIB 23 August 1996 3. Definitions MAU-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Integer32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2 FROM SNMPv2-SMI TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; mauMod MODULE-IDENTITY LAST-UPDATED "9608230000Z" ORGANIZATION "IETF HUB MIB Working Group" CONTACT-INFO "WG E-mail: hubmib@hprnd.rose.hp.com Chair: Dan Romascanu Postal: Madge Networks (Israel) Ltd. Atidim Technology Park, Bldg. 3 Tel Aviv 61131, Israel Tel: 972-3-6458414, 6458458 Fax: 972-3-6487146 E-mail: dromasca@madge.com Editor: Kathryn de Graaf Postal: 3Com Corporation 118 Turnpike Rd. Southborough, MA 01772 USA Tel: (508)229-1627 Fax: (508)490-5882 E-mail: kdegraaf@isd.3com.com" DESCRIPTION "Management information for 802.3 MAUs. The following references are used throughout this MIB module: [IEEE 802.3 Std] refers to IEEE 802.3/ISO 8802-3 Information processing systems - Local area networks - Expires February 1997 [Page 7] Internet Draft 802.3 MAU MIB 23 August 1996 Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications (1993), and to IEEE Std 802.3u-1995, Supplement to IEEE Std 802.3, clauses 22 through 29. [IEEE 802.3 Mgt] refers to IEEE 802.3u-1995, - 10 Mb/s & 100 Mb/s Management, Section 30 - Supplement to IEEE Std 802.3." ::= { snmpDot3MauMgt 6 } snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 } dot3RpMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 } dot3IfMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 } dot3BroadMauBasicGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 } dot3IfMauAutoNegGroup OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 } -- object identifiers for MAU types -- (see rpMauType and ifMauType for usage) dot3MauType OBJECT IDENTIFIER ::= { snmpDot3MauMgt 4 } dot3MauTypeAUI -- no internal MAU, view from AUI OBJECT IDENTIFIER ::= { dot3MauType 1 } dot3MauType10Base5 -- thick coax MAU (per 802.3 section 8) OBJECT IDENTIFIER ::= { dot3MauType 2 } dot3MauTypeFoirl -- FOIRL MAU (per 802.3 section 9.9) OBJECT IDENTIFIER ::= { dot3MauType 3 } dot3MauType10Base2 -- thin coax MAU (per 802.3 section 10) OBJECT IDENTIFIER ::= { dot3MauType 4 } dot3MauType10BaseT -- UTP MAU (per 802.3 section 14) OBJECT IDENTIFIER ::= { dot3MauType 5 } dot3MauType10BaseFP -- passive fiber MAU (per 802.3 section 16) OBJECT IDENTIFIER ::= { dot3MauType 6 } dot3MauType10BaseFB -- sync fiber MAU (per 802.3 section 17) OBJECT IDENTIFIER ::= { dot3MauType 7 } dot3MauType10BaseFL -- async fiber MAU (per 802.3 section 18) OBJECT IDENTIFIER ::= { dot3MauType 8 } Expires February 1997 [Page 8] Internet Draft 802.3 MAU MIB 23 August 1996 dot3MauType10Broad36 -- broadband DTE MAU (per 802.3 section 11) -- note that 10BROAD36 MAUs can be attached to interfaces but -- not to repeaters OBJECT IDENTIFIER ::= { dot3MauType 9 } ------ new since RFC 1515: dot3MauType10BaseTHD -- UTP MAU (per 802.3 section 14) -- half duplex mode OBJECT IDENTIFIER ::= { dot3MauType 10 } dot3MauType10BaseTFD -- UTP MAU (per 802.3 section 14) -- full duplex mode OBJECT IDENTIFIER ::= { dot3MauType 11 } dot3MauType10BaseFLHD -- async fiber MAU (per 802.3 section 18) -- half duplex mode OBJECT IDENTIFIER ::= { dot3MauType 12 } dot3MauType10BaseFLFD -- async fiber MAU (per 802.3 section 18) -- full duplex mode OBJECT IDENTIFIER ::= { dot3MauType 13 } dot3MauType100BaseT4 -- 4 pair categ. 3 UTP (per 802.3 section 23) OBJECT IDENTIFIER ::= { dot3MauType 14 } dot3MauType100BaseTXHD -- 2 pair categ. 5 UTP (per 802.3 section 25), -- half duplex mode OBJECT IDENTIFIER ::= { dot3MauType 15 } dot3MauType100BaseTXFD -- 2 pair categ. 5 UTP (per 802.3 section 25), -- full duplex mode OBJECT IDENTIFIER ::= { dot3MauType 16 } dot3MauType100BaseFXHD -- X fiber over PMT (per 802.3 section 26) -- half duplex mode OBJECT IDENTIFIER ::= { dot3MauType 17 } dot3MauType100BaseFXFD -- X fiber over PMT (per 802.3 section 26) -- full duplex mode OBJECT IDENTIFIER ::= { dot3MauType 18 } dot3MauType100BaseT2 OBJECT IDENTIFIER ::= { dot3MauType 19 } Expires February 1997 [Page 9] Internet Draft 802.3 MAU MIB 23 August 1996 -- -- The Basic Repeater MAU Table -- rpMauTable OBJECT-TYPE SYNTAX SEQUENCE OF RpMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about the MAU(s) attached to the ports of a repeater." ::= { dot3RpMauBasicGroup 1 } rpMauEntry OBJECT-TYPE SYNTAX RpMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single MAU." INDEX { rpMauGroupIndex, rpMauPortIndex, rpMauIndex } ::= { rpMauTable 1 } RpMauEntry ::= SEQUENCE { rpMauGroupIndex Integer32, rpMauPortIndex Integer32, rpMauIndex Integer32, rpMauType OBJECT IDENTIFIER, rpMauStatus INTEGER, rpMauMediaAvail INTEGER, rpMauMediaAvailStateExits Counter32, rpMauJabberState INTEGER, rpMauJabberingStateEnters Counter32, rpMauFalseCarriers Counter32 Expires February 1997 [Page 10] Internet Draft 802.3 MAU MIB 23 August 1996 } rpMauGroupIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the group containing the port to which the MAU described by this entry is connected. Note: In practice, a group will generally be a field-replaceable unit (i.e., module, card, or board) that can fit in the physical system enclosure, and the group number will correspond to a number marked on the physical enclosure. The group denoted by a particular value of this object is the same as the group denoted by the same value of rptrGroupIndex." ::= { rpMauEntry 1 } rpMauPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the repeater port within group rpMauGroupIndex to which the MAU described by this entry is connected." REFERENCE "Reference RFC 1516, rptrPortIndex." ::= { rpMauEntry 2 } rpMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same port (rpMauPortIndex)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID." ::= { rpMauEntry 3 } Expires February 1997 [Page 11] Internet Draft 802.3 MAU MIB 23 August 1996 rpMauType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the 10 or 100 Mb/s baseband MAU type. An initial set of MAU types are defined above. The assignment of OBJECT IDENTIFIERs to new types of MAUs is managed by the IANA. If the MAU type is unknown, the object identifier unknownMauType OBJECT IDENTIFIER ::= { 0 0 } is returned. Note that unknownMauType is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.2, aMAUType." ::= { rpMauEntry 4 } rpMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the MAU. This object may be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. Expires February 1997 [Page 12] Internet Draft 802.3 MAU MIB 23 August 1996 The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. A MAU in the operational(3) state is fully functional, operates, and passes signals to its attached DTE or repeater port in accordance to its specification. A MAU in standby(4) state forces DI and CI to idle and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of rpMauMediaAvail is unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter as though it were powered down or not connected. The MAU may return other(1) value for the rpMauJabberState and rpMauMediaAvail objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power- on cycle of at least one-half second would. The agent is not required to return the value reset (6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, acRESETMAU." ::= { rpMauEntry 5 } rpMauMediaAvail OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), available(3), Expires February 1997 [Page 13] Internet Draft 802.3 MAU MIB 23 August 1996 notAvailable(4), remoteFault(5), invalidSignal(6), remoteJabber(7), remoteLinkLoss(8), remoteTest(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "If the MAU is a link or fiber type (FOIRL, 10BASE-T, 10BASE-F) then this is equivalent to the link test fail state/low light function. For an AUI or a coax (including broadband) MAU this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. The value other(1) is returned if the mediaAvail state is not one of 2 through 6. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. At power-up or following a reset, the value of this attribute will be unknown for AUI, coax, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission then loopback will be detected. The value of this attribute will only change during non-collided transmissions for AUI, coax, and 10BASE-FP MAUs. For 100BASE-T4, 100BASE-TX and 100BASE-FX the enumerations match the states within the respective link integrity state diagrams, fig 23- 12 and 24-15 of sections 23 and 24 of [2]. Any MAU which implements management of auto- negotiation will map remote fault indication to remote fault. The value available(3) indicates that the link, Expires February 1997 [Page 14] Internet Draft 802.3 MAU MIB 23 August 1996 light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), and remoteTest(9) should be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. InvalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3u-1995 clause 22 MII is present, a logic one in the remote fault bit (reference section 22.2.4.2.8 of that document) maps to the value remoteFault(5), and a logic zero in the link status bit (reference section 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.4, aMediaAvailable." ::= { rpMauEntry 6 } rpMauMediaAvailStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that rpMauMediaAvail for this MAU instance leaves the state available(3)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.5, aLoseMediaCounter." ::= { rpMauEntry 7 } rpMauJabberState OBJECT-TYPE SYNTAX INTEGER { Expires February 1997 [Page 15] Internet Draft 802.3 MAU MIB 23 August 1996 other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber state is not 2, 3, or 4. The agent must always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, aJabber.jabberFlag." ::= { rpMauEntry 8 } rpMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). For MAUs of type dot3MauTypeAUI, dot3MauType100BaseT4, dot3MauType100BaseTX, and dot3MauType100BaseFX, this counter will always indicate zero." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, aJabber.jabberCounter." ::= { rpMauEntry 9 } rpMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires February 1997 [Page 16] Internet Draft 802.3 MAU MIB 23 August 1996 STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X links. This counter does not increment at the symbol rate. It can increment after a valid carrier completion at a maximum rate of once per 100 ms until the next carrier event. This counter increments only for MAUs of type dot3MauType100BaseT4, dot3MauType100BaseTX, and dot3MauType100BaseFX. For all other MAU types, this counter will always indicate zero. The approximate minimum time for rollover of this counter is 7.4 hours." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.10, aFalseCarriers." ::= { rpMauEntry 10 } -- The rpJackTable applies to MAUs attached to repeaters -- which have one or more external jacks (connectors). rpJackTable OBJECT-TYPE SYNTAX SEQUENCE OF RpJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the external jacks attached to MAUs attached to the ports of a repeater." ::= { dot3RpMauBasicGroup 2 } rpJackEntry OBJECT-TYPE SYNTAX RpJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a particular jack." INDEX { rpMauGroupIndex, rpMauPortIndex, rpMauIndex, rpJackIndex } ::= { rpJackTable 1 } Expires February 1997 [Page 17] Internet Draft 802.3 MAU MIB 23 August 1996 RpJackEntry ::= SEQUENCE { rpJackIndex Integer32, rpJackType INTEGER } rpJackIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the jack described by this entry from among other jacks attached to the same MAU (rpMauIndex)." ::= { rpJackEntry 1 } rpJackType OBJECT-TYPE SYNTAX INTEGER { other(1), rj45(2), rj45S(3), -- rj45 shielded db9(4), bnc(5), fAUI(6), -- female aui mAUI(7), -- male aui fiberSC(8), fiberMIC(9), fiberST(10), telco(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The jack connector type, as it appears on the outside of the system." ::= { rpJackEntry 2 } -- -- The Basic Interface MAU Table -- ifMauTable OBJECT-TYPE Expires February 1997 [Page 18] Internet Draft 802.3 MAU MIB 23 August 1996 SYNTAX SEQUENCE OF IfMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about MAU(s) attached to an interface." ::= { dot3IfMauBasicGroup 1 } ifMauEntry OBJECT-TYPE SYNTAX IfMauEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single MAU." INDEX { ifMauIfIndex, ifMauIndex } ::= { ifMauTable 1 } IfMauEntry ::= SEQUENCE { ifMauIfIndex Integer32, ifMauIndex Integer32, ifMauType OBJECT IDENTIFIER, ifMauStatus INTEGER, ifMauMediaAvail INTEGER, ifMauMediaAvailStateExits Counter32, ifMauJabberState INTEGER, ifMauJabberingStateEnters Counter32, ifMauFalseCarriers Counter32, ifMauTypeList Integer32, ifMauDefaultType OBJECT IDENTIFIER, ifMauAutoNegSupported TruthValue } Expires February 1997 [Page 19] Internet Draft 802.3 MAU MIB 23 August 1996 ifMauIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the interface to which the MAU described by this entry is connected." REFERENCE "RFC 1213, ifIndex" ::= { ifMauEntry 1 } ifMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same interface (ifMauIfIndex)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID." ::= { ifMauEntry 2 } ifMauType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the 10 or 100 Mb/s baseband MAU type. An initial set of MAU types are defined above. The assignment of OBJECT IDENTIFIERs to new types of MAUs is managed by the IANA. If the MAU type is unknown, the object identifier unknownMauType OBJECT IDENTIFIER ::= { 0 0 } is returned. Note that unknownMauType is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value. This object represents the operational type of the MAU, as determined by either (1) the result of the Expires February 1997 [Page 20] Internet Draft 802.3 MAU MIB 23 August 1996 auto-negotiation function or (2) if auto- negotiation is not enabled or is not implemented for this MAU, by the value of the object ifMauDefaultType. In case (2), a set to the object ifMauDefaultType will force the MAU into the new operating mode." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.2, aMAUType." ::= { ifMauEntry 3 } ifMauStatus OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), operational(3), standby(4), shutdown(5), reset(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The current state of the MAU. This object may be implemented as a read-only object by those agents and MAUs that do not implement software control of the MAU state. Some agents may not support setting the value of this object to some of the enumerated values. The value other(1) is returned if the MAU is in a state other than one of the states 2 through 6. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. A MAU in the operational(3) state is fully functional, operates, and passes signals to its attached DTE or repeater port in accordance to its specification. A MAU in standby(4) state forces DI and CI to idle and the media transmitter to idle or fault, if supported. Standby(4) mode only applies to link type MAUs. The state of ifMauMediaAvail is Expires February 1997 [Page 21] Internet Draft 802.3 MAU MIB 23 August 1996 unaffected. A MAU in shutdown(5) state assumes the same condition on DI, CI, and the media transmitter as though it were powered down or not connected. The MAU may return other(1) value for the ifMauJabberState and ifMauMediaAvail objects when it is in this state. For an AUI, this state will remove power from the AUI. Setting this variable to the value reset(6) resets the MAU in the same manner as a power-off, power- on cycle of at least one-half second would. The agent is not required to return the value reset (6). Setting this variable to the value operational(3), standby(4), or shutdown(5) causes the MAU to assume the respective state except that setting a mixing-type MAU or an AUI to standby(4) will cause the MAU to enter the shutdown state." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.7, aMAUAdminState, 30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1, acRESETMAU." ::= { ifMauEntry 4 } ifMauMediaAvail OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), available(3), notAvailable(4), remoteFault(5), invalidSignal(6), remoteJabber(7), remoteLinkLoss(8), remoteTest(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "If the MAU is a link or fiber type (FOIRL, 10BASE-T, 10BASE-F) then this is equivalent to the link test fail state/low light function. For an Expires February 1997 [Page 22] Internet Draft 802.3 MAU MIB 23 August 1996 AUI or a coax (including broadband) MAU this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. The value other(1) is returned if the mediaAvail state is not one of 2 through 6. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. At power-up or following a reset, the value of this attribute will be unknown for AUI, coax, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission then loopback will be detected. The value of this attribute will only change during non-collided transmissions for AUI, coax, and 10BASE-FP MAUs. For 100BASE-T4, 100BASE-TX and 100BASE-FX the enumerations match the states within the respective link integrity state diagrams, fig 23- 12 and 24-15 of sections 23 and 24 of [2]. Any MAU which implements management of auto- negotiation will map remote fault indication to remote fault. The value available(3) indicates that the link, light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), and remoteTest(9) should be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. Expires February 1997 [Page 23] Internet Draft 802.3 MAU MIB 23 August 1996 The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. InvalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3u-1995 clause 22 MII is present, a logic one in the remote fault bit (reference section 22.2.4.2.8 of that document) maps to the value remoteFault(5), and a logic zero in the link status bit (reference section 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.4, aMediaAvailable." ::= { ifMauEntry 5 } ifMauMediaAvailStateExits OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that ifMauMediaAvail for this MAU instance leaves the state available(3)." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.5, aLoseMediaCounter." ::= { ifMauEntry 6 } ifMauJabberState OBJECT-TYPE SYNTAX INTEGER { other(1), unknown(2), noJabber(3), jabbering(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value other(1) is returned if the jabber state is not 2, 3, or 4. The agent must always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is Expires February 1997 [Page 24] Internet Draft 802.3 MAU MIB 23 August 1996 being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, aJabber.jabberFlag." ::= { ifMauEntry 7 } ifMauJabberingStateEnters OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of times that mauJabberState for this MAU instance enters the state jabbering(4). For MAUs of type dot3MauTypeAUI, dot3MauType100BaseT4, dot3MauType100BaseTX, and dot3MauType100BaseFX, this counter will always indicate zero." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.6, aJabber.jabberCounter." ::= { ifMauEntry 8 } ifMauFalseCarriers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of false carrier events during IDLE in 100BASE-X links. This counter does not increment at the symbol rate. It can increment after a valid carrier completion at a maximum rate of once per 100 ms until the next carrier event. This counter increments only for MAUs of type dot3MauType100BaseT4, dot3MauType100BaseTX, and dot3MauType100BaseFX. For all other MAU types, this counter will always indicate zero. Expires February 1997 [Page 25] Internet Draft 802.3 MAU MIB 23 August 1996 The approximate minimum time for rollover of this counter is 7.4 hours." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.10, aFalseCarriers." ::= { ifMauEntry 9 } ifMauTypeList OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of possible IEEE 802.3 types that the MAU could be. The value is a sum which initially takes the value zero. Then, for each type capability of this MAU, 2 raised to the power noted below is added to the sum. For example, a MAU which has the capability to be only 10BASE-T would have a value of 512 (2**9). In contrast, a MAU which supports both 10Base-T (full duplex) and 100BASE-TX (full duplex) would have a value of ((2**11) + (2**16)) or 67584. The powers of 2 assigned to the capabilities are these: Power Capability 0 other or unknown 1 AUI 2 10BASE-5 3 FOIRL 4 10BASE-2 5 10BASE-T duplex mode unknown 6 10BASE-FP 7 10BASE-FB 8 10BASE-FL duplex mode unknown 9 10BROAD36 10 10BASE-T half duplex mode 11 10BASE-T full duplex mode 12 10BASE-FL half duplex mode 13 10BASE-FL full duplex mode 14 100BASE-T4 15 100BASE-TX half duplex mode 16 100BASE-TX full duplex mode 17 100BASE-FX half duplex mode Expires February 1997 [Page 26] Internet Draft 802.3 MAU MIB 23 August 1996 18 100BASE-FX full duplex mode 19 100BASE-T2 If auto-negotiation is present on this MAU, this object will map to ifMauAutoNegCapability." ::= { ifMauEntry 10 } ifMauDefaultType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the default administrative 10 or 100 Mb/s baseband MAU type, to be used in conjunction with the operational MAU type denoted by ifMauType. The set of possible values for this object is the same as the set defined for the ifMauType object. This object represents the administratively- configured type of the MAU. If auto-negotiation is not enabled or is not implemented for this MAU, the value of this object determines the operational type of the MAU. In this case, a set to this object will force the MAU into the specified operating mode. If auto-negotiation is implemented and enabled for this MAU, the operational type of the MAU is determined by auto-negotiation, and the value of this object denotes the type to which the MAU will automatically revert if/when auto-negotiation is later disabled. NOTE TO IMPLEMENTORS: It may be necessary to provide for underlying hardware implementations which do not follow the exact behavior specified above. In particular, when ifMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation must ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by this object, rather than continuing to operate at the value earlier determined by the Expires February 1997 [Page 27] Internet Draft 802.3 MAU MIB 23 August 1996 auto-negotiation function." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.1.1, aMAUID, and [IEEE 802.3 Std], 22.2.4.1.4." ::= { ifMauEntry 11 } ifMauAutoNegSupported OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates whether or not auto- negotiation is supported on this MAU." ::= { ifMauEntry 12 } -- The ifJackTable applies to MAUs attached to interfaces -- which have one or more external jacks (connectors). ifJackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the external jacks attached to MAUs attached to an interface." ::= { dot3IfMauBasicGroup 2 } ifJackEntry OBJECT-TYPE SYNTAX IfJackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a particular jack." INDEX { ifMauIfIndex, ifMauIndex, ifJackIndex } ::= { ifJackTable 1 } IfJackEntry ::= SEQUENCE { ifJackIndex Integer32, Expires February 1997 [Page 28] Internet Draft 802.3 MAU MIB 23 August 1996 ifJackType INTEGER } ifJackIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable uniquely identifies the jack described by this entry from among other jacks attached to the same MAU." ::= { ifJackEntry 1 } ifJackType OBJECT-TYPE SYNTAX INTEGER { other(1), rj45(2), rj45S(3), -- rj45 shielded db9(4), bnc(5), fAUI(6), -- female aui mAUI(7), -- male aui fiberSC(8), fiberMIC(9), fiberST(10), telco(11) } MAX-ACCESS read-only STATUS current DESCRIPTION "The jack connector type, as it appears on the outside of the system." ::= { ifJackEntry 2 } -- The ifMauAutoNegTable applies to systems in which -- auto-negotiation is supported on one or more MAUs -- attached to interfaces. Note that if auto-negotiation -- is present and enabled, the ifMauType object reflects -- the result of the auto-negotiation function. ifMauAutoNegTable OBJECT-TYPE SYNTAX SEQUENCE OF IfMauAutoNegEntry Expires February 1997 [Page 29] Internet Draft 802.3 MAU MIB 23 August 1996 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Configuration and status objects for the auto- negotiation function of MAUs attached to interfaces." ::= { dot3IfMauAutoNegGroup 1 } ifMauAutoNegEntry OBJECT-TYPE SYNTAX IfMauAutoNegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing configuration and status information for the auto-negotiation function of a particular MAU." INDEX { ifMauIfIndex, ifMauIndex } ::= { ifMauAutoNegTable 1 } IfMauAutoNegEntry ::= SEQUENCE { ifMauAutoNegAdminStatus INTEGER, ifMauAutoNegRemoteSignaling INTEGER, ifMauAutoNegConfig INTEGER, ifMauAutoNegCapability Integer32, ifMauAutoNegCapAdvertised Integer32, ifMauAutoNegCapReceived Integer32, ifMauAutoNegRestart INTEGER } ifMauAutoNegAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write Expires February 1997 [Page 30] Internet Draft 802.3 MAU MIB 23 August 1996 STATUS current DESCRIPTION "Setting this object to enabled(1) will cause the interface which has the auto-negotiation signaling ability to be enabled. If the value of this object is disabled(2) then the interface will act as it would if it had no auto-negotiation signaling. Under these conditions, an IEEE 802.3 MAU will immediately be forced to the state indicated by the value of the object ifMauDefaultType. NOTE TO IMPLEMENTORS: When ifMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation must ensure that the operational type of the MAU (as reported by ifMauType) correctly transitions to the value specified by the ifMauDefaultType object, rather than continuing to operate at the value earlier determined by the auto-negotiation function." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.2, aAutoNegAdminState and 30.6.1.2.2, acAutoNegAdminControl." ::= { ifMauAutoNegEntry 1 } ifMauAutoNegRemoteSignaling OBJECT-TYPE SYNTAX INTEGER { detected(1), notdetected(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating whether the remote end of the link is using auto-negotiation signaling. It takes the value detected(1) if and only if, during the previous link negotiation, FLP Bursts were received." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.3, aAutoNegRemoteSignaling." ::= { ifMauAutoNegEntry 2 } ifMauAutoNegConfig OBJECT-TYPE Expires February 1997 [Page 31] Internet Draft 802.3 MAU MIB 23 August 1996 SYNTAX INTEGER { other(1), configuring(2), complete(3), disabled(4), parallelDetectFail(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value indicating the current status of the auto-negotiation process. The enumeration parallelDetectFail(5) maps to a failure in parallel detection as defined in 28.2.3.1 of [IEEE 802.3 Std]." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.4, aAutoNegAutoConfig." ::= { ifMauAutoNegEntry 4 } ifMauAutoNegCapability OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities of the local auto-negotiation entity. The value is a sum which initially takes the value zero. Then, for each capability of this interface, 2 raised to the power noted below is added to the sum. For example, an interface which has the capability to support only 100Base-TX half duplex would have a value of 32768 (2**15). In contrast, an interface which supports both 100Base-TX half duplex and and 100Base-TX full duplex would have a value of 98304 ((2**15) + (2**16)). The powers of 2 assigned to the capabilities are these: Power Capability 0 other or unknown (1-9) (reserved) 10 10BASE-T half duplex mode Expires February 1997 [Page 32] Internet Draft 802.3 MAU MIB 23 August 1996 11 10BASE-T full duplex mode 12 (reserved) 13 (reserved) 14 100BASE-T4 15 100BASE-TX half duplex mode 16 100BASE-TX full duplex mode Note that interfaces that support this MIB may have capabilities that extend beyond the scope of this MIB." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.5, aAutoNegLocalTechnologyAbility." ::= { ifMauAutoNegEntry 5 } ifMauAutoNegCapAdvertised OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities advertised by the local auto- negotiation entity. Refer to ifMauAutoNegCapability for a description of the possible values of this object. Capabilities in this object that are not available in ifMauAutoNegCapability cannot be enabled." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.6, aAutoNegAdvertisedTechnologyAbility." ::= { ifMauAutoNegEntry 6 } ifMauAutoNegCapReceived OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A value that uniquely identifies the set of capabilities received from the remote auto- negotiation entity. Refer to ifMauAutoNegCapability for a description of the possible values of this object. Note that interfaces that support this MIB may be Expires February 1997 [Page 33] Internet Draft 802.3 MAU MIB 23 August 1996 attached to remote auto-negotiation entities which have capabilities beyond the scope of this MIB." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.1.7, aAutoNegReceivedTechnologyAbility." ::= { ifMauAutoNegEntry 7 } ifMauAutoNegRestart OBJECT-TYPE SYNTAX INTEGER { restart(1), norestart(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "If the value of this object is set to restart(1) then this will force auto-negotiation to begin link renegotiation. If auto-negotiation signaling is disabled, a write to this object has no effect. Setting the value of this object to norestart(2) has no effect." REFERENCE "[IEEE 802.3 Mgt], 30.6.1.2.1, acAutoNegRestartAutoConfig." ::= { ifMauAutoNegEntry 8 } broadMauBasicTable OBJECT-TYPE SYNTAX SEQUENCE OF BroadMauBasicEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of descriptive and status information about the broadband MAUs connected to interfaces." ::= { dot3BroadMauBasicGroup 1 } broadMauBasicEntry OBJECT-TYPE SYNTAX BroadMauBasicEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table, containing information about a single broadband MAU." INDEX { broadMauIfIndex, broadMauIndex } Expires February 1997 [Page 34] Internet Draft 802.3 MAU MIB 23 August 1996 ::= { broadMauBasicTable 1 } BroadMauBasicEntry ::= SEQUENCE { broadMauIfIndex Integer32, broadMauIndex Integer32, broadMauXmtRcvSplitType INTEGER, broadMauXmtCarrierFreq Integer32, broadMauTranslationFreq Integer32 } broadMauIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the interface to which the MAU described by this entry is connected." REFERENCE "Reference RFC 1213, ifIndex." ::= { broadMauBasicEntry 1 } broadMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the MAU connected to interface broadMauIfIndex that is described by this entry." REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aMAUID." ::= { broadMauBasicEntry 2 } broadMauXmtRcvSplitType OBJECT-TYPE SYNTAX INTEGER { other(1), single(2), dual(3) Expires February 1997 [Page 35] Internet Draft 802.3 MAU MIB 23 August 1996 } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the type of frequency multiplexing/cabling system used to separate the transmit and receive paths for the 10BROAD36 MAU. The value other(1) is returned if the split type is not either single or dual. The value single(2) indicates a single cable system. The value dual(3) indicates a dual cable system, offset normally zero." REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aBbMAUXmitRcvSplitType." ::= { broadMauBasicEntry 3 } broadMauXmtCarrierFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the transmit carrier frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aBroadbandFrequencies.xmitCarrierFrequency." ::= { broadMauBasicEntry 4 } broadMauTranslationFreq OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This variable indicates the translation offset frequency of the 10BROAD36 MAU in MHz/4; that is, in units of 250 kHz." REFERENCE "Reference IEEE 802.3 MAU Mgt, 20.2.3.2, aBroadbandFrequencies.translationFrequency." ::= { broadMauBasicEntry 5 } Expires February 1997 [Page 36] Internet Draft 802.3 MAU MIB 23 August 1996 -- Notifications for use by 802.3 MAUs rpMauJabberTrap NOTIFICATION-TYPE OBJECTS { rpMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed repeater MAU enters the jabber state. The agent must throttle the generation of consecutive rpMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauMgt 0 1 } ifMauJabberTrap NOTIFICATION-TYPE OBJECTS { ifMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed interface MAU enters the jabber state. The agent must throttle the generation of consecutive ifMauJabberTraps so that there is at least a five-second gap between them." REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauMgt 0 2 } -- Conformance information mauModConf OBJECT IDENTIFIER ::= { mauMod 1 } mauModCompls OBJECT IDENTIFIER ::= { mauModConf 1 } mauModObjGrps OBJECT IDENTIFIER ::= { mauModConf 2 } mauModNotGrps OBJECT IDENTIFIER ::= { mauModConf 3 } Expires February 1997 [Page 37] Internet Draft 802.3 MAU MIB 23 August 1996 -- Object groups mauRpGrpBasic OBJECT-GROUP OBJECTS { rpMauGroupIndex, rpMauPortIndex, rpMauIndex, rpMauType, rpMauStatus, rpMauMediaAvail, rpMauMediaAvailStateExits, rpMauJabberState, rpMauJabberingStateEnters } STATUS current DESCRIPTION "Basic conformance group for MAUs attached to repeater ports. This group is also the conformance specification for RFC 1515 implementations." ::= { mauModObjGrps 1 } mauRpGrp100Mbs OBJECT-GROUP OBJECTS { rpMauFalseCarriers } STATUS current DESCRIPTION "Conformance group for MAUs attached to repeater ports with 100 Mb/s capability." ::= { mauModObjGrps 2 } mauRpGrpJack OBJECT-GROUP OBJECTS { rpJackType } STATUS current DESCRIPTION "Conformance group for MAUs attached to repeater ports with managed jacks." ::= { mauModObjGrps 3 } mauIfGrpBasic OBJECT-GROUP OBJECTS { ifMauIfIndex, ifMauIndex, ifMauType, ifMauStatus, ifMauMediaAvail, ifMauMediaAvailStateExits, ifMauJabberState, ifMauJabberingStateEnters } Expires February 1997 [Page 38] Internet Draft 802.3 MAU MIB 23 August 1996 STATUS current DESCRIPTION "Basic conformance group for MAUs attached to interfaces. This group also provides a conformance specification for RFC 1515 implementations." ::= { mauModObjGrps 4 } mauIfGrp100Mbs OBJECT-GROUP OBJECTS { ifMauFalseCarriers, ifMauTypeList, ifMauDefaultType, ifMauAutoNegSupported } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with 100 Mb/s capability." ::= { mauModObjGrps 5 } mauIfGrpJack OBJECT-GROUP OBJECTS { ifJackType } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with managed jacks." ::= { mauModObjGrps 6 } mauIfGrpAutoNeg OBJECT-GROUP OBJECTS { ifMauAutoNegAdminStatus, ifMauAutoNegRemoteSignaling, ifMauAutoNegConfig, ifMauAutoNegCapability, ifMauAutoNegCapAdvertised, ifMauAutoNegCapReceived, ifMauAutoNegRestart } STATUS current DESCRIPTION "Conformance group for MAUs attached to interfaces with managed auto-negotiation." ::= { mauModObjGrps 7 } mauBroadBasic OBJECT-GROUP OBJECTS { broadMauIfIndex, broadMauIndex, broadMauXmtRcvSplitType, Expires February 1997 [Page 39] Internet Draft 802.3 MAU MIB 23 August 1996 broadMauXmtCarrierFreq, broadMauTranslationFreq } STATUS current DESCRIPTION "Conformance group for broadband MAUs attached to interfaces. This group provides a conformance specification for RFC 1515 implementations." ::= { mauModObjGrps 8 } -- Compliances mauModRpCompl MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for MAUs attached to repeater ports." MODULE -- this module MANDATORY-GROUPS { mauRpGrpBasic } GROUP mauRpGrp100Mbs DESCRIPTION "Implementation of this optional group is recommended for MAUs which have 100Mb/s capability." GROUP mauRpGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs which have one or more external jacks." ::= { mauModCompls 1 } mauModIfCompl MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance for MAUs attached to interfaces." MODULE -- this module MANDATORY-GROUPS { mauIfGrpBasic } GROUP mauIfGrp100Mbs Expires February 1997 [Page 40] Internet Draft 802.3 MAU MIB 23 August 1996 DESCRIPTION "Implementation of this optional group is recommended for MAUs which have 100Mb/s capability." GROUP mauIfGrpJack DESCRIPTION "Implementation of this optional group is recommended for MAUs which have one or more external jacks." GROUP mauIfGrpAutoNeg DESCRIPTION "Implementation of this group is mandatory for MAUs which support managed auto-negotiation." GROUP mauBroadBasic DESCRIPTION "Implementation of this group is mandatory for broadband MAUs." ::= { mauModCompls 2 } END Expires February 1997 [Page 41] Internet Draft 802.3 MAU MIB 23 August 1996 4. Acknowledgements This document was produced by the IETF Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: Chuck Black John Flick Jeff Johnson Leon Leong Mike Lui Dave Perkins Geoff Thompson Maurice Turcotte Paul Woodruff Expires February 1997 [Page 42] Internet Draft 802.3 MAU MIB 23 August 1996 5. References [1] IEEE 802.3/ISO 8802-3 Information processing systems - Local area networks - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 1993. [2] IEEE 802.3u-1995, "MAC Parameters, Physical Layer, Medium Attachment Units and Repeater for 100 Mb/s Operation, Type 100BASE-T," Sections 21 through 29, Supplement to IEEE Std 802.3, October 26, 1995. [3] IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, Supplement to IEEE Std 802.3, October 26, 1995. [4] Romascanu, D., and K. de Graaf, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", May 1996. [5] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [10] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Expires February 1997 [Page 43] Internet Draft 802.3 MAU MIB 23 August 1996 Performance Systems International, MIT Laboratory for Computer Science, May 1990. [11] McMaster, D., K. McCloghrie, S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 1515, September 1993. Expires February 1997 [Page 44] Internet Draft 802.3 MAU MIB 23 August 1996 6. Security Considerations Security issues are not discussed in this memo. 7. Authors' Addresses Donna McMaster Livingston Enterprises Tel: (916) 676-1147 E-Mail: donna@livingston.com Keith McCloghrie Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 Tel: (408) 526-5260 E-Mail: kzm@cisco.com Sam Roberts Farallon Computing, Inc. 2470 Mariner Square Loop Alameda, CA 94501-1010 Tel: (510) 814-5215 E-Mail: sroberts@farallon.com Dan Romascanu Madge Networks (Israel) Ltd. Atidim Technology Park, Bldg. 3 Tel Aviv 61131, Israel Tel: 972-3-6458414, 6458458 Fax: 972-3-6487146 E-mail: dromasca@madge.com Kathryn de Graaf 3Com Corporation 118 Turnpike Rd. Southborough, MA 01772 USA Tel: (508)229-1627 Fax: (508)490-5882 E-mail: kdegraaf@isd.3com.com Expires February 1997 [Page 45] Internet Draft 802.3 MAU MIB 23 August 1996 Table of Contents 1 The SNMPv2 Network Management Framework ............... 2 1.1 Object Definitions .................................. 3 2 Overview .............................................. 4 2.1 Relationship to RFC 1515 ............................ 4 2.2 MAU Management ...................................... 4 2.3 Relationship to Other MIBs .......................... 4 2.3.1 Relationship to the MIB-II 'interfaces' group ..... 5 2.3.2 Relationship to the 802.3 Repeater MIB ............ 5 2.4 Management of Internal MAUs ......................... 5 3 Definitions ........................................... 7 4 Acknowledgements ...................................... 42 5 References ............................................ 43 6 Security Considerations ............................... 45 7 Authors' Addresses .................................... 45 Expires February 1997 [Page 46] ---- next item ------   Received: from ietf.org by ietf.org id aa03626; 23 Aug 96 15:16 EDT Received: from cnri by ietf.org id aa03620; 23 Aug 96 15:16 EDT Received: from hp.com by CNRI.Reston.VA.US id aa12240; 23 Aug 96 15:16 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA256227260; Fri, 23 Aug 1996 12:07:40 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA072267235; Fri, 23 Aug 1996 12:07:21 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA035977791; Fri, 23 Aug 1996 12:16:31 -0700 Message-Id: <199608231916.AA035977791@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com Subject: Fwd: [Re: [Fwd: Hub MIB to Proposed Standard]] Date: Fri, 23 Aug 1996 12:16:31 -0700 Sender:ietf-archive-request@ietf.org From: John Flick Hi, I am resending the message that Kathy sent yesterday. We were having some DNS problems yesterday that was preventing mail from being forwarded to most .com addresses from within the HP intranet. As a result, this message didn't make it to many of the people on the list. It looks like things may be working again, since Kathy's message today with the updated MAU MIB didn't bounce. Crossing fingers and hitting "send", 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 AA012195003; Thu, 22 Aug 1996 13:16:43 -0700 Return-Path: Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA251714416; Thu, 22 Aug 1996 13:06:56 -0700 Received: from ISD.3Com.com (chipcom.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA222894323; Thu, 22 Aug 1996 13:05:23 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA13084; Thu, 22 Aug 96 16:02:15 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA8480; Thu, 22 Aug 96 16:03:16 -0700 Message-Id: <9608222303.AA8480@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 4FD085CD0E3B42B48525638E006A679A; Thu, 22 Aug 96 16:03:16 EDT To: hubmib From: Kathy deGraaf/US/3Com Date: 22 Aug 96 16:06:43 EDT Subject: Re: [Fwd: Hub MIB to Proposed Standard] Mime-Version: 1.0 Content-Type: Text/Plain Hi all, It has been pointed out, to my chagrin, that Bob sent his comments on the repeater MIB only to me, and didn't copy the list. I've appended his mail below. My sincere apologies for missing this and for not forwarding it sooner. I also have the agreed-upon updates to the MAU MIB in the pipe, and will be sending them to the list in the next day or so. Bob brought up some items that we should discuss. I can't recall now why we included a separate integer for indexing the various source addresses seen on a particular port (rptrExtAddrTrackTable)...why not index off the MAC address itself? As far as correlation between indices and MAC addresses in the table entries, I'm not sure it's an issue. I would expect an application to download the entire set of addresses for a particular port at one time, or, if we index it off of MAC address, to ask whether a particular address was seen on a port. I can't see the need for the integer index for a particular MAC address to be consistent over time. We have no lock or owner string on the rptrAddrTrackReset object, so maybe we need to highlight the fact that resetting the table isn't necessarily friendly in a multiple-manager situation. Do we need a lock/owner after all? I agree with the suggested name change to the topNPortRateBase. I can easily change the "restart version" wording, unless anyone is particularly attached to it? Any suggestions for substitute wording? I'm comfortable with the presence of so many optional functions...do we agree on this, as a group? It doesn't seem like as big an issue as it has been in the past, since there is more precedent for it these days (as Bob points out). - --Kathy To: Kathy_deGraaf/US/3Com%3COM @ smtp1.isd.3com.com @ SMTP1 cc: kostick @ qsun.att.com @ SMTP1 From: bstewart @ cisco.com (Bob Stewart) @ SMTP1 Date: Thursday July 11, 1996 02:59 PM Subject: Re: [Fwd: Hub MIB to Proposed Standard] - ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Circa 5:30 PM -0400 7/9/96, Kathy deGraaf/US/3Com bitwhacked: >The latest draft is draft-ietf-hubmib-repeater-dev-02.txt and is dated May 14. >It should be in the Internet-Drafts directory. Got it. Here's my official review on behalf of the NM Area Director. I copied Deirdre so she can see that I did it and get the flavor of my comments. > goto try_again Tsk, tsk, tsk. A goto. Shameful. I forgot C allowed such things. > rptrExtAddrTrackMacIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The index of a source MAC address seen on > the port." > ::= { rptrExtAddrTrackEntry 1 } I assume that the relationship of this index and a given MAC address can't change without an indication of discontinuity. If that's true, it should probably say that here. If it's not, there's at least awkwardness with using the table. > rptrAddrTrackReset OBJECT-TYPE > SYNTAX INTEGER { > noReset(1), > reset(2) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Setting this object to reset(2) causes > the agent to empty the contents of the > rptrExtAddrTrackTable. The contents of > the rptrAddrTrackTable are not affected. > > Setting this object to noReset(1) has no effect. > The agent will always return the value noReset(1) > when this object is read." > ::= { rptrAddrTrackPortInfo 3 } Hmmmm. A built-in discontinuity creator. Ahhhh. I was about to complain about multiple managers conflicting, then realized that this is covered by the lock and the owner string. Or is it? That's not clear. > rptrTopNPortRateBase OBJECT-TYPE > SYNTAX INTEGER { > rptrMonitorPortReadableFrames(1), > rptrMonitorPortReadableOctets(2), > rptrMonitorPortFCSErrors(3), > rptrMonitorPortAlignmentErrors(4), > rptrMonitorPortFrameTooLongs(5), > rptrMonitorPortShortEvents(6), > rptrMonitorPortRunts(7), > rptrMonitorPortCollisions(8), > rptrMonitorPortLateEvents(9), > rptrMonitorPortVeryLongEvents(10), > rptrMonitorPortDataRateMismatches(11), > rptrMonitorPortAutoPartitions(12), > rptrMonitorPortTotalErrors(13), > rptrMonitorPortIsolates(14), > rptrMonitorPortSymbolErrors(15) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The monitored variable, which the rptrTopNPortRate > variable is based upon. > > The value of this object may not be modified if > the associated rptrTopNPortRowStatus object has > a value of active(1)." > ::= { rptrTopNPortControlEntry 3 } Although it seems elegant for the enumerations to match the object names, I'm not so sure that's a good idea. I can see it confusing an expression analyzer that can't tell whether I mean the constant value or the value of the object. I'd be happier if these didn't match so closely. It would be clean to remove the redundant "rptrMonitorPort" from the beginning of each one. I'd like to believe that's a change that could be made without otherwise disrupting stability. > snmpRptrGrpBasicRS OBJECT-GROUP > OBJECTS { rptrGroupIndex, > rptrGroupObjectID, > rptrGroupOperStatus, > rptrGroupPortCapacity, > > rptrPortGroupIndex, > rptrPortIndex, > rptrPortAdminStatus, > rptrPortAutoPartitionState, > rptrPortOperStatus, > rptrPortRptrId, > > rptrInfoId, > rptrInfoRptrType, > rptrInfoOperStatus, > rptrInfoReset, > rptrInfoPartitionedPorts, > rptrInfoLastChange } > STATUS current > DESCRIPTION > "Basic group for a system with one or more > repeater-units in restart version of the MIB > module." > ::= { snmpRptrModObjGrps 5 } I don't understand what "restart version of the MIB module means. Restart of what? Does it just mean this latest version? If so, I think we need clearer terminology. > "Implementation of this optional group is > recommended for systems which have the I'm somewhat uncomfortable with so much of this being optional. I understand the pressure to have a common definition, but I question whether this creates enough pressure for widespread implementation. On the other hand, I guess it's not any worse than RMON's optional groups... > 4. Topology Mapping > > The network mapping algorithm presented below takes > information available from network devices such as repeaters, > bridges, and switches, and creates a representation of the > physical topology of the network. We need more of this sort of application information in our MIBs. Good work! Overall the MIB looks to me like quality work. Bob ------- End of Forwarded Message   Received: from ietf.org by ietf.org id aa04460; 23 Aug 96 15:51 EDT Received: from cnri by ietf.org id aa04456; 23 Aug 96 15:51 EDT Received: from hp.com by CNRI.Reston.VA.US id aa12713; 23 Aug 96 15:51 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA009249534; Fri, 23 Aug 1996 12:45:34 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA076909473; Fri, 23 Aug 1996 12:44:33 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA036590029; Fri, 23 Aug 1996 12:53:49 -0700 Message-Id: <199608231953.AA036590029@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com Subject: Re: [Fwd: Hub MIB to Proposed Standard] In-Reply-To: Your message of "22 Aug 1996 16:06:43 EDT." <9608222303.AA8480@> Date: Fri, 23 Aug 1996 12:53:49 -0700 Sender:ietf-archive-request@ietf.org From: John Flick Some comments on the issues from Bob's review comments. >I can't recall now why we included a separate integer for indexing the various > >source addresses seen on a particular port (rptrExtAddrTrackTable)...why not >index off the MAC address itself? As far as correlation between indices and >MAC addresses in the table entries, I'm not sure it's an issue. I would expec >t >an application to download the entire set of addresses for a particular port a >t >one time, or, if we index it off of MAC address, to ask whether a particular >address was seen on a port. I can't see the need for the integer index for a >particular MAC address to be consistent over time. True, there is probably not a need for maintaining a correlation between the integer index and the MAC address. However, the idea of just using the MAC address directly in the index is probably not a bad idea. I don't think we ever really discussed alternative options for indexing this table, so we really never discussed any reasons for having the separate integer index. Avoiding content-free indices is usually a good idea. However, I am hesitant at making a substantial change at this point. I want this MIB published SOON. >We have no lock or owner string on the rptrAddrTrackReset object, so maybe we >need to highlight the fact that resetting the table isn't necessarily friendly > >in a multiple-manager situation. Do we need a lock/owner after all? I don't see what a lock/owner buys you here. You hit the reset object and (most of) the contents of the table go away. Unless you are planning on maintaining separate copies of this table associated with a control table with the lock/owner and reset object (ala RMON). I think that would be overkill. I really have never liked this object, for the very reason Bob brings up. It is a discontinuity creator. However, I realize this is something we have discussed before (in Dallas, I believe), and we decided to keep it. So in the interest of getting finished quickly, and not rehashing old discussions, I favor just putting in a warning about multi-manager unfriendly-ness and moving on. >I agree with the suggested name change to the topNPortRateBase. Seems reasonable. >I can easily change the "restart version" wording, unless anyone is >particularly attached to it? Any suggestions for substitute wording? How about "multi-segment"? Hmmm. I realize we want people to use the new stuff even for simple, single segment hubs, but multi-segment support was the motivation for many of the changes. Let's not get too hung up on wording here. >I'm comfortable with the presence of so many optional functions...do we agree >on this, as a group? It doesn't seem like as big an issue as it has been in >the past, since there is more precedent for it these days (as Bob points out). Much of this MIB has been optional ever since RFC 1368. However, most implementations seem to just do all of it. That may change with this version (some of the new features can be expensive, depending on your hardware capabilities). I think we should keep at least the TopNPort, ExtAddrTrack, and AddrSearch strongly recommended but optional. However, it may be reasonable at this point to make the Monitor and AddrTrack groups mandatory, and the Monitor100 stuff conditionally mandatory. An implementation with just the basic group seems really unlikely, and not very useful. John   Received: from ietf.org by ietf.org id aa09522; 26 Aug 96 5:20 EDT Received: from cnri by ietf.org id aa09518; 26 Aug 96 5:20 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa03848; 26 Aug 96 5:20 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA298520934; Mon, 26 Aug 1996 02:15:35 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA094500826; Mon, 26 Aug 1996 02:13:47 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA296240823; Mon, 26 Aug 1996 02:13:43 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Mon, 26 Aug 96 02:19:59 -0800 Message-Id: <0483213201660C00@mail.madge.com> In-Reply-To: <30DE1C3201660C00> Date: Mon, 26 Aug 96 12:00:40 +0300 Sender:ietf-archive-request@ietf.org From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: hubmib , Kathy deGraaf/US/3Com Subject: Re: [Fwd: Hub MIB to Proposed Standard] X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Kathy, >I can't recall now why we included a separate integer for indexing the various >source addresses seen on a particular port (rptrExtAddrTrackTable)...why not >index off the MAC address itself? As far as correlation between indices and >MAC addresses in the table entries, I'm not sure it's an issue. I would expect >an application to download the entire set of addresses for a particular port at >one time, or, if we index it off of MAC address, to ask whether a particular >address was seen on a port. I can't see the need for the integer index for a >particular MAC address to be consistent over time. I recall we had in one of our meetings an argument relative to the order of appearance of the addresses in the table. We reached the conclusion that adding a timestamp object is too 'heavy', but a integer index would be both easier to implement and could be interpreted as a mark for the order of appearance, if the implementation is capable of providing him such a significance. (maybe this should ba backed by some text?). The MAC as index is more compact, but has no functional significance. >We have no lock or owner string on the rptrAddrTrackReset object, so maybe we >need to highlight the fact that resetting the table isn't necessarily friendly >in a multiple-manager situation. Do we need a lock/owner after all? I don't think so. There are plenty of Reset objects in different MIBs, with impact on the collected data flow and the general rule is that they do not have a lock/owner. >I'm comfortable with the presence of so many optional functions...do we agree >on this, as a group? It doesn't seem like as big an issue as it has been in >the past, since there is more precedent for it these days (as Bob points out). I think this is unavoidable when you need to compromise between extended functionality, price and backward compatibility. LET'S GET THIS STUFF ROLLING! Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.org by ietf.org id aa15014; 26 Aug 96 9:47 EDT Received: from localhost by ietf.org id aa11942; 26 Aug 96 9:31 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.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-hubmib-mau-mib-03.txt Date: Mon, 26 Aug 1996 09:31:53 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9608260931.aa11942@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IEEE 802.3 Hub MIB Working Group of the IETF. Title : Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) Author(s) : D. McMaster, K. McCloghrie, S. Roberts, D. Romascanu, K. De Graaf Filename : draft-ietf-hubmib-mau-mib-03.txt Pages : 46 Date : 08/23/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-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-mau-mib-03.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-03.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@ietf.org 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: <19960823150115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-mau-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-mau-mib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960823150115.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16163; 26 Aug 96 19:22 EDT Received: from cnri by ietf.org id aa16159; 26 Aug 96 19:22 EDT Received: from hp.com by CNRI.Reston.VA.US id aa16501; 26 Aug 96 19:22 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA014291134; Mon, 26 Aug 1996 16:12:15 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA034581122; Mon, 26 Aug 1996 16:12:02 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA248541685; Mon, 26 Aug 1996 16:21:25 -0700 Message-Id: <199608262321.AA248541685@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com, Dan Romascano ESD-Tel Subject: Re: [Fwd: Hub MIB to Proposed Standard] In-Reply-To: Your message of "Mon, 26 Aug 1996 12:00:40 +0300." <0483213201660C00@mail.madge.com> Date: Mon, 26 Aug 1996 16:21:25 -0700 Sender:ietf-archive-request@ietf.org From: John Flick Dan, >I recall we had in one of our meetings an argument relative to the order >of appearance of the addresses in the table. We reached the conclusion >that adding a timestamp object is too 'heavy', but a integer index would >be both easier to implement and could be interpreted as a mark for the >order of appearance, if the implementation is capable of providing him >such a significance. It is that last "if" that causes me to wonder how useful this is. If the manager can't depend on the agent to have them in order, what good does it do to say it MIGHT be in order of appearance? >I don't think so. There are plenty of Reset objects in different MIBs, >with impact on the collected data flow and the general rule is that they >do not have a lock/owner. I don't know of any Reset object in a standards-track MIB that causes a discontinuity, without some way of indicating that the discontinuity has happened. Multiple managers can be using the ExtAddrTrackTable, and if one manager sets the Reset object, the other manager will lose data it was using without any indication that this has happened. I don't know of any other standards-track MIB that has this problem. I think that adding warning text would be prudent. Perhaps, rather than a lock/owner scheme, a simple timestamp of last reset would be better (and easier to implement). >LET'S GET THIS STUFF ROLLING! Agreed!!! However, the NM Area reviewer's comments do require a response, even if that response is just the rationale for not making a change. John   Received: from ietf.org by ietf.org id aa25222; 27 Aug 96 1:31 EDT Received: from cnri by ietf.org id aa25218; 27 Aug 96 1:31 EDT Received: from hp.com by CNRI.Reston.VA.US id aa01836; 27 Aug 96 1:31 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA074123488; Mon, 26 Aug 1996 22:24:49 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA075083472; Mon, 26 Aug 1996 22:24:32 -0700 Received: from foxhound.cisco.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA073883471; Mon, 26 Aug 1996 22:24:31 -0700 Received: (kzm@localhost) by foxhound.cisco.com (8.6.12/8.6.5) id WAA03743; Mon, 26 Aug 1996 22:20:45 -0700 Sender:ietf-archive-request@ietf.org From: Keith McCloghrie Message-Id: <199608270520.WAA03743@foxhound.cisco.com> Subject: Re: [Fwd: Hub MIB to Proposed Standard] To: John Flick Date: Mon, 26 Aug 1996 22:20:44 -0700 (PDT) Cc: hubmib@hprnd.rose.hp.com, dromasca@madge.com In-Reply-To: <199608262321.AA248541685@hprnljf.rose.hp.com> from "John Flick" at Aug 26, 96 04:21:25 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: 780 > I don't know of any Reset object in a standards-track MIB that causes > a discontinuity, without some way of indicating that the discontinuity > has happened. Multiple managers can be using the ExtAddrTrackTable, > and if one manager sets the Reset object, the other manager will lose > data it was using without any indication that this has happened. > I don't know of any other standards-track MIB that has this problem. > I think that adding warning text would be prudent. Perhaps, rather > than a lock/owner scheme, a simple timestamp of last reset would be > better (and easier to implement). If these are Counter32 discontinuities, then adding a timestamp object seems the simplest solution, and is as specified in RFC 1902 (see section 7.1.6, 2nd paragraph). Keith.   Received: from ietf.org by ietf.org id aa25818; 27 Aug 96 2:25 EDT Received: from cnri by ietf.org id aa25814; 27 Aug 96 2:25 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa02359; 27 Aug 96 2:25 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA140276791; Mon, 26 Aug 1996 23:19:52 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA078596776; Mon, 26 Aug 1996 23:19:37 -0700 Received: from mail.madge.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA139966775; Mon, 26 Aug 1996 23:19:35 -0700 Received: from Connect2 Message Router by mail.madge.com via Connect2-SMTP 4.00; Mon, 26 Aug 96 23:26:27 -0800 Message-Id: <60AE223201660C00@mail.madge.com> In-Reply-To: <1C0D223201660C00> Date: Tue, 27 Aug 96 9:13:50 +0300 Sender:ietf-archive-request@ietf.org From: Dan Romascano ESD-Tel X-Orig-Sender: Dan Romascano ESD-Tel Organization: Madge Networks To: John Flick , Keith McCloghrie Cc: hubmib@hprnd.rose.hp.com Subject: Re: [Fwd: Hub MIB to Proposed Standard] X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway >If these are Counter32 discontinuities, then adding a timestamp object >seems the simplest solution, and is as specified in RFC 1902 (see section >7.1.6, 2nd paragraph). I support Keith's proposal. Does anyone have a major objection? Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.org by ietf.org id aa11038; 27 Aug 96 15:22 EDT Received: from cnri by ietf.org id aa11034; 27 Aug 96 15:22 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa12051; 27 Aug 96 15:22 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA047493181; Tue, 27 Aug 1996 12:13:01 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA125473146; Tue, 27 Aug 1996 12:12:27 -0700 Received: from ISD.3Com.com (chipcom.com) by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA046263145; Tue, 27 Aug 1996 12:12:25 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA00983; Tue, 27 Aug 96 15:09:26 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA3037; Tue, 27 Aug 96 15:10:30 -0700 Message-Id: <9608272210.AA3037@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id F174F7356D7D96AF8525639300663B09; Tue, 27 Aug 96 15:10:26 EDT To: Dan Romascano ESD-Tel Cc: hubmib Sender:ietf-archive-request@ietf.org From: Kathy deGraaf/US/3Com Date: 27 Aug 96 15:07:44 EDT Subject: Re: [Fwd: Hub MIB to Proposed Standard] Mime-Version: 1.0 Content-Type: Text/Plain > I support Keith's proposal. Does anyone have a major objection? No objection. It sounds like the simplest solution (even though we're not talking about counters). Does the following suggested text look ok? rptrAddrTrackLastResetTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object denotes the value of sysUpTime when rptrExtAddrTrackTable was last reset via the rptrAddrTrackReset object." ::= { rptrAddrTrackPortInfo 4 } Also, just a reminder that John had earlier brought up another issue with the reset object, which isn't addressed in the current draft. He noted that the reset object supposedly empties the rptrExtAddrTrackTable but not the rptrAddrTrackTable, and requested that the reset definition be updated to read that it empties all but ONE of the entries in the rptrExtAddrTrackTable (John, do I have that right?). This would lighten the implementation burden on agents, but it would also mean there is no way to find out whether or not that one remaining address is really current (was it seen in the last 30 seconds, or was it seen two months ago?). If we go with the lastResetTime, I think it becomes more important to clean out that last entry so that the contents of the table are current wrt the timestamp. (Now that I think back on the discussions, was one of the original reasons for the reset object that we wanted a way to clear out old information from the extended table?) --Kathy ----- Previous Message ---------------------------------------------------- To: johnf @ hprnljf.rose.hp.com @ SMTP1 kzm @ cisco.com @ SMTP1 cc: hubmib @ hprnd.rose.hp.com @ SMTP1 From: dromasca @ madge.com ("Dan Romascano ESD-Tel") @ SMTP1 Date: Tuesday August 27, 1996 09:13 AM Subject: Re: [Fwd: Hub MIB to Proposed Standard] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >If these are Counter32 discontinuities, then adding a timestamp object >seems the simplest solution, and is as specified in RFC 1902 (see section >7.1.6, 2nd paragraph). I support Keith's proposal. Does anyone have a major objection? Dan Romascanu, Systems Architecture Team Manager, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dromasca@madge.com -------------------------------------------------------------------------- ----   Received: from ietf.org by ietf.org id aa18154; 27 Aug 96 18:49 EDT Received: from cnri by ietf.org id aa18150; 27 Aug 96 18:49 EDT Received: from hp.com by CNRI.Reston.VA.US id aa14826; 27 Aug 96 18:49 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA108455505; Tue, 27 Aug 1996 15:38:25 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA146005496; Tue, 27 Aug 1996 15:38:16 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA074106062; Tue, 27 Aug 1996 15:47:42 -0700 Message-Id: <199608272247.AA074106062@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com, Kathy deGraaf/US/3Com Subject: Re: [Fwd: Hub MIB to Proposed Standard] In-Reply-To: Your message of "27 Aug 1996 15:07:44 EDT." <9608272210.AA3037@> Date: Tue, 27 Aug 1996 15:47:41 -0700 Sender:ietf-archive-request@ietf.org From: John Flick >> I support Keith's proposal. Does anyone have a major objection? > >No objection. It sounds like the simplest solution (even though we're not >talking about counters). Does the following suggested text look ok? The proposed new object looks fine. >Also, just a reminder that John had earlier brought up another issue with the >reset object, which isn't addressed in the current draft. He noted that the >reset object supposedly empties the rptrExtAddrTrackTable but not the >rptrAddrTrackTable, and requested that the reset definition be updated to read > >that it empties all but ONE of the entries in the rptrExtAddrTrackTable (John, > >do I have that right?). The main problem was that the rptrExtAddrTrackTable definition says: The first entry for each port contains the same MAC address that is given by the rptrAddrTrackNewLastSrcAddress for that port. This seems to imply that the last heard address is always in the table. The description of the reset object contradicts this. One or the other of these descriptions needs to be updated. I proposed resolving the discrepancy in the way that would be easiest to implement. >This would lighten the implementation burden on >agents, but it would also mean there is no way to find out whether or not that > >one remaining address is really current (was it seen in the last 30 seconds, o >r >was it seen two months ago?). If we go with the lastResetTime, I think it >becomes more important to clean out that last entry so that the contents of th >e >table are current wrt the timestamp. (Now that I think back on the discussions >, >was one of the original reasons for the reset object that we wanted a way to >clear out old information from the extended table?) I think this is will be rather difficult to implement for agents that don't have hardware support for more than one address per port, and are filling this table by software polling of the last source address register. They will now have to be keeping track of whether the address in that register has transmitted since the last reset. I think the result will be that agent developers will just choose to not implement this table, rather than buy into this additional burden. John   Received: from ietf.org by ietf.org id aa06218; 29 Aug 96 12:30 EDT Received: from cnri by ietf.org id aa06214; 29 Aug 96 12:30 EDT Received: from relay.hp.com by CNRI.Reston.VA.US id aa10106; 29 Aug 96 12:30 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA171365712; Thu, 29 Aug 1996 09:21:52 -0700 Received: from relay.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA098235597; Thu, 29 Aug 1996 09:20:58 -0700 Received: from ISD.3Com.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA166005516; Thu, 29 Aug 1996 09:18:36 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA15291; Thu, 29 Aug 96 12:15:22 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA1977; Thu, 29 Aug 96 12:16:26 -0700 Message-Id: <9608291916.AA1977@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 626361C84D7409C4852563950058AA8E; Thu, 29 Aug 96 12:16:11 EDT To: John Flick Cc: hubmib Sender:ietf-archive-request@ietf.org From: Kathy deGraaf/US/3Com Date: 29 Aug 96 12:15:30 EDT Subject: Re: [Fwd: Hub MIB to Proposed Standard] Mime-Version: 1.0 Content-Type: Text/Plain I guess I still don't understand why the implementation burden is so high. Earlier you'd mentioned that you would need to snapshot a counter per port, which would be expensive in terms of memory. But couldn't it be done instead with a flag (one bit) per port? Since it's just a question "did I see this address since the last reset? -- yes/no"? I think it would be inconsistent to have an object that supposedly resets the table, and a corresponding timestamp since which all addresses are supposedly current (like I said, I thought that was the point of the reset object), but it doesn't really clean out all the old information after all. If we can't make the reset work right, then I'd rather drop it altogether and make the NMS poll the table to track the changes (maybe this would be a better approach anyway?). --Kathy ----- Previous Message ---------------------------------------------------- To: hubmib @ hprnd.rose.hp.com @ SMTP1 Kathy_deGraaf/US/3Com%3COM @ smtp1.isd.3com.com @ SMTP1 cc: From: johnf @ hprnljf.rose.hp.com (John Flick) @ SMTP1 Date: Tuesday August 27, 1996 03:47 PM Subject: Re: [Fwd: Hub MIB to Proposed Standard] ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> I support Keith's proposal. Does anyone have a major objection? > >No objection. It sounds like the simplest solution (even though we're not >talking about counters). Does the following suggested text look ok? The proposed new object looks fine. >Also, just a reminder that John had earlier brought up another issue with the >reset object, which isn't addressed in the current draft. He noted that the >reset object supposedly empties the rptrExtAddrTrackTable but not the >rptrAddrTrackTable, and requested that the reset definition be updated to read > >that it empties all but ONE of the entries in the rptrExtAddrTrackTable (John, > >do I have that right?). The main problem was that the rptrExtAddrTrackTable definition says: The first entry for each port contains the same MAC address that is given by the rptrAddrTrackNewLastSrcAddress for that port. This seems to imply that the last heard address is always in the table. The description of the reset object contradicts this. One or the other of these descriptions needs to be updated. I proposed resolving the discrepancy in the way that would be easiest to implement. >This would lighten the implementation burden on >agents, but it would also mean there is no way to find out whether or not that > >one remaining address is really current (was it seen in the last 30 seconds, o >r >was it seen two months ago?). If we go with the lastResetTime, I think it >becomes more important to clean out that last entry so that the contents of th >e >table are current wrt the timestamp. (Now that I think back on the discussions >, >was one of the original reasons for the reset object that we wanted a way to >clear out old information from the extended table?) I think this is will be rather difficult to implement for agents that don't have hardware support for more than one address per port, and are filling this table by software polling of the last source address register. They will now have to be keeping track of whether the address in that register has transmitted since the last reset. I think the result will be that agent developers will just choose to not implement this table, rather than buy into this additional burden. John   Received: from ietf.org by ietf.org id aa25086; 29 Aug 96 17:57 EDT Received: from cnri by ietf.org id aa25082; 29 Aug 96 17:57 EDT Received: from [15.255.152.2] by CNRI.Reston.VA.US id aa15243; 29 Aug 96 17:57 EDT Received: from hprnd.rose.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA057815453; Thu, 29 Aug 1996 14:50:53 -0700 Received: from hprnljf.rose.hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA137865351; Thu, 29 Aug 1996 14:49:11 -0700 Received: from localhost by hprnljf.rose.hp.com with SMTP (1.37.109.18/15.5+ECS 3.4 ) id AA021735921; Thu, 29 Aug 1996 14:58:41 -0700 Message-Id: <199608292158.AA021735921@hprnljf.rose.hp.com> To: hubmib@hprnd.rose.hp.com, Kathy deGraaf/US/3Com Subject: Re: [Fwd: Hub MIB to Proposed Standard] In-Reply-To: Your message of "29 Aug 1996 12:15:30 EDT." <9608291916.AA1973@> Date: Thu, 29 Aug 1996 14:58:40 -0700 Sender:ietf-archive-request@ietf.org From: John Flick >I guess I still don't understand why the implementation burden is so high. >Earlier you'd mentioned that you would need to snapshot a counter per port, >which would be expensive in terms of memory. But couldn't it be done instead >with a flag (one bit) per port? Since it's just a question "did I see this >address since the last reset? -- yes/no"? There are several possible ways to implement this feature. Some incur additional memory costs (like the counter snapshot). Some incur additional CPU costs (like the 'have we seen it?' flag). Hardware capabilities will determine just how much of a burden it is. Existing proprietary features may affect how much of a delta it is over current implementations. The question I am trying to keep in mind is this: When we reactivate to go from Proposed to Draft, and conduct an implementor's survey of this MIB, how many implementations of this table will we find? I currently don't know of any apps that are actually planning on using this table. If it isn't easy for an agent to implement, I don't think it will be implemented. That said, I don't want this issue to delay things any longer. I don't really care which way we go with this, as long as the table description and reset description are made consistent. >I think it would be inconsistent to > >have an object that supposedly resets the table, and a corresponding timestamp > >since which all addresses are supposedly current (like I said, I thought that >was the point of the reset object), but it doesn't really clean out all the ol >d >information after all. If we can't make the reset work right, then I'd rather > >drop it altogether and make the NMS poll the table to track the changes (maybe > >this would be a better approach anyway?). As I mentioned in my response to Bob's review comments, I have never been particularly fond of the reset object, for the very reason that Bob brought up. I would not mourn its passing. John   Received: from ietf.org by ietf.org id aa07397; 30 Aug 96 15:09 EDT Received: from cnri by ietf.org id aa07393; 30 Aug 96 15:09 EDT Received: from hp.com by CNRI.Reston.VA.US id aa11870; 30 Aug 96 15:09 EDT Received: from hprnd.rose.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA028091757; Fri, 30 Aug 1996 12:02:37 -0700 Received: from hp.com by hprnd.rose.hp.com with ESMTP (1.37.109.18/15.5+ECS 3.3) id AA262901702; Fri, 30 Aug 1996 12:01:43 -0700 Received: from ISD.3Com.com (chipcom.com) by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA026811701; Fri, 30 Aug 1996 12:01:41 -0700 Received: from (smtp1.chipcom.com) by ISD.3Com.com (4.1/SMI-4.0) id AA07133; Fri, 30 Aug 96 14:58:42 EDT Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.2) id AA6893; Fri, 30 Aug 96 14:59:48 -0700 Message-Id: <9608302159.AA6893@> Received: by 3Com (Lotus Notes Mail Gateway for SMTP V1.1) id 17834765A95282388525639600683F01; Fri, 30 Aug 96 14:59:35 EDT To: John Flick Cc: hubmib , Kathy deGraaf/US/3Com Sender:ietf-archive-request@ietf.org From: Kathy deGraaf/US/3Com Date: 30 Aug 96 14:59:35 EDT Subject: Re: [Fwd: Hub MIB to Proposed Standard] Mime-Version: 1.0 Content-Type: Text/Plain John said: > ... I would not mourn its passing. In that case, I'd like to move that we get rid of it. Anybody else want to offer an opinion? --Kathy