From owner-snmpv3@lists.tislabs.com Mon Feb 3 10:53:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11107 for ; Mon, 3 Feb 2003 10:53:55 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00978 Mon, 3 Feb 2003 09:49:52 -0500 (EST) Date: Fri, 31 Jan 2003 23:01:28 -0500 From: David Dickson Subject: Information Sharing Training Conference - Feb 25 - Arlington, VA To: SNMPV3@lists.tislabs.com Message-id: <4117736-220032614128330@emarketing> Organization: Market*Access MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7BIT To: SNMPV3@LISTS.TISLABS.COM Information Sharing Homeland Defense Training Conference(tm) February 25, 2003 Executive Conference Center (NRECA Building) 4301 Wilson Boulevard Arlington, Virginia 22203 Time: 7:00 AM Registration Program Starts: 8:30 AM Wrap-up: 4:45 PM Continental Breakfast, Refreshments, Lunch included. **** For information on how you can register on line and view our web site with a current list of speakers, call our Training Conference Hotline at 703-807-2027. **** ABOUT THIS TRAINING CONFERENCE: Information contributes to every aspect of homeland security and is a vital foundation for the homeland security effort. Every government official performing every homeland security mission depends upon information and information technology. Although American information technology is the most advanced in the world, our country's information systems have not adequately supported the homeland security mission. Much of the information needed to support the war on terrorism is in disparate databases scattered among federal, state, and local entities. In many cases, these computer systems cannot share information-either "horizontally" (across the same level of government) or "vertically" (between federal, state, and local governments). However, since 9.11, there have been significant efforts to address this challenge. This conference will examine the many steps now being taken to address this national imperative. Federal, state, local, regional and industry initiatives will be presented. Focus will be on best practices, lessons-learned and innovation. WHO SHOULD ATTEND: * CIOs at federal, state and corporate levels * CTOs at federal, state and corporate levels * Government program managers for information systems planning, development and operation * Information system planners and developers * Senior management and marketing for solutions providers WHAT YOU WILL LEARN: * New information sharing initiatives * Special needs and requirements for sharing information * New initiatives being planned at the federal, state, regional and local levels * New technologies and products in development and on the drawing boards * Lessons-learned * Best practices * What works - what doesn't SPEAKERS INVITED: * Angelo Fiumara, Deputy Director , RISS Office of Information Technology [Government Keynote Speaker] * Dr. Robert L. Popp, Deputy Director, DARPA/IAO (Information Awareness Office) * COL Ted Dmuchowski, Director of Information Assurance, Information Assurance Division, (Tactical), Initiative for State Infrastructure Protection (ISIP), HQDA, CIO/G6, US ARMY * Rob Atkinson, Vice-President and Director of the Technology and New Economy Project, The Progressive Policy Institute * Kevin Miller, Special Agent, InfraGard Program, FBI * George Brundage, Chief Enterprise Architect, Department of the Treasury * Speaker TBD, Open GIS Consortium (OGC) (Discussing GIS Interoperability Standards) * Speaker TBD, NCI Information Systems (Invited) * George Molaski, President and CEO, e-Associates, (Former CIO US Department of Transportation and Principal, Council for Excellence in Government) * Mark Lavoie, Communications Officer, Director of Navy Marine Corps Intranet (NMCI) Office ...other speakers to be announced. ATTN: Solutions and Product Suppliers ... Excellent Exhibitor and Sponsor opportunities are available! POINTS OF CONTACT: * For information on sponsorship opportunities and exhibitor arrangements, please contact Ms. Donna Anderson at 703-807-2740 * For registration or general information about this event, please contact Mr. Parrish Knight, 703/807-2748. SPONSORS: Symantec Information Builders Alvarion Broadband Wireless Xaware ...additional sponsors to be announced. ****How to leverage your marketing dollars - Exhibitor and Sponsor Opportunities available! If you would like to showcase your products and services, have access to over 50,000 readers of the Homeland Defense Journal and network with government and industry executives that make decisions on purchasing your products and services, sign up to be a sponsor or exhibitor at this conference. Information, rates and options are outlined in our set of exhibitor forms. To learn about marketing, sales and advertising programs available from Market*Access and the Homeland Defense Journal, call our Training Conference hotline for website information. **** For information on how you can register on line and view our web site with a current list of speakers, call our Training Conference Hotline at 703-807-2027. **** The REGISTRATION FEE for this important training conference is: * Government: $395 * Industry: $595 Credit cards and checks are accepted. Registration fee includes conference, refreshments, lunch and conference proceedings. REGISTRATION OPTIONS: [1] Phone: 703-807-2748. [2] Register online: Use our online booking form to register and pay by credit card electronically. Call our hotline at 703-807-2027 for website information. [3] Fax: registration form to 703-807-2728. To register by phone or to request more information: Call 703-807-2748. DIRECTIONS TO THE EXECUTIVE CONFERENCE CENTER: The Ellipse Conference Center at Ballston The National Rural Electric Cooperative Association, Plaza Level 4301 Wilson Boulevard, Arlington, Virginia 22203 TRANSPORTATION AND PARKING: At the corner of Wilson Boulevard and N. Taylor in the heart of Arlington's Ballston district, the Ellipse Conference Center is easily accessible by public transportation or automobile. >From Metro's Orange Line, exit at Ballston; NRECA is less than one block southwest from the Ballston Station. A covered walkway is available from the Metro Station Plaza to the Ballston Common Mall; NRECA is less than one block northwest from the mall exit. >From I-66, take the Glebe Road/Ballston Exit. Follow Glebe until it intersects with Wilson; turn left onto Wilson and left again onto N. Taylor Street. The building's four-level parking garage is accessible from the N. Taylor Street ramp. Rates start at $2.50 per hour. Two shuttle elevators operate from each garage level to the Plaza Lobby. Access for the Disabled: The NRECA building and Ellipse Conference Center meet all ADA requirements and are completely accessible to the disabled. Marketing, Conference Management and Production by: Market*Access International, Inc. (301) 455-5633 ************************************************** REGISTRATION FORM Information Sharing Homeland Defense Training Conference February 25, 2003 Registration Form (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Company/Agency Web site: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Boulevard, Suite 1003, Arlington VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order _______________________________________ Pre-Registration Fee: Industry Credit Card or Check in Advance $595 Government Credit Card or Check in Advance $395 Registration and Information: Call Parrish S. Knight (703) 807-2748 Fax this form to 703-807-2728. Thank you. I would be very interested in attending a future training conference on the subject of: _________________________________________ I am a manager/subject matter expert for the following technical/mission area: _________________________________________ The most significant challenge my organization faces is: _________________________________________ Here are email addresses of my contacts and peers who should be invited to this conference: _________________________________________ NOTE: If you would like to be removed from our distribution list, please REPLY by placing REMOVE in the subject line and we will delete you from our listing. If you wish to be REMOVED from this list, please REPLY to this message and place REMOVE in the SUBJECT line. This is a business communication and we do not wish to send you an email message if you do not wish to receive one. Thank you. From owner-snmpv3@lists.tislabs.com Mon Feb 3 17:48:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24314 for ; Mon, 3 Feb 2003 17:48:12 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02605 Mon, 3 Feb 2003 16:58:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: coex last call Date: Mon, 3 Feb 2003 17:00:50 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602F5D@NHROCMBX1.ets.enterasys.com> Thread-Topic: coex last call Thread-Index: AcLLz5m8GiwLpMAcS6Gph/eG1i4MNw== From: "Harrington, David" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 03 Feb 2003 22:00:50.0601 (UTC) FILETIME=[B6D70990:01C2CBCF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA02602 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I am trying to determine consensus on the following change. It is my impression that we have rough consensus to make the change. Does anybody strongly object to making the proposed change? >So I still say that right thing to do is to change "MUST" to "SHOULD" >in paragraph (3) of the first numbered list in Section 2.1.1 and to >move this paragraph into the 2nd list in Section 2.1.1 (which is the >list of changes that are desirable but not absolutely required). dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks From owner-snmpv3@lists.tislabs.com Mon Feb 3 17:58:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24527 for ; Mon, 3 Feb 2003 17:58:08 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02649 Mon, 3 Feb 2003 17:18:33 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6C3D2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: RE: coex last call Date: Mon, 3 Feb 2003 23:20:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk No objection from me. In fact I support the change. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 3 februari 2003 23:01 > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: coex last call > > > Hi, > > I am trying to determine consensus on the following change. > It is my impression that we have rough consensus to make the > change. Does anybody strongly object to making the proposed change? > > >So I still say that right thing to do is to change "MUST" to "SHOULD" > >in paragraph (3) of the first numbered list in Section 2.1.1 and to > >move this paragraph into the 2nd list in Section 2.1.1 (which is the > >list of changes that are desirable but not absolutely required). > > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks > > From owner-snmpv3@lists.tislabs.com Tue Feb 4 19:52:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09341 for ; Tue, 4 Feb 2003 19:52:56 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06393 Tue, 4 Feb 2003 18:58:41 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: coex last call X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 Feb 2003 19:01:40 -0500 Message-ID: <23E9D952BB39FC4B9E6410AAF23E2376B0218E@dc2kex01.vibrant-1.com> Thread-Topic: coex last call Thread-Index: AcLL2DlAcYrRNdZOSlSOWcGcPJHLfwA0PMiA From: "Frye, Rob" To: "Wijnen, Bert (Bert)" , "Snmpv3@Lists.Tislabs.Com (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA06389 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit No objection. I made that change already in what I sent to Bert. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, February 03, 2003 5:21 PM To: Snmpv3@Lists.Tislabs.Com (E-mail) Subject: RE: coex last call No objection from me. In fact I support the change. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 3 februari 2003 23:01 > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: coex last call > > > Hi, > > I am trying to determine consensus on the following change. > It is my impression that we have rough consensus to make the > change. Does anybody strongly object to making the proposed change? > > >So I still say that right thing to do is to change "MUST" to "SHOULD" > >in paragraph (3) of the first numbered list in Section 2.1.1 and to > >move this paragraph into the 2nd list in Section 2.1.1 (which is the > >list of changes that are desirable but not absolutely required). > > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks > > From owner-snmpv3@lists.tislabs.com Fri Feb 7 12:11:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15756 for ; Fri, 7 Feb 2003 12:11:38 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16496 Fri, 7 Feb 2003 11:05:57 -0500 (EST) Date: Fri, 31 Jan 2003 23:01:28 -0500 From: David Dickson Subject: Information Sharing Training Conference - Feb 25 - Arlington, VA To: SNMPV3@lists.tislabs.com Message-id: <4117736-220032614128330@emarketing> Organization: Market*Access MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7BIT To: SNMPV3@LISTS.TISLABS.COM Information Sharing Homeland Defense Training Conference(tm) February 25, 2003 Executive Conference Center (NRECA Building) 4301 Wilson Boulevard Arlington, Virginia 22203 Time: 7:00 AM Registration Program Starts: 8:30 AM Wrap-up: 4:45 PM Continental Breakfast, Refreshments, Lunch included. **** For information on how you can register on line and view our web site with a current list of speakers, call our Training Conference Hotline at 703-807-2027. **** ABOUT THIS TRAINING CONFERENCE: Information contributes to every aspect of homeland security and is a vital foundation for the homeland security effort. Every government official performing every homeland security mission depends upon information and information technology. Although American information technology is the most advanced in the world, our country's information systems have not adequately supported the homeland security mission. Much of the information needed to support the war on terrorism is in disparate databases scattered among federal, state, and local entities. In many cases, these computer systems cannot share information-either "horizontally" (across the same level of government) or "vertically" (between federal, state, and local governments). However, since 9.11, there have been significant efforts to address this challenge. This conference will examine the many steps now being taken to address this national imperative. Federal, state, local, regional and industry initiatives will be presented. Focus will be on best practices, lessons-learned and innovation. WHO SHOULD ATTEND: * CIOs at federal, state and corporate levels * CTOs at federal, state and corporate levels * Government program managers for information systems planning, development and operation * Information system planners and developers * Senior management and marketing for solutions providers WHAT YOU WILL LEARN: * New information sharing initiatives * Special needs and requirements for sharing information * New initiatives being planned at the federal, state, regional and local levels * New technologies and products in development and on the drawing boards * Lessons-learned * Best practices * What works - what doesn't SPEAKERS INVITED: * Angelo Fiumara, Deputy Director , RISS Office of Information Technology [Government Keynote Speaker] * Dr. Robert L. Popp, Deputy Director, DARPA/IAO (Information Awareness Office) * COL Ted Dmuchowski, Director of Information Assurance, Information Assurance Division, (Tactical), Initiative for State Infrastructure Protection (ISIP), HQDA, CIO/G6, US ARMY * Rob Atkinson, Vice-President and Director of the Technology and New Economy Project, The Progressive Policy Institute * Kevin Miller, Special Agent, InfraGard Program, FBI * George Brundage, Chief Enterprise Architect, Department of the Treasury * Speaker TBD, Open GIS Consortium (OGC) (Discussing GIS Interoperability Standards) * Speaker TBD, NCI Information Systems (Invited) * George Molaski, President and CEO, e-Associates, (Former CIO US Department of Transportation and Principal, Council for Excellence in Government) * Mark Lavoie, Communications Officer, Director of Navy Marine Corps Intranet (NMCI) Office ...other speakers to be announced. ATTN: Solutions and Product Suppliers ... Excellent Exhibitor and Sponsor opportunities are available! POINTS OF CONTACT: * For information on sponsorship opportunities and exhibitor arrangements, please contact Ms. Donna Anderson at 703-807-2740 * For registration or general information about this event, please contact Mr. Parrish Knight, 703/807-2748. SPONSORS: Symantec Information Builders Alvarion Broadband Wireless Xaware ...additional sponsors to be announced. ****How to leverage your marketing dollars - Exhibitor and Sponsor Opportunities available! If you would like to showcase your products and services, have access to over 50,000 readers of the Homeland Defense Journal and network with government and industry executives that make decisions on purchasing your products and services, sign up to be a sponsor or exhibitor at this conference. Information, rates and options are outlined in our set of exhibitor forms. To learn about marketing, sales and advertising programs available from Market*Access and the Homeland Defense Journal, call our Training Conference hotline for website information. **** For information on how you can register on line and view our web site with a current list of speakers, call our Training Conference Hotline at 703-807-2027. **** The REGISTRATION FEE for this important training conference is: * Government: $395 * Industry: $595 Credit cards and checks are accepted. Registration fee includes conference, refreshments, lunch and conference proceedings. REGISTRATION OPTIONS: [1] Phone: 703-807-2748. [2] Register online: Use our online booking form to register and pay by credit card electronically. Call our hotline at 703-807-2027 for website information. [3] Fax: registration form to 703-807-2728. To register by phone or to request more information: Call 703-807-2748. DIRECTIONS TO THE EXECUTIVE CONFERENCE CENTER: The Ellipse Conference Center at Ballston The National Rural Electric Cooperative Association, Plaza Level 4301 Wilson Boulevard, Arlington, Virginia 22203 TRANSPORTATION AND PARKING: At the corner of Wilson Boulevard and N. Taylor in the heart of Arlington's Ballston district, the Ellipse Conference Center is easily accessible by public transportation or automobile. >From Metro's Orange Line, exit at Ballston; NRECA is less than one block southwest from the Ballston Station. A covered walkway is available from the Metro Station Plaza to the Ballston Common Mall; NRECA is less than one block northwest from the mall exit. >From I-66, take the Glebe Road/Ballston Exit. Follow Glebe until it intersects with Wilson; turn left onto Wilson and left again onto N. Taylor Street. The building's four-level parking garage is accessible from the N. Taylor Street ramp. Rates start at $2.50 per hour. Two shuttle elevators operate from each garage level to the Plaza Lobby. Access for the Disabled: The NRECA building and Ellipse Conference Center meet all ADA requirements and are completely accessible to the disabled. Marketing, Conference Management and Production by: Market*Access International, Inc. (301) 455-5633 ************************************************** REGISTRATION FORM Information Sharing Homeland Defense Training Conference February 25, 2003 Registration Form (Use additional pages as needed for multiple employees) Attendee Name: Title: Company/Agency: Company/Agency Web site: Address: City: State: Zip Code: Email: Telephone: Fax: Note: Payment requested in advance. Please check one of the following as your form of payment: [ ] Check Make checks payable to: Market*Access International Send to: Market*Access, 4301 Wilson Boulevard, Suite 1003, Arlington VA 22203 [ ] VISA [ ] MasterCard [ ] American Express Account Number: ___________________________Exp. Date___________________ Cardholder Name: ______________________________________________________ Signature (required) or telephone order _______________________________________ Pre-Registration Fee: Industry Credit Card or Check in Advance $595 Government Credit Card or Check in Advance $395 Registration and Information: Call Parrish S. Knight (703) 807-2748 Fax this form to 703-807-2728. Thank you. I would be very interested in attending a future training conference on the subject of: _________________________________________ I am a manager/subject matter expert for the following technical/mission area: _________________________________________ The most significant challenge my organization faces is: _________________________________________ Here are email addresses of my contacts and peers who should be invited to this conference: _________________________________________ NOTE: If you would like to be removed from our distribution list, please REPLY by placing REMOVE in the subject line and we will delete you from our listing. If you wish to be REMOVED from this list, please REPLY to this message and place REMOVE in the SUBJECT line. This is a business communication and we do not wish to send you an email message if you do not wish to receive one. Thank you. From owner-snmpv3@lists.tislabs.com Tue Feb 11 22:23:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26583 for ; Tue, 11 Feb 2003 22:23:19 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10416 Tue, 11 Feb 2003 21:34:28 -0500 (EST) Message-ID: <007d01c2d240$458550e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Subject: Re: IESG Statement on IDN Date: Tue, 11 Feb 2003 18:41:40 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - Consequently, the value of sysName for such a system would be the ascii-encoded form of the IDNA name, right? Randy > From: "The IESG" > To: > Sent: Tuesday, February 11, 2003 6:04 PM > Subject: IESG Statement on IDN > > > IESG Statement on IDN: > > IDNA [IDNA] specifies an encoding of characters in the Unicode > character repertoire [UNICODE] which is backwards-compatible with the > current definition of hostnames. This implies that domain names > encoded according to IDNA will be able to be transported between > peers using any existing protocol, including DNS. > > IDNA, through its requirement of Nameprep [NAMEPREP], uses equivalence > tables that are based only on the characters themselves; no attention > is paid to the intended language (if any) for the domain name. However, > for many domain names, the intended language of one or more parts of > the domain name actually does matter to the users. > > Similarly, many names cannot be presented and used without ambiguity > unless the scripts to which their characters belong are known. In both > cases, this additional information should be of concern to the registry. > > If there are no constraints on registration in a zone, people can > register combinations of characters in a manner that increases the > risk of misunderstandings, cybersquatting, and other forms of > confusion. A somewhat similar situation existed before the introduction > of IDNA exemplified by domain names such as example.com and examp1e.com > (note that the latter domain has the digit "1" instead of the letter > "L"). > > For some human languages, there are strings of characters that have > equivalent or near-equivalent meanings. When someone registers a name > containing such a string, the registry might want to automatically > generate a list of semantically or visually equivalent strings and > suggest that they also be registered. Further, some registries might > want to prevent particular characters for language-based reasons. > > Some registries, in particular the gTLD ones, are not naturally part > of any specific language group. In these cases, extra care must be > taken not to create unacceptable problems for any of the languages that > might be used. > > It is suggested that a registry act conservatively when starting to > accept IDNA-based domain names. Equivalences are very hard (if not > impossible) to define after registration has started. Assume that the > labels "x" and "y" at first are different, but later the tables for the > registry are changed so that "x" and "y" are then treated as being the > same. If x.example.com and y.example.com both were already registered > to different registrants, it is unclear which of them has to withdraw > the registration, how that selection process done, and so on. Thus, > having complete, publicly-stated policies before accepting > registration will lead to a much more stable registration process. > > There are also other problems that we know to be difficult when > dealing with IDNA-based domain names, for instance when to convert them > between their display format and their wire format, how to deal with > display formats on systems that do not support all of Unicode 3.2, and > how to deal with the problem of domain names in one format showing up > where names in the other format was expected by protocols or by people. > These problems are largely outside the scope of the IDNA standards > themselves, but they are of concern to anyone attempting to implement > the IDNA standard in products. See the IDNA specification for more > examples. > > The use of display-format IDNA-based domain names in other protocols > is not yet part of any standard; implementors are admonished to use > the wire format, i.e. ASCII-encoded, of the name until protocol > updates allowing the use of display format, e.g. Unicode-based > international character/glyph, are standardized. > > [IDNA] "Internationalizing Domain Names in Applications (IDNA)", > draft-ietf-idn-idna. > > [NAMEPREP] "Nameprep: A Stringprep Profile for Internationalized Domain > Names", draft-ietf-idn-nameprep. > > [UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 > is defined by The Unicode Standard, Version 3.0 (Reading, MA, > Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode > Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) > and by the Unicode Standard Annex #28: Unicode 3.2 > (http://www.unicode.org/reports/tr28/). > From owner-snmpv3@lists.tislabs.com Wed Feb 12 01:40:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00315 for ; Wed, 12 Feb 2003 01:40:40 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12046 Wed, 12 Feb 2003 00:58:35 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: coex last call X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 Feb 2003 19:01:40 -0500 Message-ID: <23E9D952BB39FC4B9E6410AAF23E2376B0218E@dc2kex01.vibrant-1.com> Thread-Topic: coex last call Thread-Index: AcLL2DlAcYrRNdZOSlSOWcGcPJHLfwA0PMiA From: "Frye, Rob" To: "Wijnen, Bert (Bert)" , "Snmpv3@Lists.Tislabs.Com (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA06389 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit No objection. I made that change already in what I sent to Bert. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Monday, February 03, 2003 5:21 PM To: Snmpv3@Lists.Tislabs.Com (E-mail) Subject: RE: coex last call No objection from me. In fact I support the change. Thanks, Bert > -----Original Message----- > From: Harrington, David [mailto:dbh@enterasys.com] > Sent: maandag 3 februari 2003 23:01 > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: coex last call > > > Hi, > > I am trying to determine consensus on the following change. > It is my impression that we have rough consensus to make the > change. Does anybody strongly object to making the proposed change? > > >So I still say that right thing to do is to change "MUST" to "SHOULD" > >in paragraph (3) of the first numbered list in Section 2.1.1 and to > >move this paragraph into the 2nd list in Section 2.1.1 (which is the > >list of changes that are desirable but not absolutely required). > > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks > > From owner-snmpv3@lists.tislabs.com Fri Feb 14 11:00:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25627 for ; Fri, 14 Feb 2003 11:00:55 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23233 Fri, 14 Feb 2003 09:57:07 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D3AF.7ACA0170" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: FW: Status of the WG Date: Thu, 13 Feb 2003 17:30:15 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA602FC4@NHROCMBX1.ets.enterasys.com> Thread-Topic: Status of the WG Thread-Index: AcLTpPF7Cj3VZHQjRXSu9hK/sBt57gAAO1NQAAJZLbA= From: "Harrington, David" To: "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 13 Feb 2003 22:30:15.0459 (UTC) FILETIME=[7AE87F30:01C2D3AF] Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D3AF.7ACA0170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a slightly different viewpoint.=20 =20 Both eos and sming are developing add-ons to SNMPv3. And I think SNMPv3 = is the problem. SNMPv3 is incomplete, and the things it needs are not = new mib syntax or compressed PDUs or TCP support. What it needs is some = guidance about how to deploy it, and how to migrate a network, and = network management tools, from SNMPv1 to SNMPv3. =20 SNMPv3, as currently defined, is difficult to deploy. There is no = standardized initial key distribution mechanism, only an experimental = Diffie-Hellman approach. There is no integration with centralized key = management and authorization, such as RADIUS; one approach exists for = Kerberos, but that has been labeled experimental, and Kerberos does not = seem to be in wide commercial use. There has been no official work to = standardized the widely desired AES support. There has been no work to = guide operators/vendors how to provide support for VACM views, given the = design of existing mibs. There has been no work to guide mib writers how = to write VACM-friendly mibs. There has been no work to define an = easier-to-deploy access control model.=20 =20 The five leading network/systems management frameworks - HPOV, BMC = Patrol, CA-Unicenter, Tivoli TME, and Spectrum - offer little support = for SNMPv3 messaging, and no support for managing the elements of SNMPv3 = such as users, views, and groups. Best-of-breed application vendors such = as Concord Communications and Micromuse do not offer SNMPv3 support. = Equipment vendors have provided support for SNMPv3 in their devices, but = even their own applications, such as CiscoWorks, hide the details of the = underlying SNMPv3 systems, and do not take advantage of the power of = SNMPv3 concepts. =20 No SNMP applications have been developed to manage SNMPv3 key = distribution in-band between multiple agents and multiple applications. = I have seen no applications to provide an easy graphical way to define = and distribute VACM views.=20 =20 There are a number of applications that do policy-based management, = including assigning roles to users, but they have not been integrated = with SNMPv3 users and groups. Different operators often manage different = aspects of networks, such as routing or security, but no standards have = been developed to define policy-based division of labor for Network = Management protocols. =20 No standards have been defined for integrating the security models of = SNMPv3 and CLI and web-based management. Securing one interface but not = the others makes no sense. No work has been done to define how one = should distribute SNMPv3 keys in CLI command scripts. =20 EOS and SMING are interesting research projects, but they aren't very = practical because they depend on a protocol and a security design that = nobody can deploy reasonably. Before EOS and SMING become truly = relevant, we need to help the industry get SNMPv3 deployed. =20 We really need to decide whether we believe SNMPv3 is worth the effort = to help get it deployed. If not, we should declare it Historic, pick an = alternative, and move on. If we want it to be accepted, then we need to = help the industry understand how to deploy it. So far, we have simply = chosen to not get involved. If we don't believe it's worth the work, why = should operators and vendors believe it's worth the work? =20 I propose we deactivate EOS and SMING, and combine our efforts in an = SNMPv3 deployment WG. This would be a good opportunity to have the = network management experts and the operations experts work together to = develop some recommended practices and the necessary missing pieces to = make SNMPv3 a deployable secure network management protocol. =20 dbh =20 -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: Thursday, February 13, 2003 4:06 PM To: Durham, David Cc: Wijnen, Bert (Bert); Sming (E-mail); Randy Bush (E-mail) Subject: RE: Status of the WG At 09:39 AM 2/13/2003 -0800, Durham, David wrote: >The silence is deafening, and says it all. It seems that while most are >in agreement that SMI is seriously antiquated, convoluted, and requires >several maintenance fixes, there is very little (apparently zero now) >interest in fixing it and improving it. It would seem people are >satisfied with SNMP being regulated to a legacy systems management >interface. > >There is the realization that up-to-date data modeling languages are >already widely used and available (e.g. XMLSchema), and that the IETF >should not be engaged in the task of inventing yet another = idiosyncratic >data modeling language... Particularly given that it will seriously >languish behind those that are commonly available today. > >Looking at the ROI on this effort, there are those who are asking why >not just adopt what is already available and stop beating a dead horse >in the hopes it will rise. I agree with this assessment. It would be a large development effort to move from SMIv2 to any new syntax. The key question is how much benefit will be realized by making a particular change. While I still believe there is enough benefit in the data modeling features of SMI-DS to make it worthwhile, I no longer believe that SNMP vendors and customers are willing to incur any significant cost to get this benefit. I think the resources devoted to SNMP development are diminishing quickly (as expected for a legacy technology), and developers and customers believe SMIv2 is good enough, for the amount of effort they are willing to invest in SNMP. The cost/benefit ratio for SMIv2.1 seems worthwhile. The need for HC data types has been known since (at least) 1992. Mandatory maintenance of SMIv2 is something that should already be done, so better late than never. Keep in mind that the decision to abandon SMIv3 (and EOS) sends a clear message to vendors and customers that SNMP technology has reached its peak. What we have now is as good as its ever going to get. Those that are happy with SNMPv3/SMIv2 will continue to use it. Those looking for something better will accelerate their efforts to transition to something else. >-Dave Andy >> -----Original Message----- >> From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com] >> >> So... not much (if anything) seems to be happening. >> ------_=_NextPart_001_01C2D3AF.7ACA0170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Status of the WG
Hi,
 
I have=20 a slightly different viewpoint.
 
Both=20 eos and sming are developing add-ons to SNMPv3. And I think SNMPv3 is = the=20 problem. SNMPv3 is incomplete, and the things it needs = are not new=20 mib syntax or compressed PDUs or TCP support. What it needs is some = guidance=20 about how to deploy it, and how to migrate a network, and network = management=20 tools, from SNMPv1 to SNMPv3.
 
SNMPv3, as=20 currently defined, is difficult to deploy. = There is no=20 standardized initial key distribution mechanism, only an experimental=20 Diffie-Hellman approach. There is no integration with = centralized key=20 management and authorization, such as RADIUS; one approach exists for = Kerberos,=20 but that has been labeled experimental, and Kerberos does not seem to be = in wide=20 commercial use. There has been no official work to standardized the = widely=20 desired AES support. There has been no work to guide=20 operators/vendors how to provide support for VACM views, given the = design of=20 existing mibs. There has been no work to guide mib writers how = to write=20 VACM-friendly mibs. There has been no work to define an easier-to-deploy = access=20 control model.
 
The=20 five leading network/systems management frameworks - HPOV, BMC = Patrol,=20 CA-Unicenter, Tivoli TME, and Spectrum - offer little support for SNMPv3 = messaging, and no support for managing the elements of SNMPv3 such = as=20 users, views, and groups. Best-of-breed application vendors such as = Concord=20 Communications and Micromuse do not offer SNMPv3 support. Equipment vendors have provided support for = SNMPv3 in their=20 devices, but even their own applications, such as CiscoWorks, hide = the=20 details of the underlying SNMPv3 systems, and do not take advantage of = the power=20 of SNMPv3 concepts.
 
No SNMP applications have been = developed to=20 manage SNMPv3 key distribution in-band between multiple agents and = multiple=20 applications. I have seen no applications to provide an easy graphical = way to=20 define and distribute VACM views.
 
There are a number of applications = that do=20 policy-based management, including assigning roles to users, but they = have not=20 been integrated with SNMPv3 users and groups. Different operators often = manage=20 different aspects of networks, such as routing or security, but no=20 standards have been developed to define policy-based division of labor = for=20 Network Management protocols.
 
No standards have been defined for = integrating=20 the security models of SNMPv3 and CLI and web-based management. Securing = one=20 interface but not the others makes no sense. No work has been done to = define how=20 one should distribute SNMPv3 keys in CLI command=20 scripts.
 
EOS and SMING are interesting = research projects,=20 but they aren't very practical because they depend on a protocol and a = security=20 design that nobody can deploy reasonably. Before EOS and SMING become truly relevant, we = need to help=20 the industry get SNMPv3 deployed.
 
We really need to decide whether = we believe=20 SNMPv3 is worth the effort to help get it deployed. If not, we should = declare it=20 Historic, pick an alternative, and move on. If we want it to be = accepted,=20 then we need to help the industry understand how to deploy it. So far, = we have=20 simply chosen to not get involved. If we don't believe it's worth the = work, why=20 should operators and vendors believe it's worth the=20 work?
 
I propose we deactivate EOS and = SMING, and=20 combine our efforts in an SNMPv3 deployment WG. This would be a good = opportunity=20 to have the network management experts and the operations experts work = together=20 to develop some recommended practices and the necessary missing pieces = to make=20 SNMPv3 a deployable secure network management=20 protocol.
 
dbh
 
 -----Original = Message-----
From:=20 Andy Bierman [mailto:abierman@cisco.com]
Sent: Thursday, = February 13,=20 2003 4:06 PM
To: Durham, David
Cc: Wijnen, Bert = (Bert);=20 Sming (E-mail); Randy Bush (E-mail)
Subject: RE: Status of the = WG

At 09:39 AM 2/13/2003 -0800, Durham, David = wrote:
>The=20 silence is deafening, and says it all. It seems that while most = are
>in=20 agreement that SMI is seriously antiquated, convoluted, and=20 requires
>several maintenance fixes, there is very little = (apparently=20 zero now)
>interest in fixing it and improving it. It would seem = people=20 are
>satisfied with SNMP being regulated to a legacy systems=20 management
>interface.
>
>There is the realization = that=20 up-to-date data modeling languages are
>already widely used and=20 available (e.g. XMLSchema), and that the IETF
>should not be = engaged in=20 the task of inventing yet another idiosyncratic
>data modeling=20 language... Particularly given that it will seriously
>languish = behind=20 those that are commonly available today.
>
>Looking at the = ROI on=20 this effort, there are those who are asking why
>not just adopt = what is=20 already available and stop beating a dead horse
>in the hopes it = will=20 rise.

I agree with this assessment.  It would be a large=20 development
effort to move from SMIv2 to any new syntax.  The = key=20 question
is how much benefit will be realized by making a = particular=20 change.

While I still believe there is enough benefit in the = data=20 modeling
features of SMI-DS to make it worthwhile, I no longer = believe=20 that
SNMP vendors and customers are willing to incur any = significant=20 cost
to get this benefit.  I think the resources devoted to=20 SNMP
development are diminishing quickly (as expected for a=20 legacy
technology), and developers and customers believe SMIv2 = is
good=20 enough, for the amount of effort they are willing to
invest in=20 SNMP.

The cost/benefit ratio for SMIv2.1 seems = worthwhile. =20 The
need for HC data types has been known since (at least)=20 1992.
Mandatory maintenance of SMIv2 is something that should = already
be=20 done, so better late than never.

Keep in mind that the decision = to=20 abandon SMIv3 (and EOS)
sends a clear message to vendors and = customers that=20 SNMP
technology has reached its peak. What we have now is
as = good as its=20 ever going to get.  Those that are happy
with SNMPv3/SMIv2 = will=20 continue to use it.  Those looking
for something better will=20 accelerate their efforts to
transition to something=20 else.


>-Dave

Andy



>> = -----Original=20 Message-----
>> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>= >
>>=20 So... not much (if anything) seems to be=20 = happening.
>>


------_=_NextPart_001_01C2D3AF.7ACA0170-- From owner-snmpv3@lists.tislabs.com Fri Feb 14 15:13:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03465 for ; Fri, 14 Feb 2003 15:13:10 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26198 Fri, 14 Feb 2003 14:32:24 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 14 Feb 2003 14:34:45 -0500 From: Quality Quorum To: "Harrington, David" cc: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: Re: FW: Status of the WG In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA602FC4@NHROCMBX1.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Thu, 13 Feb 2003, Harrington, David wrote: > We really need to decide whether we believe SNMPv3 is worth the effort > to help get it deployed. If not, we should declare it Historic, pick an > alternative, and move on. If we want it to be accepted, then ... I suppose that first we have to change area director and wg chair. > dbh Thanks, Aleksey From owner-snmpv3@lists.tislabs.com Sat Feb 15 11:12:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04506 for ; Sat, 15 Feb 2003 11:12:20 -0500 (EST) From: owner-snmpv3@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07747 Sat, 15 Feb 2003 10:23:13 -0500 (EST) Date: Sat, 15 Feb 2003 10:23:13 -0500 (EST) Message-Id: <200302151523.KAA07747@lists.tislabs.com> >From: >Date: Fri, 14 Feb 2003 12:59:02 -0500 (EST) >To: owner-snmpv3@lists.tislabs.com >Subject: BOUNCE snmpv3@lists.tislabs.com: Non-member submission from [Stevenmitchell1@aol.com] > > >From majordomo-owner Fri Feb 14 12:59:00 2003 >Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) > by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA25233 > Fri, 14 Feb 2003 12:59:00 -0500 (EST) >From: Stevenmitchell1@aol.com >Received: by sentry.gw.tislabs.com; id NAA28070; Fri, 14 Feb 2003 13:03:04 -0500 (EST) >Received: from imo-r08.mx.aol.com(152.163.225.104) by sentry.gw.tislabs.com via smap (V5.5) > id xma028050; Fri, 14 Feb 03 13:02:14 -0500 >Received: from Stevenmitchell1@aol.com > by imo-r08.mx.aol.com (mail_out_v34.21.) id o.125.1e42dc38 (4012); > Fri, 14 Feb 2003 13:01:13 -0500 (EST) >Message-ID: <125.1e42dc38.2b7e88e9@aol.com> >Date: Fri, 14 Feb 2003 13:01:13 EST >Subject: Re: 1906-20 Scope >To: bwijnen@lucent.com >CC: snmpv3@lists.tislabs.com >MIME-Version: 1.0 >Content-Type: text/plain; charset="US-ASCII" >Content-Transfer-Encoding: 7bit >X-Mailer: AOL 4.0 for Windows 95 sub 124 > >Since UDP has historically been the method for all SNMP / IP management >solutions Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk -- -- John C. Kelley Development Engineer NAILabs at Network Associates, Inc. Rockville, MD "Curiousity salted the snail." From owner-snmpv3@lists.tislabs.com Wed Feb 19 16:46:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09810 for ; Wed, 19 Feb 2003 16:46:15 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16441 Wed, 19 Feb 2003 15:43:23 -0500 (EST) Message-ID: <01dd01c2d858$7f137b20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: Subject: RFC 2576 vs IPv6 Date: Wed, 19 Feb 2003 12:50:11 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - I think the analysis of RFC 2576 in section 5.070 (see below) of draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect. These rules for handling legacy data which happen to be IPv4 addresses have no bearing on the ability to operate in or manage IPv6 environments. Randy -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version 3 of the Internet-standard Network Management Framework (SNMP) This document states: (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). and defines the OID: snmpTrapAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the agent-addr field of a Trap PDU which is forwarded by a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the agent-addr field from the original Trap PDU as generated by an SNMPv1 agent." ::= { snmpCommunityMIBObjects 3 } This clearly points out a lack of IPv6 awareness in this protocol. From owner-snmpv3@lists.tislabs.com Wed Feb 19 18:27:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12637 for ; Wed, 19 Feb 2003 18:27:10 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16717 Wed, 19 Feb 2003 17:12:06 -0500 (EST) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 19 Feb 2003 14:14:37 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: snmpv3@lists.tislabs.com cc: phil@nesser.com Subject: Re: RFC 2576 vs IPv6 In-Reply-To: <01dd01c2d858$7f137b20$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Wed, 19 Feb 2003, Randy Presuhn wrote: > I think the analysis of RFC 2576 in section 5.070 (see below) of > draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect. > These rules for handling legacy data which happen to be > IPv4 addresses have no bearing on the ability to operate > in or manage IPv6 environments. I agree with that, and the same comment applies to the analysis of the Notification Log MIB: 5.112 RFC 3014 Notification Log MIB This document contains OIDs that are IPv4 specific: nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. Although this seems to be unfriendly for IPv6, we have to recognize that there are a number of older MIBs that do contain an IPv4 format address, known as IpAddress. IPv6 addresses are represented using TAddress or InetAddress, and so the underlying datatype is OCTET STRING, and their value would be stored in the nlmLogVariableOctetStringVal column." ::= { nlmLogVariableEntry 9 } Not withstanding the note in the DESCRIPTION. The purpose of this object is to handle legacy data. It is, in effect a member of a discriminated union designed to handle arbitrary SMIv2 data types (including the obsolete ones), and its presence in no way indicates that the MIB module is inadequate for IPv6. //cmh From owner-snmpv3@lists.tislabs.com Wed Feb 19 19:16:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13721 for ; Wed, 19 Feb 2003 19:16:01 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16945 Wed, 19 Feb 2003 18:29:56 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C0E7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , snmpv3@lists.tislabs.com Cc: phil@nesser.com Subject: RE: RFC 2576 vs IPv6 Date: Thu, 20 Feb 2003 00:32:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk I thought I had made similar comment to an earlier version of phil's document. Thanks, Bert > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: woensdag 19 februari 2003 21:50 > To: snmpv3@lists.tislabs.com > Cc: phil@nesser.com > Subject: RFC 2576 vs IPv6 > > > Hi - > > I think the analysis of RFC 2576 in section 5.070 (see below) of > draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect. > These rules for handling legacy data which happen to be > IPv4 addresses have no bearing on the ability to operate > in or manage IPv6 environments. > > Randy > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version > 3 of the Internet-standard Network Management Framework (SNMP) > > This document states: > > (11) For any object with a SYNTAX of NetworkAddress, the > SYNTAX MUST > be changed to IpAddress. Note that the use of > NetworkAddress in > new MIB documents is strongly discouraged (in fact, new MIB > documents should be written using SMIv2, which does not define > NetworkAddress). > > and defines the OID: > > snmpTrapAddress OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The value of the agent-addr field of a Trap PDU which > is forwarded by a proxy forwarder application using > an SNMP version other than SNMPv1. The value of this > object SHOULD contain the value of the agent-addr field > from the original Trap PDU as generated by an SNMPv1 > agent." > ::= { snmpCommunityMIBObjects 3 } > > This clearly points out a lack of IPv6 awareness in this protocol. > > > From owner-snmpv3@lists.tislabs.com Wed Feb 19 22:26:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17085 for ; Wed, 19 Feb 2003 22:26:16 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17454 Wed, 19 Feb 2003 21:44:59 -0500 (EST) Reply-To: From: "Philip J. Nesser II" To: "'Wijnen, Bert \(Bert\)'" , "'Randy Presuhn'" , Subject: RE: RFC 2576 vs IPv6 Date: Wed, 19 Feb 2003 15:53:24 -0800 Organization: Nesser & Nesser Consulting Message-ID: <075b01c2d872$174897e0$bf3b68c0@A30P> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155F7C0E7@nl0006exch001u.nl.lucent.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bert, You did, and I thought I had made all of your changes, but I must have missed this one. It WILL be fixed in the -01 draft. - ---> Phil > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, February 19, 2003 3:33 PM > To: Randy Presuhn; snmpv3@lists.tislabs.com > Cc: phil@nesser.com > Subject: RE: RFC 2576 vs IPv6 > > I thought I had made similar comment to an earlier version > of phil's document. > > Thanks, > Bert > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: woensdag 19 februari 2003 21:50 > > To: snmpv3@lists.tislabs.com > > Cc: phil@nesser.com > > Subject: RFC 2576 vs IPv6 > > > > > > Hi - > > > > I think the analysis of RFC 2576 in section 5.070 (see below) of > > draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect. > > These rules for handling legacy data which happen to be > > IPv4 addresses have no bearing on the ability to operate > > in or manage IPv6 environments. > > > > Randy > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > 5.070 RFC 2576 Coexistence between Version 1 Version 2 and > > Version > > 3 of the Internet-standard Network Management Framework > > (SNMP) > > > > This document states: > > > > (11) For any object with a SYNTAX of NetworkAddress, the > > SYNTAX MUST > > be changed to IpAddress. Note that the use of > > NetworkAddress in > > new MIB documents is strongly discouraged (in fact, new > > MIB > > documents should be written using SMIv2, which does not > > define > > NetworkAddress). > > > > and defines the OID: > > > > snmpTrapAddress OBJECT-TYPE > > SYNTAX IpAddress > > MAX-ACCESS accessible-for-notify > > STATUS current > > DESCRIPTION > > "The value of the agent-addr field of a Trap PDU which > > is forwarded by a proxy forwarder application using > > an SNMP version other than SNMPv1. The value of this > > object SHOULD contain the value of the agent-addr field > > from the original Trap PDU as generated by an SNMPv1 > > agent." > > ::= { snmpCommunityMIBObjects 3 } > > > > This clearly points out a lack of IPv6 awareness in this > > protocol. > > > > > > -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBPlQY9A6aViIxlRuuEQK+nQCeOaj6MM373V4mwq5CZMFvJT1oBeEAoOJl kqUznjrgpQ1ZNj5ZuEJ9xMJ6 =moq0 -----END PGP SIGNATURE----- From owner-snmpv3@lists.tislabs.com Wed Feb 19 22:28:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17111 for ; Wed, 19 Feb 2003 22:28:02 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17442 Wed, 19 Feb 2003 21:43:58 -0500 (EST) Reply-To: From: "Philip J. Nesser II" To: "'Randy Presuhn'" , Subject: RE: RFC 2576 vs IPv6 Date: Wed, 19 Feb 2003 14:16:30 -0800 Organization: Nesser & Nesser Consulting Message-ID: <071501c2d864$8daf4b80$bf3b68c0@A30P> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <01dd01c2d858$7f137b20$7f1afea9@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randy, Thanks. I will make updates in the -01 version. The whole goal is to solicit input from the people who have a much more intimate knowledge of individual protocols than I do. It has been a daunting task and it is hard to fit everything together when you are trying to digest 900 or so protocol documents. I really appreciate your time to read through the document and make your comments. I am currently taking input from (hopefully) a lot of independent sources and putting then all together. - ---> Phil > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, February 19, 2003 12:50 PM > To: snmpv3@lists.tislabs.com > Cc: phil@nesser.com > Subject: RFC 2576 vs IPv6 > > Hi - > > I think the analysis of RFC 2576 in section 5.070 (see below) of > draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect. > These rules for handling legacy data which happen to be > IPv4 addresses have no bearing on the ability to operate > in or manage IPv6 environments. > > Randy > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version > 3 of the Internet-standard Network Management Framework > (SNMP) > > This document states: > > (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX > MUST > be changed to IpAddress. Note that the use of > NetworkAddress in > new MIB documents is strongly discouraged (in fact, new MIB > documents should be written using SMIv2, which does not > define > NetworkAddress). > > and defines the OID: > > snmpTrapAddress OBJECT-TYPE > SYNTAX IpAddress > MAX-ACCESS accessible-for-notify > STATUS current > DESCRIPTION > "The value of the agent-addr field of a Trap PDU which > is forwarded by a proxy forwarder application using > an SNMP version other than SNMPv1. The value of this > object SHOULD contain the value of the agent-addr field > from the original Trap PDU as generated by an SNMPv1 > agent." > ::= { snmpCommunityMIBObjects 3 } > > This clearly points out a lack of IPv6 awareness in this protocol. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBPlQCPg6aViIxlRuuEQLw/QCg0nGe7nuJP/qbnzmrliplJeU5An8AoMgP CvZn2bjaSwLlxx2p6gjcML0A =vY41 -----END PGP SIGNATURE----- From owner-snmpv3@lists.tislabs.com Fri Feb 21 02:15:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21637 for ; Fri, 21 Feb 2003 02:15:43 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20448 Fri, 21 Feb 2003 01:22:43 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381012705B5@ma19exm01.e2.bcs.mot.com> From: Donati Andrew-MGIA0477 To: "'snmpv3@lists.tislabs.com'" Subject: rfc3418 and statistical information related to SMIv2 Date: Thu, 20 Feb 2003 10:11:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk rfc3418 references obsolete objects in the snmp group. Some of these contain some SNMP v1(now historic) statistical definitions. The question is, are there any plans or intentions to add some statistical objects related to SMIv2 as defined in rfc 1905 such as 'snmpNoCreations', 'snmpWrongValues' etc ? Also, objects such as 'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be added. ---Below shows the obsolete group defined rfc3418. snmpObsoleteGroup OBJECT-GROUP OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, snmpInTotalReqVars, snmpInTotalSetVars, snmpInGetRequests, snmpInGetNexts, snmpInSetRequests, snmpInGetResponses, snmpInTraps, snmpOutTooBigs, snmpOutNoSuchNames, snmpOutBadValues, snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts, snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps } STATUS obsolete DESCRIPTION "A collection of objects from RFC 1213 made obsolete by this MIB module." ::= { snmpMIBGroups 10 } Thanks, Andy From owner-snmpv3@lists.tislabs.com Fri Feb 21 04:22:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24030 for ; Fri, 21 Feb 2003 04:22:26 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20698 Fri, 21 Feb 2003 03:40:03 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381012705B6@ma19exm01.e2.bcs.mot.com> From: Donati Andrew-MGIA0477 To: "'snmpv3@lists.tislabs.com'" Subject: rfc3418 and statistical information related to SMNPv2/v3 Date: Thu, 20 Feb 2003 10:29:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk rfc3418 references obsolete objects in the snmp group. Some of these contain some SNMP v1(now historic) statistical definitions. The question is, are there any plans or intentions to add some statistical objects related to SMNPv2/v3 as defined in rfc 1905 such as 'snmpNoCreations', 'snmpWrongValues' etc ? Also, objects such as 'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be added. Note: (This is a corrected message where 'SNMPv2/v3' replaced 'SMIv2'). ---Below shows the obsolete group defined rfc3418. snmpObsoleteGroup OBJECT-GROUP OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, snmpInTotalReqVars, snmpInTotalSetVars, snmpInGetRequests, snmpInGetNexts, snmpInSetRequests, snmpInGetResponses, snmpInTraps, snmpOutTooBigs, snmpOutNoSuchNames, snmpOutBadValues, snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts, snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps } STATUS obsolete DESCRIPTION "A collection of objects from RFC 1213 made obsolete by this MIB module." ::= { snmpMIBGroups 10 } Thanks, Andy From owner-snmpv3@lists.tislabs.com Fri Feb 21 13:40:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10430 for ; Fri, 21 Feb 2003 13:40:25 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21860 Fri, 21 Feb 2003 12:36:20 -0500 (EST) Message-ID: <0A11633F61BD9F40B43ABCC694004F93C8CDFC@zsc3c026.us.nortel.com> From: "David Levi" To: "'Harrie Hazewinkel'" , WG IETF snmpv3 Cc: David Harrington Subject: RE: review draft-ietf-snmpv3-coex-v2-02.txt Date: Fri, 21 Feb 2003 09:38:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi Harrie, Please see me comments below . . . -Dave > -----Original Message----- > From: Harrie Hazewinkel [mailto:harrie@lisanza.net] > Sent: Wednesday, January 08, 2003 5:21 AM > To: WG IETF snmpv3 > Cc: David Harrington > Subject: review draft-ietf-snmpv3-coex-v2-02.txt > > > Hi, > > I have reviewed the draft and here are my comments. > I believe there is nothing broken, but some clarifications > could be usefull. > > See below between pieces of the draft. > > > > Coexistence between Version 1, Version 2, and Version 3 > > of the Internet-standard Network Management Framework > > > > > Abstract > > > > The purpose of this document is to describe coexistence between > > version 3 of the Internet-standard Network Management Framework, > > (SNMPv3), version 2 of the Internet-standard Network Management > > Framework (SNMPv2), and the original Internet-standard Network > > Management Framework (SNMPv1). This document obsoletes RFC 2576 > > [21]. > > Just to be clear. It basically speaks about coexistance between > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions > against the other versions. right? > > I am asking, since > - for instance, section 1.4 looks like v1 and v2 only (See > there also). > - the document also describes coexistance between SMIv1 and SMIv2 > where SMIv2 is a seperate standard. > Is that therefore needed in this document? > Is SMIv1 and SMIv2 not usefull if that will be added in the > abstract? I wasn't sure what exactly you were asking us to change here. It sounded like you were suggesting that the parts of the document regarding converting from SMIv1 to SMIv2 be removed and put in a different document. Can you clarify this? > > > Table Of Contents > [snip] > > B. Changes From RFC1908 > ........................................ 55 > > What about the changes since RFC2576? > Mentioned already by, "C. M. Heard" There will be an updated change log in the upcoming I-D. > > 1.4. SNMPv1 and SNMPv2 Access to MIB Data > > Correct me if I am wrong, but this is related to the SNMP-PDU > and the SNMP-PDU is not different between SNMPv3 and SNMPv2. > For MIB access the difference between SNMPv3 and SNMPv2 is nihil, > but that is maybe worthwhile mentioning. Also since a big part of > the document uses this. Added text to clarify this at the end of section 1.4. > > > SNMPv1 access to MIB data may generate SNMPv1 > error-status values, > > will never generate exception codes nor use the > Counter64 data type, > > and will provide SNMPv1 format parameters for generating > > notifications. Note also that SNMPv1 access to MIB data will > > actually never generate a readOnly error (a noSuchName > error would > > always occur in the situation where one would expect a readOnly > > error). > > > > SNMPv2 access to MIB data may generate SNMPv2 > error-status values, > > may generate exception codes, may use the Counter64 data > type, and > > will provide SNMPv2 format parameters for generating > notifications. > > Note that SNMPv2 access to MIB data will never generate readOnly, > > noSuchName, or badValue errors. > > The above two paragraphs make it look like the 'readOnly' > error exists, > but may never be used. Maybe it maybe used for SNMPv3. That's right, it exists, but is never used. > This section 1.4 seems also the be hanging between section 2 and 3. Not sure what you mean here, is there something you thought should change? > Also later section 4.3 discusses the mapping between SNMPv1 > and SNMPv2, > but there is also SNMPv3 equal to SNMPv2. Somehow, I get the feeling > this is more SMIv1 and SMIv2 access to the MIB. Section 4.3 is related to protocol operations, which are defined in SNMPv1 and SNMPv2. Not sure why you thought this was related to SMIv1 and SMIv2. Again, was there something you thought should be changed here? > > 2. SMI and Management Information Mappings > > > > 2.1. MIB Modules > > > > MIB modules defined using the SMIv1 may continue to be used with > > protocol versions which use SNMPv2 PDUs. However, for the MIB > ^^^^^^^ > suggested change into 'the SMIv1 MIB', since this section is > SMIv1 to SMIv2 translation. (This could be used in more > places later on.) Changed 'for the MIB' to 'for SMIv1 MIB' > > > modules to conform to the SMIv2, the following changes > SHALL be made: > > > > 2.1.1. Object Definitions > > > > In general, conversion of a MIB module does not require the > > deprecation of the objects contained therein. If the > definition of > > an object is truly inadequate for its intended purpose, > the object > > SHALL be deprecated or obsoleted, otherwise deprecation is not > > required. > > I am just curious about the text "If the definition of > an object is truly inadequate for its intended purpose". > which does not make it look like a conversion from SMIv1 to SMIv2 > or vice versa. That is more a design/experience issue. This text is just to clarify that converting a MIB from SMIv1 to SMIv2 does not mean you must deprecate objects, unless there there is some other good reason to deprecate them. > > 3. Translating Notifications Parameters > > > > This section describes how parameters used for generating > > notifications are translated between the format used for SNMPv1 > > notification protocol operations and the format used for SNMPv2 > > notification protocol operations. The parameters used > to generate a > > notification are called 'notification parameters.' The format of > > parameters used for SNMPv1 notification protocol operations is > > refered to in this document as 'SNMPv1 notification > parameters.' The > > format of parameters used for SNMPv2 notification > protocol operations > > is refered to in this document as 'SNMPv2 notification > parameters.' > > What about SNMPv3 'notification parameters'?? > I guess, this is similar to my comment earlier in section 1.4. Since 'notification parameters' are determined by the version of protocol operations, there are only SNMPv1 and SNMPv2 'notification parameters.' I don't think there's anything we need to change here. > > 4.1.1. Command Generator > > > > A command generator must select an appropriate message > version when > > sending requests to another entity. One way to achieve > this is to > > consult a local database to select the appropriate > message version. > > > > In addition, a command generator MUST 'downgrade' > GetBulk requests to > > GetNext requests when selecting SNMPv1 as the message > version for an > > outgoing request. This is done by simply changing the > operation type > > to GetNext, ignoring any non-repeaters and > max-repetitions values, > > and setting error-status and error-index to zero. > > Correct me if I am wrong, but this does not provide the same > functionality > from the command generators point of view. Should that be noted?? This is true, but I think we would be adding too much detail about how to implement code if we said anything more here. > > 4.1.3. Notification Originator > > > > A notification originator must be able to translate > between SNMPv1 > > notification parameters and SNMPv2 notification > parameters in order > > to send a notification using a particular SNMP message > version. If a > > notification is generated using SNMPv1 notification > parameters, and > > configuration information specifies that notifications > be sent using > > SNMPv2c or SNMPv3, the notification parameters must be > translated to > > SNMPv2 notification parameters. > > here I see the first time that SNMPv2c and SNMPv3 are treated > more equal > and then maps upon SNMPV2 notification parameters. Well, this is the first place it talks about the actual SNMP message version being used for sending notifications. I don't think there's anything to change here. > > 5. Message Processing Models and Security Models > > > > In order to adapt SNMPv1 (and SNMPv2c) into the SNMP > architecture, > > the following models are defined in this document: > > > > - The SNMPv1 Message Processing Model > > > > - The SNMPv1 Community-Based Security Model > > > > The following models are also described in this document: > > The above sentence seems redundant if the '(' and ')' earlier > are deleted. Why not listing them just four bullets?? This parentheses are there because we wanted to try to de-emphasize the stuff about SNMPv2c. This was discussed long ago (I can't remember whether it was at an IETF meeting or an interim meeting). We've removed the sentence between the two bullets, though. > > - The SNMPv2c Message Processing Model > > > > - The SNMPv2c Community-Based Security Model > > > > In most respects, the SNMPv1 Message Processing > Model and the > > SNMPv2c Message Processing Model are identical, > and so these > > are not discussed independently in this document. > Differences > > between the two models are described as required. > > > > Similarly, the SNMPv1 Community-Based Security > Model and the > > SNMPv2c Community-Based Security Model are nearly > identical, > > and so are not discussed independently. > Differences between > > these two models are also described as required. > > The indent of the last 2 paragraphs make it look like it is only part > of SNMPv2C. Not needed in my opinion. The indentation was a typo, it has been fixed. > > 5.3. The SNMP Community MIB Module > > > > snmpCommunityMIBCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP engines which > > implement the SNMP-COMMUNITY-MIB." > > > > MODULE -- this module > > MANDATORY-GROUPS { snmpCommunityTableGroup } > > > > OBJECT snmpCommunityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunitySecurityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextEngineID > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityTransportTag > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStorageType > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStatus > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > ::= { snmpCommunityMIBCompliances 1 } > > I remember a discussion of having full compliance and read-only > compliance in some other MIB modules, like DIFFSERV-MIB. (Bert maybe > as well, he can as AD provide IESG guidelines, I hope. It was laid > down on other working groups after all too and I do not see a reason > why telling other WG to do it, while we ourselves don't do it.) > That could be usefull, in order to have people implementing > it also as read-write in order to be fully compliant. > This would mean just adding a full-compliance statement where it > is all implemented and with read/write. > > > > > 9. References > > Should these not be split into normative and informational > references. Done. > > cheers, > > Harrie > ------------------------------------------------------------------ > Author of MOD-SNMP, enabling SNMP management of Apache HTTP server > From owner-snmpv3@lists.tislabs.com Sun Feb 23 10:30:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08863 for ; Sun, 23 Feb 2003 10:30:18 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26419 Sun, 23 Feb 2003 09:20:22 -0500 (EST) Message-ID: <0A11633F61BD9F40B43ABCC694004F93C8CDFD@zsc3c026.us.nortel.com> From: "David Levi" To: "David Levi" , "'Harrie Hazewinkel'" , WG IETF snmpv3 Cc: David Harrington Subject: RE: review draft-ietf-snmpv3-coex-v2-02.txt Date: Fri, 21 Feb 2003 12:53:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D9EB.2E0B976E" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D9EB.2E0B976E Content-Type: text/plain; charset="iso-8859-1" Hi, Also, we will add the full read-write compliance statement (next-to-last item in your original comments). -Dave > -----Original Message----- > From: Levi, David [SC100:323:EXCH] > Sent: Friday, February 21, 2003 12:38 PM > To: 'Harrie Hazewinkel'; WG IETF snmpv3 > Cc: David Harrington > Subject: RE: review draft-ietf-snmpv3-coex-v2-02.txt > > > Hi Harrie, > > Please see me comments below . . . > > -Dave > > > -----Original Message----- > > From: Harrie Hazewinkel [mailto:harrie@lisanza.net] > > Sent: Wednesday, January 08, 2003 5:21 AM > > To: WG IETF snmpv3 > > Cc: David Harrington > > Subject: review draft-ietf-snmpv3-coex-v2-02.txt > > > > > > Hi, > > > > I have reviewed the draft and here are my comments. > > I believe there is nothing broken, but some clarifications > > could be usefull. > > > > See below between pieces of the draft. > > > > > > > Coexistence between Version 1, Version 2, and Version 3 > > > of the Internet-standard Network Management Framework > > > > > > > > Abstract > > > > > > The purpose of this document is to describe coexistence between > > > version 3 of the Internet-standard Network Management > Framework, > > > (SNMPv3), version 2 of the Internet-standard Network Management > > > Framework (SNMPv2), and the original Internet-standard Network > > > Management Framework (SNMPv1). This document > obsoletes RFC 2576 > > > [21]. > > > > Just to be clear. It basically speaks about coexistance between > > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions > > against the other versions. right? > > > > I am asking, since > > - for instance, section 1.4 looks like v1 and v2 only (See > > there also). > > - the document also describes coexistance between SMIv1 and SMIv2 > > where SMIv2 is a seperate standard. > > Is that therefore needed in this document? > > Is SMIv1 and SMIv2 not usefull if that will be added in the > > abstract? > > > I wasn't sure what exactly you were asking us to change here. > It sounded > like you were suggesting that the parts of the document > regarding converting > from SMIv1 to SMIv2 be removed and put in a different > document. Can you > clarify this? > > > > > > > Table Of Contents > > [snip] > > > B. Changes From RFC1908 > > ........................................ 55 > > > > What about the changes since RFC2576? > > Mentioned already by, "C. M. Heard" > > > There will be an updated change log in the upcoming I-D. > > > > > 1.4. SNMPv1 and SNMPv2 Access to MIB Data > > > > Correct me if I am wrong, but this is related to the SNMP-PDU > > and the SNMP-PDU is not different between SNMPv3 and SNMPv2. > > For MIB access the difference between SNMPv3 and SNMPv2 is nihil, > > but that is maybe worthwhile mentioning. Also since a big part of > > the document uses this. > > > Added text to clarify this at the end of section 1.4. > > > > > > > SNMPv1 access to MIB data may generate SNMPv1 > > error-status values, > > > will never generate exception codes nor use the > > Counter64 data type, > > > and will provide SNMPv1 format parameters for generating > > > notifications. Note also that SNMPv1 access to MIB data will > > > actually never generate a readOnly error (a noSuchName > > error would > > > always occur in the situation where one would expect a readOnly > > > error). > > > > > > SNMPv2 access to MIB data may generate SNMPv2 > > error-status values, > > > may generate exception codes, may use the Counter64 data > > type, and > > > will provide SNMPv2 format parameters for generating > > notifications. > > > Note that SNMPv2 access to MIB data will never > generate readOnly, > > > noSuchName, or badValue errors. > > > > The above two paragraphs make it look like the 'readOnly' > > error exists, > > but may never be used. Maybe it maybe used for SNMPv3. > > > That's right, it exists, but is never used. > > > > This section 1.4 seems also the be hanging between section 2 and 3. > > > Not sure what you mean here, is there something you thought > should change? > > > > Also later section 4.3 discusses the mapping between SNMPv1 > > and SNMPv2, > > but there is also SNMPv3 equal to SNMPv2. Somehow, I get the feeling > > this is more SMIv1 and SMIv2 access to the MIB. > > > Section 4.3 is related to protocol operations, which are defined in > SNMPv1 and SNMPv2. Not sure why you thought this was related to SMIv1 > and SMIv2. Again, was there something you thought should be > changed here? > > > > > 2. SMI and Management Information Mappings > > > > > > 2.1. MIB Modules > > > > > > MIB modules defined using the SMIv1 may continue to be > used with > > > protocol versions which use SNMPv2 PDUs. However, for the MIB > > ^^^^^^^ > > suggested change into 'the SMIv1 MIB', since this section is > > SMIv1 to SMIv2 translation. (This could be used in more > > places later on.) > > > Changed 'for the MIB' to 'for SMIv1 MIB' > > > > > > > modules to conform to the SMIv2, the following changes > > SHALL be made: > > > > > > 2.1.1. Object Definitions > > > > > > In general, conversion of a MIB module does not require the > > > deprecation of the objects contained therein. If the > > definition of > > > an object is truly inadequate for its intended purpose, > > the object > > > SHALL be deprecated or obsoleted, otherwise deprecation is not > > > required. > > > > I am just curious about the text "If the definition of > > an object is truly inadequate for its intended purpose". > > which does not make it look like a conversion from SMIv1 to SMIv2 > > or vice versa. That is more a design/experience issue. > > > This text is just to clarify that converting a MIB from SMIv1 to SMIv2 > does not mean you must deprecate objects, unless there there is some > other good reason to deprecate them. > > > > > 3. Translating Notifications Parameters > > > > > > This section describes how parameters used for generating > > > notifications are translated between the format used for SNMPv1 > > > notification protocol operations and the format used for SNMPv2 > > > notification protocol operations. The parameters used > > to generate a > > > notification are called 'notification parameters.' > The format of > > > parameters used for SNMPv1 notification protocol operations is > > > refered to in this document as 'SNMPv1 notification > > parameters.' The > > > format of parameters used for SNMPv2 notification > > protocol operations > > > is refered to in this document as 'SNMPv2 notification > > parameters.' > > > > What about SNMPv3 'notification parameters'?? > > I guess, this is similar to my comment earlier in section 1.4. > > > Since 'notification parameters' are determined by the version > of protocol > operations, there are only SNMPv1 and SNMPv2 'notification > parameters.' > I don't think there's anything we need to change here. > > > > > 4.1.1. Command Generator > > > > > > A command generator must select an appropriate message > > version when > > > sending requests to another entity. One way to achieve > > this is to > > > consult a local database to select the appropriate > > message version. > > > > > > In addition, a command generator MUST 'downgrade' > > GetBulk requests to > > > GetNext requests when selecting SNMPv1 as the message > > version for an > > > outgoing request. This is done by simply changing the > > operation type > > > to GetNext, ignoring any non-repeaters and > > max-repetitions values, > > > and setting error-status and error-index to zero. > > > > Correct me if I am wrong, but this does not provide the same > > functionality > > from the command generators point of view. Should that be noted?? > > > This is true, but I think we would be adding too much detail about how > to implement code if we said anything more here. > > > > > 4.1.3. Notification Originator > > > > > > A notification originator must be able to translate > > between SNMPv1 > > > notification parameters and SNMPv2 notification > > parameters in order > > > to send a notification using a particular SNMP message > > version. If a > > > notification is generated using SNMPv1 notification > > parameters, and > > > configuration information specifies that notifications > > be sent using > > > SNMPv2c or SNMPv3, the notification parameters must be > > translated to > > > SNMPv2 notification parameters. > > > > here I see the first time that SNMPv2c and SNMPv3 are treated > > more equal > > and then maps upon SNMPV2 notification parameters. > > > Well, this is the first place it talks about the actual SNMP message > version being used for sending notifications. I don't think there's > anything to change here. > > > > > 5. Message Processing Models and Security Models > > > > > > In order to adapt SNMPv1 (and SNMPv2c) into the SNMP > > architecture, > > > the following models are defined in this document: > > > > > > - The SNMPv1 Message Processing Model > > > > > > - The SNMPv1 Community-Based Security Model > > > > > > The following models are also described in this document: > > > > The above sentence seems redundant if the '(' and ')' earlier > > are deleted. Why not listing them just four bullets?? > > > This parentheses are there because we wanted to try to > de-emphasize the > stuff > about SNMPv2c. This was discussed long ago (I can't remember whether > it was at an IETF meeting or an interim meeting). We've removed the > sentence > between the two bullets, though. > > > > > - The SNMPv2c Message Processing Model > > > > > > - The SNMPv2c Community-Based Security Model > > > > > > In most respects, the SNMPv1 Message Processing > > Model and the > > > SNMPv2c Message Processing Model are identical, > > and so these > > > are not discussed independently in this document. > > Differences > > > between the two models are described as required. > > > > > > Similarly, the SNMPv1 Community-Based Security > > Model and the > > > SNMPv2c Community-Based Security Model are nearly > > identical, > > > and so are not discussed independently. > > Differences between > > > these two models are also described as required. > > > > The indent of the last 2 paragraphs make it look like it is > only part > > of SNMPv2C. Not needed in my opinion. > > > The indentation was a typo, it has been fixed. > > > > > 5.3. The SNMP Community MIB Module > > > > > > snmpCommunityMIBCompliance MODULE-COMPLIANCE > > > STATUS current > > > DESCRIPTION > > > "The compliance statement for SNMP engines which > > > implement the SNMP-COMMUNITY-MIB." > > > > > > MODULE -- this module > > > MANDATORY-GROUPS { snmpCommunityTableGroup } > > > > > > OBJECT snmpCommunityName > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunitySecurityName > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunityContextEngineID > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunityContextName > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunityTransportTag > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunityStorageType > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > OBJECT snmpCommunityStatus > > > MIN-ACCESS read-only > > > DESCRIPTION "Write access is not required." > > > > > > ::= { snmpCommunityMIBCompliances 1 } > > > > I remember a discussion of having full compliance and read-only > > compliance in some other MIB modules, like DIFFSERV-MIB. (Bert maybe > > as well, he can as AD provide IESG guidelines, I hope. It was laid > > down on other working groups after all too and I do not see a reason > > why telling other WG to do it, while we ourselves don't do it.) > > That could be usefull, in order to have people implementing > > it also as read-write in order to be fully compliant. > > This would mean just adding a full-compliance statement where it > > is all implemented and with read/write. > > > > > > > > 9. References > > > > Should these not be split into normative and informational > > references. > > > Done. > > > > > > cheers, > > > > Harrie > > ------------------------------------------------------------------ > > Author of MOD-SNMP, enabling SNMP management of Apache HTTP server > > > ------_=_NextPart_001_01C2D9EB.2E0B976E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: review draft-ietf-snmpv3-coex-v2-02.txt

Hi,

Also, we will add the full read-write compliance = statement (next-to-last
item in your original comments).

-Dave

> -----Original Message-----
> From: Levi, David [SC100:323:EXCH]
> Sent: Friday, February 21, 2003 12:38 PM
> To: 'Harrie Hazewinkel'; WG IETF snmpv3
> Cc: David Harrington
> Subject: RE: review = draft-ietf-snmpv3-coex-v2-02.txt
>
>
> Hi Harrie,
>
> Please see me comments below . . .
>
> -Dave
>
> > -----Original Message-----
> > From: Harrie Hazewinkel [mailto:harrie@lisanza.net]=
> > Sent: Wednesday, January 08, 2003 5:21 = AM
> > To: WG IETF snmpv3
> > Cc: David Harrington
> > Subject: review = draft-ietf-snmpv3-coex-v2-02.txt
> >
> >
> > Hi,
> >
> > I have reviewed the draft and here are my = comments.
> > I believe there is nothing broken, but = some clarifications
> > could be usefull.
> >
> > See below between pieces of the = draft.
> >
> >
> > = >         Coexistence = between Version 1, Version 2, and Version 3
> > = >          of the = Internet-standard Network Management Framework
> > = >           &n= bsp;        = <draft-ietf-snmpv3-coex-v2-02.txt>
> >
> > > Abstract
> > >
> > >    The purpose of this = document is to describe coexistence between
> > >    version 3 of the = Internet-standard Network Management
> Framework,
> > >    (SNMPv3), version 2 = of the Internet-standard Network Management
> > >    Framework (SNMPv2), = and the original Internet-standard Network
> > >    Management = Framework (SNMPv1).  This document
> obsoletes RFC 2576
> > >    [21].
> >
> > Just to be clear. It basically speaks = about coexistance between
> > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - = SNMPv3. All versions
> > against the other versions. right?
> >
> > I am asking, since
> > -  for instance, section 1.4 looks = like v1 and v2 only (See
> > there also).
> > -  the document also describes = coexistance between SMIv1 and SMIv2
> >        = where SMIv2 is a seperate standard.
> >        = Is that therefore needed in this document?
> >        = Is SMIv1 and SMIv2 not usefull if that will be added in the
> > abstract?
>
>
> I wasn't sure what exactly you were asking us = to change here.
>  It sounded
> like you were suggesting that the parts of the = document
> regarding converting
> from SMIv1 to SMIv2 be removed and put in a = different
> document.  Can you
> clarify this?
>
>
> >
> > >    Table Of = Contents
> > [snip]
> > >    B. Changes From = RFC1908
> > = ........................................   55
> >
> > What about the changes since = RFC2576?
> > Mentioned already by, "C. M. = Heard" <heard@pobox.com>
>
>
> There will be an updated change log in the = upcoming I-D.
>
>
> > > 1.4.  SNMPv1 and SNMPv2 Access = to MIB Data
> >
> > Correct me if I am wrong, but this is = related to the SNMP-PDU
> > and the SNMP-PDU is not different between = SNMPv3 and SNMPv2.
> > For MIB access the difference between = SNMPv3 and SNMPv2 is nihil,
> > but that is maybe worthwhile mentioning. = Also since a big part of
> > the document uses this.
>
>
> Added text to clarify this at the end of = section 1.4.
>
>
> >
> > >    SNMPv1 access to = MIB data may generate SNMPv1
> > error-status values,
> > >    will never generate = exception codes nor use the
> > Counter64 data type,
> > >    and will provide = SNMPv1 format parameters for generating
> > >    = notifications.  Note also that SNMPv1 access to MIB data = will
> > >    actually never = generate a readOnly error (a noSuchName
> > error would
> > >    always occur in the = situation where one would expect a readOnly
> > >    error).
> > >
> > >    SNMPv2 access to = MIB data may generate SNMPv2
> > error-status values,
> > >    may generate = exception codes, may use the Counter64 data
> > type, and
> > >    will provide SNMPv2 = format parameters for generating
> > notifications.
> > >    Note that SNMPv2 = access to MIB data will never
> generate readOnly,
> > >    noSuchName, or = badValue errors.
> >
> > The above two paragraphs make it look like = the 'readOnly'
> > error exists,
> > but may never be used. Maybe it maybe used = for SNMPv3.
>
>
> That's right, it exists, but is never = used.
>
>
> > This section 1.4 seems also the be hanging = between section 2 and 3.
>
>
> Not sure what you mean here, is there something = you thought
> should change?
>
>
> > Also later section 4.3 discusses the = mapping between SNMPv1
> > and SNMPv2,
> > but there is also SNMPv3 equal to SNMPv2. = Somehow, I get the feeling
> > this is more SMIv1 and SMIv2 access to the = MIB.
>
>
> Section 4.3 is related to protocol operations, = which are defined in
> SNMPv1 and SNMPv2.  Not sure why you = thought this was related to SMIv1
> and SMIv2.  Again, was there something you = thought should be
> changed here?
>
>
> > > 2.  SMI and Management = Information Mappings
> > >
> > > 2.1.  MIB Modules
> > >
> > >    MIB modules defined = using the SMIv1 may continue to be
> used with
> > >    protocol versions = which use SNMPv2 PDUs.  However, for the MIB
> = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;  ^^^^^^^
> > suggested change into 'the SMIv1 MIB', = since this section is
> > SMIv1 to SMIv2 translation. (This could be = used in more
> > places later on.)
>
>
> Changed 'for the MIB' to 'for SMIv1 MIB'
>
>
> >
> > >    modules to conform = to the SMIv2, the following changes
> > SHALL be made:
> > >
> > > 2.1.1.  Object = Definitions
> > >
> > >    In general, = conversion of a MIB module does not require the
> > >    deprecation of the = objects contained therein.  If the
> > definition of
> > >    an object is truly = inadequate for its intended purpose,
> > the object
> > >    SHALL be deprecated = or obsoleted, otherwise deprecation is not
> > >    required.
> >
> > I am just curious about the text "If = the definition of
> >     an object is truly = inadequate for its intended purpose".
> > which does not make it look like a = conversion from SMIv1 to SMIv2
> > or vice versa. That is more a = design/experience issue.
>
>
> This text is just to clarify that converting a = MIB from SMIv1 to SMIv2
> does not mean you must deprecate objects, = unless there there is some
> other good reason to deprecate them.
>
>
> > > 3.  Translating Notifications = Parameters
> > >
> > >    This section = describes how parameters used for generating
> > >    notifications are = translated between the format used for SNMPv1
> > >    notification = protocol operations and the format used for SNMPv2
> > >    notification = protocol operations.  The parameters used
> > to generate a
> > >    notification are = called 'notification parameters.' 
> The format of
> > >    parameters used for = SNMPv1 notification protocol operations is
> > >    refered to in this = document as 'SNMPv1 notification
> > parameters.'  The
> > >    format of = parameters used for SNMPv2 notification
> > protocol operations
> > >    is refered to in = this document as 'SNMPv2 notification
> > parameters.'
> >
> > What about SNMPv3 'notification = parameters'??
> > I guess, this is similar to my comment = earlier in section 1.4.
>
>
> Since 'notification parameters' are determined = by the version
> of protocol
> operations, there are only SNMPv1 and SNMPv2 = 'notification
> parameters.'
> I don't think there's anything we need to = change here.
>
>
> > > 4.1.1.  Command Generator
> > >
> > >    A command generator = must select an appropriate message
> > version when
> > >    sending requests to = another entity.  One way to achieve
> > this is to
> > >    consult a local = database to select the appropriate
> > message version.
> > >
> > >    In addition, a = command generator MUST 'downgrade'
> > GetBulk requests to
> > >    GetNext requests = when selecting SNMPv1 as the message
> > version for an
> > >    outgoing = request.  This is done by simply changing the
> > operation type
> > >    to GetNext, = ignoring any non-repeaters and
> > max-repetitions values,
> > >    and setting = error-status and error-index to zero.
> >
> > Correct me if I am wrong, but this does = not provide the same
> > functionality
> > from the command generators point of view. = Should that be noted??
>
>
> This is true, but I think we would be adding = too much detail about how
> to implement code if we said anything more = here.
>
>
> > > 4.1.3.  Notification = Originator
> > >
> > >    A notification = originator must be able to translate
> > between SNMPv1
> > >    notification = parameters and SNMPv2 notification
> > parameters in order
> > >    to send a = notification using a particular SNMP message
> > version.  If a
> > >    notification is = generated using SNMPv1 notification
> > parameters, and
> > >    configuration = information specifies that notifications
> > be sent using
> > >    SNMPv2c or SNMPv3, = the notification parameters must be
> > translated to
> > >    SNMPv2 notification = parameters.
> >
> > here I see the first time that SNMPv2c and = SNMPv3 are treated
> > more equal
> > and then maps upon SNMPV2 notification = parameters.
>
>
> Well, this is the first place it talks about = the actual SNMP message
> version being used for sending = notifications.  I don't think there's
> anything to change here.
>
>
> > > 5.  Message Processing Models = and Security Models
> > >
> > >    In order to adapt = SNMPv1 (and SNMPv2c) into the SNMP
> > architecture,
> > >    the following = models are defined in this document:
> > >
> > = >        -  The SNMPv1 = Message Processing Model
> > >
> > = >        -  The SNMPv1 = Community-Based Security Model
> > >
> > >    The following = models are also described in this document:
> >
> > The above sentence seems redundant if the = '(' and ')' earlier
> > are deleted. Why not listing them just = four bullets??
>
>
> This parentheses are there because we wanted to = try to
> de-emphasize the
> stuff
> about SNMPv2c.  This was discussed long = ago (I can't remember whether
> it was at an IETF meeting or an interim = meeting).  We've removed the
> sentence
> between the two bullets, though.
>
> 
> > = >        -  The SNMPv2c = Message Processing Model
> > >
> > = >        -  The SNMPv2c = Community-Based Security Model
> > >
> > = >           In = most respects, the SNMPv1 Message Processing
> > Model and the
> > = >           = SNMPv2c Message Processing Model are identical,
> > and so these
> > = >           are = not discussed independently in this document.
> >  Differences
> > = >           = between the two models are described as required.
> > >
> > = >           = Similarly, the SNMPv1 Community-Based Security
> > Model and the
> > = >           = SNMPv2c Community-Based Security Model are nearly
> > identical,
> > = >           and so = are not discussed independently. 
> > Differences between
> > = >           these = two models are also described as required.
> >
> > The indent of the last 2 paragraphs make = it look like it is
> only part
> > of SNMPv2C. Not needed in my = opinion.
>
>
> The indentation was a typo, it has been = fixed.
>
>
> > > 5.3.  The SNMP Community MIB = Module
> > >
> > >       = snmpCommunityMIBCompliance MODULE-COMPLIANCE
> > = >           = STATUS       current
> > = >           = DESCRIPTION
> > = >           &n= bsp;   "The compliance statement for SNMP engines = which
> > = >           &n= bsp;    implement the SNMP-COMMUNITY-MIB."
> > >
> > = >           = MODULE       -- this module
> > = >           &n= bsp;   MANDATORY-GROUPS { snmpCommunityTableGroup }
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityName
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunitySecurityName
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityContextEngineID
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityContextName
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityTransportTag
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityStorageType
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > >      &nb= sp;        = DESCRIPTION     "Write access is not = required."
> > >
> > = >           &n= bsp;   = OBJECT           = snmpCommunityStatus
> > = >           &n= bsp;   MIN-ACCESS       = read-only
> > = >           &n= bsp;   DESCRIPTION     "Write access = is not required."
> > >
> > = >           ::=3D = { snmpCommunityMIBCompliances 1 }
> >
> > I remember a discussion of having full = compliance and read-only
> > compliance in some other MIB modules, like = DIFFSERV-MIB. (Bert maybe
> > as well, he can as AD provide IESG = guidelines, I hope. It was laid
> > down on other working groups after all too = and I do not see a reason
> > why telling other WG to do it, while we = ourselves don't do it.)
> > That could be usefull, in order to have = people implementing
> > it also as read-write in order to be fully = compliant.
> > This would mean just adding a = full-compliance statement where it
> > is all implemented and with = read/write.
> >
> > >
> > > 9.  References
> >
> > Should these not be split into normative = and informational
> > references.
>
>
> Done.
>
>
> >
> > cheers,
> >
> > Harrie
> > = ------------------------------------------------------------------
> > Author of MOD-SNMP, enabling SNMP = management of Apache HTTP server
> >
>

------_=_NextPart_001_01C2D9EB.2E0B976E-- From owner-snmpv3@lists.tislabs.com Mon Feb 24 06:14:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07757 for ; Mon, 24 Feb 2003 06:14:09 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA28709 Mon, 24 Feb 2003 05:20:09 -0500 (EST) Date: Mon, 24 Feb 2003 11:24:48 +0100 Subject: Re: review draft-ietf-snmpv3-coex-v2-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Harrie Hazewinkel , WG IETF snmpv3 , David Harrington To: "David Levi" From: Harrie Hazewinkel In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93C8CDFD@zsc3c026.us.nortel.com> Message-Id: <33E54B1E-47E2-11D7-B372-0003934A5A7E@jumpy.it> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA28706 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit HI, On Friday, February 21, 2003, at 09:53 PM, David Levi wrote: > > > > Hi Harrie, > > > > Abstract > > > > > > > >    The purpose of this document is to describe coexistence > between > > > >    version 3 of the Internet-standard Network Management > > Framework, > > > >    (SNMPv3), version 2 of the Internet-standard Network > Management > > > >    Framework (SNMPv2), and the original Internet-standard Network > > > >    Management Framework (SNMPv1).  This document > > obsoletes RFC 2576 > > > >    [21]. > > > > > > Just to be clear. It basically speaks about coexistance between > > > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions > > > against the other versions. right? > > > > > > I am asking, since > > > -  for instance, section 1.4 looks like v1 and v2 only (See > > > there also). > > > -  the document also describes coexistance between SMIv1 and SMIv2 > > >        where SMIv2 is a seperate standard. > > >        Is that therefore needed in this document? > > >        Is SMIv1 and SMIv2 not usefull if that will be added in the > > > abstract? > > > > > > I wasn't sure what exactly you were asking us to change here. > >  It sounded > > like you were suggesting that the parts of the document > > regarding converting > > from SMIv1 to SMIv2 be removed and put in a different > > document.  Can you > > clarify this? I was indeed not that clear, I was also stating more a question. IMO, the abstract could be made more precise. This document not only handles SNMP protocol version differences, but also SMI version differences. Not that I want to seperate that. For SNMPv1 the connection to SMIv1 is clear (those go hand-in-hand), but SNMPv2 and SNMPv3 both have SMIv2 plus the fact that SMIv2 is a seperate STD58. Therefore, I believe that if SMIv2 is seperated also the abstract should mention it unless we have to see some version of SMI as an integral part of some version of the 'Internet-standard Network Management Framework'. > > > > > > This section 1.4 seems also the be hanging between section 2 and 3. > > > > > > Not sure what you mean here, is there something you thought > > should change? What I think is odd is that it all seperates the SNMP protocol versions nicely and section 1.4 combines 2 versions of SMI. Therefore, it looks like this section is somewhere between section 2 and 3. What I would do (believe should be done) is drop this section and make it part of section 2. > > > > > > > > 3.  Translating Notifications Parameters > > > > > > > >    This section describes how parameters used for generating > > > >    notifications are translated between the format used for > SNMPv1 > > > >    notification protocol operations and the format used for > SNMPv2 > > > >    notification protocol operations.  The parameters used > > > to generate a > > > >    notification are called 'notification parameters.'  > > The format of > > > >    parameters used for SNMPv1 notification protocol operations is > > > >    refered to in this document as 'SNMPv1 notification > > > parameters.'  The > > > >    format of parameters used for SNMPv2 notification > > > protocol operations > > > >    is refered to in this document as 'SNMPv2 notification > > > parameters.' > > > > > > What about SNMPv3 'notification parameters'?? > > > I guess, this is similar to my comment earlier in section 1.4. > > > > > > Since 'notification parameters' are determined by the version > > of protocol > > operations, there are only SNMPv1 and SNMPv2 'notification > > parameters.' > > I don't think there's anything we need to change here. See "4.1.3. Notification Originator" below. > > > > > > > > 4.1.1.  Command Generator > > > > > > > >    A command generator must select an appropriate message > > > version when > > > >    sending requests to another entity.  One way to achieve > > > this is to > > > >    consult a local database to select the appropriate > > > message version. > > > > > > > >    In addition, a command generator MUST 'downgrade' > > > GetBulk requests to > > > >    GetNext requests when selecting SNMPv1 as the message > > > version for an > > > >    outgoing request.  This is done by simply changing the > > > operation type > > > >    to GetNext, ignoring any non-repeaters and > > > max-repetitions values, > > > >    and setting error-status and error-index to zero. > > > > > > Correct me if I am wrong, but this does not provide the same > > > functionality > > > from the command generators point of view. Should that be noted?? > > > > > > This is true, but I think we would be adding too much detail about > how > > to implement code if we said anything more here. Understand. > > > > > > > > 4.1.3.  Notification Originator > > > > > > > >    A notification originator must be able to translate > > > between SNMPv1 > > > >    notification parameters and SNMPv2 notification > > > parameters in order > > > >    to send a notification using a particular SNMP message > > > version.  If a > > > >    notification is generated using SNMPv1 notification > > > parameters, and > > > >    configuration information specifies that notifications > > > be sent using > > > >    SNMPv2c or SNMPv3, the notification parameters must be > > > translated to > > > >    SNMPv2 notification parameters. > > > > > > here I see the first time that SNMPv2c and SNMPv3 are treated > > > more equal > > > and then maps upon SNMPV2 notification parameters. > > > > > > Well, this is the first place it talks about the actual SNMP message > > version being used for sending notifications.  I don't think there's > > anything to change here. Now I see why SNMPv3 is not always mentioned/repeated again after SNMPv2. The difference is an SNMP message and SNMP PDU simply said. SNMPv3 uses SNMPv2 PDUs. Altough, that is quit clear to me, but I did not get this fully while reading the document. An 'ignorant' reader would be confused by this. Therefore, I believe it could be a good idea to add a line in section 1.3 explaining that SNMPv3 is not always mentioned/repeated specifically when it is about/uses the same definitions as SNMPv2. > 1.3. SNMPv3 > SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 > and > the SMIv2 definitions of 2578 through 2580 described above. I suggest adding something like: Therefore, thoughout this document when SNMPv3 is not mentioned specifically the same definitions of SNMPv2 apply for SNMPv3. Hope this helps, Harrie ------------------------------------------------------------------ Author of MOD-SNMP, enabling SNMP management of Apache HTTP server From owner-snmpv3@lists.tislabs.com Tue Feb 25 14:06:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10941 for ; Tue, 25 Feb 2003 14:06:03 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03088 Tue, 25 Feb 2003 13:15:54 -0500 (EST) Message-ID: <03b001c2dcfa$b2b164a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <62173B970AE0A044AED8723C3BCF2381012705B6@ma19exm01.e2.bcs.mot.com> Subject: Re: rfc3418 and statistical information related to SMNPv2/v3 Date: Tue, 25 Feb 2003 10:21:21 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Donati Andrew-MGIA0477" > To: > Sent: Thursday, February 20, 2003 7:29 AM > Subject: rfc3418 and statistical information related to SMNPv2/v3 > > rfc3418 references obsolete objects in the snmp group. Some of these > contain some SNMP v1(now historic) statistical definitions. > > The question is, are there any plans or intentions to add some statistical > objects related to SMNPv2/v3 as defined in rfc 1905 such as > 'snmpNoCreations', 'snmpWrongValues' etc ? Also, objects such as > 'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be > added. ... I know of no such plans. As a practical matter, since most implementations are already (at least) bi-lingual, I'd be rather suprised if anyone were to remove the historical objects. The cost of removing the code would likely be far greater than any benefit. Furthermore, despite the security risks, some folks seem intent on continuing to use SNMPv1 management tools. For the same reasons that the old objects (snmpNoCreations) weren't carried forward (they weren't found to be terribly useful) I doubt that there would be much support for adding the new objects suggested above. Randy From owner-snmpv3@lists.tislabs.com Thu Feb 27 10:58:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09238 for ; Thu, 27 Feb 2003 10:58:35 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09860 Thu, 27 Feb 2003 10:06:19 -0500 (EST) Message-ID: <62173B970AE0A044AED8723C3BCF2381012705D8@ma19exm01.e2.bcs.mot.com> From: Donati Andrew-MGIA0477 To: "'Randy Presuhn'" , snmpv3@lists.tislabs.com Subject: RE: rfc3418 and statistical information related to SMNPv2/v3 Date: Thu, 27 Feb 2003 10:09:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Randy, Thank you for your reply. Thanks, Andy -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Tuesday, February 25, 2003 1:21 PM To: snmpv3@lists.tislabs.com Subject: Re: rfc3418 and statistical information related to SMNPv2/v3 Hi - > From: "Donati Andrew-MGIA0477" > To: > Sent: Thursday, February 20, 2003 7:29 AM > Subject: rfc3418 and statistical information related to SMNPv2/v3 > > rfc3418 references obsolete objects in the snmp group. Some of these > contain some SNMP v1(now historic) statistical definitions. > > The question is, are there any plans or intentions to add some statistical > objects related to SMNPv2/v3 as defined in rfc 1905 such as > 'snmpNoCreations', 'snmpWrongValues' etc ? Also, objects such as > 'snmpOutNotifications', 'snmpOutInforms', 'snmpInformRetries' can also be > added. ... I know of no such plans. As a practical matter, since most implementations are already (at least) bi-lingual, I'd be rather suprised if anyone were to remove the historical objects. The cost of removing the code would likely be far greater than any benefit. Furthermore, despite the security risks, some folks seem intent on continuing to use SNMPv1 management tools. For the same reasons that the old objects (snmpNoCreations) weren't carried forward (they weren't found to be terribly useful) I doubt that there would be much support for adding the new objects suggested above. Randy From owner-snmpv3@lists.tislabs.com Fri Feb 28 21:17:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20251 for ; Fri, 28 Feb 2003 21:17:29 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14930 Fri, 28 Feb 2003 19:28:22 -0500 (EST) Message-ID: <0A11633F61BD9F40B43ABCC694004F93C8CE63@zsc3c026.us.nortel.com> From: "David Levi" To: WG IETF snmpv3 Subject: coex draft Date: Fri, 28 Feb 2003 14:29:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2DF78.DF1E1D3C" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2DF78.DF1E1D3C Content-Type: text/plain; charset="iso-8859-1" Hi All, Here is a change-bar version of the new coex draft (this is not the official version). This will be submitted tomorrow to the ID editor. Also, I've attached a list of responses to the lists of proposed changes. -Dave ------------------------------------------------------------------------ David B. Levi Nortel Networks dlevi@nortelnetworks.com Voice: +1 865 686 0432 ESN: 455-6004 ------------------------------------------------------------------------ ------_=_NextPart_000_01C2DF78.DF1E1D3C Content-Type: application/octet-stream; name="coex.cb" Content-Disposition: attachment; filename="coex.cb" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= INTERNET-DRAFT Rob = Frye=0A= Vibrant = Solutions=0A= David B. = Levi=0A= Nortel = Networks=0A= Shawn A. = Routhier=0A= Integrated Systems = Inc.=0A= Bert = Wijnen=0A= Lucent = Technologies=0A= 28 Feb = 2003=0A= =0A= =0A= Coexistence between Version 1, Version 2, and Version 3=0A= of the Internet-standard Network Management Framework=0A= = |=0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with = |=0A= all provisions of Section 10 of RFC 2026. Internet-Drafts are = |=0A= working = |=0A= documents of the Internet Engineering Task Force (IETF), its = areas,=0A= and its working groups. Note that other groups may also = distribute=0A= working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved. = |=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 1]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= Abstract=0A= =0A= The purpose of this document is to describe coexistence between=0A= version 3 of the Internet-standard Network Management Framework,=0A= (SNMPv3), version 2 of the Internet-standard Network Management=0A= Framework (SNMPv2), and the original Internet-standard Network = |=0A= Management Framework (SNMPv1). This document also describes how to = |=0A= convert MIB modules from SMIv1 format to SMIv2 format. This = document |=0A= obsoletes RFC 2576. = |=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 2]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= Table Of Contents=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 3]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= Table Of Contents=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 4]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 1. Overview=0A= =0A= The purpose of this document is to describe coexistence between=0A= version 3 of the Internet-standard Network Management Framework,=0A= termed the SNMP version 3 framework (SNMPv3), version 2 of the=0A= Internet-standard Network Management Framework, termed the SNMP=0A= version 2 framework (SNMPv2), and the original Internet-standard=0A= Network Management Framework (SNMPv1).=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this |=0A= document are to be interpreted as described in RFC 2119 [RFC2119]. = |=0A= =0A= There are four general aspects of coexistence described in this=0A= document. Each of these is described in a separate section:=0A= =0A= - Conversion of MIB documents between SMIv1 and SMIv2 formats = is=0A= documented in section 2.=0A= =0A= - Mapping of notification parameters is documented in section = 3.=0A= =0A= - Approaches to coexistence between entities which support = the=0A= various versions of SNMP in a multi-lingual network is=0A= documented in section 4. This section addresses the=0A= processing of protocol operations in multi-lingual=0A= implementations, as well as behaviour of proxy=0A= implementations.=0A= =0A= - The SNMPv1 Message Processing Model and Community-Based=0A= Security Model, which provides mechanisms for adapting = SNMPv1=0A= into the View-Based Access Control Model (VACM) [20], is=0A= documented in section 5 (this section also addresses the=0A= SNMPv2c Message Processing Model and Community-Based = Security=0A= Model).=0A= =0A= =0A= =0A= 1.1. SNMPv1=0A= =0A= SNMPv1 is defined by these documents:=0A= =0A= - STD 15, RFC 1157 [RFC1157] which defines the Simple Network = |=0A= Management = |=0A= Protocol (SNMPv1), the protocol used for network access to=0A= managed objects.=0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 5]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - STD 16, RFC 1155 [RFC1155] which defines the Structure of = |=0A= Management = |=0A= Information (SMIv1), the mechanisms used for describing = and=0A= naming objects for the purpose of management.=0A= =0A= - STD 16, RFC 1212 [RFC1212] which defines a more concise = |=0A= description = |=0A= mechanism, which is wholly consistent with the SMIv1.=0A= =0A= - RFC 1215 [RFC1215] which defines a convention for defining = |=0A= Traps for use = |=0A= with the SMIv1.=0A= =0A= Note that throughout this document, the term 'SMIv1' is used. = This=0A= term generally refers to the information presented in RFC 1155, = RFC=0A= 1212, and RFC 1215.=0A= =0A= =0A= =0A= 1.2. SNMPv2=0A= =0A= SNMPv2 is defined by these documents:=0A= =0A= - STD 58, RFC 2578 which defines Version 2 of the Structure = of=0A= Management Information (SMIv2) [RFC2578]. = |=0A= =0A= - STD 58, RFC 2579 which defines common MIB "Textual = |=0A= Conventions" [RFC2579]. = |=0A= =0A= - STD 58, RFC 2580 which defines Conformance Statements and=0A= requirements for defining agent and manager capabilities = |=0A= [RFC2580]. = |=0A= =0A= - STD 62, RFC 3416 which defines the Protocol Operations used = in |=0A= processing [RFC3416]. = |=0A= =0A= - STD 62, RFC 3417 which defines the Transport Mappings used = "on |=0A= the wire" [RFC3417]. = |=0A= =0A= - STD 62, RFC 3418 which defines the basic Management = |=0A= Information Base for monitoring and controlling some basic = |=0A= common functions of SNMP entities [RFC3418]. = |=0A= =0A= Note that SMIv2 as used throughout this document refers to the = first=0A= three documents listed above (RFCs 2578, 2579, and 2580).=0A= =0A= The following document augments the definition of SNMPv2:=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 6]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - RFC 1901 [RFC1901] is an Experimental definition for using = |=0A= SNMPv2 PDUs = |=0A= within a community-based message wrapper. This is referred = to=0A= throughout this document as SNMPv2c.=0A= =0A= =0A= =0A= 1.3. SNMPv3=0A= =0A= SNMPv3 is defined by these documents:=0A= =0A= - STD 62, RFC 3411 which defines an Architecture for Describing = |=0A= SNMP Management Frameworks [RFC3411]. = |=0A= =0A= - STD 62, RFC 3412 which defines Message Processing and = |=0A= Dispatching [RFC3412]. = |=0A= =0A= - STD 62, RFC 3413 which defines various SNMP Applications = |=0A= [RFC3413]. = |=0A= =0A= - STD 62, RFC 3414 which defines the User-based Security Model = |=0A= (USM), providing for both Authenticated and Private = |=0A= (encrypted) SNMP messages [RFC3414]. = |=0A= =0A= - STD 62, RFC 3415 which defines the View-based Access Control = |=0A= Model (VACM), = |=0A= providing the ability to limit access to different MIB = objects |=0A= on a per-user basis [RFC3415]. = |=0A= =0A= SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 = and |=0A= the SMIv2 definitions of 2578 through 2580 described above. Note = |=0A= that text throughout this document that refers to SNMPv2 PDU types = |=0A= and protocol operations applies to both SNMPv2c and SNMPv3. = |=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 7]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 2. SMI and Management Information Mappings = -=0A= =0A= The SMIv2 approach towards describing collections of managed = objects=0A= is nearly a proper superset of the approach defined in the SMIv1. = |=0A= For example, both approaches use an adapted subset of ASN.1 [ASN1] = |=0A= as the basis for a formal descriptive notation. Indeed, one = might=0A= note that the SMIv2 approach largely codifies the existing = practice=0A= for defining MIB modules, based on extensive experience with the=0A= SMIv1.=0A= =0A= The following sections consider the three areas: MIB modules,=0A= compliance statements, and capabilities statements.=0A= =0A= =0A= 2.1. MIB Modules=0A= =0A= MIB modules defined using the SMIv1 may continue to be used with=0A= protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB = |=0A= modules to = |=0A= conform to the SMIv2, the following changes SHALL be made:=0A= =0A= =0A= 2.1.1. Object Definitions=0A= =0A= In general, conversion of a MIB module does not require the=0A= deprecation of the objects contained therein. If the definition = of=0A= an object is truly inadequate for its intended purpose, the = object=0A= SHALL be deprecated or obsoleted, otherwise deprecation is not=0A= required.=0A= =0A= (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of=0A= RFC1155-SMI and RFC-1212.=0A= =0A= (2) The MODULE-IDENTITY macro MUST be invoked immediately after any=0A= IMPORTs statement.=0A= =0A= (3) = -=0A= For any object with a SYNTAX clause value of Counter, the = object=0A= MUST have the value of its SYNTAX clause changed to Counter32.=0A= =0A= (4) For any object with a SYNTAX clause value of Gauge, the object = MUST=0A= have the value of its SYNTAX clause changed to Gauge32, or=0A= Unsigned32 where appropriate.=0A= =0A= (5) For all objects, the ACCESS clause MUST be replaced by a = MAX-ACCESS=0A= clause. The value of the MAX-ACCESS clause SHALL be the same = as=0A= that of the ACCESS clause unless some other value makes = "protocol=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 8]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= sense" as the maximal level of access for the object. In=0A= particular, object types for which instances can be explicitly=0A= created by a protocol set operation, SHALL have a MAX-ACCESS = clause=0A= of "read-create". If the value of the ACCESS clause is "write-=0A= only", then the value of the MAX-ACCESS clause MUST be "read-=0A= write", and the DESCRIPTION clause SHALL note that reading this=0A= object will result in implementation-specific results. Note = that=0A= in SMIv1, the ACCESS clause specifies the minimal required = access,=0A= while in SMIv2, the MAX-ACCESS clause specifies the maximum = allowed=0A= access. This should be considered when converting an ACCESS = clause=0A= to a MAX-ACCESS clause.=0A= =0A= (6) For all objects, if the value of the STATUS clause is = "mandatory"=0A= or "optional", the value MUST be replaced with "current",=0A= "deprecated", or "obsolete" depending on the current usage of = such=0A= objects.=0A= =0A= (7) For any object not containing a DESCRIPTION clause, the object = MUST=0A= have a DESCRIPTION clause defined.=0A= =0A= (8) For any object corresponding to a conceptual row which does not=0A= have an INDEX clause, the object MUST have either an INDEX = clause=0A= or an AUGMENTS clause defined.=0A= =0A= (9) If any INDEX clause contains a reference to an object with a = syntax=0A= of NetworkAddress, then a new object MUST be created and placed = in=0A= this INDEX clause immediately preceding the object whose syntax = is=0A= NetworkAddress. This new object MUST have a syntax of INTEGER, = it=0A= MUST be not-accessible, and its value MUST always be 1. This = |=0A= effect of this, and the preceding bullet, is to allow one to = |=0A= convert a MIB module in SMIv1 format = |=0A= to one in SMIv2 format, and then use it with the SNMPv1 = protocol=0A= with no impact to existing SNMPv1 agents and managers.=0A= =0A= (10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST = be=0A= changed to IpAddress. Note that the use of NetworkAddress in = new=0A= MIB documents is strongly discouraged (in fact, new MIB = documents=0A= should be written using SMIv2, which does not define=0A= NetworkAddress).=0A= =0A= (11) For any object containing a DEFVAL clause with an OBJECT = IDENTIFIER=0A= value which is expressed as a collection of sub-identifiers, = the=0A= value MUST be changed to reference a single ASN.1 identifier. = This=0A= may require defining a series of new administrative assignments=0A= (OBJECT IDENTIFIERS) in order to define the single ASN.1=0A= identifier.=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 9]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= (12) One or more OBJECT-GROUPS MUST be defined, and related objects = MUST=0A= be collected into appropriate groups. Note that SMIv2 requires = all=0A= OBJECT-TYPEs to be a member of at least one OBJECT-GROUP.=0A= =0A= (13) For any non-columnar object that is instanced as if it were = +=0A= immediately subordinate to a conceptual row, the value of the = +=0A= STATUS clause of that object MUST be changed to "obsolete". = +=0A= =0A= (14) For any conceptual row object that is not immediately subordinate = +=0A= to a conceptual table, the value of the STATUS clause of that = +=0A= object (and all subordinate objects) MUST be changed to = "obsolete". +=0A= =0A= Other changes are desirable, but not necessary:=0A= =0A= (1) Creation and deletion of conceptual rows is inconsistent using = the=0A= SMIv1. The SMIv2 corrects this. As such, if the MIB module=0A= undergoes review early in its lifetime, and it contains = conceptual=0A= tables which allow creation and deletion of conceptual rows, = then=0A= the objects relating to those tables MAY be deprecated and = replaced=0A= with objects defined using the new approach. The approach based = on |=0A= SMIv2 can be found in section 7 of RFC 2578 [RFC2578], = |=0A= and the RowStatus and StorageType TEXTUAL-CONVENTIONs are = described |=0A= in section 2 of RFC 2579 [RFC2579]. = |=0A= =0A= (2) For any object with an integer-valued SYNTAX clause, in which the = +=0A= corresponding INTEGER does not have a range restriction (i.e., the = +=0A= INTEGER has neither a defined set of named-number enumerations nor = +=0A= an assignment of lower- and upper-bounds on its value), the object = +=0A= SHOULD have the value of its SYNTAX clause changed to Integer32, = or +=0A= have an appropriate range specified. = +=0A= =0A= (3) = +=0A= For any object with a string-valued SYNTAX clause, in which the=0A= corresponding OCTET STRING does not have a size restriction = (i.e.,=0A= the OCTET STRING has no assignment of lower- and upper-bounds = on=0A= its length), the bounds for the size of the object SHOULD be=0A= defined.=0A= =0A= (4) All textual conventions informally defined in the MIB module = SHOULD=0A= be redefined using the TEXTUAL-CONVENTION macro. Such a change=0A= would not necessitate deprecating objects previously defined = using=0A= an informal textual convention.=0A= =0A= (5) For any object which represents a measurement in some kind of=0A= units, a UNITS clause SHOULD be added to the definition of that=0A= object.=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 10]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= (6) For any conceptual row which is an extension of another = conceptual=0A= row, i.e., for which subordinate columnar objects both exist = and=0A= are identified via the same semantics as the other conceptual = row,=0A= an AUGMENTS clause SHOULD be used in place of the INDEX clause = for=0A= the object corresponding to the conceptual row which is an=0A= extension. = -=0A= =0A= =0A= 2.1.2. Trap and Notification Definitions = -=0A= =0A= If a MIB module is changed to conform to the SMIv2, then each=0A= occurrence of the TRAP-TYPE macro MUST be changed to a = corresponding=0A= invocation of the NOTIFICATION-TYPE macro:=0A= =0A= (1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and = |=0A= MUST = |=0A= reference SNMPv2-SMI instead.=0A= =0A= (2) The ENTERPRISE clause MUST be removed.=0A= =0A= (3) The VARIABLES clause MUST be renamed to the OBJECTS clause.=0A= =0A= (4) A STATUS clause MUST be added, with an appropriate value. = Normally=0A= the value should be 'current,' although 'deprecated' or = 'obsolete'=0A= may be used as needed.=0A= =0A= (5) The value of an invocation of the NOTIFICATION-TYPE macro is an=0A= OBJECT IDENTIFIER, not an INTEGER, and MUST be changed = accordingly.=0A= Specifically, if the value of the ENTERPRISE clause is not = 'snmp'=0A= then the value of the invocation SHALL be the value of the=0A= ENTERPRISE clause extended with two sub-identifiers, the first = of=0A= which has the value 0, and the second has the value of the=0A= invocation of the TRAP-TYPE. If the value of the ENTERPRISE = clause=0A= is 'snmp', then the value of the invocation of the = NOTIFICATION-=0A= TYPE macro SHALL be mapped in the same manner as described in=0A= section 3.1 in this document.=0A= =0A= (6) A DESCRIPTION clause MUST be added, if not already present.=0A= =0A= (7) One or more NOTIFICATION-GROUPs MUST be defined, and related=0A= notifications MUST be collected into those groups. Note that = SMIv2=0A= requires that all NOTIFICATION-TYPEs be a member of at least = one=0A= NOTIFICATION-GROUP.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 11]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 2.2. Compliance Statements=0A= =0A= For those information modules which are "standards track", a=0A= corresponding invocation of the MODULE-COMPLIANCE macro and = related=0A= OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included = within=0A= the information module (or in a companion information module), = and=0A= any commentary text in the information module which relates to=0A= compliance SHOULD be removed. Typically this editing can occur = when=0A= the information module undergoes review.=0A= =0A= Note that a MODULE-COMPLIANCE statement is not required for a MIB=0A= document that is not on the standards track (for example, an=0A= enterprise MIB), though it may be useful in some circumstances to=0A= define a MODULE-COMPLIANCE statement for such a MIB document.=0A= =0A= =0A= 2.3. Capabilities Statements=0A= =0A= RFC 1303 [RFC1303] uses the = |=0A= MODULE-CONFORMANCE macro to describe an agent's capabilities with=0A= respect to one or more MIB modules. Converting such a = description=0A= for use with the SMIv2 requires these changes:=0A= =0A= (1) The macro name AGENT-CAPABILITIES MUST be used instead of = MODULE-=0A= CONFORMANCE.=0A= =0A= (2) The STATUS clause MUST be added, with a value of 'current'.=0A= =0A= (3) All occurrences of the CREATION-REQUIRES clause MUST either be=0A= omitted if appropriate, or be changed such that the semantics are = |=0A= consistent with RFC 2580 [RFC2580]. = |=0A= =0A= In order to ease coexistence, object groups defined in an SMIv1=0A= compliant MIB module may be referenced by the INCLUDES clause of = an=0A= invocation of the AGENT-CAPABILITIES macro: upon encountering a=0A= reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB=0A= module, all leaf objects which are subordinate to the subtree and=0A= have a STATUS clause value of mandatory are deemed to be = INCLUDEd.=0A= (Note that this method is ambiguous when different revisions of = an=0A= SMIv1 MIB have different sets of mandatory objects under the same=0A= subtree; in such cases, the only solution is to rewrite the MIB = using=0A= the SMIv2 in order to define the object groups unambiguously.)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 12]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 3. Translating Notification Parameters=0A= =0A= This section describes how parameters used for generating=0A= notifications are translated between the format used for SNMPv1=0A= notification protocol operations and the format used for SNMPv2=0A= notification protocol operations. The parameters used to generate = a=0A= notification are called 'notification parameters.' The format of=0A= parameters used for SNMPv1 notification protocol operations is = |=0A= referred to in this document as 'SNMPv1 notification = |=0A= parameters.' The format of parameters used for SNMPv2 = notification=0A= protocol operations is referred to in this document as 'SNMPv2 = |=0A= notification = |=0A= parameters.'=0A= =0A= The situations where notification parameters MUST be translated = are:=0A= =0A= - When an entity generates a set of notification parameters in = a=0A= particular format, and the configuration of the entity=0A= indicates that the notification must be sent using an SNMP=0A= message version that requires the other format for=0A= notification parameters.=0A= =0A= - When a proxy receives a notification that was sent using = an=0A= SNMP message version that requires one format of = notification=0A= parameters, and must forward the notification using an = SNMP=0A= message version that requires the other format of = notification=0A= parameters.=0A= =0A= In addition, it MAY be desirable to translate notification = parameters=0A= in a notification receiver application in order to present=0A= notifications to the end user in a consistent format.=0A= =0A= Note that for the purposes of this section, the set of = notification=0A= parameters is independent of whether the notification is to be = sent=0A= as a trap or an inform.=0A= =0A= SNMPv1 notification parameters consist of:=0A= =0A= - An enterprise parameter (OBJECT IDENTIFIER).=0A= =0A= - An agent-addr parameter (NetworkAddress).=0A= =0A= - A generic-trap parameter (INTEGER).=0A= =0A= - A specific-trap parameter (INTEGER).=0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 13]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - A time-stamp parameter (TimeTicks).=0A= =0A= - A list of variable-bindings (VarBindList).=0A= =0A= SNMPv2 notification parameters consist of:=0A= =0A= - A sysUpTime parameter (TimeTicks). This appears in the = first=0A= variable-binding in an SNMPv2-Trap-PDU or = InformRequest-PDU.=0A= =0A= - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears = in=0A= the second variable-binding in an SNMPv2-Trap-PDU or=0A= InformRequest-PDU, and is equal to the value portion of = that=0A= variable-binding (not the name portion, as both the name = and=0A= value are OBJECT IDENTIFIERs).=0A= =0A= - A list of variable-bindings (VarBindList). This refers to = all=0A= but the first two variable-bindings in an SNMPv2-Trap-PDU = or=0A= InformRequest-PDU.=0A= =0A= =0A= =0A= 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 = Notification=0A= Parameters=0A= =0A= The following procedure describes how to translate SNMPv1=0A= notification parameters into SNMPv2 notification parameters:=0A= =0A= (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the=0A= SNMPv1 time-stamp parameter.=0A= =0A= (2) If the SNMPv1 generic-trap parameter is = 'enterpriseSpecific(6)',=0A= the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of = the=0A= SNMPv1 enterprise parameter and two additional sub-identifiers,=0A= '0', and the SNMPv1 specific-trap parameter.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 14]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= (3) If the SNMPv1 generic-trap parameter is not=0A= 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL = be=0A= the corresponding trap as defined in section 2 of RFC 3418 = |=0A= [RFC3418]: = |=0A= =0A= generic-trap = |=0A= parameter snmpTrapOID.0 = |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = |=0A= 0 1.3.6.1.6.3.1.1.5.1 (coldStart) = |=0A= 1 1.3.6.1.6.3.1.1.5.2 (warmStart) = |=0A= 2 1.3.6.1.6.3.1.1.5.3 (linkDown) = |=0A= 3 1.3.6.1.6.3.1.1.5.4 (linkUp) = |=0A= 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) = |=0A= 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) = |=0A= =0A= =0A= (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 = variable-bindings.=0A= In addition, if the translation is being performed by a proxy = in=0A= order to forward a received trap, three additional variable-=0A= bindings will be appended, if these three additional variable-=0A= bindings do not already exist in the SNMPv1 variable-bindings. = The=0A= name portion of the first additional variable binding SHALL = contain=0A= snmpTrapAddress.0, and the value SHALL contain the SNMPv1 = agent-=0A= addr parameter. The name portion of the second additional = variable=0A= binding SHALL contain snmpTrapCommunity.0, and the value SHALL=0A= contain the value of the community-string field from the = received=0A= SNMPv1 message which contained the SNMPv1 Trap-PDU. The name=0A= portion of the third additional variable binding SHALL contain = |=0A= snmpTrapEnterprise.0 [RFC3418], and the = |=0A= value SHALL be the SNMPv1 enterprise parameter.=0A= =0A= =0A= =0A= 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 = Notification=0A= Parameters=0A= =0A= The following procedure describes how to translate SNMPv2=0A= notification parameters into SNMPv1 notification parameters:=0A= =0A= (1) The SNMPv1 enterprise parameter SHALL be determined as follows:=0A= =0A= - If the SNMPv2 snmpTrapOID parameter is one of the standard=0A= traps as defined in RFC 3418 [RFC3418], then the SNMPv1 = |=0A= enterprise parameter SHALL be = |=0A= set to the value of the variable-binding in the SNMPv2=0A= variable-bindings whose name is snmpTrapEnterprise.0 if = that=0A= variable-binding exists. If it does not exist, the SNMPv1 = |=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 15]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= enterprise parameter SHALL be set to the value = |=0A= =0A= - If the SNMPv2 snmpTrapOID parameter is not one of the = standard=0A= traps as defined in RFC 3418 [RFC3418], then the SNMPv1 = |=0A= enterprise parameter = |=0A= SHALL be determined from the SNMPv2 snmpTrapOID parameter = as=0A= follows:=0A= =0A= - If the next-to-last sub-identifier of the snmpTrapOID=0A= value is zero, then the SNMPv1 enterprise SHALL be the=0A= SNMPv2 snmpTrapOID value with the last 2 = sub-identifiers=0A= removed, otherwise=0A= =0A= - If the next-to-last sub-identifier of the snmpTrapOID=0A= value is non-zero, then the SNMPv1 enterprise SHALL be = the=0A= SNMPv2 snmpTrapOID value with the last sub-identifier=0A= removed.=0A= =0A= (2) The SNMPv1 agent-addr parameter SHALL be determined based on = the=0A= situation in which the translation occurs.=0A= =0A= - If the translation occurs within a notification originator=0A= application, and the notification is to be sent over IP, = the=0A= SNMPv1 agent-addr parameter SHALL be set to the IP address = of=0A= the SNMP entity in which the notification originator = resides.=0A= If the notification is to be sent over some other = transport,=0A= the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.=0A= =0A= - If the translation occurs within a proxy application, the=0A= proxy must attempt to extract the original source of the=0A= notification from the variable-bindings. If the SNMPv2=0A= variable-bindings contains a variable binding whose name = is=0A= snmpTrapAddress.0, the agent-addr parameter SHALL be set = to=0A= the value of that variable binding. Otherwise, the SNMPv1=0A= agent-addr parameter SHALL be set to 0.0.0.0.=0A= =0A= (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps = as=0A= defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter = |=0A= SHALL be set as follows: = |=0A= =0A= snmpTrapOID.0 parameter generic-trap=0A= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= 1.3.6.1.6.3.1.1.5.1 (coldStart) 0=0A= 1.3.6.1.6.3.1.1.5.2 (warmStart) 1=0A= 1.3.6.1.6.3.1.1.5.3 (linkDown) 2=0A= 1.3.6.1.6.3.1.1.5.4 (linkUp) 3=0A= 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 16]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5=0A= =0A= Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.=0A= =0A= (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps = as=0A= defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap parameter = |=0A= SHALL be set to = |=0A= zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be = set=0A= to the last sub-identifier of the SNMPv2 snmpTrapOID parameter.=0A= =0A= (5) The SNMPv1 time-stamp parameter SHALL be taken directly from = the=0A= SNMPv2 sysUpTime parameter.=0A= =0A= (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings = |=0A= (and note that the SNMPv2 variable-bindings do not include the = |=0A= variable-bindings containing sysUpTime.0, snmpTrapOID.0). = |=0A= Note, however, that if the SNMPv2 variable-bindings contain any=0A= objects whose type is Counter64, the translation to SNMPv1=0A= notification parameters cannot be performed. In this case, the=0A= notification cannot be encoded in an SNMPv1 packet (and so the = |=0A= notification cannot be sent using SNMPv1, see section 4.2.3 and = |=0A= section 4.3). = |=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 17]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 4. Approaches to Coexistence in a Multi-lingual Network=0A= =0A= There are two basic approaches to coexistence in a multi-lingual=0A= network, multi-lingual implementations and proxy implementations.=0A= Multi-lingual implementations allow elements in a network to=0A= communicate with each other using an SNMP version which both = elements=0A= support. This allows a multi-lingual implementation to = communicate=0A= with any mono-lingual implementation, regardless of the SNMP = version=0A= supported by the mono-lingual implementation.=0A= =0A= Proxy implementations provide a mechanism for translating between=0A= SNMP versions using a third party network element. This allows=0A= network elements which support only a single, but different, SNMP=0A= version to communicate with each other. Proxy implementations = are=0A= also useful for securing communications over an insecure link = between=0A= two locally secure networks.=0A= =0A= =0A= 4.1. SNMPv1 and SNMPv2 Access to MIB Data=0A= =0A= Throughout section 4., this document refers to 'SNMPv1 Access to MIB = +=0A= Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the = part +=0A= of an SNMP agent which actually accesses instances of MIB objects, = +=0A= and which actually initiates generation of notifications. = +=0A= Differences between the two types of access to MIB data are: = +=0A= =0A= - Error-status values generated. = +=0A= =0A= - Generation of exception codes. = +=0A= =0A= - Use of the Counter64 data type. = +=0A= =0A= - The format of parameters provided when a notification is = +=0A= generated. = +=0A= =0A= SNMPv1 access to MIB data may generate SNMPv1 error-status values, = +=0A= will never generate exception codes nor use the Counter64 data type, = +=0A= and will provide SNMPv1 format parameters for generating = +=0A= notifications. Note also that SNMPv1 access to MIB data will = +=0A= actually never generate a readOnly error (a noSuchName error would = +=0A= always occur in the situation where one would expect a readOnly = +=0A= error). = +=0A= =0A= SNMPv2 access to MIB data may generate SNMPv2 error-status values, = +=0A= may generate exception codes, may use the Counter64 data type, and = +=0A= will provide SNMPv2 format parameters for generating notifications. = +=0A= Note that SNMPv2 access to MIB data will never generate readOnly, = +=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 18]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= noSuchName, or badValue errors. = +=0A= =0A= Note that a particular multi-lingual implementation may choose to = +=0A= implement all access to MIB data as SNMPv2 access to MIB data, and = +=0A= perform the translations described herein for SNMPv1-based = +=0A= transactions. = +=0A= =0A= Further, note that there is no mention of 'SNMPv3 access to MIB = data' +=0A= in this document, as SNMPv3 uses SNMPv2 PDU types and protocol = +=0A= operations. = +=0A= =0A= =0A= 4.2. Multi-lingual implementations=0A= =0A= This approach requires an entity to support multiple SNMP message=0A= versions. Typically this means supporting SNMPv1, SNMPv2c, and=0A= SNMPv3 message versions. The behaviour of various types of SNMP=0A= applications which support multiple message versions is described = in=0A= the following sections. This approach allows entities which = support=0A= multiple SNMP message versions to coexist with and communicate = with=0A= entities which support only a single SNMP message version.=0A= =0A= =0A= =0A= 4.2.1. Command Generator=0A= =0A= A command generator must select an appropriate message version = when=0A= sending requests to another entity. One way to achieve this is = to=0A= consult a local database to select the appropriate message = version.=0A= =0A= In addition, a command generator MUST 'downgrade' GetBulk requests = to=0A= GetNext requests when selecting SNMPv1 as the message version for = an=0A= outgoing request. This is done by simply changing the operation = type=0A= to GetNext, ignoring any non-repeaters and max-repetitions = values,=0A= and setting error-status and error-index to zero.=0A= =0A= =0A= =0A= 4.2.2. Command Responder=0A= =0A= A command responder must be able to deal with both SNMPv1 and = SNMPv2=0A= access to MIB data. There are three aspects to dealing with this. = A=0A= command responder must:=0A= =0A= - Deal correctly with SNMPv2 access to MIB data that returns = a=0A= Counter64 value while processing an SNMPv1 message,=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 19]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - Deal correctly with SNMPv2 access to MIB data that returns = one=0A= of the three exception values while processing an SNMPv1=0A= message, and=0A= =0A= - Map SNMPv2 error codes returned from SNMPv2 access to MIB = data=0A= into SNMPv1 error codes when processing an SNMPv1 message.=0A= =0A= Note that SNMPv1 error codes SHOULD NOT be used without any = change=0A= when processing SNMPv2c or SNMPv3 messages, except in the case of = |=0A= proxy forwarding. Also, SNMPv1 access to MIB data SHOULD NOT be = used |=0A= when processing SNMPv2c or SNMPv3 messages. In the case of proxy = |=0A= forwarding, for backwards compatibility, SNMPv1 error codes may = be=0A= used without any change in a forwarded SNMPv2c or SNMPv3 message.=0A= =0A= The following sections describe the behaviour of a command = responder=0A= application which supports multiple SNMP message versions, and which = |=0A= uses some SNMPv2 access to MIB data when processing an SNMPv2c or = |=0A= SNMPv3 message. = |=0A= =0A= =0A= =0A= 4.2.2.1. Handling Counter64=0A= =0A= The SMIv2 [RFC2579] defines one new syntax that is incompatible with = |=0A= SMIv1. This syntax is Counter64. All other syntaxes defined by=0A= SMIv2 are compatible with SMIv1.=0A= =0A= The impact on multi-lingual command responders is that they MUST = NOT=0A= ever return a variable binding containing a Counter64 value in a=0A= response to a request that was received using the SNMPv1 message=0A= version.=0A= =0A= Multi-lingual command responders SHALL take the approach that = object=0A= instances whose type is Counter64 are implicitly excluded from = view=0A= when processing an SNMPv1 message. So:=0A= =0A= - On receipt of an SNMPv1 GetRequest-PDU containing a = variable=0A= binding whose name field points to an object instance of = type=0A= Counter64, a GetResponsePDU SHALL be returned, with an = error-=0A= status of noSuchName and the error-index set to the = variable=0A= binding that caused this error.=0A= =0A= - On an SNMPv1 GetNextRequest-PDU, any object instance which=0A= contains a syntax of Counter64 SHALL be skipped, and the = next=0A= accessible object instance that does not have the syntax = of=0A= Counter64 SHALL be retrieved. If no such object instance=0A= exists, then an error-status of noSuchName SHALL be = returned,=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 20]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= and the error-index SHALL be set to the variable binding = that=0A= caused this error.=0A= =0A= - Any SNMPv1 request which contains a variable binding with = a=0A= Counter64 value is ill-formed, so the foregoing rules do = not=0A= apply. If that error is detected, a response SHALL NOT be=0A= returned, since it would contain a copy of the ill-formed=0A= variable binding. Instead, the offending PDU SHALL be=0A= discarded and the counter snmpInASNParseErrs SHALL be=0A= incremented.=0A= =0A= =0A= =0A= 4.2.2.2. Mapping SNMPv2 Exceptions=0A= =0A= SNMPv2 provides a feature called exceptions, which allow an = SNMPv2=0A= Response PDU to return as much management information as = possible,=0A= even when an error occurs. However, SNMPv1 does not support=0A= exceptions, and so an SNMPv1 Response PDU cannot return any=0A= management information, and can only return an error-status and = an=0A= error-index value.=0A= =0A= When an SNMPv1 request is received, a command responder MUST = check=0A= any variable bindings returned using SNMPv2 access to MIB data = for=0A= exception values, and convert these exception values into SNMPv1=0A= error codes.=0A= =0A= The type of exception that can be returned when accessing MIB = data=0A= and the action taken depends on the type of SNMP request.=0A= =0A= - For a GetRequest, a noSuchObject or noSuchInstance = exception=0A= may be returned.=0A= =0A= - For a GetNextRequest, an endOfMibView exception may be=0A= returned.=0A= =0A= - No exceptions will be returned for a SetRequest, and a=0A= GetBulkRequest should only be received in an SNMPv2c or = SNMPv3=0A= message, so these request types may be ignored when = mapping=0A= exceptions.=0A= =0A= Note that when a response contains multiple exceptions, it is an=0A= implementation choice as to which variable binding the = error-index=0A= should reference.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 21]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 4.2.2.2.1. Mapping noSuchObject and noSuchInstance=0A= =0A= A noSuchObject or noSuchInstance exception generated by an SNMPv2=0A= access to MIB data indicates that the requested object instance = can=0A= not be returned. The SNMPv1 error code for this condition is=0A= noSuchName, and so the error-status field of the response PDU = SHALL=0A= be set to noSuchName. Also, the error-index field SHALL be set = to=0A= the index of the variable binding for which an exception occurred = (if |=0A= there is more than one then it is an implementation = |=0A= decision as to which is used), and the variable binding list from = the=0A= original request SHALL be returned with the response PDU.=0A= =0A= =0A= =0A= 4.2.2.2.2. Mapping endOfMibView=0A= =0A= When an SNMPv2 access to MIB data returns a variable binding=0A= containing an endOfMibView exception, it indicates that there are = no=0A= object instances available which lexicographically follow the = object=0A= in the request. In an SNMPv1 agent, this condition normally = results=0A= in a noSuchName error, and so the error-status field of the = response=0A= PDU SHALL be set to noSuchName. Also, the error-index field SHALL = be=0A= set to the index of the variable binding for which an exception = |=0A= occurred (if there is more than one then it is an implementation = |=0A= decision as to which is used), and the variable binding list from = the=0A= original request SHALL be returned with the response PDU.=0A= =0A= =0A= =0A= 4.2.2.3. Processing An SNMPv1 GetRequest=0A= =0A= When processing an SNMPv1 GetRequest, the following procedures = MUST=0A= be followed when using an SNMPv2 access to MIB data.=0A= =0A= When such an access to MIB data returns response data using = SNMPv2=0A= syntax and error-status values, then:=0A= =0A= (1) If the error-status is anything other than noError,=0A= =0A= - The error status SHALL be translated to an SNMPv1 = error-status |=0A= using the table in section 4.4, "Error Status Mappings". = |=0A= =0A= - The error-index SHALL be set to the position (in the = original=0A= request) of the variable binding that caused the = error-status.=0A= =0A= - The variable binding list of the response PDU SHALL be = made=0A= exactly the same as the variable binding list that was=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 22]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= received in the original request.=0A= =0A= (2) If the error-status is noError, the variable bindings SHALL be=0A= checked for any SNMPv2 exception (noSuchObject or = noSuchInstance)=0A= or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If=0A= there are any such variable bindings, one of those variable=0A= bindings SHALL be selected (it is an implementation choice as = to=0A= which is selected), and:=0A= =0A= - The error-status SHALL be set to noSuchName,=0A= =0A= - The error-index SHALL be set to the position (in the = variable=0A= binding list of the original request) of the selected = variable=0A= binding, and=0A= =0A= - The variable binding list of the response PDU SHALL be = exactly=0A= the same as the variable binding list that was received in = the=0A= original request.=0A= =0A= (3) If there are no such variable bindings, then:=0A= =0A= - The error-status SHALL be set to noError,=0A= =0A= - The error-index SHALL be set to zero, and=0A= =0A= - The variable binding list of the response SHALL be = composed=0A= from the data as it is returned by the access to MIB data.=0A= =0A= =0A= =0A= 4.2.2.4. Processing An SNMPv1 GetNextRequest=0A= =0A= When processing an SNMPv1 GetNextRequest, the following procedures = |=0A= MUST be followed when SNMPv2 access to MIB data is used as = |=0A= part of processing the request. There may be repetitive accesses = to=0A= MIB data to try to find the first object which lexicographically=0A= follows each of the objects in the request. This is = implementation=0A= specific. These procedures are followed only for data returned = when=0A= using SNMPv2 access to MIB data. Data returned using SNMPv1 = access=0A= to MIB data may be treated in the normal manner for an SNMPv1=0A= request.=0A= =0A= First, if the access to MIB data returns an error-status of = anything=0A= other than noError:=0A= =0A= (1) The error status SHALL be translated to an SNMPv1 error-status = |=0A= using the table in section 4.4, "Error Status Mappings". = |=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 23]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= (2) The error-index SHALL be set to the position (in the original=0A= request) of the variable binding that caused the error-status.=0A= =0A= (3) The variable binding list of the response PDU SHALL be exactly = the=0A= same as the variable binding list that was received in the = original=0A= request.=0A= =0A= Otherwise, if the access to MIB data returns an error-status of=0A= noError:=0A= =0A= (1) Any variable bindings containing an SNMPv2 syntax of Counter64=0A= SHALL be considered to be not in view, and MIB data SHALL be=0A= accessed as many times as is required until either a value = other=0A= than Counter64 is returned, or an error or endOfMibView exception = |=0A= occurs. = |=0A= =0A= (2) If there is any variable binding that contains an SNMPv2 exception = |=0A= endOfMibView (if there is more than one then it is an = |=0A= implementation = |=0A= decision as to which is chosen):=0A= =0A= - The error-status SHALL be set to noSuchName,=0A= =0A= - The error-index SHALL be set to the position (in the = variable=0A= binding list of the original request) of the variable = binding=0A= that returned such an SNMPv2 exception, and=0A= =0A= - The variable binding list of the response PDU SHALL be = exactly=0A= the same as the variable binding list that was received in = the=0A= original request.=0A= =0A= (3) If there are no such variable bindings, then:=0A= =0A= - The error-status SHALL be set to noError,=0A= =0A= - The error-index SHALL be set to zero, and=0A= =0A= - The variable binding list of the response SHALL be = composed=0A= from the data as it is returned by the access to MIB data.=0A= =0A= =0A= =0A= 4.2.2.5. Processing An SNMPv1 SetRequest=0A= =0A= When processing an SNMPv1 SetRequest, the following procedures MUST = |=0A= be followed when using SNMPv2 access to MIB data. = |=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 24]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= When such MIB access returns response data using SNMPv2 = |=0A= syntax and error-status values, and the error-status is anything=0A= other than noError, then:=0A= =0A= - The error status SHALL be translated to an SNMPv1 = error-status |=0A= using the table in section 4.4, "Error Status Mappings". = |=0A= =0A= - The error-index SHALL be set to the position (in the = original=0A= request) of the variable binding that caused the = error-status.=0A= =0A= - The variable binding list of the response PDU SHALL be = made=0A= exactly the same as the variable binding list that was=0A= received in the original request.=0A= =0A= =0A= =0A= 4.2.3. Notification Originator=0A= =0A= A notification originator must be able to translate between = SNMPv1=0A= notification parameters and SNMPv2 notification parameters in = order=0A= to send a notification using a particular SNMP message version. If = a=0A= notification is generated using SNMPv1 notification parameters, = and=0A= configuration information specifies that notifications be sent = using=0A= SNMPv2c or SNMPv3, the notification parameters must be translated = to=0A= SNMPv2 notification parameters. Likewise, if a notification is=0A= generated using SNMPv2 notification parameters, and configuration=0A= information specifies that notifications be sent using SNMPv1, = the=0A= notification parameters must be translated to SNMPv1 notification=0A= parameters. In this case, if the notification cannot be = translated=0A= (due to the presence of a Counter64 type), it will not be sent = using=0A= SNMPv1.=0A= =0A= When a notification originator generates a notification, using=0A= parameters obtained from the SNMP-TARGET-MIB and = SNMP-NOTIFICATION-=0A= MIB, if the SNMP version used to generate the notification is = SNMPv1,=0A= the PDU type used will always be a TrapPDU, regardless of whether = the=0A= value of snmpNotifyType is trap(1) or inform(2).=0A= =0A= Note also that access control and notification filtering are=0A= performed in the usual manner for notifications, regardless of = the=0A= SNMP message version to be used when sending a notification. The=0A= parameters for performing access control are found in the usual=0A= manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-=0A= NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, = in |=0A= order to perform the access check specified in [RFC3413], section = |=0A= 3.3, bullet (3), the notification originator may need to generate = a=0A= value for snmpTrapOID.0 as described in section 3.1, bullets (2) = and=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 25]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= (3) of this document. If the SNMPv1 notification parameters = being=0A= used were previously translated from a set of SNMPv2 notification=0A= parameters, this value may already be known, in which case it = need=0A= not be generated.=0A= =0A= =0A= 4.2.4. Notification Receiver=0A= =0A= There are no special requirements of a notification receiver.=0A= However, an implementation may find it useful to allow a higher = level=0A= application to request whether notifications should be delivered to = a=0A= higher level application using SNMPv1 notification parameter or=0A= SNMPv2 notification parameters. The notification receiver would = then=0A= translate notification parameters when required in order to present = a=0A= notification using the desired set of parameters.=0A= =0A= =0A= =0A= 4.3. Proxy Implementations=0A= =0A= A proxy implementation may be used to enable communication = between=0A= entities which support different SNMP message versions. This is=0A= accomplished in a proxy forwarder application by performing=0A= translations on PDUs. These translations depend on the PDU type, = the=0A= SNMP version of the packet containing a received PDU, and the = SNMP=0A= version to be used to forward a received PDU. The following = sections=0A= describe these translations. In all cases other than those = described=0A= below, the proxy SHALL forward a received PDU without change, = subject |=0A= to size constraints as defined in section 5.3 (Community MIB) = |=0A= of this document. Note that in the following sections, the = 'Upstream=0A= Version' refers to the version used between the command generator = or=0A= notification receiver and the proxy, and the 'Downstream Version'=0A= refers to the version used between the proxy and the command=0A= responder or notification originator, regardless of the PDU type = or=0A= direction.=0A= =0A= =0A= 4.3.1. Upstream Version Greater Than Downstream Version=0A= =0A= - If a GetBulkRequest-PDU is received and must be forwarded=0A= using the SNMPv1 message version, the proxy forwarder SHALL = |=0A= act as if the non-repeaters and max-repetitions fields were = |=0A= both set to 0, and SHALL set the tag of the PDU to = |=0A= GetNextRequest-PDU.=0A= =0A= - If a GetResponse-PDU is received whose error-status field = has=0A= a value of 'tooBig', and the message will be forwarded = using=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 26]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= the SNMPv2c or SNMPv3 message version, and the original=0A= request received by the proxy was not a = GetBulkRequest-PDU,=0A= the proxy forwarder SHALL remove the contents of the=0A= variable-bindings field and ensure that the error-index = field=0A= is set to 0 before forwarding the response.=0A= =0A= - If a GetResponse-PDU is received whose error-status field = has=0A= a value of 'tooBig,' and the message will be forwarded = using=0A= the SNMPv2c or SNMPv3 message version, and the original=0A= request received by the proxy was a GetBulkRequest-PDU, = the=0A= proxy forwarder SHALL re-send the forwarded request (which=0A= would have been altered to be a GetNextRequest-PDU) with = all=0A= but the first variable-binding removed. The proxy = forwarder=0A= SHALL only re-send such a request a single time. If the=0A= resulting GetResponse-PDU also contains an error-status = field=0A= with a value of 'tooBig,' then the proxy forwarder SHALL=0A= remove the contents of the variable-bindings field, and = change=0A= the error-status field to 'noError', and ensure that the=0A= error-index field is set to 0 before forwarding the = response.=0A= Note that if the original request only contained a single=0A= variable-binding, the proxy may skip re-sending the = request=0A= and simply remove the variable-bindings and change the error- = |=0A= status to 'noError.' Further note that, while it might have = |=0A= been possible to fit more variable bindings if the proxy only = |=0A= re-sent the request multiple times, and stripped only a = single |=0A= variable binding from the request at a time, this is deemed = |=0A= too expensive. The approach described here preserves the = |=0A= behaviour of a GetBulkRequest as closely as possible, without = |=0A= incurring the cost of re-sending the request multiple times. = |=0A= =0A= - If a Trap-PDU is received, and will be forwarded using the=0A= SNMPv2c or SNMPv3 message version, the proxy SHALL apply = the=0A= translation rules described in section 3, and SHALL = forward=0A= the notification as an SNMPv2-Trap-PDU.=0A= =0A= Note that when an SNMPv1 agent generates a message = containing=0A= a Trap-PDU which is subsequently forwarded by one or more=0A= proxy forwarders using SNMP versions other than SNMPv1, = the=0A= community string and agent-addr fields from the original=0A= message generated by the SNMPv1 agent will be preserved=0A= through the use of the snmpTrapAddress and = snmpTrapCommunity=0A= objects.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 27]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 4.3.2. Upstream Version Less Than Downstream Version=0A= =0A= - If a GetResponse-PDU is received in response to a = GetRequest-=0A= PDU (previously generated by the proxy) which contains=0A= variable-bindings of type Counter64 or which contain an = SNMPv2=0A= exception code, and the message would be forwarded using = the=0A= SNMPv1 message version, the proxy MUST generate an = alternate=0A= response PDU consisting of the request-id and variable=0A= bindings from the original SNMPv1 request, containing a=0A= noSuchName error-status value, and containing an = error-index=0A= value indicating the position of the variable-binding=0A= containing the Counter64 type or exception code.=0A= =0A= - If a GetResponse-PDU is received in response to a=0A= GetNextRequest-PDU (previously generated by the proxy) = which=0A= contains variable-bindings that contain an SNMPv2 = exception=0A= code, and the message would be forwarded using the SNMPv1=0A= message version, the proxy MUST generate an alternate = response=0A= PDU consisting of the request-id and variable bindings = from=0A= the original SNMPv1 request, containing a noSuchName = error-=0A= status value, and containing an error-index value = indicating=0A= the position of the variable-binding containing the = exception=0A= code.=0A= =0A= - If a GetResponse-PDU is received in response to a=0A= GetNextRequest-PDU (previously generated by the proxy) = which=0A= contains variable-bindings of type Counter64, the proxy = MUST=0A= re-send the entire GetNextRequest-PDU, with the following=0A= modifications. For any variable bindings in the received=0A= GetResponse which contained Counter64 types, the proxy=0A= substitutes the object names of these variable bindings = for=0A= the corresponding object names in the previously-sent=0A= GetNextRequest. The proxy MUST repeat this process until = no=0A= Counter64 objects are returned. Note that an = implementation=0A= may attempt to optimize this process of skipping Counter64=0A= objects. One approach to such an optimization would be to=0A= replace the last sub-identifier of the object names of=0A= varbinds containing a Counter64 type with 65535 if that = sub-=0A= identifier is less than 65535, or with 4294967295 if that=0A= sub-identifier is greater than 65535. This approach = should=0A= skip multiple instances of the same Counter64 object, = while=0A= maintaining compatibility with some broken agent=0A= implementations (which only use 16-bit integers for sub-=0A= identifiers).=0A= =0A= Deployment Hint: The process of repeated GetNext requests=0A= used by a proxy when Counter64 types are returned can be=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 28]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= expensive. When deploying a proxy, this can be avoided by=0A= configuring the target agents to which the proxy forwards=0A= requests in a manner such that any objects of type = Counter64=0A= are in fact not-in-view for the principal that the proxy = is=0A= using when communicating with these agents. However, when = |=0A= using such a configuration, one should be careful to use a = |=0A= different principal for communicating with the target agent = |=0A= when an incoming SNMPv2c or SNMPv3 request is received, to = |=0A= ensure that objects of type Counter64 are properly returned. = |=0A= =0A= - If a GetResponse-PDU is received which contains an SNMPv2=0A= error-status value of wrongValue, wrongEncoding, = wrongType,=0A= wrongLength, inconsistentValue, noAccess, notWritable,=0A= noCreation, inconsistentName, resourceUnavailable, = |=0A= commitFailed, undoFailed, or authorizationError, and the = |=0A= message would be forwarded using the SNMPv1 message version, = |=0A= the error-status value is modified using the mappings in = |=0A= section 4.4. = |=0A= =0A= - If an SNMPv2-Trap-PDU is received, and will be forwarded = using=0A= the SNMPv1 message version, the proxy SHALL apply the=0A= translation rules described in section 3, and SHALL = forward=0A= the notification as a Trap-PDU. Note that if the = translation=0A= fails due to the existence of a Counter64 data-type in the=0A= received SNMPv2-Trap-PDU, the trap cannot be forwarded = using=0A= SNMPv1.=0A= =0A= - If an InformRequest-PDU is received, any configuration=0A= information indicating that it would be forwarded using = the=0A= SNMPv1 message version SHALL be ignored. An = InformRequest-PDU=0A= can only be forwarded using the SNMPv2c or SNMPv3 message=0A= version. The InformRequest-PDU may still be forwarded if=0A= there is other configuration information indicating that = it=0A= should be forwarded using SNMPv2c or SNMPv3.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 29]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 4.4. Error Status Mappings=0A= =0A= The following tables shows the mappings of SNMPv1 error-status = values=0A= into SNMPv2 error-status values, and the mappings of SNMPv2 = error-=0A= status values into SNMPv1 error-status values.=0A= =0A= SNMPv1 error-status SNMPv2 error-status=0A= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= noError noError=0A= tooBig tooBig=0A= noSuchName noSuchName=0A= badValue badValue=0A= genErr genErr=0A= =0A= =0A= SNMPv2 error-status SNMPv1 error-status=0A= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= noError noError=0A= tooBig tooBig=0A= genErr genErr=0A= wrongValue badValue=0A= wrongEncoding badValue=0A= wrongType badValue=0A= wrongLength badValue=0A= inconsistentValue badValue=0A= noAccess noSuchName=0A= notWritable noSuchName=0A= noCreation noSuchName=0A= inconsistentName noSuchName=0A= resourceUnavailable genErr=0A= commitFailed genErr=0A= undoFailed genErr=0A= authorizationError noSuchName=0A= =0A= =0A= Whenever the SNMPv2 error-status value of authorizationError is=0A= translated to an SNMPv1 error-status value of noSuchName, the = value=0A= of snmpInBadCommunityUses MUST be incremented.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 30]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 5. Message Processing Models and Security Models=0A= =0A= In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, = |=0A= the following Message Processing (MP) models are defined in this = |=0A= document: = |=0A= =0A= - The SNMPv1 Message Processing Model=0A= =0A= - The SNMPv1 Community-Based Security Model = -=0A= =0A= - The SNMPv2c Message Processing Model=0A= =0A= - The SNMPv2c Community-Based Security Model=0A= =0A= In most respects, the SNMPv1 Message Processing Model and the = SNMPv2c=0A= Message Processing Model are identical, and so these are not=0A= discussed independently in this document. Differences between = the=0A= two models are described as required.=0A= =0A= Similarly, the SNMPv1 Community-Based Security Model and the = SNMPv2c=0A= Community-Based Security Model are nearly identical, and so are = not=0A= discussed independently. Differences between these two models = are=0A= also described as required.=0A= =0A= =0A= 5.1. Mappings=0A= =0A= The SNMPv1 (and SNMPv2c) Message Processing Model and Security = Model=0A= require mappings between parameters used in SNMPv1 (and SNMPv2c)=0A= messages, and the version independent parameters used in the SNMP = |=0A= architecture [RFC3411]. = |=0A= The parameters which MUST be mapped consist of the SNMPv1 (and=0A= SNMPv2c) community name, and the SNMP securityName and=0A= contextEngineID/contextName pair. A MIB module (the = SNMP-COMMUNITY-=0A= MIB) is provided in this document in order to perform these = mappings.=0A= This MIB provides mappings in both directions, that is, a = community=0A= name may be mapped to a securityName, contextEngineID, and=0A= contextName, or the combination of securityName, contextEngineID, = and=0A= contextName may be mapped to a community name.=0A= =0A= =0A= 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model=0A= =0A= The SNMPv1 Message Processing Model handles processing of SNMPv1=0A= messages. The processing of messages is handled generally in the = |=0A= same manner as described in RFC 1157 [RFC1157], with differences and = |=0A= clarifications as described in the following sections. The=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 31]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for=0A= SNMPv2c is 1).=0A= =0A= =0A= =0A= 5.2.1. Processing An Incoming Request=0A= =0A= In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which = |=0A= receives a = |=0A= message, states that various parameters are passed to the = 'desired=0A= authentication scheme.' The desired authentication scheme in = this=0A= case is the SNMPv1 Community-Based Security Model, which will be=0A= called using the processIncomingMsg ASI. The parameters passed = to=0A= this ASI are:=0A= =0A= - The messageProcessingModel, which will be 0 (or 1 for=0A= SNMPv2c).=0A= =0A= - The maxMessageSize, which should be the maximum size of a=0A= message that the receiving entity can generate (since there = is=0A= no such value in the received message).=0A= =0A= - The securityParameters, which consist of the community = string=0A= and the message's source and destination transport domains = and=0A= addresses.=0A= =0A= - The securityModel, which will be 1 (or 2 for SNMPv2c).=0A= =0A= - The securityLevel, which will be noAuthNoPriv.=0A= =0A= - The wholeMsg and wholeMsgLength.=0A= =0A= The Community-Based Security Model will attempt to select a row = in=0A= the snmpCommunityTable. This is done by performing a search = through=0A= the snmpCommunityTable in lexicographic order. The first entry = for=0A= which the following matching criteria are satisfied will be = selected:=0A= =0A= - The community string is equal to the snmpCommunityName = value.=0A= =0A= - If the snmpCommunityTransportTag is an empty string, it is=0A= ignored for the purpose of matching. If the=0A= snmpCommunityTransportTag is not an empty string, the=0A= transportDomain and transportAddress from which the = message=0A= was received must match one of the entries in the=0A= snmpTargetAddrTable selected by the = snmpCommunityTransportTag=0A= value. The snmpTargetAddrTMask object is used as described = in=0A= section 5.3 when checking whether the transportDomain and=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 32]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= transportAddress matches a entry in the = snmpTargetAddrTable.=0A= =0A= If no such entry can be found, an authentication failure occurs as = |=0A= described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames = |=0A= counter = |=0A= is incremented.=0A= =0A= The parameters returned from the Community-Based Security Model = are:=0A= =0A= - The securityEngineID, which will always be the local value = of=0A= snmpEngineID.0.=0A= =0A= - The securityName, which will be the value of = |=0A= snmpCommunitySecurityName from the selected row in the = |=0A= snmpCommunityTable. = |=0A= =0A= - The scopedPDU. Note that this parameter will actually = consist=0A= of three values, the contextSnmpEngineID (which will be = the=0A= value of snmpCommunityContextEngineID from the selected = entry=0A= in the snmpCommunityTable), the contextName (which will be = the=0A= value of snmpCommunityContextName from the selected entry = in=0A= the snmpCommunityTable), and the PDU. These must be = separate=0A= values, since the first two do not actually appear in the=0A= message.=0A= =0A= - The maxSizeResponseScopedPDU, which will be derived using the = |=0A= minimum of the maxMessageSize above, and the value of = |=0A= snmpTargetAddrMMS of the selected row in the = |=0A= snmpTargetAddrTable. If no such entry was selected, then = this |=0A= value will be derived from the maxMessageSize only. = |=0A= =0A= - The securityStateReference, which MUST contain the community = |=0A= string from the original request. = |=0A= =0A= The appropriate SNMP application will then be called (depending = on=0A= the value of the contextEngineID and the request type in the PDU)=0A= using the processPdu ASI. The parameters passed to this ASI are:=0A= =0A= - The messageProcessingModel, which will be 0 (or 1 for=0A= SNMPv2c).=0A= =0A= - The securityModel, which will be 1 (or 2 for SNMPv2c).=0A= =0A= - The securityName, which was returned from the call to=0A= processIncomingMsg.=0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 33]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - The securityLevel, which is noAuthNoPriv.=0A= =0A= - The contextEngineID, which was returned as part of the=0A= ScopedPDU from the call to processIncomingMsg.=0A= =0A= - The contextName, which was returned as part of the = ScopedPDU=0A= from the call to processIncomingMsg.=0A= =0A= - The pduVersion, which should indicate an SNMPv1 version = PDU=0A= (if the message version was SNMPv2c, this would be an = SNMPv2=0A= version PDU).=0A= =0A= - The PDU, which was returned as part of the ScopedPDU from = the=0A= call to processIncomingMsg.=0A= =0A= - The maxSizeResponseScopedPDU which was returned from the = call=0A= to processIncomingMsg.=0A= =0A= - The stateReference which was returned from the call to=0A= processIncomingMsg.=0A= =0A= The SNMP application should process the request as described=0A= previously in this document. Note that access control is applied = by=0A= an SNMPv3 command responder application as usual. The parameters = as=0A= passed to the processPdu ASI will be used in calls to the=0A= isAccessAllowed ASI.=0A= =0A= =0A= =0A= 5.2.2. Generating An Outgoing Response=0A= =0A= There is no special processing required for generating an = outgoing=0A= response. However, the community string used in an outgoing = response=0A= must be the same as the community string from the original = request.=0A= The original community string MUST be present in the = |=0A= securityStateReference information of = |=0A= the original request.=0A= =0A= =0A= =0A= 5.2.3. Generating An Outgoing Notification=0A= =0A= In a multi-lingual SNMP entity, the parameters used for = generating=0A= notifications will be obtained by examining the SNMP-TARGET-MIB = and=0A= SNMP-NOTIFICATION-MIB. These parameters will be passed to the = SNMPv1=0A= Message Processing Model using the sendPdu ASI. The SNMPv1 = Message=0A= Processing Model will attempt to locate an appropriate community=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 34]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= string in the snmpCommunityTable based on the parameters passed = to=0A= the sendPdu ASI. This is done by performing a search through the=0A= snmpCommunityTable in lexicographic order. The first entry for = which=0A= the following matching criteria are satisfied will be selected:=0A= =0A= - The securityName must be equal to the=0A= snmpCommunitySecurityName value.=0A= =0A= - The contextEngineID must be equal to the=0A= snmpCommunityContextEngineID value.=0A= =0A= - The contextName must be equal to the = snmpCommunityContextName=0A= value.=0A= =0A= - If the snmpCommunityTransportTag is an empty string, it is=0A= ignored for the purpose of matching. If the=0A= snmpCommunityTransportTag is not an empty string, the=0A= transportDomain and transportAddress must match one of the=0A= entries in the snmpTargetAddrTable selected by the=0A= snmpCommunityTransportTag value.=0A= =0A= If no such entry can be found, the notification is not sent.=0A= Otherwise, the community string used in the outgoing notification=0A= will be the value of the snmpCommunityName column of the selected=0A= row.=0A= =0A= =0A= =0A= 5.2.4. Proxy Forwarding Of Requests=0A= =0A= In a proxy forwarding application, when a received request is to = be=0A= forwarded using the SNMPv1 Message Processing Model, the = parameters=0A= used for forwarding will be obtained by examining the = SNMP-PROXY-MIB=0A= and the SNMP-TARGET-MIB. These parameters will be passed to the=0A= SNMPv1 Message Processing Model using the sendPdu ASI. The = SNMPv1=0A= Message Processing Model will attempt to locate an appropriate=0A= community string in the snmpCommunityTable based on the = parameters=0A= passed to the sendPdu ASI. This is done by performing a search=0A= through the snmpCommunityTable in lexicographic order. The first=0A= entry for which the following matching criteria are satisfied will = be=0A= selected:=0A= =0A= - The securityName must be equal to the=0A= snmpCommunitySecurityName value.=0A= =0A= - The contextEngineID must be equal to the=0A= snmpCommunityContextEngineID value.=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 35]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - The contextName must be equal to the = snmpCommunityContextName=0A= value.=0A= =0A= If no such entry can be found, the proxy forwarding application = |=0A= should follow the procedure described in RFC 3413 [RFC3413], section = |=0A= 3.5.1.1, item (2). This procedure states that the snmpProxyDrops = |=0A= counter [RFC3418] = |=0A= is incremented, and that a Response-PDU is generated by calling = the=0A= Dispatcher using the returnResponsePdu abstract service = interface.=0A= =0A= =0A= =0A= =0A= 5.3. The SNMP Community MIB Module=0A= =0A= The SNMP-COMMUNITY-MIB contains objects for mapping between = community=0A= strings and version-independent SNMP message parameters. In=0A= addition, this MIB provides a mechanism for performing source = address=0A= validation on incoming requests, and for selecting community = strings=0A= based on target addresses for outgoing notifications. These two=0A= features are accomplished by providing a tag in the=0A= snmpCommunityTable which selects sets of entries in the = |=0A= snmpTargetAddrTable [RFC3413]. In addition, the SNMP-COMMUNITY-MIB = |=0A= augments the snmpTargetAddrTable with a transport address mask = value=0A= and a maximum message size value. These values are used only = where=0A= explicitly stated. In cases where the snmpTargetAddrTable is = used=0A= without mention of these augmenting values, the augmenting values=0A= should be ignored.=0A= =0A= The mask value, snmpTargetAddrTMask, allows selected entries in = the=0A= snmpTargetAddrTable to specify multiple addresses (rather than just = a=0A= single address per entry). This would typically be used to specify = a=0A= subnet in an snmpTargetAddrTable rather than just a single = address.=0A= The mask value is used to select which bits of a transport = address=0A= must match bits of the corresponding instance of=0A= snmpTargetAddrTAddress, in order for the transport address to match = a=0A= particular entry in the snmpTargetAddrTable. The value of an=0A= instance of snmpTargetAddrTMask must always be an OCTET STRING = whose=0A= length is either zero or the same as that of the corresponding=0A= instance of snmpTargetAddrTAddress.=0A= =0A= Note that the snmpTargetAddrTMask object is only used where=0A= explicitly stated. In particular, it is not used when generating=0A= notifications (i.e., when generating notifications, entries in = the=0A= snmpTargetAddrTable only specify individual addresses). If use of = |=0A= the snmpTargetAddrTMask object is not mentioned in text describing = |=0A= matching addresses in the snmpTargetAddrTable, then it's value MUST = |=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 36]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= be ignored. = |=0A= =0A= When checking whether a transport address matches an entry in the=0A= snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a = zero-=0A= length OCTET STRING, the mask value is ignored, and the value of=0A= snmpTargetAddrTAddress must exactly match a transport address.=0A= Otherwise, each bit of each octet in the snmpTargetAddrTMask = value=0A= corresponds to the same bit of the same octet in the=0A= snmpTargetAddrTAddress value. For bits that are set in the=0A= snmpTargetAddrTMask value (i.e., bits equal to 1), the = corresponding=0A= bits in the snmpTargetAddrTAddress value must match the bits in a=0A= transport address. If all such bits match, the transport address = is=0A= matched by that snmpTargetAddrTable entry. Otherwise, the = transport=0A= address is not matched.=0A= =0A= The maximum message size value, snmpTargetAddrMMS, is used to=0A= determine the maximum message size acceptable to another SNMP = entity=0A= when the value cannot be determined from the protocol.=0A= =0A= SNMP-COMMUNITY-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= IpAddress,=0A= MODULE-IDENTITY,=0A= OBJECT-TYPE,=0A= Integer32,=0A= snmpModules=0A= FROM SNMPv2-SMI=0A= RowStatus,=0A= StorageType=0A= FROM SNMPv2-TC=0A= SnmpAdminString,=0A= SnmpEngineID=0A= FROM SNMP-FRAMEWORK-MIB=0A= SnmpTagValue,=0A= snmpTargetAddrEntry=0A= FROM SNMP-TARGET-MIB=0A= MODULE-COMPLIANCE,=0A= OBJECT-GROUP=0A= FROM SNMPv2-CONF;=0A= =0A= snmpCommunityMIB MODULE-IDENTITY=0A= LAST-UPDATED "200302280000Z" -- 28 Feb 2003, midnight = |=0A= ORGANIZATION "SNMPv3 Working Group"=0A= CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com=0A= Subscribe: majordomo@lists.tislabs.com=0A= In msg body: subscribe snmpv3=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 37]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= Co-Chair: Russ Mundy=0A= Network Associates Laboratories = |=0A= Postal: 15204 Omega Drive, Suite 300 = |=0A= Rockville, MD 20850-4601 = |=0A= USA=0A= EMail: mundy@tislabs.com=0A= Phone: +1 301-947-7107 = |=0A= =0A= Co-Chair: David Harrington=0A= Enterasys Networks=0A= Postal: 35 Industrial Way=0A= P. O. Box 5005 = |=0A= Rochester, New Hampshire = 03866-5005=0A= USA=0A= EMail: dbh@enterasys.com=0A= Phone: +1 603-337-2614=0A= =0A= Co-editor: Rob Frye=0A= Vibrant Solutions=0A= Postal: 2711 Prosperity Ave=0A= Fairfax, Virginia 22031=0A= USA=0A= E-mail: rfrye@vibrant-1.com=0A= Phone: +1-703-270-2000=0A= =0A= Co-editor: David B. Levi=0A= Nortel Networks=0A= Postal: 3505 Kesterwood Drive=0A= Knoxville, Tennessee 37918=0A= E-mail: dlevi@nortelnetworks.com=0A= Phone: +1 423 686 0432=0A= =0A= Co-editor: Shawn A. Routhier=0A= Integrated Systems Inc.=0A= Postal: 333 North Ave 4th Floor=0A= Wakefield, Massachusetts 01880=0A= E-mail: sar@epilogue.com=0A= Phone: +1 781 245 0804=0A= =0A= Co-editor: Bert Wijnen=0A= Lucent Technologies=0A= Postal: Schagen 33=0A= 3461 GL Linschoten=0A= Netherlands=0A= Email: bwijnen@lucent.com=0A= Phone: +31-348-480-685 = |=0A= "=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 38]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= DESCRIPTION=0A= "This MIB module defines objects to help support = |=0A= coexistence between SNMPv1, SNMPv2c, and SNMPv3. = |=0A= = |=0A= Copyright (C) The Internet Society (2003) This = |=0A= version of this MIB module is part of RFC xxxx; = |=0A= see the RFC itself for full legal notices." = |=0A= -- = |=0A= -- RFC-editor: replace xxxx with the actual RFC = |=0A= -- number & remove this notice = |=0A= -- = |=0A= =0A= REVISION "200302280000Z" -- 28 Feb 2003 = |=0A= DESCRIPTION = |=0A= "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION = |=0A= clauses and added a copyright notice to the = |=0A= DESCRIPTION clause of the MIB module's = |=0A= MODULE-IDENTITY invocation. = |=0A= =0A= Updated the description of snmpCommunityTransportTag = |=0A= to make it consistent with the rest of the document. = |=0A= =0A= Updated the description of `snmpTargetAddrMMS' to = |=0A= clarify that a value of 0 means that the maximum = |=0A= message size is unknown. = |=0A= =0A= Changed the name of 'snmpCommunityGroup' to a name = |=0A= conflict with the SNMPv2-MIB. = |=0A= =0A= This version published as RFC xxxx." = |=0A= -- = |=0A= -- RFC-editor: replace xxxx with the actual RFC = |=0A= -- number & remove this notice = |=0A= -- = |=0A= REVISION "200003060000Z" -- 6 Mar 2000 = |=0A= DESCRIPTION "This version published as RFC 2576." = |=0A= =0A= ::=3D { snmpModules 18 }=0A= =0A= -- Administrative assignments = ************************************ |=0A= =0A= snmpCommunityMIBObjects = |=0A= OBJECT IDENTIFIER ::=3D { snmpCommunityMIB 1 } = |=0A= snmpCommunityMIBConformance = |=0A= OBJECT IDENTIFIER ::=3D { snmpCommunityMIB 2 } = |=0A= =0A= --=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 39]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= -- The snmpCommunityTable contains a database of community = |=0A= -- strings. This table provides mappings between community = |=0A= -- strings, and the parameters required for View-based Access = |=0A= -- Control. = |=0A= --=0A= =0A= snmpCommunityTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF SnmpCommunityEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "The table of community strings configured in the SNMP=0A= engine's Local Configuration Datastore (LCD)."=0A= ::=3D { snmpCommunityMIBObjects 1 }=0A= =0A= snmpCommunityEntry OBJECT-TYPE=0A= SYNTAX SnmpCommunityEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "Information about a particular community string."=0A= INDEX { IMPLIED snmpCommunityIndex }=0A= ::=3D { snmpCommunityTable 1 }=0A= =0A= SnmpCommunityEntry ::=3D SEQUENCE {=0A= snmpCommunityIndex SnmpAdminString,=0A= snmpCommunityName OCTET STRING,=0A= snmpCommunitySecurityName SnmpAdminString,=0A= snmpCommunityContextEngineID SnmpEngineID,=0A= snmpCommunityContextName SnmpAdminString,=0A= snmpCommunityTransportTag SnmpTagValue,=0A= snmpCommunityStorageType StorageType,=0A= snmpCommunityStatus RowStatus=0A= }=0A= =0A= snmpCommunityIndex OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "The unique index value of a row in this table."=0A= ::=3D { snmpCommunityEntry 1 }=0A= =0A= snmpCommunityName OBJECT-TYPE=0A= SYNTAX OCTET STRING=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 40]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= DESCRIPTION=0A= "The community string for which a row in this table=0A= represents a configuration. Although there is no SIZE = |=0A= restriction specified on this object, in practice, we do = |=0A= not expect people to use community names that are too = |=0A= long to cause the OID for an instance of this object to = |=0A= be more than 128 sub-identifiers. If they get longer, = |=0A= they may not be supported by (currently) existing SNMP = |=0A= engines." = |=0A= ::=3D { snmpCommunityEntry 2 }=0A= =0A= snmpCommunitySecurityName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "A human readable string representing the = corresponding=0A= value of snmpCommunityName in a Security Model=0A= independent format."=0A= ::=3D { snmpCommunityEntry 3 }=0A= =0A= snmpCommunityContextEngineID OBJECT-TYPE=0A= SYNTAX SnmpEngineID=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "The contextEngineID indicating the location of the=0A= context in which management information is accessed=0A= when using the community string specified by the=0A= corresponding instance of snmpCommunityName.=0A= =0A= The default value is the snmpEngineID of the entity = in=0A= which this object is instantiated."=0A= ::=3D { snmpCommunityEntry 4 }=0A= =0A= snmpCommunityContextName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(0..32))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "The context in which management information is = accessed=0A= when using the community string specified by the = |=0A= corresponding instance of snmpCommunityName." = |=0A= DEFVAL { ''H } -- the empty string=0A= ::=3D { snmpCommunityEntry 5 }=0A= =0A= snmpCommunityTransportTag OBJECT-TYPE=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 41]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= SYNTAX SnmpTagValue=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "This object specifies a set of transport endpoints=0A= which are used in two ways:=0A= - to specify the transport endpoints from which an=0A= SNMP entity will accept management requests, and=0A= - to specify the transport endpoints to which a=0A= notification may be sent using the community=0A= string matching the corresponding instance of=0A= snmpCommunityName.=0A= In either case, if the value of this object has=0A= zero-length, transport endpoints are not checked when=0A= either authenticating messages containing this community = |=0A= string, nor when generating notifications. = |=0A= =0A= The transports identified by this object are = specified=0A= in the snmpTargetAddrTable. Entries in that table=0A= whose snmpTargetAddrTagList contains this tag value=0A= are identified.=0A= =0A= If a management request containing a community string=0A= that matches the corresponding instance of=0A= snmpCommunityName is received on a transport endpoint=0A= other than the transport endpoints identified by this=0A= object the request is deemed unauthentic.=0A= =0A= When a notification is to be sent using an entry in=0A= this table, if the destination transport endpoint of=0A= the notification does not match one of the transport=0A= endpoints selected by this object, the notification=0A= is not sent."=0A= DEFVAL { ''H } -- the empty string=0A= ::=3D { snmpCommunityEntry 6 }=0A= =0A= snmpCommunityStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "The storage type for this conceptual row in the=0A= snmpCommunityTable. Conceptual rows having the value=0A= 'permanent' need not allow write-access to any=0A= columnar object in the row."=0A= ::=3D { snmpCommunityEntry 7 }=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 42]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= snmpCommunityStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "The status of this conceptual row in the = |=0A= snmpCommunityTable. = |=0A= =0A= An entry in this table is not qualified for = activation=0A= until instances of all corresponding columns have = been=0A= initialized, either through default values, or = through=0A= Set operations. The snmpCommunityName and=0A= snmpCommunitySecurityName objects must be explicitly = set.=0A= =0A= There is no restriction on setting columns in this = table=0A= when the value of snmpCommunityStatus is active(1)."=0A= ::=3D { snmpCommunityEntry 8 }=0A= =0A= --=0A= -- The snmpTargetAddrExtTable=0A= --=0A= =0A= snmpTargetAddrExtTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "The table of mask and maximum message size (mms) values = |=0A= associated with the snmpTargetAddrTable. = |=0A= =0A= The snmpTargetAddrExtTable augments the=0A= snmpTargetAddrTable with a transport address mask = value=0A= and a maximum message size value. The transport = address=0A= mask allows entries in the snmpTargetAddrTable to = define=0A= a set of addresses instead of just a single address.=0A= The maximum message size value allows the maximum=0A= message size of another SNMP entity to be configured = for=0A= use in SNMPv1 (and SNMPv2c) transactions, where the=0A= message format does not specify a maximum message = size."=0A= ::=3D { snmpCommunityMIBObjects 2 }=0A= =0A= snmpTargetAddrExtEntry OBJECT-TYPE=0A= SYNTAX SnmpTargetAddrExtEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "Information about a particular mask and mms value."=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 43]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= AUGMENTS { snmpTargetAddrEntry }=0A= ::=3D { snmpTargetAddrExtTable 1 }=0A= =0A= SnmpTargetAddrExtEntry ::=3D SEQUENCE {=0A= snmpTargetAddrTMask OCTET STRING,=0A= snmpTargetAddrMMS Integer32=0A= }=0A= =0A= snmpTargetAddrTMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE (0..255))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION=0A= "The mask value associated with an entry in the=0A= snmpTargetAddrTable. The value of this object must=0A= have the same length as the corresponding instance of=0A= snmpTargetAddrTAddress, or must have length 0. An=0A= attempt to set it to any other value will result in=0A= an inconsistentValue error.=0A= =0A= The value of this object allows an entry in the=0A= snmpTargetAddrTable to specify multiple addresses.=0A= The mask value is used to select which bits of=0A= a transport address must match bits of the = corresponding=0A= instance of snmpTargetAddrTAddress, in order for the=0A= transport address to match a particular entry in the=0A= snmpTargetAddrTable. Bits which are 1 in the mask=0A= value indicate bits in the transport address which=0A= must match bits in the snmpTargetAddrTAddress value.=0A= Bits which are 0 in the mask indicate bits in the=0A= transport address which need not match. If the=0A= length of the mask is 0, the mask should be treated=0A= as if all its bits were 1 and its length were equal=0A= to the length of the corresponding value of=0A= snmpTargetAddrTable.=0A= =0A= This object may not be modified while the value of = the=0A= corresponding instance of snmpTargetAddrRowStatus is=0A= active(1). An attempt to set this object in this = case=0A= will result in an inconsistentValue error."=0A= DEFVAL { ''H }=0A= ::=3D { snmpTargetAddrExtEntry 1 }=0A= =0A= snmpTargetAddrMMS OBJECT-TYPE=0A= SYNTAX Integer32 (0|484..2147483647)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 44]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= DESCRIPTION=0A= "The maximum message size value associated with an = entry=0A= in the snmpTargetAddrTable. Note that a value of 0 = means=0A= that the maximum message size is unknown."=0A= DEFVAL { 484 }=0A= ::=3D { snmpTargetAddrExtEntry 2 }=0A= =0A= --=0A= -- The snmpTrapAddress and snmpTrapCommunity objects are = included=0A= -- in notifications that are forwarded by a proxy, which were=0A= -- originally received as SNMPv1 Trap messages.=0A= --=0A= =0A= snmpTrapAddress OBJECT-TYPE=0A= SYNTAX IpAddress=0A= MAX-ACCESS accessible-for-notify=0A= STATUS current=0A= DESCRIPTION=0A= "The value of the agent-addr field of a Trap PDU which=0A= is forwarded by a proxy forwarder application using=0A= an SNMP version other than SNMPv1. The value of this=0A= object SHOULD contain the value of the agent-addr = field=0A= from the original Trap PDU as generated by an SNMPv1=0A= agent."=0A= ::=3D { snmpCommunityMIBObjects 3 }=0A= =0A= snmpTrapCommunity OBJECT-TYPE=0A= SYNTAX OCTET STRING=0A= MAX-ACCESS accessible-for-notify=0A= STATUS current=0A= DESCRIPTION=0A= "The value of the community string field of an SNMPv1=0A= message containing a Trap PDU which is forwarded by a=0A= a proxy forwarder application using an SNMP version=0A= other than SNMPv1. The value of this object SHOULD=0A= contain the value of the community string field from=0A= the original SNMPv1 message containing a Trap PDU as=0A= generated by an SNMPv1 agent."=0A= ::=3D { snmpCommunityMIBObjects 4 }=0A= =0A= -- Conformance Information ************************************** = |=0A= =0A= snmpCommunityMIBCompliances OBJECT IDENTIFIER=0A= ::=3D { snmpCommunityMIBConformance 1 = }=0A= snmpCommunityMIBGroups OBJECT IDENTIFIER=0A= ::=3D { snmpCommunityMIBConformance 2 = }=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 45]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= -- Compliance statements=0A= =0A= snmpCommunityMIBCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines which=0A= implement the SNMP-COMMUNITY-MIB."=0A= =0A= MODULE -- this module=0A= MANDATORY-GROUPS { snmpCommunityTableGroup }=0A= =0A= OBJECT snmpCommunityName=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunitySecurityName=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunityContextEngineID=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunityContextName=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunityTransportTag=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunityStorageType=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= OBJECT snmpCommunityStatus=0A= MIN-ACCESS read-only=0A= DESCRIPTION "Write access is not required."=0A= =0A= ::=3D { snmpCommunityMIBCompliances 1 }=0A= =0A= snmpProxyTrapForwardCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines which=0A= contain a proxy forwarding application which is=0A= capable of forwarding SNMPv1 traps using SNMPv2c=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 46]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= or SNMPv3."=0A= MODULE -- this module=0A= MANDATORY-GROUPS { snmpProxyTrapForwardGroup }=0A= ::=3D { snmpCommunityMIBCompliances 2 }=0A= =0A= snmpCommunityMIBFullCompliance MODULE-COMPLIANCE = +=0A= STATUS current = +=0A= DESCRIPTION = +=0A= "The compliance statement for SNMP engines which = +=0A= implement the SNMP-COMMUNITY-MIB with full read-create = +=0A= access." = +=0A= =0A= MODULE -- this module = +=0A= MANDATORY-GROUPS { snmpCommunityTableGroup } = +=0A= =0A= OBJECT snmpCommunityName = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is not required." = +=0A= =0A= OBJECT snmpCommunitySecurityName = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpCommunityContextEngineID = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpCommunityContextName = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpCommunityTransportTag = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpCommunityStorageType = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpCommunityStatus = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= OBJECT snmpTargetAddrTMask = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 47]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= OBJECT snmpTargetAddrMMS = +=0A= MIN-ACCESS read-create = +=0A= DESCRIPTION "Creation is required." = +=0A= =0A= ::=3D { snmpCommunityMIBCompliances 3 } = +=0A= =0A= snmpCommunityTableGroup OBJECT-GROUP=0A= OBJECTS {=0A= snmpCommunityName,=0A= snmpCommunitySecurityName,=0A= snmpCommunityContextEngineID,=0A= snmpCommunityContextName,=0A= snmpCommunityTransportTag,=0A= snmpCommunityStorageType,=0A= snmpCommunityStatus,=0A= snmpTargetAddrTMask,=0A= snmpTargetAddrMMS=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "A collection of objects providing for configuration=0A= of community strings for SNMPv1 (and SNMPv2c) usage."=0A= ::=3D { snmpCommunityMIBGroups 1 }=0A= =0A= snmpProxyTrapForwardGroup OBJECT-GROUP=0A= OBJECTS {=0A= snmpTrapAddress,=0A= snmpTrapCommunity=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Objects which are used by proxy forwarding = applications=0A= when translating traps between SNMP versions. These = are=0A= used to preserve SNMPv1-specific information when=0A= translating to SNMPv2c or SNMPv3."=0A= ::=3D { snmpCommunityMIBGroups 3 }=0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 48]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 6. Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= intellectual property or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described = in=0A= this document or the extent to which any license under such = rights=0A= might or might not be available; neither does it represent that = it=0A= has made any effort to identify any such rights. Information on = the=0A= IETF's procedures with respect to rights in standards-track and=0A= standards-related documentation can be found in BCP-11. Copies = of=0A= claims of rights made available for publication and any assurances = of=0A= licenses to be made available, or the result of an attempt made = to=0A= obtain a general license or permission for the use of such=0A= proprietary rights by implementors or users of this specification = can=0A= be obtained from the IETF Secretariat.=0A= =0A= The IETF invites any interested party to bring to its attention = any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights which may cover technology that may be required to = practice=0A= this standard. Please address the information to the IETF = Executive=0A= Director.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 49]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 7. Acknowledgments=0A= =0A= This document is the result of the efforts of the SNMPv3 Working=0A= Group. The design of the SNMP-COMMUNITY-MIB incorporates work = done=0A= by the authors of SNMPv2*:=0A= =0A= Jeff Case (SNMP Research, Inc.)=0A= David Harrington (Enterasys Networks)=0A= David Levi (Nortel Networks)=0A= Brian O'Keefe (Hewlett Packard)=0A= Jon Saperia (IronBridge Networks, Inc.)=0A= Steve Waldbusser (International Network Services)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 50]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 8. Security Considerations=0A= =0A= Although SNMPv1 and SNMPv2 do not provide any security, allowing=0A= community names to be mapped into securityName/contextName = provides=0A= the ability to use view-based access control to limit the access = of=0A= unsecured SNMPv1 and SNMPv2 operations. In fact, it is important = for=0A= network administrators to make use of this capability in order to=0A= avoid unauthorized access to MIB data that would otherwise be = secure.=0A= =0A= When a proxy implementation translates messages between SNMPv1 (or = -=0A= SNMPv2c) and SNMPv3, there may be a loss of security. For = example,=0A= an SNMPv3 message received using authentication and privacy which = is=0A= subsequently forwarded using SNMPv1 will lose the security = benefits=0A= of using authentication and privacy. Careful configuration of=0A= proxies is required to address such situations. One approach to = deal=0A= with such situations might be to use an encrypted tunnel.=0A= =0A= There are a number of management objects defined in this MIB module = +=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such = +=0A= objects may be considered sensitive or vulnerable in some network = +=0A= environments. The support for SET operations in a non-secure = +=0A= environment without proper protection can have a negative effect on = +=0A= network operations. These are the tables and objects and their = +=0A= sensitivity/vulnerability: = +=0A= =0A= - The snmpCommunityTable allows creation and deletion of = +=0A= community strings, which is potentially a serious security = +=0A= hole. Access to this table should be greatly restricted, = +=0A= preferably by only allowing write access using SNMPv3 VACM = and +=0A= USM, with authentication and privacy. = +=0A= =0A= - The snmpTargetAddrExtTable contains write-able objects which = +=0A= may also be considered sensitive, and so access to it should = +=0A= be restricted as well. = +=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with = a +=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or = +=0A= vulnerable in some network environments. It is thus important to = +=0A= control even GET and/or NOTIFY access to these objects and possibly = +=0A= to even encrypt the values of these objects when sending them over = +=0A= the network via SNMP. These are the tables and objects and their = +=0A= sensitivity/vulnerability: = +=0A= =0A= - The snmpCommunityTable has the potential to expose community = +=0A= strings which provide access to more information than that = +=0A= which is available using the usual 'public' community string. = +=0A= For this reason, a security administrator may wish to limit = +=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 51]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= accessibility to objects in the snmpCommunityTable, and in = +=0A= particular, to make it inaccessible when using the 'public' = +=0A= community string. = +=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security. = +=0A= Even if the network itself is secure (for example by using IPSec), = +=0A= even then, there is no control as to who on the secure network is = +=0A= allowed to access and GET/SET (read/change/create/delete) the = objects +=0A= in this MIB module. = +=0A= =0A= It is RECOMMENDED that implementers consider the security features = as +=0A= provided by the SNMPv3 framework (see [RFC3410], section 8), = +=0A= including full support for the SNMPv3 cryptographic mechanisms (for = +=0A= authentication and privacy). = +=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT = +=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to = +=0A= enable cryptographic security. It is then a customer/operator = +=0A= responsibility to ensure that the SNMP entity giving access to an = +=0A= instance of this MIB module is properly configured to give access to = +=0A= the objects only to those principals (users) that have legitimate = +=0A= rights to indeed GET or SET (change/create/delete) them. = +=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 52]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 9. References = +=0A= =0A= 9.1. Normative References=0A= =0A= [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification = of=0A= Management Information for TCP/IP-based internets"", = STD16,=0A= RFC 1155, May 1990.=0A= =0A= [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, = "Simple=0A= Network Management Protocol", STD15, RFC 1157, May 1990. = |=0A= =0A= [RFC1212] = |=0A= McCloghrie, K., and M. Rose, Editors, "Concise MIB=0A= Definitions", STD 16, RFC 1212, March 1991. = |=0A= =0A= [RFC1215] = |=0A= Rose, M. T., "A Convention for Defining Traps for use = with=0A= the SNMP", RFC 1215, March 1991.=0A= =0A= [RFC1303] McCloghrie, K., and M. Rose, "A Convention for = Describing=0A= SNMP-based Agents", RFC 1303, February 1992. = |=0A= =0A= [RFC1901] = |=0A= SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, = M.,=0A= and S. Waldbusser, "Introduction to Community-based = SNMPv2", |=0A= RFC 1901, January 1996. = |=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate = |=0A= Requirement Levels", BCP 14, RFC 2119, March 1997. = |=0A= =0A= [RFC2578] = |=0A= McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, = J.,=0A= Rose, M., and S. Waldbusser, "Structure of Management=0A= Information Version 2 (SMIv2)", RFC 2578, STD 58, April = |=0A= 1999. = |=0A= =0A= [RFC2579] = |=0A= McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, = J.,=0A= Rose, M., and S. Waldbusser, "Textual Conventions for=0A= SMIv2", RFC 2579, STD 58, April 1999. = |=0A= =0A= [RFC2580] = |=0A= McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, = J.,=0A= Rose, M., and S. Waldbusser, "Conformance Statements for=0A= SMIv2", RFC 2580, STD 58, April 1999. = |=0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 53]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= [RFC3411] Harrington, D., Wijnen, B., "An Architecture for Describing = |=0A= SNMP Management Frameworks", STD 62, RFC 3414, December = |=0A= 2002. = |=0A= =0A= [RFC3412] Case, J., Harrington, D., Wijnen, B., "Message Processing = |=0A= and Dispatching for the Simple Network Management Protocol = |=0A= (SNMP)", STD 62, RFC 3412, December 2002. = |=0A= =0A= [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", STD = |=0A= 62, RFC 3413, December 2002. = |=0A= =0A= [RFC3414] Blumenthal, U., Wijnen, B., "The User-Based Security Model = |=0A= for Version 3 of the Simple Network Management Protocol = |=0A= (SNMP)", STD 62, RFC 3414, December 2002. = |=0A= =0A= [RFC3415] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access = |=0A= Control Model for the Simple Network Management Protocol = |=0A= (SNMP)", STD 62, RFC 3415, December 2002. = |=0A= =0A= [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and = |=0A= S. Waldbusser, "Protocol Operations for Version 2 of the=0A= Simple Network Management Protocol (SNMPv2)", STD 62, RFC = |=0A= 3416, December 2002. = |=0A= =0A= [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. = |=0A= Waldbusser, = |=0A= "Transport Mappings for Version 2 of the Simple Network=0A= Management Protocol (SNMPv2)", STD 62, RFC 3417, December = |=0A= 2002. = |=0A= =0A= [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and = |=0A= S. Waldbusser, "Management Information Base for Version 2 = of=0A= the Simple Network Management Protocol (SNMPv2)", STD 62, = |=0A= RFC 3418, December 2002. = |=0A= =0A= [ASN1] = |=0A= Information processing systems - Open Systems=0A= Interconnection - Specification of Abstract Syntax = Notation=0A= One (ASN.1), International Organization for = Standardization.=0A= International Standard 8824, (December, 1987).=0A= =0A= =0A= 9.2. Informative References=0A= =0A= [RFC1908] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, ] = +=0A= "Coexistence between Version 1 and Version 2 of the = +=0A= Internet-standard Network Management Framework", RFC 1908, = +=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 54]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= January 1996. = +=0A= =0A= [RFC2089] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a = +=0A= bi-lingual SNMP agent", RFC 2089, January 1997. = +=0A= =0A= [RFC2576] Frye, R., Levi, D., Routhier, S., Wijnen, B., "Coexistence = +=0A= between Version 1, Version 2, and Version 3 of the = +=0A= Internet-standard Network Management Framework", RFC 2576, = +=0A= May 1999. = +=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, = +=0A= "Introduction and Applicability Statements for Internet- = +=0A= Standard Management Framework", RFC 3410, December 2002. = +=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 55]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 10. Editor's Addresses=0A= =0A= Rob Frye=0A= Vibrant Solutions=0A= 2711 Prosperity Ave=0A= Fairfax, Virginia 22031=0A= U.S.A.=0A= Phone: +1 703 270 2000=0A= EMail: rfrye@vibrant-1.com=0A= =0A= David B. Levi=0A= Nortel Networks=0A= 3505 Kesterwood Drive=0A= Knoxville, TN 37918=0A= U.S.A.=0A= Phone: +1 423 686 0432=0A= EMail: dlevi@nortelnetworks.com=0A= =0A= Shawn A. Routhier=0A= Integrated Systems Inc.=0A= 333 North Ave 4th Floor=0A= Wakefield MA 01880=0A= U.S.A.=0A= Phone: + 1 781 245 0804=0A= EMail: sar@epilogue.com=0A= =0A= Bert Wijnen=0A= Lucent Technologies=0A= Schagen 33=0A= 3461 GL Linschoten=0A= Netherlands=0A= Phone: +31 348 480 685 = |=0A= EMail: bwijnen@lucent.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 56]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= A. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved. = +=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 57]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= B. Change Log = |=0A= =0A= =0A= B.1. Changes From RFC 2576 = +=0A= =0A= Section numbers below refer to the old section numbers from RFC = 2576. +=0A= Some section numbers have changed since RFC 2576. = +=0A= =0A= =0A= - Changed "SHOULD" to "MUST" in item (13) of the first list in = +=0A= Section 2.1.1 to clarify that collecting related objects into = +=0A= groups is required when translating a MIB module from SMIv1 = to +=0A= SMIv2. = +=0A= =0A= - Changed "SHOULD" to "MUST" in items (1) and (2) of Section = 2.3 +=0A= since those updates are indeed required when translating a = +=0A= capabilities statement from the language defined by RFC 1303 = +=0A= into SMIv2. = +=0A= =0A= - Moved section 1.4 to the beginning of section 4. = +=0A= =0A= - In the second bullet of the last part of Section 3 listing = the +=0A= SNMPv2 notification parameters, clarified that the = snmpTrapOID +=0A= parameter refers to the value portion (not the name portion) = +=0A= of the second variable-binding, and changed the wording in = the +=0A= text under bullet (1) of Section 3.2 from "the snmpTrapOID" = to +=0A= "the snmpTrapOID value" to emphasize this point. = +=0A= =0A= - In Section 4.2 clarified that the 'Upstream Version' refers = to +=0A= the version used between the command generator or = notification +=0A= receiver and the proxy, and the 'Downstream Version' refers = to +=0A= the version used between the proxy and the command responder = +=0A= or notification originator. RFC 2576 neglected to mention = the +=0A= notification receiver and notification originator. = +=0A= =0A= - In Section 4.2.1 clarified that the error-index field must be = +=0A= set to zero in a translated GetResponse-PDU with an error- = +=0A= status of 'tooBig'. = +=0A= =0A= - In Section 5.2.1 clarified that the scopedPDU's = +=0A= contextSnmpEngineID and contextName values come from the = +=0A= selected entry in the snmpCommunityTable. = +=0A= =0A= - Added Section 5.2.4 on Proxy Forwarding Of Requests. = +=0A= =0A= - Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses = +=0A= and added a copyright notice to the DESCRIPTION clause of the = +=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 58]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= MIB module's MODULE-IDENTITY invocation. = +=0A= =0A= - Updated the description of snmpCommunityTransportTag to make = +=0A= it consistent with the rest of the document. = +=0A= =0A= - Updated the description of `snmpTargetAddrMMS' to clarify = that +=0A= a value of 0 means that the maximum message size is unknown. = +=0A= =0A= - Changed the name of 'snmpCommunityGroup' to a name conflict = +=0A= with the SNMPv2-MIB. = +=0A= =0A= - Divided references into Normative References and Informative = +=0A= Reference and updated them to point to current documents. = +=0A= =0A= - Inserted current year into all copyright notices. = +=0A= =0A= - Corrected various typographical and grammatical errors. = +=0A= =0A= - Re-organized bullets in section 2.1.1 to improve clarity. = +=0A= =0A= - Re-worded first bullet, section 4.2.1, to make it more = +=0A= readable. = +=0A= =0A= - Added text to abstract about conversion of MIBs from SMIv1 to = +=0A= SMIv2. = +=0A= =0A= - Added text at end of section 1.4 to clarify that there is no = +=0A= such thing as 'SNMPv3 access to MIB data,' as SNMPv3 just = uses +=0A= SNMPv2 PDU types and protocol operations. = +=0A= =0A= - Added note at end of section 1.3 that all discussion of = SNMPv2 +=0A= PDU types and protocol operations applies to both SNMPv2c and = +=0A= SNMPv3. = +=0A= =0A= - Added compliance statement to SNMP-COMMUNITY-MIB for full = +=0A= read-create compliance. = +=0A= =0A= - Added text to DESCRIPTION of snmpCommunityName to clarify why = +=0A= the object has no size restriction. = +=0A= =0A= =0A= B.2. Changes Between RFC 1908 and RFC 2576 = +=0A= =0A= =0A= - = +=0A= Editorial changes to comply with current RFC requirements.=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 59]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= - Added/updated copyright statements.=0A= =0A= - Added Intellectual Property section.=0A= =0A= - Replaced old introduction with complete new=0A= introduction/overview.=0A= =0A= - Added content for the Security Considerations Section.=0A= =0A= - Updated References to current documents.=0A= =0A= - Updated text to use current SNMP terminology.=0A= =0A= - Added coexistence for/with SNMPv3.=0A= =0A= - Added description for SNMPv1 and SNMPv2c Message = Processing=0A= Models and SNMPv1 and SNMPv2c Community-based Security = Models.=0A= =0A= - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community=0A= strings can be mapped into the SNMP Version Independent = |=0A= parameters which = |=0A= can then be used for access control using the standard = SNMPv3=0A= View-based Access Control Model and the snmpVacmMIB.=0A= =0A= - Added two MIB objects such that when an SNMPv1 = notification=0A= (trap) must be converted into an SNMPv2 notification we = add=0A= those two objects in order to preserve information about = the=0A= address and community of the originating SNMPv1 agent.=0A= =0A= - Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 = |=0A= mapping = |=0A= within a multi-lingual SNMP Engine.=0A= =0A= - Use keywords from RFC 2119 to describe requirements for=0A= compliance.=0A= =0A= - Changed/added some rules for converting a MIB module from=0A= SMIv1 to SMIv2.=0A= =0A= - Extended and improved the description of Proxy Forwarder=0A= behaviour when multiple SNMP versions are involved.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 60]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= Table Of Contents = -=0A= =0A= =0A= 1 Overview ..................................................... = 5=0A= 1.1 SNMPv1 ..................................................... = 5=0A= 1.2 SNMPv2 ..................................................... = 6=0A= 1.3 SNMPv3 ..................................................... = 7=0A= 2 SMI and Management Information Mappings ...................... = 8=0A= 2.1 MIB Modules ................................................ = 8=0A= 2.1.1 Object Definitions ....................................... = 8=0A= 2.1.2 Trap and Notification Definitions ........................ = 11=0A= 2.2 Compliance Statements ...................................... = 12=0A= 2.3 Capabilities Statements .................................... = 12=0A= 3 Translating Notification Parameters .......................... = 13=0A= 3.1 Translating SNMPv1 Notification Parameters to SNMPv2=0A= Notification Parameters ................................... = 14=0A= 3.2 Translating SNMPv2 Notification Parameters to SNMPv1=0A= Notification Parameters ................................... = 15=0A= 4 Approaches to Coexistence in a Multi-lingual Network ......... = 18=0A= 4.1 SNMPv1 and SNMPv2 Access to MIB Data ....................... = 18=0A= 4.2 Multi-lingual implementations .............................. = 19=0A= 4.2.1 Command Generator ........................................ = 19=0A= 4.2.2 Command Responder ........................................ = 19=0A= 4.2.2.1 Handling Counter64 ..................................... = 20=0A= 4.2.2.2 Mapping SNMPv2 Exceptions .............................. = 21=0A= 4.2.2.2.1 Mapping noSuchObject and noSuchInstance .............. = 22=0A= 4.2.2.2.2 Mapping endOfMibView ................................. = 22=0A= 4.2.2.3 Processing An SNMPv1 GetRequest ........................ = 22=0A= 4.2.2.4 Processing An SNMPv1 GetNextRequest .................... = 23=0A= 4.2.2.5 Processing An SNMPv1 SetRequest ........................ = 24=0A= 4.2.3 Notification Originator .................................. = 25=0A= 4.2.4 Notification Receiver .................................... = 26=0A= 4.3 Proxy Implementations ...................................... = 26=0A= 4.3.1 Upstream Version Greater Than Downstream Version ......... = 26=0A= 4.3.2 Upstream Version Less Than Downstream Version ............ = 28=0A= 4.4 Error Status Mappings ...................................... = 30=0A= 5 Message Processing Models and Security Models ................ = 31=0A= 5.1 Mappings ................................................... = 31=0A= 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security=0A= Model ..................................................... = 31=0A= 5.2.1 Processing An Incoming Request ........................... = 32=0A= 5.2.2 Generating An Outgoing Response .......................... = 34=0A= 5.2.3 Generating An Outgoing Notification ...................... = 34=0A= 5.2.4 Proxy Forwarding Of Requests ............................. = 35=0A= 5.3 The SNMP Community MIB Module .............................. = 36=0A= 6 Intellectual Property ........................................ = 49=0A= 7 Acknowledgments .............................................. = 50=0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 61]=0A= =0C=0A= Internet Draft Coexistence between SNMP versions 28 Feb = 2003=0A= =0A= =0A= 8 Security Considerations ...................................... = 51=0A= 9 References ................................................... = 53=0A= 9.1 Normative References ....................................... = 53=0A= 9.2 Informative References ..................................... = 54=0A= 10 Editor's Addresses .......................................... = 56=0A= A. Full Copyright Statement .................................... = 57=0A= B. Change Log .................................................. = 58=0A= B.1. Changes From RFC 2576 ..................................... = 58=0A= B.2. Changes Between RFC 1908 and RFC 2576 ..................... = 59=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= SNMPv3 Working Group Expires August 2003 [Page 62]=0A= =0C=0A= ------_=_NextPart_000_01C2DF78.DF1E1D3C Content-Type: text/plain; name="changes.txt" Content-Disposition: attachment; filename="changes.txt" Content-Transfer-Encoding: quoted-printable ------------------------ =20 The following edits have been made to the Coex draft, to be circulated = soon for WG Last Call. =20 ------------------------ ------------------------ Changes based on "Re: WG last call: Coex draft spelling check" from Tom = Petch [mailto:nwnetworks@dial.pipex.com ] sent Sunday, December 29, 2002 8:08 AM =20 =20 > > s1) There should not be a comma before the words "and",=20 > "or" in a list=20 > > of items (I was taught). ...=20 =20 No. The "serial comma" (comma after SNMPv2 in "SNMPv1, SNMPv2, or = SNMPv3") is a) legal and b) preferred according to the Chicago Manual of Style. Removal doesn't clarify anything, no change. =20 > > s2) There are three "e-mail" (which I regard as correct) and seven=20 > > "email" (which I do not) in 5.4 and 10. I suggest the latter be=20 > > brought in line with the former. I have not flagged these=20 > separately. =20 =20 Nit. No change. > > s3) J Case's organisation is given four times in Section 9 as=20 > > " SNMP Research,Inc."=20 > > which I suggest should be=20 > > " SNMP Research, Inc."=20 =20 Nit. No change. > > S4) Copyright Notice=20 > > **/(2001)/(2002)/ =20 =20 Changed to 2003. > > S5) In the running title, I suggest **/versions/Versions/ =20 =20 No. "versions" not intended to be proper noun. > > s6) Table Of Contents=20 > > I assume the errors here will be corrected automatically when the=20 > > titles of the sections are themselves corrected (corrections below) = =20 =20 Correct; no specific edits made to TOC. > > s7) 1. Overview=20 > > "The purpose of this document ...=20 > > termed the SNMP version 2 framework (SNMPv2), **(comma ok here) = > > and ..." =20 =20 Non-change. > >=20 > > s8) "- Approaches to coexistence ...=20 > > as well as **//the/ behaviour of proxy implementations. =20 =20 Nit. No change. > > s9) "- The SNMPv1 Message Processing Model and Community-Based=20 > > Security Model, which **/provides/provide/ mechanisms ..." = > > for adapting SNMPv1=20 > > into the View-Based Access Control Model (VACM) [20],=20 > > **/is/are/=20 > > documented in section 5 ... "=20 > > (models plural) =20 =20 No. Wrong reading of what is plural.=20 =20 > > s10) 1.1. SNMPv1=20 > > "- STD 16, RFC 1212 [3] which defines a more concise=20 > > description=20 > > mechanism, which is **/wholly/wholy/ consistent with..." = =20 No. Correct spelling is "wholly" according to US English. > > s11) " .. 'SMIv1' is used. This term **/generally refers/refers=20 > > generically/ to the ..." =20 =20 Nit. No change. > > s12) 1.2. SNMPv2=20 > > " ...(RFCs 2578, 2579, and 2580)"=20 > > (I would prefer /RFC 2578, RFC 2579 and RFC 2580/; the=20 > reference is=20 > > more to a document which has the title RFC 2580 as opposed to the=20 > > 2580th item in a list called RFC). =20 =20 Nit. No change.=20 > > s13) 1.3. SNMPv3=20 > > (Not checked, section needs replacing) =20 =20 No change from Tom. RFC numbers updated to 341x series.=20 =20 > > s14) 2.1.1. Object Definitions=20 > > This contains three numbered lists (of MUSTS, SHOULDs/MAYs then=20 > > MUSTs again) all enumerated from one. This makes any references to = > > items in the lists (eg from a working group debating the=20 > changes they=20 > > need to make) clumsy.=20 >> I suggest that either the three lists have a=20 > > single enumeration or, which I would prefer, the section is=20 > split into=20 > > two with the MUSTs in one, the rest in the other, each with an=20 > > enumeration starting from one. =20 =20 Done. > > s15) (2) "The MODULE-IDENTITY macro ... any **/IMPORTs/IMPORTS/=20 > > statement"=20 > >=20 > > s16) (12) "For any object containing a DEFVAL ... (OBJECT=20 > > IDENTIFIER**/S/s/) ..."=20 > >=20 > > s17) (13) "One or more **/OBJECT-GROUPS/OBJECT-GROUPs/ MUST be=20 > > defined" =20 =20 No change. > > s18) 2.1.2. Trap and Notification Definitions=20 > > (5) "The value of an invocation ... not an INTEGER,=20 > **(comma ok=20 > > here) and MUST ..." =20 =20 OK. Non-change. > > s19) 2.3. Capabilities Statements=20 > > "all leaf objects which are subordinate to the subtree=20 > and have a=20 > > STATUS clause value of mandatory are deemed to be INCLUDEd."=20 > > What is the past tense of INCLUDES? INCLUDESed? ugly.=20 > > Perhaps change to /are implicitly deemed to be the subject of an=20 > > INCLUDES clause/ (but I do not know the INCLUDES clause=20 > well enough to=20 > > be sure 'subject' is the right noun). =20 =20 No. Makes less clear. Readers understand "INCLUDEd". > > s20) 3. "Translating **/Notifications Parameters/Notification=20 > > Parameters/"=20 > > (since that is the phrase defined in the next paragraph) =20 =20 No change.=20 =20 > > s21) "This section describes how parameters ...=20 > > **/refered/referred/ to in this document ...=20 > > is **/refered/referred/ to in this document ...." =20 =20 Done. > > s22) 3.1. Should the OIDs listed under 'snmpTrapOID.0'=20 > start .1.3.6 as=20 > > opposed to 1.3.6? =20 =20 No. Wrong. > > s23) 5) "The SNMPv2 variable-bindings ... bindings will be = appended=20 > > ..."=20 > > (Given that appended means add at the end, whereas=20 > prepended means=20 > > add at the beginning and added means add somewhere, is appended the = > > right term? I think I see prepends not appends). =20 =20 No, the additional variable binding must be at the end of the list, in order to conform to RFC 3416, section 4.2.6. =20 > > s24) 3.2. "(1) The SNMPv1 enterprise parameter SHALL be=20 > determined as=20 > > follows:=20 > > the SNMPv2 snmpTrapOID value with the last **/2/two/=20 > > sub-identifiers..." =20 > > (usual to spell out small numbers)=20 =20 No. Nit. =20 > > s25) (2) "... and the notification is to be sent over IP .."=20 > > (Should this specify IPv4 or is IPv6 too remote to consider=20 > > here?) =20 =20 No. Specifically should NOT state IPv4. > > s26) (3) Same comment as s22) =20 =20 Same answer: No. Wrong. > > s27) 4. "There are two basic approaches ...=20 > > with any **/mono-lingual/monolingual/ implementation,=20 > regardless=20 > > of the SNMP version=20 > > supported by the **/mono-lingual/monolingual/ implementation"=20 > > (multi-lingual but monolingual) =20 =20 No. Nit. > > s28) "Proxy implementations provide a mechanism ...=20 > > This allows network elements which support only a single, but = > > **/different/not the same/,=20 > > SNMP version to communicate with each other"=20 > > (different needs 'SNMP versions' plural whereas 'not the=20 > same' takes=20 > > the singular) =20 =20 No. Nit. =20 > > s29) 4.1.2.3. Processing An SNMPv1 GetRequest=20 > > "...or an **/SNMP/SMI/v2 syntax that is unknown to=20 > **/SNMP/SMI/v1=20 > > ..."=20 > > (From the earlier sections eg section 2, syntax is part of the = > > SMI not SNMP) =20 =20 Wrong; different levels of processing. > > s30) 4.1.2.4. Processing An SNMPv1 GetNextRequest=20 > > (Two number lists again; I suggest splitting this into=20 > 4.1.2.4.1=20 > > for errors and 4.1.2.4.2 for noError) =20 =20 No. Clear enough to readers/discussion by reference. > > s31) 4.1.2.4. Processing An SNMPv1 GetNextRequest=20 > > "When processing an SNMPv1 GetNextRequest ... the following=20 > > procedures MUST be followed when **/an// SNMPv2 access to=20 > MIB data is=20 > > called as part of processing the request. ...=20 > > Or, perhaps better=20 > still, **/an=20 > > SNMPv2 access to MIB data is called/an SNMPv2 access routine is=20 > > called/ access routine is the phrase used in the next section) =20 =20 Done. > > s32) 4.1.2.4 1) **/not in view/not-in-view/=20 > > (for consistency with 4.2.2) =20 =20 Nit. No change.=20 > > s33) "Otherwise, if the access to MIB data ...=20 > > (2) "... (**/there may be more than one,/ if there is=20 > more than=20 > > one,/ it is an implementation decision ..." =20 =20 Done. > > s34) (3) "- The variable binding list of the response SHALL be=20 > > **/composed/generated/=20 > > from the data as it is returned by the access to MIB = data"=20 > > (composed of, generated from) =20 =20 No. Nit. > > s35) 4.1.4. Notification Receiver=20 > > "There are no special requirements **/of/for/ a notification=20 > > receiver" =20 =20 Nit. No change. > > s36) 4.1.4. Notification Receiver=20 > > "However, an implementation may find it useful ... to=20 > > **/request/establish/ whether ..."=20 > > (I do not 'request whether'). =20 =20 No. Terminology correct for protocol layers & requests to lower = layers. > > s37) 4.2. Proxy Implementations=20 > > "A proxy implementation ... subject to size=20 > > **/contraints/constraints/ as defined" =20 =20 Done. > > s38) 4.2.1. Upstream Version Greater Than Downstream Version=20 > > "- If a GetBulkRequest-PDU is received and must be forwarded=20 > > using the SNMPv1 message version, the proxy=20 > forwarder SHALL=20 > > set the non-repeaters and max-repetitions fields to 0"=20 > > (the proxy forwarder is setting fields in an SNMPv1=20 > PDU where the=20 > > non-repeaters and max-repetitions fields do not exist - I suggest=20 > > error-index and error-status instead) =20 =20 Reworded as: If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU. > > s39) "- If a GetResponse-PDU is received whose=20 > error-status field has=20 > > a value of **/'tooBig,'/'tooBig',/ .... contains an=20 > > error-status field=20 > > with a value of **/'tooBig,'/'tooBig',/=20 > > and change the error-status to /'noError.'/'noError'./=20 > > (move punctuation outside the quotes) =20 =20 Nit. No change. > > s40) 4.2.2. Upstream Version Less Than Downstream Version=20 > > "- If a GetResponse-PDU is received ... the proxy=20 > MUST generate=20 > > an alternate response=20 > > PDU.."=20 > > (I am not clear if alternate means a replacement PDU or an=20 > > additional PDU; alternate is famously a word whose American sense = is=20 > > not its English sense but I find neither sense clear here) =20 =20 No change made. "alternate" meant in replacement sense. I think = readers understand it. > > s41) "- If a GetResponse-PDU is received in response to a=20 > > GetNextRequest-PDU ..."=20 > > "- If a GetResponse-PDU is received which contains an SNMPv2=20 > > (in both cases you should add=20 > > /and the message would be forwarded using the SNMPv1 = message=20 > > version/=20 > > as in other paragraphs ... =20 Done. =20 > > s42) 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security=20 > > Model=20 > > (this is the first use of the acronym MP and so it should be=20 > > expanded) =20 =20 Changed text in section 5 to say "Message Processing (MP)". > > s43) 5.2.1. Processing An Incoming Request=20 > > "In RFC1157 [2], section 4.1, item (3) for an entity which=20 > > receives a=20 > > message, states ..."=20 > > (RCFC1157 section 4.1 has two numbered lists both containing = an=20 > > item 3) which is why this reference is a little clumsy! I suggest=20 > > /In section 4.1 of RFC1157 [2], item (3) of the list of=20 > actions (for=20 > > an entity which receives a message) states / =20 =20 No. Clear from context. > > s44) "... parameters are passed to the 'desired authentication=20 > > **/scheme.'/scheme'./ =20 > > s45) "The desired authentication scheme .. using the=20 > > processIncomingMsg ASI)=20 > > (First use of ASI - needs expanding)=20 > >=20 > > s46) "- If the snmpCommunityTransportTag is an empty=20 > string ... when=20 > > checking whether=20 > > **//or not/ the transportDomain ..."=20 > > ('whether' needs an alternative)=20 =20 Above 3 changes: No. Nit. > > s47) "- The pduVersion, which should indicate an SNMPv1 version = PDU=20 > > (if the message version was SNMPv2c, this would be an SNMPv2=20 > > version PDU)"=20 > > (seems clumsy - either it should or it should not be an SNMPv1 = > > version PDU; how about=20 > > /which will indicate an SNMPv1 version PDU (or an=20 > SNMPv2c version=20 > > PDU where appropriate)/ =20 =20 No change. =20 > > s48) 5.3. The SNMP Community MIB Module=20 > > "When checking whether **//or not/ a transport address matches = =20 =20 No. Nit. > > s49) snmpCommunityTransportTag OBJECT-TYPE=20 > > "This object specifies a set of transport endpoints which=20 > > **/are/is/ used"=20 > > (a set is singular) =20 =20 Does not clarify. No change. =20 > > s50) "In either case, if the value of this object has zero-length,=20 > > transport endpoints are not checked when authenticating messages=20 > > containing this community string, nor when generating=20 > notifications."=20 > > (does the qualification 'containing this community=20 > string' apply=20 > > to generating notifications? I think it does in which case I would=20 > > reword to=20 > > /transport endpoints are not checked either when=20 > authenticating=20 > > messages or when generating notifications, each of which=20 > contain this=20 > > community string./ =20 =20 No. Specifically not checked when generating Notifications. > > s51) "If a management request containing a community string ...=20 > > the request is deemed **/unauthentic/inauthentic/" =20 =20 Don't care. > > s52) snmpTargetAddrExtTable OBJECT-TYPE=20 > > "The table of mask and mms values ...=20 > > (the first use of 'mms' - should be expanded) =20 =20 Done. > > s53) snmpTrapAddress=20 > > "The value of the agent-addr field of a Trap PDU = which=20 > > is forwarded by a proxy forwarder application using = ...=20 No change. =20 > > s54) snmpCommunityTableGroup OBJECT-GROUP=20 > > "A collection of objects providing for configuration ..."=20 > > (suggest /objects which allow configuration/; 'provide for'=20 > > sounds like a parent with impecunious children) =20 =20 No change . > > s55) 7. **/Acknowledgments/Acknowledgements/ =20 =20 No. Both spellings legal, "Acknowledgments" is US preferred spelling. > > s56) A. Full Copyright Statement=20 > > (I think the copyright notice line should appear here as well as on = > > the first page). =20 =20 No. Follows standards. > > s57) B. Changes From RFC1908=20 > > "- Added snmpCommunityMIB ... **/paramaters/parameters/ = which=20 > > can then be used..." =20 =20 Done. Additional changes per WG email threads: - 9. References split into 9. Normative References and 10. Informative References. Changes align with Mike Heard's suggestions. - References done according to 2223bis. - Reviewed 2223bis, policy.html, 1id-guidelines.txt, ID-nits.html -- = This I-D now adheres to all appropriately. - No change made regarding handling of Counter64 in 2089 vs 2576. The move in 2576 to not send a notification with Counter64 was = purposeful. - Extra closing quote removed that Mike Heard pointed out in the snmpCommunityTransportTag DESCRIPTION clause: << string, nor when generating notifications." >> - Copyrights updated to 2003. - Fixed section 5.1 text indentation - Added change log from 2576. - Revisions of MIB as per Mike Heard's suggestions: removed all I-D = revisions, now have: DESCRIPTION "This MIB module defines objects to help support = coexistence between SNMPv1, SNMPv2c, and SNMPv3. =20 Copyright (C) The Internet Society (2003) This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- RFC-editor: replace xxxx with the actual RFC number & remove this = notice =20 REVISION "200301130000Z" -- 13 Jan 2003 (same as LAST-UPDATED) DESCRIPTION "Updated description of snmpCommunityTag to make it consistent with the rest of the document, and = additional edits per WG Last Call comments. This version published as = draft-ietf-snmpv3-coex-v2-03.txt and RFC xxxx." -- RFC-editor: replace xxxx with the actual RFC number & remove this = notice REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576." =20 ------------------------ ------------------------ Changes based on "review draft-ietf-snmpv3-coex-v2-02.txt" from Harrie Hazewinkel [mailto:harrie@lisanza.net] sent Wednesday, January 08, 2003 5:21 AM > -----Original Message----- > From: Harrie Hazewinkel [mailto:harrie@lisanza.net] > Sent: Wednesday, January 08, 2003 5:21 AM > To: WG IETF snmpv3 > Cc: David Harrington > Subject: review draft-ietf-snmpv3-coex-v2-02.txt >=20 >=20 > Hi, >=20 > I have reviewed the draft and here are my comments. > I believe there is nothing broken, but some clarifications > could be usefull. >=20 > See below between pieces of the draft. >=20 >=20 > > Coexistence between Version 1, Version 2, and Version 3 > > of the Internet-standard Network Management Framework > > >=20 > > Abstract > > > > The purpose of this document is to describe coexistence between > > version 3 of the Internet-standard Network Management Framework, > > (SNMPv3), version 2 of the Internet-standard Network Management > > Framework (SNMPv2), and the original Internet-standard Network > > Management Framework (SNMPv1). This document obsoletes RFC 2576 > > [21]. >=20 > Just to be clear. It basically speaks about coexistance between > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions > against the other versions. right? >=20 > I am asking, since > - for instance, section 1.4 looks like v1 and v2 only (See=20 > there also). > - the document also describes coexistance between SMIv1 and SMIv2 > where SMIv2 is a seperate standard. > Is that therefore needed in this document? > Is SMIv1 and SMIv2 not usefull if that will be added in the=20 > abstract? Added text to abstract: This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. >=20 > > Table Of Contents > [snip] > > B. Changes From RFC1908=20 > ........................................ 55 >=20 > What about the changes since RFC2576? > Mentioned already by, "C. M. Heard" There will be an updated change log in the upcoming I-D. > > 1.4. SNMPv1 and SNMPv2 Access to MIB Data >=20 > Correct me if I am wrong, but this is related to the SNMP-PDU > and the SNMP-PDU is not different between SNMPv3 and SNMPv2. > For MIB access the difference between SNMPv3 and SNMPv2 is nihil, > but that is maybe worthwhile mentioning. Also since a big part of > the document uses this. Added text to clarify this at the end of section 1.4 (now section 4.1). >=20 > > SNMPv1 access to MIB data may generate SNMPv1=20 > error-status values, > > will never generate exception codes nor use the=20 > Counter64 data type, > > and will provide SNMPv1 format parameters for generating > > notifications. Note also that SNMPv1 access to MIB data will > > actually never generate a readOnly error (a noSuchName=20 > error would > > always occur in the situation where one would expect a readOnly > > error). > > > > SNMPv2 access to MIB data may generate SNMPv2=20 > error-status values, > > may generate exception codes, may use the Counter64 data=20 > type, and > > will provide SNMPv2 format parameters for generating=20 > notifications. > > Note that SNMPv2 access to MIB data will never generate = readOnly, > > noSuchName, or badValue errors. >=20 > The above two paragraphs make it look like the 'readOnly'=20 > error exists, > but may never be used. Maybe it maybe used for SNMPv3. That's right, it exists, but is never used. Nothing to change. > This section 1.4 seems also the be hanging between section 2 and 3. Moved section 1.4 into section 4, the terms defined in section 1.4 were only used in section 4. > Also later section 4.3 discusses the mapping between SNMPv1=20 > and SNMPv2, > but there is also SNMPv3 equal to SNMPv2. Somehow, I get the feeling > this is more SMIv1 and SMIv2 access to the MIB. Added text at end of section 1.3 to clarify this. > > 2. SMI and Management Information Mappings > > > > 2.1. MIB Modules > > > > MIB modules defined using the SMIv1 may continue to be used with > > protocol versions which use SNMPv2 PDUs. However, for the MIB > ^^^^^^^ > suggested change into 'the SMIv1 MIB', since this section is > SMIv1 to SMIv2 translation. (This could be used in more=20 > places later on.) Changed 'for the MIB' to 'for SMIv1 MIB' >=20 > > modules to conform to the SMIv2, the following changes=20 > SHALL be made: > > > > 2.1.1. Object Definitions > > > > In general, conversion of a MIB module does not require the > > deprecation of the objects contained therein. If the=20 > definition of > > an object is truly inadequate for its intended purpose,=20 > the object > > SHALL be deprecated or obsoleted, otherwise deprecation is not > > required. >=20 > I am just curious about the text "If the definition of > an object is truly inadequate for its intended purpose". > which does not make it look like a conversion from SMIv1 to SMIv2 > or vice versa. That is more a design/experience issue. This text is just to clarify that converting a MIB from SMIv1 to SMIv2 does not mean you must deprecate objects, unless there there is some other good reason to deprecate them. No change. > > 3. Translating Notifications Parameters > > > > This section describes how parameters used for generating > > notifications are translated between the format used for SNMPv1 > > notification protocol operations and the format used for SNMPv2 > > notification protocol operations. The parameters used=20 > to generate a > > notification are called 'notification parameters.' The format = of > > parameters used for SNMPv1 notification protocol operations is > > refered to in this document as 'SNMPv1 notification=20 > parameters.' The > > format of parameters used for SNMPv2 notification=20 > protocol operations > > is refered to in this document as 'SNMPv2 notification=20 > parameters.' >=20 > What about SNMPv3 'notification parameters'?? > I guess, this is similar to my comment earlier in section 1.4. Since 'notification parameters' are determined by the version of = protocol operations, there are only SNMPv1 and SNMPv2 'notification parameters.' I don't think there's anything we need to change here. > > 4.1.1. Command Generator > > > > A command generator must select an appropriate message=20 > version when > > sending requests to another entity. One way to achieve=20 > this is to > > consult a local database to select the appropriate=20 > message version. > > > > In addition, a command generator MUST 'downgrade'=20 > GetBulk requests to > > GetNext requests when selecting SNMPv1 as the message=20 > version for an > > outgoing request. This is done by simply changing the=20 > operation type > > to GetNext, ignoring any non-repeaters and=20 > max-repetitions values, > > and setting error-status and error-index to zero. >=20 > Correct me if I am wrong, but this does not provide the same=20 > functionality > from the command generators point of view. Should that be noted?? This is true, but I think we would be adding too much detail about how to implement code if we said anything more here. No change. > > 4.1.3. Notification Originator > > > > A notification originator must be able to translate=20 > between SNMPv1 > > notification parameters and SNMPv2 notification=20 > parameters in order > > to send a notification using a particular SNMP message=20 > version. If a > > notification is generated using SNMPv1 notification=20 > parameters, and > > configuration information specifies that notifications=20 > be sent using > > SNMPv2c or SNMPv3, the notification parameters must be=20 > translated to > > SNMPv2 notification parameters. >=20 > here I see the first time that SNMPv2c and SNMPv3 are treated=20 > more equal > and then maps upon SNMPV2 notification parameters. Added text at end of section 1.3 to clarify this. > > 5. Message Processing Models and Security Models > > > > In order to adapt SNMPv1 (and SNMPv2c) into the SNMP=20 > architecture, > > the following models are defined in this document: > > > > - The SNMPv1 Message Processing Model > > > > - The SNMPv1 Community-Based Security Model > > > > The following models are also described in this document: >=20 > The above sentence seems redundant if the '(' and ')' earlier > are deleted. Why not listing them just four bullets?? This parentheses are there because we wanted to try to de-emphasize the stuff about SNMPv2c. This was discussed long ago (I can't remember = whether it was at an IETF meeting or an interim meeting). We've removed the sentence between the two bullets, though. =20 > > - The SNMPv2c Message Processing Model > > > > - The SNMPv2c Community-Based Security Model > > > > In most respects, the SNMPv1 Message Processing=20 > Model and the > > SNMPv2c Message Processing Model are identical,=20 > and so these > > are not discussed independently in this document.=20 > Differences > > between the two models are described as required. > > > > Similarly, the SNMPv1 Community-Based Security=20 > Model and the > > SNMPv2c Community-Based Security Model are nearly=20 > identical, > > and so are not discussed independently. =20 > Differences between > > these two models are also described as required. >=20 > The indent of the last 2 paragraphs make it look like it is only part > of SNMPv2C. Not needed in my opinion. The indentation was a typo, it has been fixed. > > 5.3. The SNMP Community MIB Module > > > > snmpCommunityMIBCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "The compliance statement for SNMP engines which > > implement the SNMP-COMMUNITY-MIB." > > > > MODULE -- this module > > MANDATORY-GROUPS { snmpCommunityTableGroup } > > > > OBJECT snmpCommunityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunitySecurityName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextEngineID > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityContextName > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityTransportTag > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStorageType > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > OBJECT snmpCommunityStatus > > MIN-ACCESS read-only > > DESCRIPTION "Write access is not required." > > > > ::=3D { snmpCommunityMIBCompliances 1 } >=20 > I remember a discussion of having full compliance and read-only > compliance in some other MIB modules, like DIFFSERV-MIB. (Bert maybe > as well, he can as AD provide IESG guidelines, I hope. It was laid > down on other working groups after all too and I do not see a reason > why telling other WG to do it, while we ourselves don't do it.) > That could be usefull, in order to have people implementing > it also as read-write in order to be fully compliant. > This would mean just adding a full-compliance statement where it > is all implemented and with read/write. Added new compliance statement. > > > > 9. References >=20 > Should these not be split into normative and informational > references. Done. =20 ------------------------ ------------------------ Changes based on "Re: coex draft last call" from Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] sent Thursday, January 09, 2003 8:08 AM > -----Original Message----- > From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] > Sent: Thursday, January 09, 2003 8:08 AM > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: Re: coex draft last call=20 >=20 >=20 > Sorry for the last-minute nature of this report, but I've now > had a chance to work through the latest coex draft, and identify > a number of points where I found the text unclear. >=20 > Most of what follows are effectively requests for clarification. > In most cases I can probably work out what I *think* is intended > from other comments in the document, but such detective-work > seems unhelpful, and a potential source of problems. I'd suggest > that it's worth saying the same thing in two places, rather than > risk an implementor going astray because they've omitted to make > a connection between two comments at opposite ends of the document! >=20 >=20 > I also noted a number of stylistic points - such as inconsistencies > in phrasing and/or layout (e.g. compare 4.1.2.3 with 4.1.2.4), or > areas where the description felt a little unclear, but I've tried to > concentrate on more substantive issues here. Particularly where > the required behaviour seemed uncertain (or unexpected). >=20 > I trust these comments are of some use. >=20 > Dave > ------------------------------------------------------- >=20 > p10: 2.1.1 bullet (10). > The final sentance is somewhat misleading. > Surely it's the combination of the effects of bullets (10) *and* (11) > that provides the SMIv1->SMIv2 transparency for SNMPv1 agents? Added text to clarify this. >=20 > p17: 3.2 bullet (2) second section. > Why is the original source of the notification to be extracted > *only* from the variable bindings? If the proxy is receiving > the notification from the notification originator via SNMPv2c > or SNMPv3, then this notification would not naturally include > an snmpTrapAddress varbind, but the proxy would (potentially) > know the originating IP address from the incoming PDU transport > information. Could it not use this information when forwarding > the SNMPv1 notification? >=20 > Though there is a potential problem in the case of a "proxy > chain" - where the proxy forwards it to a second proxy, also using > SNMPv2c or SNMPv3. This second proxy would need to recognise that > the transport address that it saw was *not* that of the original > notification originator. >=20 The purpose of including the snmpTrapAddress.0 varbind is to preserve the original value of the agent-addr field from a trap that was originally generated using SNMPv1, and was subsequently forwarded using SNMPv2c or SNMPv3. At each hop along the path through = potentially many proxies, the trap will be forwarded using either: - SNMPv1, in which case, the original value is carried in the agent-addr field of the trap, or - SNMPv2c or SNMPv3, in which case the value is carried in the snmpTrapAddress.0 varbind. Incidentally, if you read the DESCRIPTION of snmpTrapAddress, this is stated explicitly. Assuming that all proxies in the path follow these rules, whenever a trap is originally generated using SNMPv1, the agent-addr will be carried properly through the entire path. The only cases where the agent-addr at some hop might be 0.0.0.0 are: - If the trap was originally generated using SNMPv1, but was originally sent on a transport other than IPv4, in which case the value *should* be 0.0.0.0 - If the trap was originally generated using SNMPv2c or SNMPv3, and was translated to SNMPv1 by a proxy somewhere along the path. In this case, the value should also be 0.0.0.0, as we don't carry the source IP address of traps in SNMPv2 traps or informs. Trying to pick up an IP address from a hop somewhere along the way = would mean that when you receive a trap, you never know whether the = agent-addr value is that of the original agent, or of some hop in-between. So, I think the text is correct as is, no change. >=20 > p18: 3.2 bullet (6) > This description says to strip out snmpTrapAddress.0, but says > nothing about the other two varbind that may potentially have > been added - snmpTrapCommunity.0 and snmpTrapEnterprise.0. >=20 > In particular, the snmpTrapEnterprise.0 varbind has already > been used to set the SNMPv1 enterprise notification parameter > (see 3.2 bullet(1) ). Retaining it here would seem unnecessary, > so it would be sensible to remove this as well. >=20 > How to handle snmpTrapCommunity.0 seems less obvious - in > particular, should the outgoing SNMPv1 notification use this > community name, or that determined from the proxy's own configuration > (e.g. the SNMP-COMMUNITY-MIB)? >=20 > Should the snmpTrapCommunity.0 varbind be retained or not? Does > it make a difference whether this value is the same as the SNMPv1 > community notification parameter on the outgoing notification? >=20 The community name in an SNMPv1 trap being forwarded by a proxy will be determined by the proxy's configuration, as you mentioned, and so the snmpTrapCommunity.0 varbind needs to be left in the varbind list. Preserving this value may be important to some people, which is why snmpTrapCommunity.0 was defined in the first place. So, that varbind should not be removed. In any case, as discussed in subsequent e-mails, it makes sense to just leave all 3 varbinds (snmpTrapAddress, snmpTrapCommunity, snmpTrapEnterprise), so, changed the text to preserve all 3. Also changed the text about removing sysUpTime.0 and snmpTrapOID.0 from the SNMPv2 variable bindings to just note that they are not included (to make the use of the term more consistent). >=20 > p20: 4.1.2 last paragraph > This talks in general terms about "some combination of SNMPv1 and > SNMPv2 access to MIB data". But in practise, everything that > follows is talking specifically about SNMPv2 access to MIB data, > in response to an SNMPv1 request. There is nothing about the > other possible combinations. >=20 > Presumably, "homogeneous" access is not regarded as a problem > (i.e. SNMPv1 access to MIB data in response to an SNMPv1 request, > or SNMPv2 access to MIB data in response to an SNMPv2c or SNMPv3 > request)? In such a situation, the multi-lingual nature of the > agent is effectively irrelevant - yes? Right. >=20 > What about SNMPv1 access to MIB data in response to an SNMPv2c > or SNMPv3 request? If such an approach should not be used (and > I can see no good reason to do so), then perhaps this should > be stated explicitly. >=20 It should not be used, added text stating this. > I believe it would be easier to follow if the introduction to > section 4.1.2 stated up front, that the rest of the section > referred purely to SNMPv2 access to MIB data in response to > an SNMPv1 request. Changed the text at the end of the section to state this. >=20 >=20 > p24: 4.1.2.4 second list, bullet (1)=20 > Presumably an endOfMibView exception counts as an "error" in this > situation (or at least triggers the bullet (2) processing)? > This is not entirely clear, but would seem the obvious behaviour. Added text 'or an endOfMibView exception' >=20 > p27: 4.2.1 bullet (3) > The processing of a 'tooBig' response to a GetBulkRequest feels > surprising. In particular, it's inconsistent with the processing > of a 'toobig' response to the equivalent GetNextRequest. Why should > we try so hard to provide a ("sub-minimal") answer to a GetBulk? > If this behaviour is intentional, it would merit a word of=20 > explanation. This behaviour is intentional, it was deemed to expensive to try to re-send the request multiple times, with a single varbind stripped out = each time. This behaviour is intended to preserve the behaviour of a = GetBulkRequest as closely as possible. For a GetBulkRequest, you only need to return as many varbinds as will fit in the outgoing = packet, and you only return a tooBig error if you cannot fit even a single = varbind. So re-sending with just a single varbind ensures that you'll return at = least that one varbind if possible, without re-sending multiple times. This is different from how a GetNextRequest works, where you must = return all requested varbinds if they will fit in the available packet size, otherwise you must return a tooBig error. So, just added text to state that the described behaviour preserves the behaviour of GetBulk as closely as possible. >=20 >=20 > p28: 4.2.2 bullet (3) > The processing of Counter64 results in a proxy environment is > inconsistent with the of processing Counter64 results in a > multi-lingual environment (section 4.1.2.4, second bullet (1) ) > In particular, a proxy should retry the whole request, not just > the Counter64 varbinds. > Is this difference intentional? If so, then it may be worth > pointing it out explicitly. I think you're comparing apples and oranges here, section 4.1.2.4 is about MIB access internally within a command responder application, whereas section 4.2.2 is talking about forwarding requests and = responses through a proxy. I think we would make things more confusing by adding text about this. No change. >=20 > p28: 4.2.2 Deployment Hint > I'm not convinced that the not-in-view suggestion here is sensible, > unless the proxy uses different principals for forwarding SNMPv1 > requests and SNMPv2/v3c requests. If a proxy uses a single = principal > for communicating with a particular agent, then any Counter64 type > objects *should* be in-view for incoming SNMPv2c or SNMPv3 requests. > Adding the suggested access restriction would affect such requests, > as well as forwarded SNMPv1 requests. > If this suggestion is retained, then it should make mention of > this problem. >=20 Added text to clarify this. >=20 > p33: 5.2.1 CBSM returned parameters > Where is the value for 'securityName' obtained from? Is it the > value of 'snmpCommunitySecurityName' in the selected row of the > snmpCommunityTable? If so, then it's worth stating this. >=20 > Similarly, where is the value for 'maxSizeResponseScopedPDU' found? > snmpTargetAddrMMS ? Added text to clarify these. >=20 > It would also be worth mentioning any requirements on the > securityStateReference at this point, rather than waiting until > section 5.2.2. Added text to the securityStateReference bullet that it must include the community string. Also, in section 5.2.2, change 'stateReference' to 'securityStateReference,' it is really the securityStateReference that must contain the community string. >=20 >=20 > p35: 5.2.4 > If the proxy is forwarding from one example of a community-based > Message Processing Model to another (e.g. v1->v2c or vice versa) > where do the securityName, contextEngineID and contextName values > come from? Are these the values returned by the processing > described in section 5.2.1? If so, is it worth stating this > in 5.2.4? These parameters are the values passed into the sendPdu ASI, this is already mentioned here. How they are passed in to the sendPdu ASI is beyond the scope of this document, it is described in RFC3413. I don't think we need to add any new text here. Incidentally, while the contextName and contextEngineID are the values obtained in section 5.2.1, the securityName will be the value obtained by the proxy application from the SNMP-PROXY-MIB and SNMP-TARGET-MIB. This is also already stated in section 5.2.4. >=20 > p36: 5.3 third/fourth paragraphs > The third paragraph states that the snmpTargetAddrTMask is only > to be used where explicitly stated - presumably when matching on > incoming transport addresses, rather than identifying individual > destination addresses. > In a situation where the snmpTargetAddrTMask is *not* to be used, > how should transport address matching be done? In particular, if > the snmpTargetAddrTMask is a non-zero length string (i.e. this is > a "wildcard" row), should a check be done on the (exact) value of > snmpTargetAddrTAddress anyway, or should the whole row be skipped? As the text says, the value is only used where explicitly stated. If it is not explicitly state elsewhere in this document, or in another document, that the value is used to match multiple addresses, then it is not used, and matching must be exact. I added text stating that the value must be ignored when it's use is not explicitly stated. >=20 > One final issue: > Is it worth saying something about AgentX in all this? The AgentX > protocol operations are essentially SNMPv2 in a different guise, > so an AgentX master agent could be viewed as a sort of proxy. > Is it worthing saying something along these lines? > Or is it really too late to consider this properly? This has already been addressed on the mailing list, no change. ------_=_NextPart_000_01C2DF78.DF1E1D3C-- From owner-snmpv3@lists.tislabs.com Fri Feb 28 21:17:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20309 for ; Fri, 28 Feb 2003 21:17:50 -0500 (EST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14939 Fri, 28 Feb 2003 19:29:21 -0500 (EST) Message-ID: <0A11633F61BD9F40B43ABCC694004F93C8CE64@zsc3c026.us.nortel.com> From: "David Levi" To: WG IETF snmpv3 Subject: Re: coex draft Date: Fri, 28 Feb 2003 14:31:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DF79.1A9523F6" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DF79.1A9523F6 Content-Type: text/plain; charset="iso-8859-1" BTW, the change bars in the file I just sent out reflect changes made since the -02 version of the draft. -Dave ------------------------------------------------------------------------ David B. Levi Nortel Networks dlevi@nortelnetworks.com Voice: +1 865 686 0432 ESN: 455-6004 ------------------------------------------------------------------------ ------_=_NextPart_001_01C2DF79.1A9523F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: coex draft BTW, the change bars in the file I just sent out = reflect changes made since the -02 version of the draft. -Dave ---------------------------------------------------------------= --------- David B. = Levi &n= bsp; Nortel Networks dlevi@nortelnetworks.com Voice: +1 865 686 0432 ESN: = 455-6004 ---------------------------------------------------------------= --------- ------_=_NextPart_001_01C2DF79.1A9523F6--