From owner-snmpv3@lists.tislabs.com Mon May 5 10:29: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 KAA04176 for ; Mon, 5 May 2003 10:29:56 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05526 Mon, 5 May 2003 09:35:40 -0400 (EDT) Message-ID: <3EB3088D.5E5D9617@alcatel.com> Date: Fri, 02 May 2003 17:08:45 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: snmpEngineBoots Content-Type: multipart/alternative; boundary="------------FEFC1A1A3F3B7F8638CE3AA4" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --------------FEFC1A1A3F3B7F8638CE3AA4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) says 0. rfc3411 says 1. It is not impossible to stick to what two rfc's say but it is still confusing. Would it be a problem to simply start from 1 instead of 0? To be really consistent with both rfc's, the implemention could be as follows: * Set snmpEngineBoots to 0 when the SNMP agent is first installed. * Do not provide a MIB instance to snmpEngineBoots when it is 0. This implementation could cover the descriptions in the two rfc's: rfc3414, Section 2.2 When an SNMP engine is first installed, it sets its local values of snmpEngineBoots and snmpEngineTime to zero. rfc3414, Section 2.4 UsmSecurityParameters ::= ... msgAuthoritativeEngineBoots INTEGER (0..2147483647), msgAuthoritativeEngineTime INTEGER (0..2147483647), ... rfc3411 Section 5 snmpEngineBoots OBJECT-TYPE SYNTAX INTEGER (1..2147483647) Comments would be appreciated. Thanks, Ann --------------FEFC1A1A3F3B7F8638CE3AA4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) says 0. rfc3411 says 1. It is not impossible to stick to what two rfc's say but it is still confusing. Would it be a problem to simply start from 1 instead of 0?

To be really consistent with both rfc's, the implemention could be as follows:

This implementation could cover the descriptions in the two rfc's:

rfc3414, Section 2.2
When an SNMP engine is first installed, it sets its local values of snmpEngineBoots and snmpEngineTime to zero.

rfc3414, Section 2.4
UsmSecurityParameters ::=
       ...
       msgAuthoritativeEngineBoots INTEGER (0..2147483647),
       msgAuthoritativeEngineTime INTEGER (0..2147483647),
       ...

rfc3411 Section 5
snmpEngineBoots  OBJECT-TYPE
       SYNTAX       INTEGER (1..2147483647)

Comments would be appreciated.

Thanks,
Ann --------------FEFC1A1A3F3B7F8638CE3AA4-- From owner-snmpv3@lists.tislabs.com Mon May 5 10:36:06 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 KAA04356 for ; Mon, 5 May 2003 10:35:51 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05623 Mon, 5 May 2003 09:54:46 -0400 (EDT) Message-Id: <5.1.0.14.2.20030505092131.01291c28@babbage.csee.usf.edu> X-Sender: christen@babbage.csee.usf.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 May 2003 09:25:39 -0400 To: all@inf.ethz.ch From: Ken Christensen Subject: CFP for HSLN workshop (May 23rd submission deadline) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk CALL FOR PAPERS Workshop on High-Speed Local Networks (HSLN) as part of the IEEE LCN conference http://www.hcs.ufl.edu/hsln http://www.ieeelcn.org October 21, 2003 Bonn/Konigswinter, Germany Important dates and contact: ---------------------------- Paper submission: May 23, 2003 Notification of acceptance: June 27, 2003 Camera-ready copy due: July 25, 2003 Workshop Chairs: Bernd Heinrichs (bheinric@cisco.com) Alan D. George (george@hcs.ufl.edu) General Information: -------------------- The High-Speed Local Networks (HSLN) workshop, within the 28th IEEE Conference on Local Computer Networks (LCN), focuses on the design, analysis, implementation, and exploitation of new concepts, technologies, and applications related to high-performance networks on a local scale. This workshop will bring together networking researchers, engineers, and practitioners from across the spectrum of high-speed local networks, with participants from industry, academia, and government. Original papers that present research results, case studies, technology development or deployment experience, work in progress, etc. are solicited, as are survey articles. Specific areas of interest include (but are not limited to): - High-speed LANs (e.g. Gigabit Ethernet, 10 Gigabit Ethernet) - System-area networks (e.g. SCI, Myrinet, ServerNet) - Storage-area networks (e.g. Fibre Channel) and I/O interconnects - High-speed networks in embedded systems (e.g. avionics, space systems) - Protocols, services, and topologies for high-speed local networks - Routing and switch architectures for high-speed local networks - Quality of Service (QoS) in high-speed local networks - Performance analysis of high-speed local networks and systems - Modeling and simulation of high-speed local networks - Middleware for high-speed local network communication - Applications for high-speed local networks (e.g. video on demand) Paper Submission Instructions: ------------------------------ Authors are invited to submit papers of up to ten camera-ready pages, in PDF or Postscript format, for presentation at the workshop and publication in the conference proceedings. Papers should be submitted by email to the workshop at hsln@hcs.ufl.edu on or before May 23, 2003. Workshop Committee: ------------------- Workshop Chair: Bernd Heinrichs Cisco Systems bheinric@cisco.com Workshop Co-Chair: A.D. George ECE Department University of Florida george@hcs.ufl.edu Program Chair: K.J. Christensen CSE Department University of South Florida christen@csee.usf.edu Program Committee: ------------------ Jay Bragg (awbragg@yahoo.com) MCNC, USA Torsten Braun (braun@iam.unibe.ch) University of Bern, Switzerland Ron Brightwell (bright@cs.sandia.gov) Sandia National Labs, USA Helen Chen (hycsw@california.sandia.gov) Sandia National Labs, USA Giuseppe Ciaccio (ciaccio@disi.unige.it) Universit di Genova, Italy Cynthia S. Hood (hood@iit.edu) Illinois Institute of Technology, USA Anestis Karasaridis (karasaridis@att.com) AT&T Labs, USA Jack Meier (jlmeier@rockwellcollins.com) Rockwell Collins, USA Sarp Oral (oral@hcs.ufl.edu) University of Florida, USA D. K. Panda (panda@cis.ohio-state.edu) Ohio State University, USA Bettina Schnor (schnor@cs.uni-potsdam.de) Universitt Potsdam, Germany Norm Strole (ncstrole@us.ibm.com) IBM/RTP, USA Rollins Turner (rturner@paradyne.com) Paradyne Corporation, USA William White (wwhite@siue.edu) Southern Illinois University, USA Gil Utard (utard@laria.u-picardie.fr) INRIA, LIP cole Normale Suprieure de Lyon, France Larry Xue (xue@asu.edu) Arizona State University, USA --- From owner-snmpv3@lists.tislabs.com Mon May 5 11:09: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 LAA05057 for ; Mon, 5 May 2003 11:09:20 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05825 Mon, 5 May 2003 10:27:51 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 5 May 2003 07:32:48 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Ann Lo cc: snmpv3@lists.tislabs.com Subject: Re: snmpEngineBoots In-Reply-To: <3EB3088D.5E5D9617@alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Fri, 2 May 2003, Ann Lo wrote: > Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) > says 0. That's the correct initial value. > rfc3411 says 1. More precisely, it says that's the minimum value that can be returned in respose to a Get-Request-PDU. > To be really consistent with both rfc's, the implemention could be as > follows: > > * Set snmpEngineBoots to 0 when the SNMP agent is first installed. > * Do not provide a MIB instance to snmpEngineBoots when it is 0. Note that the engine _cannot_ return any value until after it is booted at least one, so the second step is automatic. I seem to recall that this discussion has taken place on this list before. //cmh From owner-snmpv3@lists.tislabs.com Mon May 5 12:06: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 MAA06479 for ; Mon, 5 May 2003 12:06:56 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06035 Mon, 5 May 2003 11:21:30 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: draft-ietf-snmpv3-coex-v2-03 Date: Mon, 5 May 2003 11:27:02 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88C979@NHROCMBX1.ets.enterasys.com> Thread-Topic: draft-ietf-snmpv3-coex-v2-03 Thread-Index: AcMTGoHIeNGl7+aARNKF016cpAz77AAACyww From: "Harrington, David" To: X-OriginalArrivalTime: 05 May 2003 15:27:02.0538 (UTC) FILETIME=[C701FEA0:01C3131A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA06032 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, The SNMPv3 working group has completed WG last call on draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for publication as a Best Current Practice RFC. This is an update to RFC 2576. Thank you, David Harrington Russ Mundy chairs, SNMPv3 WG --- David Harrington Network Management Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpv3@lists.tislabs.com Mon May 5 12:33:19 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 MAA07210 for ; Mon, 5 May 2003 12:33:19 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06120 Mon, 5 May 2003 11:45:17 -0400 (EDT) Message-ID: <007101c3131e$13044760$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6D745637A7E0F94DA070743C55CDA9BA88C979@NHROCMBX1.ets.enterasys.com> Subject: Re: draft-ietf-snmpv3-coex-v2-03 Date: Mon, 5 May 2003 08:50:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - is this the -03- in the internet drafts directory, or the one that Dave Levi posted to the WG mailing list on April 15? Randy ----- Original Message ----- From: "Harrington, David" To: Sent: Monday, May 05, 2003 8:27 AM Subject: draft-ietf-snmpv3-coex-v2-03 > Hi, > > The SNMPv3 working group has completed WG last call on > draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for > publication as a Best Current Practice RFC. This is an update to RFC > 2576. > > Thank you, > David Harrington > Russ Mundy > chairs, SNMPv3 WG > --- > David Harrington Network Management Architect > dbh@enterasys.com Office of the CTO > +1 603 337 2614 - voice Enterasys Networks > +1 603 332 1524 - fax Rochester NH, USA From owner-snmpv3@lists.tislabs.com Mon May 5 13:54:47 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 NAA09522 for ; Mon, 5 May 2003 13:54:32 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06413 Mon, 5 May 2003 13:00:00 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: draft-ietf-snmpv3-coex-v2-03 Date: Mon, 5 May 2003 13:05:43 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88C98D@NHROCMBX1.ets.enterasys.com> Thread-Topic: draft-ietf-snmpv3-coex-v2-03 Thread-Index: AcMTJyL6nxX3lZj0T8WsfND8P/cxBQAAUaqQ From: "Harrington, David" To: "C. M. Heard" , "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 05 May 2003 17:05:43.0460 (UTC) FILETIME=[9026FE40:01C31328] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA06410 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, You are absolutely correct. I goofed. I have asked david to submit the updated version to be published as -04-. Then we will submit for BCP. dbh > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Monday, May 05, 2003 12:54 PM > To: Snmpv3@Lists.Tislabs.Com (E-mail) > Subject: Re: draft-ietf-snmpv3-coex-v2-03 > > > On Mon, 5 May 2003, Harrington, David wrote: > > The SNMPv3 working group has completed WG last call on > > draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for > > publication as a Best Current Practice RFC. This is an update to RFC > > 2576. > > I object. The -03 draft that is in the repository, i.e., > http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt does not have the changes requested by Bert Wijnen and myself that were included in a preliminary version posted to the list (but not to the I-D repository) by David Levi on 15 April 2003. That version looked good to me except for one minor typo which I reported in the attached message. I think we need to have an -04 version submitted that incoporates David Levi's updates of 15 April 2003 plus the correction requested in the attached message before submitting the document to the IESG. Thanks, Mike Heard From owner-snmpv3@lists.tislabs.com Mon May 5 14:37: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 OAA10766 for ; Mon, 5 May 2003 14:37:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06571 Mon, 5 May 2003 13:47:22 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C18B3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Harrington, David" , snmpv3@lists.tislabs.com Subject: RE: draft-ietf-snmpv3-coex-v2-03 Date: Mon, 5 May 2003 19:52:00 +0200 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 > > Hi, > > The SNMPv3 working group has completed WG last call on > draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for > publication as a Best Current Practice RFC. This is an update to RFC > 2576. > I think you mean to say that it will obsolete RFC2576, no? Bert From owner-snmpv3@lists.tislabs.com Mon May 5 15:23:14 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 PAA13273 for ; Mon, 5 May 2003 15:22:58 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06754 Mon, 5 May 2003 14:31:23 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 5 May 2003 09:54:22 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: Re: draft-ietf-snmpv3-coex-v2-03 In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA88C979@NHROCMBX1.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1906178487-1052152813=:17169" Content-ID: Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2133786286-1906178487-1052152813=:17169 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Mon, 5 May 2003, Harrington, David wrote: > The SNMPv3 working group has completed WG last call on > draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for > publication as a Best Current Practice RFC. This is an update to RFC > 2576. I object. The -03 draft that is in the repository, i.e., http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-03.txt does not have the changes requested by Bert Wijnen and myself that were included in a preliminary version posted to the list (but not to the I-D repository) by David Levi on 15 April 2003. That version looked good to me except for one minor typo which I reported in the attached message. I think we need to have an -04 version submitted that incoporates David Levi's updates of 15 April 2003 plus the correction requested in the attached message before submitting the document to the IESG. Thanks, Mike Heard ---2133786286-1906178487-1052152813=:17169 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Re: coex doc update (fwd) Return-Path: Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h3GIUI732206 for ; Wed, 16 Apr 2003 11:30:18 -0700 Received: from orb.pobox.com (orb.pobox.com [208.210.125.79]) by postman.bayarea.net (8.12.8p1/8.12.8) with ESMTP id h3GIUIVw013566 for ; Wed, 16 Apr 2003 11:30:18 -0700 (PDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by orb.pobox.com (Postfix) with ESMTP id 6633F155FEC for ; Wed, 16 Apr 2003 14:30:17 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01702 Wed, 16 Apr 2003 13:36:36 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 16 Apr 2003 10:40:15 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Snmpv3@Lists.Tislabs.Com (E-mail)" Subject: Re: coex doc update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Tue, 15 Apr 2003, C. M. Heard wrote: > On Tue, 15 Apr 2003, David Levi wrote: > > Attached is an updated coex document, this incorporates the latest > > comments from Mike and Bert. Note that I didn't bump up the version > > number and related comments, I just updated the text (since we are > > not publishing a new ID at the moment). > > I just went over the changes (relative to the latest I-D) and it > looks good to me. Oops, I missed one thing -- On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > I see (In the MIB REVISION clause) > Changed the name of 'snmpCommunityGroup' to a name > conflict with the SNMPv2-MIB. > Should that be: > Changed the name of 'snmpCommunityGroup' to > snmpCommunityTableGroup to avoid a name conflict > with the SNMPv2-MIB. This error still needs to be fixed before a new I-D is submitted (it was fixed in the revision log in appendix B). Sorry about that. //cmh ---2133786286-1906178487-1052152813=:17169-- From owner-snmpv3@lists.tislabs.com Mon May 5 16:36: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 QAA15517 for ; Mon, 5 May 2003 16:36:25 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07069 Mon, 5 May 2003 15:48:32 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: draft-ietf-snmpv3-coex-v2-03 Date: Mon, 5 May 2003 15:54:12 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88C9B4@NHROCMBX1.ets.enterasys.com> Thread-Topic: draft-ietf-snmpv3-coex-v2-03 Thread-Index: AcMTLzVjiUMztaWtTEOsoqHtaX17QgAEN4mA From: "Harrington, David" To: "Wijnen, Bert (Bert)" , X-OriginalArrivalTime: 05 May 2003 19:54:12.0976 (UTC) FILETIME=[19E4B700:01C31340] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA07066 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Correct. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, May 05, 2003 1:52 PM > To: Harrington, David; snmpv3@lists.tislabs.com > Subject: RE: draft-ietf-snmpv3-coex-v2-03 > > > > > > Hi, > > > > The SNMPv3 working group has completed WG last call on > > draft-ietf-snmpv3-coex-v2-03, and would like to submit the draft for > > publication as a Best Current Practice RFC. This is an update to RFC > > 2576. > > > I think you mean to say that it will obsolete RFC2576, no? > > Bert > From owner-snmpv3@lists.tislabs.com Mon May 5 17:02:52 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 RAA16236 for ; Mon, 5 May 2003 17:02:51 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07238 Mon, 5 May 2003 16:20:21 -0400 (EDT) Message-ID: <3EB6C877.9F0B7D61@alcatel.com> Date: Mon, 05 May 2003 13:24:23 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "C. M. Heard" CC: snmpv3@lists.tislabs.com Subject: Re: snmpEngineBoots References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Thanks for your information. I guess that this definition has originated from the Unix system where the SNMP protocol can be operational when the SNMP agent is down? In many embedded systems, snmpEngineBoots would then start from 1 as these systems would not respond to any SNMP requests until the SNMP agent is up and running. Regards, Ann "C. M. Heard" wrote: > On Fri, 2 May 2003, Ann Lo wrote: > > Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) > > says 0. > > That's the correct initial value. > > > rfc3411 says 1. > > More precisely, it says that's the minimum value that can be > returned in respose to a Get-Request-PDU. > > > To be really consistent with both rfc's, the implemention could be as > > follows: > > > > * Set snmpEngineBoots to 0 when the SNMP agent is first installed. > > * Do not provide a MIB instance to snmpEngineBoots when it is 0. > > Note that the engine _cannot_ return any value until after it is > booted at least one, so the second step is automatic. > > I seem to recall that this discussion has taken place on this list > before. > > //cmh From owner-snmpv3@lists.tislabs.com Mon May 5 18:13:05 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 SAA18311 for ; Mon, 5 May 2003 18:13:05 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07355 Mon, 5 May 2003 17:03:48 -0400 (EDT) Message-ID: <006401c3134a$80ef9b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3EB6C877.9F0B7D61@alcatel.com> Subject: Re: snmpEngineBoots Date: Mon, 5 May 2003 14:08:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Ann Lo" > To: "C. M. Heard" > Cc: > Sent: Monday, May 05, 2003 1:24 PM > Subject: Re: snmpEngineBoots ... > Thanks for your information. I guess that this definition has originated > from the Unix system where the SNMP protocol can be operational when the > SNMP agent is down? No. > In many embedded systems, snmpEngineBoots would then start from 1 as these > systems would not respond to any SNMP requests until the SNMP agent is up > and running. No. The snmpEngineBoots variable needs to persist, regardless of the operating system. Whenever an SNMP engine starts up, the value needs to be incremented. Consequently, if you ever want to see it on the wire with a value of 1, theinitial value (prior to the first time the SNMP engine is ever started) must be zero. (This is just what Mike explained.) Randy > Regards, > Ann > > > "C. M. Heard" wrote: > > > On Fri, 2 May 2003, Ann Lo wrote: > > > Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) > > > says 0. > > > > That's the correct initial value. > > > > > rfc3411 says 1. > > > > More precisely, it says that's the minimum value that can be > > returned in respose to a Get-Request-PDU. > > > > > To be really consistent with both rfc's, the implemention could be as > > > follows: > > > > > > * Set snmpEngineBoots to 0 when the SNMP agent is first installed. > > > * Do not provide a MIB instance to snmpEngineBoots when it is 0. > > > > Note that the engine _cannot_ return any value until after it is > > booted at least one, so the second step is automatic. > > > > I seem to recall that this discussion has taken place on this list > > before. > > > > //cmh > From owner-snmpv3@lists.tislabs.com Mon May 5 19:50: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 TAA21764 for ; Mon, 5 May 2003 19:50:07 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07847 Mon, 5 May 2003 19:08:17 -0400 (EDT) Message-ID: <3EB6F015.E7276015@alcatel.com> Date: Mon, 05 May 2003 16:13:25 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn CC: snmpv3@lists.tislabs.com Subject: Re: snmpEngineBoots References: <3EB6C877.9F0B7D61@alcatel.com> <006401c3134a$80ef9b40$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Randy, Interpretation of snmpEngineBoots in this way appears fine. But then, shouldn't msgAuthoriativeEngineBoots start from 1 instead of 0? Presently rfc3414 (USM) says UsmSecurityParameters ::= ... msgAuthoritativeEngineBoots INTEGER (0..2147483647), msgAuthoritativeEngineTime INTEGER (0..2147483647), ... Thanks, Ann Randy Presuhn wrote: > Hi - > > > From: "Ann Lo" > > To: "C. M. Heard" > > Cc: > > Sent: Monday, May 05, 2003 1:24 PM > > Subject: Re: snmpEngineBoots > ... > > Thanks for your information. I guess that this definition has originated > > from the Unix system where the SNMP protocol can be operational when the > > SNMP agent is down? > > No. > > > In many embedded systems, snmpEngineBoots would then start from 1 as these > > systems would not respond to any SNMP requests until the SNMP agent is up > > and running. > > No. The snmpEngineBoots variable needs to persist, regardless of the > operating system. Whenever an SNMP engine starts up, the value needs to be > incremented. Consequently, if you ever want to see it on the wire with a > value of 1, theinitial value (prior to the first time the SNMP engine is ever > started) must be zero. (This is just what Mike explained.) > > Randy > > > Regards, > > Ann > > > > > > "C. M. Heard" wrote: > > > > > On Fri, 2 May 2003, Ann Lo wrote: > > > > Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) > > > > says 0. > > > > > > That's the correct initial value. > > > > > > > rfc3411 says 1. > > > > > > More precisely, it says that's the minimum value that can be > > > returned in respose to a Get-Request-PDU. > > > > > > > To be really consistent with both rfc's, the implemention could be as > > > > follows: > > > > > > > > * Set snmpEngineBoots to 0 when the SNMP agent is first installed. > > > > * Do not provide a MIB instance to snmpEngineBoots when it is 0. > > > > > > Note that the engine _cannot_ return any value until after it is > > > booted at least one, so the second step is automatic. > > > > > > I seem to recall that this discussion has taken place on this list > > > before. > > > > > > //cmh > > From owner-snmpv3@lists.tislabs.com Mon May 5 20:29: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 UAA22482 for ; Mon, 5 May 2003 20:29:16 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07993 Mon, 5 May 2003 19:50:31 -0400 (EDT) Message-ID: <001501c31361$d9e7abe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ann Lo" Cc: References: <3EB6C877.9F0B7D61@alcatel.com> <006401c3134a$80ef9b40$7f1afea9@oemcomputer> <3EB6F015.E7276015@alcatel.com> Subject: Re: snmpEngineBoots Date: Mon, 5 May 2003 16:55:48 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - > From: "Ann Lo" > To: "Randy Presuhn" > Cc: > Sent: Monday, May 05, 2003 4:13 PM > Subject: Re: snmpEngineBoots ... > Interpretation of snmpEngineBoots in this way appears fine. But then, shouldn't > msgAuthoriativeEngineBoots start from 1 instead of 0? > > Presently rfc3414 (USM) says > UsmSecurityParameters ::= > ... > msgAuthoritativeEngineBoots INTEGER (0..2147483647), > msgAuthoritativeEngineTime INTEGER (0..2147483647), ... Section 3.1 (6) (c) describes the special case when zero appears in this protocol field. Randy From owner-snmpv3@lists.tislabs.com Mon May 5 21:05: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 VAA23219 for ; Mon, 5 May 2003 21:04:57 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08139 Mon, 5 May 2003 20:22:55 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 5 May 2003 17:28:02 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Ann Lo cc: snmpv3@lists.tislabs.com Subject: Re: snmpEngineBoots In-Reply-To: <3EB6C877.9F0B7D61@alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Mon, 5 May 2003, Ann Lo wrote: > Thanks for your information. I guess that this definition has originated > from the Unix system where the SNMP protocol can be operational when the > SNMP agent is down? No ... > In many embedded systems, snmpEngineBoots would then start from 1 as these > systems would not respond to any SNMP requests until the SNMP agent is up > and running. That's the way it always works. snmpEngineBoots is set to 0 before the engine boots. It is incremented to 1 the first time the agent boots. Hence the minimum value reported by the managed object is 1. This is true irrespective of what platform upon which the agent runs. This seems to cause confusion, and I am sorry that I am explaining poorly, but there is no contradiction between RFC 3414, which instructs an implementor to initialise snmpEngineBoots to 0, and the MIB module in RFC 3411, which specifies that the minimum value ever read from snmpEngineBoots (via an SNMP GetRequest-PDU) will be 1. //cmh From owner-snmpv3@lists.tislabs.com Mon May 5 21:06:36 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 VAA23295 for ; Mon, 5 May 2003 21:06:36 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08156 Mon, 5 May 2003 20:25:04 -0400 (EDT) Message-Id: <5.2.0.9.2.20030505172017.03c005b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 05 May 2003 17:29:18 -0700 To: Ann Lo , Randy Presuhn From: "David T. Perkins" Subject: Re: snmpEngineBoots Cc: snmpv3@lists.tislabs.com In-Reply-To: <3EB6F015.E7276015@alcatel.com> References: <3EB6C877.9F0B7D61@alcatel.com> <006401c3134a$80ef9b40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk HI, If the message definition had said: msgAuthoritativeEngineBoots INTEGER (1..2147483647) instead of: msgAuthoritativeEngineBoots INTEGER (0..2147483647) then an ASN.1 parse error would occur when the value of zero is specified in the field. Note that the value of the field is ignored in messages with security level set to "noAuth/noPriv", and thus, zero makes a fine value. At 04:13 PM 5/5/2003 -0700, Ann Lo wrote: >Hi Randy, > >Interpretation of snmpEngineBoots in this way appears fine. But then, shouldn't >msgAuthoriativeEngineBoots start from 1 instead of 0? > >Presently rfc3414 (USM) says >UsmSecurityParameters ::= > ... > msgAuthoritativeEngineBoots INTEGER (0..2147483647), > msgAuthoritativeEngineTime INTEGER (0..2147483647), > ... > >Thanks, >Ann > > >Randy Presuhn wrote: > >> Hi - >> >> > From: "Ann Lo" >> > To: "C. M. Heard" >> > Cc: >> > Sent: Monday, May 05, 2003 1:24 PM >> > Subject: Re: snmpEngineBoots >> ... >> > Thanks for your information. I guess that this definition has originated >> > from the Unix system where the SNMP protocol can be operational when the >> > SNMP agent is down? >> >> No. >> >> > In many embedded systems, snmpEngineBoots would then start from 1 as these >> > systems would not respond to any SNMP requests until the SNMP agent is up >> > and running. >> >> No. The snmpEngineBoots variable needs to persist, regardless of the >> operating system. Whenever an SNMP engine starts up, the value needs to be >> incremented. Consequently, if you ever want to see it on the wire with a >> value of 1, theinitial value (prior to the first time the SNMP engine is ever >> started) must be zero. (This is just what Mike explained.) >> >> Randy >> >> > Regards, >> > Ann >> > >> > >> > "C. M. Heard" wrote: >> > >> > > On Fri, 2 May 2003, Ann Lo wrote: >> > > > Should snmpEngineBoots be initialized to 0 or 1? rfc3414 (USM) >> > > > says 0. >> > > >> > > That's the correct initial value. >> > > >> > > > rfc3411 says 1. >> > > >> > > More precisely, it says that's the minimum value that can be >> > > returned in respose to a Get-Request-PDU. >> > > >> > > > To be really consistent with both rfc's, the implemention could be as >> > > > follows: >> > > > >> > > > * Set snmpEngineBoots to 0 when the SNMP agent is first installed. >> > > > * Do not provide a MIB instance to snmpEngineBoots when it is 0. >> > > >> > > Note that the engine _cannot_ return any value until after it is >> > > booted at least one, so the second step is automatic. >> > > >> > > I seem to recall that this discussion has taken place on this list >> > > before. >> > > >> > > //cmh >> > From owner-snmpv3@lists.tislabs.com Tue May 6 14:00:39 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 OAA01483 for ; Tue, 6 May 2003 14:00:39 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11113 Tue, 6 May 2003 13:10:19 -0400 (EDT) Message-ID: <003801c313f3$0200e6a0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "C. M. Heard" Cc: Subject: Re: snmpEngineBoots Date: Tue, 6 May 2003 17:51:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit . > >I seem to recall that this discussion has taken place on this list >before. > >//cmh > and no doubt will again so as and when the document is updated, then adding this expanation would help. Tom Petch From owner-snmpv3@lists.tislabs.com Wed May 7 10:06: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 KAA01458 for ; Wed, 7 May 2003 10:06:37 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13695 Wed, 7 May 2003 09:02:57 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 7 May 2003 06:08:07 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "SNMPv3 (E-mail)" Subject: draft-ietf-snmpv3-coex-v2-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Colleagues, Although the announcement hasn't yet been sent, http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt is now available in the repository. It matches the version posted to this list on 15 April 2003. As previously noted, that version fixed all outstanding comments except the following one: On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > I see (In the MIB REVISION clause) > Changed the name of 'snmpCommunityGroup' to a name > conflict with the SNMPv2-MIB. > Should that be: > Changed the name of 'snmpCommunityGroup' to > snmpCommunityTableGroup to avoid a name conflict > with the SNMPv2-MIB. So this error still needs to be fixed before publication (note that a similar error was was fixed in the revision log in appendix B). //cmh From owner-snmpv3@lists.tislabs.com Wed May 7 11:21: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 LAA05535 for ; Wed, 7 May 2003 11:21:38 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13956 Wed, 7 May 2003 10:19:58 -0400 (EDT) Message-ID: <3EB863FD.3AF5C865@alcatel.com> Date: Tue, 06 May 2003 18:40:13 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: snmpEngineBoots Content-Type: multipart/alternative; boundary="------------9F11BB621E342E0C741B9D3F" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --------------9F11BB621E342E0C741B9D3F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks much for the informative replies from C.M. Heard, Randy Presuhn, and David Perkins. In case this might be useful, a summary of answers to my questions are: * msgAuthoritativeEngineBoots is 0 in a Request message when the authoritative engine id is empty. o rfc3414 (USM) Section 3.1 (6) (c) * snmpEngineBoots starts from the value 1 when the SNMP agent is up and running. Regards, Ann --------------9F11BB621E342E0C741B9D3F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks much for the informative replies from C.M. Heard, Randy Presuhn, and David Perkins.

In case this might be useful, a summary of answers to my questions are:

Regards,
Ann
  --------------9F11BB621E342E0C741B9D3F-- From owner-snmpv3@lists.tislabs.com Wed May 7 11:23:39 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 LAA05632 for ; Wed, 7 May 2003 11:23:39 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13957 Wed, 7 May 2003 10:19:58 -0400 (EDT) Message-Id: <200305071115.HAA23810@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-coex-v2-04.txt Date: Wed, 07 May 2003 07:15:19 -0400 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Author(s) : R. Frye, D. Levi, S. Routhier, B. Wijnen Filename : draft-ietf-snmpv3-coex-v2-04.txt Pages : 61 Date : 2003-5-6 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 also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-coex-v2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-6153440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-coex-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153440.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpv3@lists.tislabs.com Wed May 7 12:11:41 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 MAA06985 for ; Wed, 7 May 2003 12:11:40 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14155 Wed, 7 May 2003 11:19:12 -0400 (EDT) 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="us-ascii" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt Date: Wed, 7 May 2003 11:24:30 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA88CA2F@NHROCMBX1.ets.enterasys.com> Thread-Topic: draft-ietf-snmpv3-coex-v2-04.txt Thread-Index: AcMUoM94fNLjq4KYQ02vYQphlDp70gAC9yaw From: "Harrington, David" To: "C. M. Heard" , "SNMPv3 (E-mail)" X-OriginalArrivalTime: 07 May 2003 15:24:31.0245 (UTC) FILETIME=[C1A803D0:01C314AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA14152 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Noted that we need to fix in auth48 review. Thanks for catching that. dbh > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Wednesday, May 07, 2003 9:08 AM > To: SNMPv3 (E-mail) > Subject: draft-ietf-snmpv3-coex-v2-04.txt > > > Colleagues, > > Although the announcement hasn't yet been sent, > > http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt > > is now available in the repository. It matches the version posted to > this list on 15 April 2003. As previously noted, that version fixed > all outstanding comments except the following one: > > On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > > I see (In the MIB REVISION clause) > > Changed the name of 'snmpCommunityGroup' > to a name > > conflict with the SNMPv2-MIB. > > Should that be: > > Changed the name of 'snmpCommunityGroup' to > > snmpCommunityTableGroup to avoid a name conflict > > with the SNMPv2-MIB. > > So this error still needs to be fixed before publication (note that > a similar error was was fixed in the revision log in appendix B). > > //cmh > > From owner-snmpv3@lists.tislabs.com Wed May 7 13:55:32 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 NAA10153 for ; Wed, 7 May 2003 13:55:32 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14461 Wed, 7 May 2003 13:01:17 -0400 (EDT) Message-Id: <5.2.0.9.2.20030507090034.03bbe6b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 07 May 2003 09:05:38 -0700 To: Ann Lo , snmpv3@lists.tislabs.com From: "David T. Perkins" Subject: Re: snmpEngineBoots In-Reply-To: <3EB863FD.3AF5C865@alcatel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3072789==.ALT" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --=====================_3072789==.ALT Content-Type: text/plain; charset="us-ascii" HI, You didn't include the case I sent you. That is, when you are using noAuth/noPriv, the value in a request is not verified by the "agent", and a value of zero, is a nice choice. At 06:40 PM 5/6/2003 -0700, Ann Lo wrote: >Thanks much for the informative replies from C.M. Heard, Randy Presuhn, and David Perkins. > >In case this might be useful, a summary of answers to my questions are: > * msgAuthoritativeEngineBoots is 0 in a Request message when the authoritative engine id is empty. > * rfc3414 (USM) Section 3.1 (6) (c) > * snmpEngineBoots starts from the value 1 when the SNMP agent is up and running. >Regards, >Ann Regards, /david t. perkins --=====================_3072789==.ALT Content-Type: text/html; charset="us-ascii" HI,

You didn't include the case I sent you. That is, when you are
using noAuth/noPriv, the value in a request is not verified by
the "agent", and a value of zero, is a nice choice.

At 06:40 PM 5/6/2003 -0700, Ann Lo wrote:
Thanks much for the informative replies from C.M. Heard, Randy Presuhn, and David Perkins.

In case this might be useful, a summary of answers to my questions are:
  • msgAuthoritativeEngineBoots is 0 in a Request message when the authoritative engine id is empty.
    • rfc3414 (USM) Section 3.1 (6) (c)
  • snmpEngineBoots starts from the value 1 when the SNMP agent is up and running.
Regards,
Ann

Regards,
/david t. perkins --=====================_3072789==.ALT-- From owner-snmpv3@lists.tislabs.com Thu May 8 11:27: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 LAA26568 for ; Thu, 8 May 2003 11:27:09 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19118 Thu, 8 May 2003 10:32:05 -0400 (EDT) Message-ID: <3EB9B362.5A7A561E@alcatel.com> Date: Wed, 07 May 2003 18:31:14 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: snmpEngineBoots Content-Type: multipart/alternative; boundary="------------5BE1A5CEEC5C3E25178806F0" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --------------5BE1A5CEEC5C3E25178806F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A revised summary of answers to my questions on snmpEngineBoots are: * msgAuthoritativeEngineBoots is 0 in a Request message when the authoritative engine id is empty. o rfc3414 (USM) Section 3.1 (6) (c) * msgAuthoritativeEngineBoots can also be 0 in messages with security level set to noAuth/noPriv. o The value of this field is ignored for noAuth/noPriv. o rfc3414 (USM) Section 3.1. * snmpEngineBoots starts from the value 1 when the SNMP agent is up and running. Thanks, Ann --------------5BE1A5CEEC5C3E25178806F0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A revised summary of answers to my questions on snmpEngineBoots are:
  • msgAuthoritativeEngineBoots is 0 in a Request message when the authoritative engine id is empty.
    • rfc3414 (USM) Section 3.1 (6) (c)
  • msgAuthoritativeEngineBoots can also be 0 in messages with security level set to noAuth/noPriv.
    • The value of this field is ignored for noAuth/noPriv.
    • rfc3414 (USM) Section 3.1.
  • snmpEngineBoots starts from the value 1 when the SNMP agent is up and running.
Thanks,
Ann
  --------------5BE1A5CEEC5C3E25178806F0-- From owner-snmpv3@lists.tislabs.com Thu May 8 13:43: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 NAA01336 for ; Thu, 8 May 2003 13:43:16 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19480 Thu, 8 May 2003 12:59:30 -0400 (EDT) Message-ID: <2444.192.168.1.28.1052411356.squirrel@www.mibtonix.com> Date: Thu, 8 May 2003 09:29:16 -0700 (PDT) Subject: VACM reports/responses From: "Sean Lawless" To: X-Priority: 3 Importance: Normal Reply-To: sean@mibtonix.com X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Greetings, We are having difficulty locating a specification document for View based Access Control Model (VACM) error responses/reports. Specifically, from a Command Responder perspective, what should be sent in response to a request that results in the VACM function isAccessAllowed returning notInView, noSuchView, etc. From rfc3414 and rfc3415, the best guess we can ascertain is to return a standard endOfMibView for GetNext requests that encounter any VACM problem and noSuchName for Get and Set requests. Is this correct and does anyone know a document (rfc) that specifies this? Thank you much and good day. Sean Lawless Mibtonix, Inc. From owner-snmpv3@lists.tislabs.com Thu May 8 18:20: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 SAA14765 for ; Thu, 8 May 2003 18:20:15 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20180 Thu, 8 May 2003 17:32:53 -0400 (EDT) Message-Id: <200305082137.h48LbWu01204@snowball.snmp.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: sean@mibtonix.com cc: snmpv3@lists.tislabs.com Subject: Re: VACM reports/responses In-reply-to: Your message of Thu, 08 May 2003 09:29:16 -0700. <2444.192.168.1.28.1052411356.squirrel@www.mibtonix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 08 May 2003 17:37:32 -0400 From: Steve Moulton Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Sean, The general design philosophy is that objects that are out of a MIB (VACM) view are treated as if they don't exist. For get and set operations, if the entire object is out of view, a noSuchObject exception should be returned. If the object is partially in view, but the particular instance you want is not, a noSuchInstance exception should be returned. Ref: RFC3416, 4.2.1 for get, which has more precise language than this. In the case of getnext operations, the next instance that is in the VACM view should be returned. The instance may not be of the object requested, if the remainder of the instances for that object are out of view. If there are no further instances (of any object) in the MIB view, then an endOfMibView exception should be returned. Ref: RFC3416, 4.2.2 for getnext (for more precise language) Note that SNMPv3 command responders will not generate noSuchName errors in response to SNMPv3 requests. See RFC2576 for more on this. Best Regards, Steve On Thursday, May 8 2003, "Sean Lawless" wrote: > Greetings, > > We are having difficulty locating a specification document for View based > Access Control Model (VACM) error responses/reports. Specifically, from a > Command Responder perspective, what should be sent in response to a > request that results in the VACM function isAccessAllowed returning > notInView, noSuchView, etc. > > >From rfc3414 and rfc3415, the best guess we can ascertain is to return a > standard endOfMibView for GetNext requests that encounter any VACM problem > and noSuchName for Get and Set requests. > > Is this correct and does anyone know a document (rfc) that specifies this? > > Thank you much and good day. > > Sean Lawless > Mibtonix, Inc. > > --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com From owner-snmpv3@lists.tislabs.com Thu May 8 18:21: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 SAA14793 for ; Thu, 8 May 2003 18:21:15 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20192 Thu, 8 May 2003 17:41:41 -0400 (EDT) Message-ID: <001001c3159c$8df793c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , References: <2444.192.168.1.28.1052411356.squirrel@www.mibtonix.com> Subject: Re: VACM reports/responses Date: Thu, 8 May 2003 13:01:03 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - I think you'd find RFC 3413, especially section 3.2 (page 11 or so) helpful. The endOfMibView would be correct only if there is nothing else lexicographically later in the context to which access could be permitted. RFC 2741 might also be helpful in explaining the things that need to happen during get-next and get-bulk proccessing when access control enters the picture. Randy ----- Original Message ----- From: "Sean Lawless" To: Sent: Thursday, May 08, 2003 9:29 AM Subject: VACM reports/responses > Greetings, > > We are having difficulty locating a specification document for View based > Access Control Model (VACM) error responses/reports. Specifically, from a > Command Responder perspective, what should be sent in response to a > request that results in the VACM function isAccessAllowed returning > notInView, noSuchView, etc. > > From rfc3414 and rfc3415, the best guess we can ascertain is to return a > standard endOfMibView for GetNext requests that encounter any VACM problem > and noSuchName for Get and Set requests. > > Is this correct and does anyone know a document (rfc) that specifies this? > > Thank you much and good day. > > Sean Lawless > Mibtonix, Inc. > > From owner-snmpv3@lists.tislabs.com Thu May 8 20:05: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 UAA17231 for ; Thu, 8 May 2003 20:05:43 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20626 Thu, 8 May 2003 19:29:41 -0400 (EDT) Message-ID: <000c01c315ba$40ea40a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200305082137.h48LbWu01204@snowball.snmp.com> Subject: Re: VACM reports/responses Date: Thu, 8 May 2003 16:33:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Hi - (I dropped Sean from the CC list because his mail service has blacklisted my ISP, Earthlink/Mindspring) > From: "Steve Moulton" > To: > Cc: > Sent: Thursday, May 08, 2003 2:37 PM > Subject: Re: VACM reports/responses ... > Note that SNMPv3 command responders will not generate noSuchName > errors in response to SNMPv3 requests. See RFC2576 for more on this. ... But do keep RFC 3416 section 4.2.4 in mind. There are cases where command responders are doing things that are proxy in the classic sense, but not in the RFC 2576 sense, and will not necessarily be able to make the fine-grained distinctions. One case that's probably more wide-spread than anyone would like is access via underlying RFC 1227 machinery. These will generate noSuchName errors when the modern codes would be better. Randy From owner-snmpv3@lists.tislabs.com Fri May 9 09:58:39 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 JAA15999 for ; Fri, 9 May 2003 09:58:39 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22540 Fri, 9 May 2003 09:07:19 -0400 (EDT) Message-ID: <3EBAFF28.4D02FFAF@alcatel.com> Date: Thu, 08 May 2003 18:06:48 -0700 From: Ann Lo Organization: Alcatel CID X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: Question on draft-ietf-snmpv3-coex-v2-04.txt Content-Type: multipart/alternative; boundary="------------A64FAA2AFA14E341D591D2A5" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk --------------A64FAA2AFA14E341D591D2A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Is there any chance that there might be a limitation on the use of community names in rfc2576 and the recent draft? An example in v1 is as follows: * In v1, we may use a community name, say "NetMgr", for access and the same community name for traps. * For MIB access, we may restrict the source IP addresses of "NetMgr" to "138.120.1.1" and "138.120.1.2" and "138.120.1.3". * For traps, we may define trap destinations to be "138.120.1.1" only. In rfc2576 and the recent draft, the community table is used for both the processing of incoming requests and the generation of outgoing notifications. In the above example, however, incoming requests from "NetMgr" should be checked against three source addresses. Outgoing notifications using the community name "NetMgr" should be sent to one destination address only. According to Section 5.2.1 and 5.2.3, the first entry in the community table satisfying the specified criteria is used. Does this mean that two different community names must be used for access and for traps? A separate question from the above is: Do we care the values of snmpCommunityContextEngineID and snmpCommunityContextName in the community table if the trap destinations are SNMP managers supporting only v1? Your information would be appreciated. Regards, Ann --------------A64FAA2AFA14E341D591D2A5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Is there any chance that there might be a limitation on the use of community names in rfc2576 and the recent draft?

An example in v1 is as follows:

  • In v1, we may use a community name, say "NetMgr", for access and the same community name for traps.
  • For MIB access, we may restrict the source IP addresses of "NetMgr" to "138.120.1.1" and "138.120.1.2" and "138.120.1.3".
  • For traps, we may define trap destinations to be "138.120.1.1" only.
In rfc2576 and the recent draft, the community table is used for both the processing of incoming requests and the generation of outgoing notifications. In the above example, however, incoming requests from "NetMgr" should be checked against three source addresses. Outgoing notifications using the community name "NetMgr" should be sent to one destination address only.

According to Section 5.2.1 and 5.2.3, the first entry in the community table satisfying the specified criteria is used. Does this mean that two different community names must be used for access and for traps?

A separate question from the above is: Do we care the values of snmpCommunityContextEngineID and snmpCommunityContextName in the community table if the trap destinations are SNMP managers supporting only v1?

Your information would be appreciated.

Regards,
Ann --------------A64FAA2AFA14E341D591D2A5-- From owner-snmpv3@lists.tislabs.com Wed May 14 15:24:49 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 PAA02352 for ; Wed, 14 May 2003 15:24:49 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12336 Wed, 14 May 2003 14:29:02 -0400 (EDT) Message-ID: <3EC28B9B.958D5DD@cs.berkeley.edu> Date: Wed, 14 May 2003 11:31:55 -0700 From: Ion Stoica X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: Call For Participation: IWQoS'03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Please accept my apology if you receive multiple copies of this message. Ion ---- The 11th International Workshop on Quality of Service (IWQoS'03) 2-4 June, 2003 Dubletree Hotel, Monterey, California, June 2-4, 2003 http://iwqos03.cs.berkeley.edu/ Highlights: Invited talks: - "Micro-Buffered Networks", Rene Cruz (UCSD) - "Breaking the Great Internet Deadlock OR Why there isn't any Network QoS and what to do about it", Abhay Parekh (ICSI Berkeley) - "Go After Challenges", Lixia Zhang (UCLA) Panel: "QoS in Demand: Who Needs it Anyway?" - Chair: Klara Nahrstedt (UIUC) Panelists: Andrew Campbell (Columbia U.), Dave Hartzell (NASA Ames), Srinivasan Keshav (Ensim), Jerry Rolia (HP Labs), Harick Vin (UT Austin) The full program consisting of 27 regular papers is available at http://iwqos03.cs.berkeley.edu/program.html Quality of Service continues to be an active research field, especially in the networking community. IWQoS is a successful series of workshops that aims to provide a forum for the presentation and discussion of new research and ideas on QoS. Traditionally, IWQoS workshops are cross-disciplinary and well focused, with the emphasis on innovation. As a result, a considerable amount of time is devoted to informal discussion. In addition to the traditional QoS topics such as service guarantees and admission control, this year we aimed to expand the scope of the workshop by encouraging submissions offering research contributions related to robustness, resilience, security, and predictability in networking and distributed systems. As a result, the program included two sessions on availability, fault tolerance, and dependability. The other sessions covered routing, resource allocation, storage, Web services, incentives, and rate based QoS. From owner-snmpv3@lists.tislabs.com Tue May 20 12:30:37 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 MAA20280 for ; Tue, 20 May 2003 12:30:37 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16418 Tue, 20 May 2003 11:35:19 -0400 (EDT) Message-ID: <111f01c31e8f$86c79810$6700a8c0@MIRELA> From: "Mirela Sechi Moretti Annoni Notare" To: Subject: 7th IEEE DS-RT'2003 - Call for Papers Date: Tue, 20 May 2003 02:20:27 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit ==================================================================== Our apologies if you have received multiple copies. Call for Papers DS-RT 2003 Seventh IEEE* International Symposium on Distributed Simulation and Real Time Applications, October 23-25, 2003, Delft, The Netherlands. http://www.cs.unibo.it/ds-rt2003/ In conjunction with 15th European Simulation Symposium (ESS 2003) October 26-29, 2003, Delft, The Netherlands Hosted by the Delft University of Technology *IEEE Approval Pending SCOPE In its seventh year, the 2003 International Symposium on Distributed Simulation and Real Time Applications (DS-RT 2003) will take place at the Delft University of Technology, Delft, The Netherlands, just before the European Simulation Symposium (ESS 2003). This is an excellent opportunity to participate in two conferences covering a wide range of simulation research. SYMPOSIUM OBJECTIVES DS-RT 2003 serves as a forum for simulationists from academia, industry and research labs, for presenting recent research results in Distributed Simulation and Real Time Applications. DS-RT 2003 targets the growing overlap between large distributed simulations and real time applications. The conference features prominent invited speakers as well as papers by top researchers in the field. DS-RT 2003 will include contributed technical papers, invited papers, and panel discussions. The proceedings will be published by IEEE-CS press. CALL FOR PAPERS DS-RT is intended to provide an international forum for the discussion and presentation of original ideas, recent results and achievements by researchers, students, and systems developers on issues and challenges related to distributed simulation and real time applications. Authors are encouraged to submit both theoretical and practical results of significance. Demonstration of new tools/applications is very desirable. The scope of the symposium includes, but is not limited to: o- Interactive Virtual Reality, Multi-User Virtual Reality, Interactive Simulation in Entertainment; o- Algorithms and Studies relating to existing protocols (e.g., HLA, DIS); o- Implementation issues; (e.g., general purpose distributed simulation); o- Algorithms and Methods for Distributed Interactive Simulation (e.g.,event synchronization, network time protocols); o- Applications of Distributed Simulation (e.g., Real Time DS, large distributed simulation systems); o- Distributed Models and Simulation for Analysis; o- Data Distribution Management and Interest Management; o- Multi-resolution modeling; o- Current Critical Design Issues (e.g.: causality, simultaneous events, zero look-ahead, compensation for slower than real time); o- Methodology for Distributed/Parallel Simulation; o- Approaches to interoperation of COTS simulation modelling packages; o- Interface Definition, Communication, Management, Security; o- Performance of Distributed Simulation; (e.g., benchmark, theoretical, empirical, and HLA/RTI studies); o- Dead-Reckoning Mechanisms; o- Visual Interactive Simulation (e.g., generic animation, visual interactive modeling, interactive computer based learning); o- Animating Language Tools, Visualization Tools for Computational Process under Simulation; o- Language and Modeling Issues; o- Modeling and Simulation Environments for Real Time Concurrent Systems; o- Influence of Network-Centric Systems (such as Java, and DCOM) on DIS; o- Interoperable Communication Networks; o- Network support for distributed simulation and real-time systems (QoS requirements and their realization, multicast for distributed/ real-time simulation systems); o- Applications of Web-Based Simulation (e.g. Modeling Global Internet); o- Integration of DIS and HLA with Web Technologies. IMPORTANT DATES Submission Deadline: June 1, 2003 (hard copy or electronic paper submission) Notification of Acceptance: July 15, 2003 Camera Ready version due: August 15, 2003 Symposium presentation: October 23-25, 2003 in Delft, The Netherlands IMPORTANT: ATTENDANCE BY AT LEAST ONE AUTHOR IS MANDATORY SUBMISSION GUIDELINES Papers should be written in English and should not exceed 20 pages. Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript pdf, or Microsoft Word 6.0 (or higher) only. Please submit papers to http://sentosa.sas.ntu.edu.sg:8000/~dsrt2003/ by June 1, 2003. Questions from authors may be directed to Simon Taylor (simon.taylor@brunel.ac.uk), or Stephen Turner (ASSJTurner@ntu.edu.sg). Hardcopy papers also may be submitted, in which case four copies are required. Each submission, electronic or paper, must be accompanied by the following information: a short abstract a complete list of authors and their affiliations a contact person for correspondence postal and e-mail addresses. Please contact the above if you wish to do so. ORGANIZING COMMITTEE General Chair Stephen J. Turner School of Computer Engineering Nanyang Technological University Nanyang Avenue, Singapore 639798 Email: ASSJTurner@ntu.edu.sg Phone: +65-6790-4054. Fax : +65-6792-6559 Program Chair Simon J. E. Taylor Department of Information Systems and Computing Brunel University Uxbridge, Middx, UB8 3PH Email: simon.taylor@brunel.ac.uk Phone: +44-1895-203389 Fax: +44-1895-251686 Publicity Co-Chairs Helen Karatza, Aristotle University of Thessaloniki, Greece Mirela M. S. A. Notare, Barddal University, Brazil Program Committee Lee Belfore, Old Dominion University, USA Luciano Bononi, University of Bologna, Italy Azzedine Boukerche, University of North Texas, USA Alexander Verbraeck, TU Delft Don Brutzman, Naval Postgraduate School Wentong Cai, Nanyang Technological University Judith Dahmann, MITRE Corporation, USA Alois Ferscha, Johannes Kepler University at Linz Robert Fransechini, SAIC, USA Richard Fujimoto, Georgia Institute of Technology Katherine Morse, SAIC, USA Anand Natrajan, University of Virginia Mikel Petty, Old Dominion University Mark Pullen, George Mason University Paul Reynolds, University of Virginia Doug Schmidt, DARPA, and University of California at Irvine Roger Smith, Model Benders Corp., USA Gary Tan, National University of Singapore Simon Taylor, Brunel University, UK Stephen Turner, Nanyang Technological University Richard Weatherly, MITRE Corp., USA Philip Wilsey, University of Cincinnati Steering Committee Azzedine Boukerche (Chair), University of North Texas Sajal K. Das, University of Texas at Arlington Paul Reynolds, University of Virginia Stephen J. Turner, Nanyang Technological University, Singapore Albert Zomaya, University of Western Australia Advisory Board Committee Jean-Loup Baer, University of Washington Jason Yi-Bing Lin, National Chiao-Tung University, Taiwan Azzedine Boukerche, University of North Texas K. M. Chandy, California Institute of Technology, USA Sajal K. Das, University of North Texas Lorenzo Donatiello, University of Bologna, Italy Doug DeGroot, Texas Instruments, USA Tuncer Oren, University of Ottawa, Canada Paul Reynolds, University of Virginia Gabriel Silberman, IBM Research, USA Stephen J. Turner, Nanyang Technological University, Singapore G. Zobrist, University of Missouri-Rolla, USA Local Arrangement Chair: Alexander Verbraeck, Systems Engineering, TU Delft Delft, The Netherlands Registration Chair Susan Standing, Brunel University, UK Webmaster and System Chair Luciano Bononi, University of Bologna, Italy For local information on the beautiful city of Delft see www.delft.nl! ==================================================================== From owner-snmpv3@lists.tislabs.com Tue May 20 12:38:17 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 MAA20666 for ; Tue, 20 May 2003 12:38:16 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16439 Tue, 20 May 2003 11:36:20 -0400 (EDT) Message-ID: <112701c31e8f$92b94d80$6700a8c0@MIRELA> From: "Mirela Sechi Moretti Annoni Notare" To: Subject: 6th ACM MSWiM'2003 - Call for Papers Date: Tue, 20 May 2003 02:20:47 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS perl-10 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit ============ Our apologies if you have received multiple copies. ============ CALL FOR PAPERS 6th ACM MSWiM 2003 The Sixth International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems (Jointly with ACM MobiCom 2003, September 14-19) September 19, 2003 San Diego, CA, USA http://www.cs.unibo.it/mswim2003/ MSWiM is intended to provide an international forum for the discussion and presentation of original ideas, recent results and achievements by researchers, students, and systems developers on issues and challenges related to mobile and wireless systems. Authors are encouraged to submit both theoretical and practical results of significance on all aspects of modeling, analysis and simulation of mobile computing and wireless networks. Topics of interest include, but are not limited to: * Performance evaluation and modeling of mobile and wireless communication networks * Simulation and analysis of wireless protocols and mobile computing systems * Integrated simulation and measurement based evaluation of mobile and wireless systems * Survivability and reliability evaluation and modeling * RF channel capacity modeling and analysis * Design methodologies for wireless systems * Network support for QoS provisioning in wireless and mobile networks * Modeling and analysis of wireless Internet access * Traffic measurements and models for audio, video, multimedia, and WWW services * New simulation languages and tools for wireless systems * Database management systems and mobile computing (location-based queries, wireless data caching, mobile transactions) * Wireless data dissemination (broadcasting and indexing techniques) * Pervasive computing and ad hoc networking * Wireless PANs, LANs * Sensor networks * Mobile agents support for wireless networks PAPER SUBMISSION AND PUBLICATION High-quality original papers are solicited. Papers must be unpublished and must not be submitted for publication elsewhere. All papers will be reviewed by Technical Program Committee members and other experts active in the field to ensure high quality and relevance to the conference. Paper length should not exceed 20 pages. Only Postscript and PDF formats are accepted. Papers must be submitted electronically through the EDAS system. For paper submission, please follow the submission instructions at: http://www.cs.unibo.it/mswim2003/ Accepted papers will appear in the conference proceedings published by by ACM CS-press. A Special Issue with ACM/Baltzer MONET/WINET will be planned which will contain selected papers from MSWiM. IMPORTANT DATES Full papers due: June 5, 2003 Notification: July 15, 2003 Camera Ready due: TBD Organizing Committee General Chair Rassul Ayani Department of Microelectronics and Information Technology Royal Institute of Technology (KTH) Email: rassul@it.kth.se Program Co-Chairs Carla-Fabiana Chiasserini Dipartimento di Elettronica, Politecnico di Torino, Italy Email: chiasserini@polito.it Hossam Hassanein Department of Computing and Information Science Queen's University Email: Hossam@cs.queensu.ca Publicity Co-Chairs Luciano Bononi Universita' di Bologna, Bologna, Italy Email: bononi@cs.unibo.it Helen Karatza Aristotle University of Thessaloniki, Thessaloniki, Greece Email: karatza@csd.auth.gr Mirela Sechi Moretti Annoni Notare Barddal University, Florianopolis, SC Brazil Email: mirela@barddal.br Program Committee Anand Balachandran, University of California at San Diego, USA Simonetta Balsamo, Universita' Ca' Foscari di Venezia, Italy Luciano Bononi, Universita' di Bologna, Bologna, Italy Azzedine Boukerche, University of North Texas, USA Lorenzo Casaccia, Qualcomm, San Diego, USA Xiuzhen Cheng, George Washington University, USA Carla-Fabiana Chiasserini, Politecnico di Torino, Italy Marco Conti, IIT - CNR, Italy Teresa A. Dahlberg, University of North Carolina at Charlotte, USA Sajal K. Das, University of Texas at Arlington, USA Juan Carlos De Martin, Politecnico di Torino, Italy Alois Ferscha, Johannes Kepler University of Linz, Austria Vincenzo Grassi, Universita' di Roma Tor Vergata, Italy Mohsen Guizani, Western Michigan University, USA Fredrik Gunnarsson, Ericsson Research, Sweden Hossam Hassanein, Queen's University, Canada Sumi Helal, University of Florida, USA Helen Karatza, Aristotle University of Thessaloniki, Greece Yi-Bing Lin, Academia Sinica, Taipei, Taiwan Michela Meo, Politecnico di Torino, Italy Pavan Nugehalli, University of California at San Diego, USA Mohamed Ould-Khaoua, University of Glasgow, UK Mirela Sechi Moretti Annoni Notare, Barddal University, Brazil Krishna M. Sivalingam, University of Maryland Baltimore County, USA Vikram Srinivasan, University of California at San Diego, USA Dirk Staehle, University of Wurzburg, Germany Mineo Takai, University of California at Los Angeles, USA David Tipper, University of Pittsburgh, USA Phuoc Tran-Gia, University of Wurzburg, Germany Albert Y. Zomaya, University of Sydney, AU Steering Committee Chair Azzedine Boukerche, University of North texas, USA Advisory Board Committee Azzedine Boukerche, University of North texas, USA Sajal K. Das, University of Texas at Arlington, USA Lorenzo Donatiello, Universita' di Bologna, Italy Jason Yi-Bing Lin, National Chiao-Tung University, Taiwan William C.Y. Lee, AirTouch Inc. Registration Chair Tom Jacob, University of North texas, USA Webmaster and System Co-Chairs Luciano Bononi, University of Bologna, Italy Email: bononi@cs.unibo.it Maurizio Munafo', Politecnico di Torino, Italy Email: munafo@polito.it From owner-snmpv3@lists.tislabs.com Tue May 20 19:22:59 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 TAA05444 for ; Tue, 20 May 2003 19:22:59 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18823 Tue, 20 May 2003 18:17:51 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C23FD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "SNMPv3 (E-mail)" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt Date: Wed, 21 May 2003 00:22:45 +0200 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 DO we worry at all about two SMICng warnings: W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have SIZE specified W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have SIZE specified We could add a SIZE of (1..0xffff) I would think Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: woensdag 7 mei 2003 15:08 > To: SNMPv3 (E-mail) > Subject: draft-ietf-snmpv3-coex-v2-04.txt > > > Colleagues, > > Although the announcement hasn't yet been sent, > > http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt > > is now available in the repository. It matches the version posted to > this list on 15 April 2003. As previously noted, that version fixed > all outstanding comments except the following one: > > On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > > I see (In the MIB REVISION clause) > > Changed the name of 'snmpCommunityGroup' > to a name > > conflict with the SNMPv2-MIB. > > Should that be: > > Changed the name of 'snmpCommunityGroup' to > > snmpCommunityTableGroup to avoid a name conflict > > with the SNMPv2-MIB. > > So this error still needs to be fixed before publication (note that > a similar error was was fixed in the revision log in appendix B). > > //cmh > From owner-snmpv3@lists.tislabs.com Tue May 20 21:23:24 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 VAA07912 for ; Tue, 20 May 2003 21:23:23 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19523 Tue, 20 May 2003 20:38:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt Date: Tue, 20 May 2003 20:43:15 -0400 Message-ID: <23E9D952BB39FC4B9E6410AAF23E2376DAD805@dc2kex01.vibrant-1.com> Thread-Topic: draft-ietf-snmpv3-coex-v2-04.txt Thread-Index: AcMfJsPQ2rolKfL+SPy0iAwWZHQEgwACvBRA From: "Frye, Rob" To: "Wijnen, Bert (Bert)" , "SNMPv3 (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA19516 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit IHMO: No. They are warnings, and Coex is about bridging the gap between old-SMI/SNMP and new. There are bound to be some complaints with compilers that expect new syntax when dealing with something "on the boundary" between the two. -- Rob. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, May 20, 2003 6:23 PM To: SNMPv3 (E-mail) Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt DO we worry at all about two SMICng warnings: W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have SIZE specified W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have SIZE specified We could add a SIZE of (1..0xffff) I would think Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: woensdag 7 mei 2003 15:08 > To: SNMPv3 (E-mail) > Subject: draft-ietf-snmpv3-coex-v2-04.txt > > > Colleagues, > > Although the announcement hasn't yet been sent, > > http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt > > is now available in the repository. It matches the version posted to > this list on 15 April 2003. As previously noted, that version fixed > all outstanding comments except the following one: > > On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote: > > I see (In the MIB REVISION clause) > > Changed the name of 'snmpCommunityGroup' > to a name > > conflict with the SNMPv2-MIB. > > Should that be: > > Changed the name of 'snmpCommunityGroup' to > > snmpCommunityTableGroup to avoid a name conflict > > with the SNMPv2-MIB. > > So this error still needs to be fixed before publication (note that a > similar error was was fixed in the revision log in appendix B). > > //cmh > From owner-snmpv3@lists.tislabs.com Tue May 20 22:01: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 WAA08365 for ; Tue, 20 May 2003 22:01:01 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19781 Tue, 20 May 2003 21:21:26 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 20 May 2003 18:26:54 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "SNMPv3 (E-mail)" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155019C23FD@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Wed, 21 May 2003, Wijnen, Bert (Bert) wrote: > DO we worry at all about two SMICng warnings: > W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have SIZE specified > W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have SIZE specified > > We could add a SIZE of (1..0xffff) I would think If a SIZE constraint is put in at all it should probably be (0..65535) (or (0..'ffff'h) if the hexadecimal style is preferred) since neither RFC 1157 nor RFC 1901 actually specified that the length of the community name must be non-zero. That said, I don't care one way or another, and I'm happy to leave it up to the document authors. But if a SIZE constraint is added, then the following text in the DESCRIPTION clauses should be adjusted to match: There is no SIZE constraint specified for this object because RFC 1157 does not impose any explicit limitation on the length of community strings (their size is constrained indirectly by the SNMP message size). //cmh From owner-snmpv3@lists.tislabs.com Tue May 20 22:21:06 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 WAA08805 for ; Tue, 20 May 2003 22:21:06 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19822 Tue, 20 May 2003 21:30:57 -0400 (EDT) Date: Tue, 20 May 2003 18:29:14 -0700 (PDT) From: Michael Kirkham To: "Wijnen, Bert (Bert)" cc: "SNMPv3 (E-mail)" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155019C23FD@nl0006exch001u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Wed, 21 May 2003, Wijnen, Bert (Bert) wrote: > Date: Wed, 21 May 2003 00:22:45 +0200 > From: "Wijnen, Bert (Bert)" > To: "SNMPv3 (E-mail)" > Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt > > DO we worry at all about two SMICng warnings: > W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have SIZE specified > W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have SIZE specified > > We could add a SIZE of (1..0xffff) I would think > > Thanks, > Bert > This very question was brought up up back in December in a message to this list in the thread "Re: WG last call: Coex draft" and the response at the time (though I'm only seeing one in my archive offhand) seemed to be "no": | On Mon, 23 Dec 2002, Michael Kirkham wrote: | > I would suggest that snmpCommunityName and snmpTrapCommunity should have | > size restrictions. While SMIv2 has an implied limit of 64k for OCTET | > STRING, it's not particularly realistic to have 64k community strings, let | > alone in the table. Unfortunately SNMPv1 and v2c don't specify a | > community string size limit, so choosing one that's appropriate and agreed | > upon may be difficult. | | I think these object definitions should be left unchanged. Changing | (or adding) a SIZE restriction is not one of the modifications that is | permitted by RFC 2578 Section 10.2. Since neither of these objects | appears in an INDEX clause, there is nothing illegal about the | definitions as they stand and so no error to fix; and as noted above, | it's not obvious what the limit should be anyway. | | //cmh -- Michael Kirkham www.muonics.com From owner-snmpv3@lists.tislabs.com Wed May 21 01:07: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 BAA12313 for ; Wed, 21 May 2003 01:07:40 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20621 Wed, 21 May 2003 00:22:27 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 20 May 2003 21:27:54 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "SNMPv3 (E-mail)" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk On Tue, 20 May 2003, Michael Kirkham wrote: > This very question was brought up up back in December in a message to this > list in the thread "Re: WG last call: Coex draft" and the response at the > time (though I'm only seeing one in my archive offhand) seemed to be "no": > > | On Mon, 23 Dec 2002, Michael Kirkham wrote: > | > I would suggest that snmpCommunityName and snmpTrapCommunity should have > | > size restrictions. While SMIv2 has an implied limit of 64k for OCTET > | > STRING, it's not particularly realistic to have 64k community strings, let > | > alone in the table. Unfortunately SNMPv1 and v2c don't specify a > | > community string size limit, so choosing one that's appropriate and agreed > | > upon may be difficult. > | > | I think these object definitions should be left unchanged. Changing > | (or adding) a SIZE restriction is not one of the modifications that is > | permitted by RFC 2578 Section 10.2. Since neither of these objects > | appears in an INDEX clause, there is nothing illegal about the > | definitions as they stand and so no error to fix; and as noted above, > | it's not obvious what the limit should be anyway. > | > | //cmh How short my memory is. Let's leave it alone and not embarrass me any more :-( //cmh From owner-snmpv3@lists.tislabs.com Wed May 21 03:47:41 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 DAA11274 for ; Wed, 21 May 2003 03:47:41 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21630 Wed, 21 May 2003 03:00:35 -0400 (EDT) Date: Wed, 21 May 2003 09:05:58 +0200 Message-Id: <200305210705.h4L75wGN027979@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpv3@lists.tislabs.com In-reply-to: <23E9D952BB39FC4B9E6410AAF23E2376DAD805@dc2kex01.vibrant-1.com> (rfrye@vibrant-1.com) Subject: Re: draft-ietf-snmpv3-coex-v2-04.txt References: <23E9D952BB39FC4B9E6410AAF23E2376DAD805@dc2kex01.vibrant-1.com> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk >>>>> Frye, Rob writes: Rob> IHMO: No. They are warnings, and Coex is about bridging the gap Rob> between old-SMI/SNMP and new. There are bound to be some Rob> complaints with compilers that expect new syntax when dealing Rob> with something "on the boundary" between the two. I think Dave Perkins wants people to be explicit that there is a size constraint for all octet strings in SNMP. Personally, I would leave it to the discretion of the authors whether they add an explicit size constraint of (0..65535) or not. /js -- Juergen Schoenwaelder International University Bremen Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany Fax: +49 421 200 3103 From owner-snmpv3@lists.tislabs.com Wed May 21 06:37: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 GAA14206 for ; Wed, 21 May 2003 06:37:22 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22921 Wed, 21 May 2003 05:47:28 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C24F6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "SNMPv3 (E-mail)" Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt Date: Wed, 21 May 2003 11:52:24 +0200 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 OK, thanks for the reactions. It was late (too late?) when I was checking this, and I should have seen the DESCRIPTION text that explains why there is no SIZE. Let us indeed leave it as is. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 21 mei 2003 0:23 > To: SNMPv3 (E-mail) > Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt > > > DO we worry at all about two SMICng warnings: > W: f(coex.mi2), (178,24) Item "snmpCommunityName" should have > SIZE specified > W: f(coex.mi2), (396,23) Item "snmpTrapCommunity" should have > SIZE specified > > We could add a SIZE of (1..0xffff) I would think > > Thanks, > Bert From owner-snmpv3@lists.tislabs.com Thu May 22 17:46:36 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 RAA00014 for ; Thu, 22 May 2003 17:46:35 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05362 Thu, 22 May 2003 16:34:46 -0400 (EDT) Message-ID: <3ECD3594.6040207@juniper.net> Date: Thu, 22 May 2003 13:39:48 -0700 From: Daniel Chuang Organization: Juniper User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: snmpv3@lists.tislabs.com Subject: context name for sending out the trap/inform. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, everyone, I apologize if this question has been asked before. In RFC 3413: sec 3.3. Notification Originator Applications When a notification originator wishes to generate a notification, it must first determine in which context the information to be conveyed in the notification exists, i.e., it must determine the contextEngineID and contextName. ..... Then, Is there any standard way to specify the context name for sending out the notification since notify view is determined by context name prefix or this is totally implementation dependent ? Thanks for clarification. Daniel From owner-snmpv3@lists.tislabs.com Thu May 22 18:53: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 SAA03671 for ; Thu, 22 May 2003 18:53:16 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05783 Thu, 22 May 2003 17:57:34 -0400 (EDT) Message-Id: <5.2.0.9.2.20030522145312.03f3dd90@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 22 May 2003 15:02:12 -0700 To: Daniel Chuang , snmpv3@lists.tislabs.com From: "David T. Perkins" Subject: Re: context name for sending out the trap/inform. In-Reply-To: <3ECD3594.6040207@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk HI, Management information exists in one (and possibly additional) contexts. A notification generator must "know" this, as well as "know" the reason for the notification and the object instances to include in an object instance. All of that is independent from the authorization rules. Conceptually, a generator puts together a PDU with engineID and context string and hands it to the notification distribution system which does filtering and management target selection. Note that the description of the notification distribution system is quite complex and difficult to understand in the RFCs. At 01:39 PM 5/22/2003 -0700, Daniel Chuang wrote: >Hi, everyone, > > I apologize if this question has been asked before. > >In RFC 3413: > >sec 3.3. Notification Originator Applications > >When a notification originator wishes to generate a notification, it > must first determine in which context the information to be conveyed > in the notification exists, i.e., it must determine the > contextEngineID and contextName. ..... > >Then, >Is there any standard way to specify the context name for sending out >the notification since notify view is determined by context name prefix >or this is totally implementation dependent ? > >Thanks for clarification. > >Daniel Regards, /david t. perkins From owner-snmpv3@lists.tislabs.com Fri May 23 10:13: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 KAA06617 for ; Fri, 23 May 2003 10:13:55 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10920 Fri, 23 May 2003 09:17:30 -0400 (EDT) Message-Id: <200305222156.RAA00385@ietf.org> To: IETF-Announce: ; Cc: snmpv3@lists.tislabs.com From: The IESG SUBJECT: Last Call: Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework to BCP Reply-to: iesg@ietf.org Date: Thu, 22 May 2003 17:56:15 -0400 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk The IESG has received a request from the SNMP Version 3 Working Group to consider Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-5. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt From owner-snmpv3@lists.tislabs.com Fri May 23 10:17:39 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 KAA07009 for ; Fri, 23 May 2003 10:17:39 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10903 Fri, 23 May 2003 09:16:29 -0400 (EDT) Message-Id: <200305222156.RAA00385@ietf.org> To: IETF-Announce: ; Cc: snmpv3@lists.tislabs.com From: The IESG SUBJECT: Last Call: Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework to BCP Reply-to: iesg@ietf.org Date: Thu, 22 May 2003 17:56:15 -0400 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk The IESG has received a request from the SNMP Version 3 Working Group to consider Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-5. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt From owner-snmpv3@lists.tislabs.com Thu May 29 14:30:42 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 OAA13302 for ; Thu, 29 May 2003 14:30:42 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21055 Thu, 29 May 2003 13:36:51 -0400 (EDT) Message-ID: <4FB6F321746ED4118A0500508BD8A24002184121@cinthol.india.ipolicynet.com> From: "Sharma, Tarun" To: "'snmpv3@lists.tislabs.com'" Subject: Latest in snmpv3 Date: Thu, 29 May 2003 14:14:13 +0530 Importance: high X-Priority: 1 Sensitivity: Personal MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C325BE.7B54FE4C" 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_01C325BE.7B54FE4C Content-Type: text/plain; charset="iso-8859-1" Hi I have just joined this group. Can anybody tell me whats latest going on in snmpv3. Regards Tarun Sharma ------_=_NextPart_001_01C325BE.7B54FE4C Content-Type: text/html; charset="iso-8859-1"

Hi
I have just joined this group. Can anybody tell me whats latest going on in snmpv3.
 
Regards
 
Tarun Sharma
------_=_NextPart_001_01C325BE.7B54FE4C-- From owner-snmpv3@lists.tislabs.com Thu May 29 17:01: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 RAA19636 for ; Thu, 29 May 2003 17:01:40 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21673 Thu, 29 May 2003 16:11:44 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Latest in snmpv3 Date: Thu, 29 May 2003 16:18:13 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA489537@NHROCMBX1.ets.enterasys.com> Thread-Topic: Latest in snmpv3 Thread-Index: AcMmD6hgLWKzi3oER9C3f+CE0qyy8QADyGlg Sensitivity: Personal From: "Harrington, David" To: "Sharma, Tarun" , X-OriginalArrivalTime: 29 May 2003 20:18:13.0976 (UTC) FILETIME=[6EB5DD80:01C3261F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA21670 Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 8bit Hi Tarun, You've joined us a bit late. The SNMPv3 WG has completed all its chartered work on developing the SNMPv3 standard, and SNMPv2 has become a full standard of the IETF. The document that describes coexistence between SNMPv1, SNMPv2C, and SNMPv3 has been completed and has been sent to the IESG for approval and for publication as a "Best Current Practice" RFC. Once the coexistence document is published as an RFC, the SNMPv3 WG will have completed all chartered work and will shut down. David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG -----Original Message----- From: Sharma, Tarun [mailto:tsharma@ipolicynet.com] Sent: Thursday, May 29, 2003 4:44 AM To: 'snmpv3@lists.tislabs.com' Subject: Latest in snmpv3 Importance: High Sensitivity: Personal Hi I have just joined this group. Can anybody tell me whats latest going on in snmpv3. Regards Tarun Sharma From owner-snmpv3@lists.tislabs.com Fri May 30 10:48:57 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 KAA11208 for ; Fri, 30 May 2003 10:48:56 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27053 Fri, 30 May 2003 10:09:28 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32632.ADB3E990" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Latest in snmpv3 Date: Thu, 29 May 2003 18:36:00 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA60329B@NHROCMBX1.ets.enterasys.com> Thread-Topic: Latest in snmpv3 Thread-Index: AcMmIvXhIm0pGGOpSieW3ffNSYL5kgAD5Q1w Sensitivity: Personal From: "Harrington, David" To: "Wijnen, Bert (Bert)" , "Snmpv3@Lists.Tislabs.Com (E-mail)" X-OriginalArrivalTime: 29 May 2003 22:36:00.0565 (UTC) FILETIME=[ADFB3E50:01C32632] Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C32632.ADB3E990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Whoops! Typo.=20 =20 SNMPv3 has become full standard, not SNMPv2. =20 dbh -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, May 29, 2003 4:42 PM To: Harrington, David Subject: RE: Latest in snmpv3 Sensitivity: Personal > -----Original Message----- > From: Harrington, David [ mailto:dbh@enterasys.com] > Sent: donderdag 29 mei 2003 22:18 > To: Sharma, Tarun; snmpv3@lists.tislabs.com > Subject: RE: Latest in snmpv3 > Sensitivity: Personal > > > Hi Tarun, > > You've joined us a bit late. > > The SNMPv3 WG has completed all its chartered work on > developing the SNMPv3 standard, and SNMPv2 has become a full > standard of the IETF. > SNMPv2 has becoem full standard ??? ;-) > The document that describes coexistence between SNMPv1, > SNMPv2C, and SNMPv3 has been completed and has been sent to > the IESG for approval and for publication as a "Best Current > Practice" RFC. > > Once the coexistence document is published as an RFC, the > SNMPv3 WG will have completed all chartered work and will shut down. > > David Harrington =20 > dbh@enterasys.com =20 > co-chair, IETF SNMPv3 WG > > -----Original Message----- > From: Sharma, Tarun [ mailto:tsharma@ipolicynet.com] > Sent: Thursday, May 29, 2003 4:44 AM > To: 'snmpv3@lists.tislabs.com' > Subject: Latest in snmpv3 > Importance: High > Sensitivity: Personal > > > Hi > I have just joined this group. Can anybody tell me whats > latest going on in snmpv3. > > Regards > > Tarun Sharma > ------_=_NextPart_001_01C32632.ADB3E990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Latest in snmpv3
Whoops! Typo.
 
SNMPv3=20 has become full standard, not SNMPv2.
 
dbh
-----Original Message-----
From: Wijnen, Bert = (Bert)=20 [mailto:bwijnen@lucent.com]
Sent: Thursday, May 29, 2003 = 4:42=20 PM
To: Harrington, David
Subject: RE: Latest in=20 snmpv3
Sensitivity: Personal


> -----Original Message-----
> From: = Harrington,=20 David [mailto:dbh@enterasys.com]
> = Sent:=20 donderdag 29 mei 2003 22:18
> To: Sharma, Tarun;=20 snmpv3@lists.tislabs.com
> Subject: RE: Latest in snmpv3
> = Sensitivity: Personal
>
>
> Hi = Tarun,
>
> You've=20 joined us a bit late.
>
> The SNMPv3 WG has completed all = its=20 chartered work on
> developing the SNMPv3 standard, and SNMPv2 = has=20 become a full
> standard of the IETF.
>
SNMPv2 has = becoem full=20 standard ??? ;-)

> The document that describes coexistence = between=20 SNMPv1,
> SNMPv2C, and SNMPv3 has been completed and has been = sent=20 to
> the IESG for approval and for publication as a "Best=20 Current
> Practice" RFC.
>
> Once the coexistence = document=20 is published as an RFC, the
> SNMPv3 WG will have completed all=20 chartered work and will shut down.
>
> David=20 = Harrington          >=20 = dbh@enterasys.com         >=20 co-chair, IETF SNMPv3 WG
>
> -----Original = Message-----
>=20 From: Sharma, Tarun [mailto:tsharma@ipolicynet.com]=
>=20 Sent: Thursday, May 29, 2003 4:44 AM
> To:=20 'snmpv3@lists.tislabs.com'
> Subject: Latest in snmpv3
>=20 Importance: High
> Sensitivity: Personal
>
>
> = Hi
> I have just joined this group. Can anybody tell me = whats
>=20 latest going on in snmpv3.
>
> Regards
>
> = Tarun=20 Sharma
>

------_=_NextPart_001_01C32632.ADB3E990-- From owner-snmpv3@lists.tislabs.com Fri May 30 10:51:25 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 KAA11263 for ; Fri, 30 May 2003 10:51:25 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27040 Fri, 30 May 2003 10:08:28 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 29 May 2003 13:25:41 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Sharma, Tarun" cc: "'snmpv3@lists.tislabs.com'" Subject: Re: Latest in snmpv3 In-Reply-To: <4FB6F321746ED4118A0500508BD8A24002184121@cinthol.india.ipolicynet.com> Message-ID: X-Cursor-Pos: cc 0 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-120191071-1054237320=:7034" Content-ID: Sender: owner-snmpv3@lists.tislabs.com Precedence: bulk ---2133786286-120191071-1054237320=:7034 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Thu, 29 May 2003, Sharma, Tarun wrote: > I have just joined this group. Can anybody tell me whats latest > going on in snmpv3. Late last year all the SNMgBPv3 documents were approved as Internet Standards and published as RFCs 3410 through 3418. Recently an IETF last call was issued to advance the coexistence document http://www.ietf.org/internet-drafts/draft-ietf-snmpv3-coex-v2-04.txt to BCP. My understanding is that when this document is approved and published the working group's job will be done and it will be concluded. Mike Heard ---2133786286-120191071-1054237320=:7034-- From owner-snmpv3@lists.tislabs.com Fri May 30 10:57:48 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 KAA11537 for ; Fri, 30 May 2003 10:57:48 -0400 (EDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27085 Fri, 30 May 2003 10:10:28 -0400 (EDT) Message-ID: <4FB6F321746ED4118A0500508BD8A24002184126@cinthol.india.ipolicynet.com> From: "Sharma, Tarun" To: "'Harrington, David'" , "Sharma, Tarun" , snmpv3@lists.tislabs.com Subject: RE: Latest in snmpv3 Date: Fri, 30 May 2003 10:11:30 +0530 Importance: high X-Priority: 1 Sensitivity: Personal MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32665.C19269BA" 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_01C32665.C19269BA Content-Type: text/plain; charset="iso-8859-1" Hi David, Thanks for your reply. Actually I mostly worked in RMON and recently I have been shifted to development of SNMP agent. So I wanted to know about all the latest developments in snmpv3. Now can you please tell me any other groups which might have some development/discussion going on snmpv3 or snmp. Regards Tarun Sharma MTS, Ipolicy Networks, 47467 Fremont Blvd., Fremont CA <>-----Original Message----- <>From: Harrington, David [mailto:dbh@enterasys.com] <>Sent: Friday, May 30, 2003 1:48 AM <>To: Sharma, Tarun; snmpv3@lists.tislabs.com <>Subject: RE: Latest in snmpv3 <>Sensitivity: Personal <> <> <>Hi Tarun, <> <>You've joined us a bit late. <> <>The SNMPv3 WG has completed all its chartered work on <>developing the SNMPv3 standard, and SNMPv2 has become a full <>standard of the IETF. <> <>The document that describes coexistence between SNMPv1, <>SNMPv2C, and SNMPv3 has been completed and has been sent to <>the IESG for approval and for publication as a "Best Current <>Practice" RFC. <> <>Once the coexistence document is published as an RFC, the <>SNMPv3 WG will have completed all chartered work and will shut down. <> <>David Harrington <>dbh@enterasys.com <>co-chair, IETF SNMPv3 WG <> <>-----Original Message----- <>From: Sharma, Tarun [mailto:tsharma@ipolicynet.com] <>Sent: Thursday, May 29, 2003 4:44 AM <>To: 'snmpv3@lists.tislabs.com' <>Subject: Latest in snmpv3 <>Importance: High <>Sensitivity: Personal <> <> <>Hi <>I have just joined this group. Can anybody tell me whats <>latest going on in snmpv3. <> <>Regards <> <>Tarun Sharma <> ------_=_NextPart_001_01C32665.C19269BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Latest in snmpv3

Hi David,
Thanks for your reply.
Actually I mostly worked in RMON and recently I have = been shifted to development of SNMP agent. So I wanted to know about = all the latest developments in snmpv3.

Now can you please tell me any other groups which = might have some development/discussion going on snmpv3 or snmp.

Regards

Tarun Sharma
MTS,
Ipolicy Networks,
47467 Fremont Blvd., Fremont CA






<>-----Original Message-----
<>From: Harrington, David [mailto:dbh@enterasys.com]
<>Sent: Friday, May 30, 2003 1:48 AM
<>To: Sharma, Tarun; = snmpv3@lists.tislabs.com
<>Subject: RE: Latest in snmpv3
<>Sensitivity: Personal
<>
<>
<>Hi Tarun,
<>
<>You've joined us a bit late.
<>
<>The SNMPv3 WG has completed all its = chartered work on
<>developing the SNMPv3 standard, and SNMPv2 = has become a full
<>standard of the IETF.
<>
<>The document that describes coexistence = between SNMPv1,
<>SNMPv2C, and SNMPv3 has been completed and = has been sent to
<>the IESG for approval and for publication as = a "Best Current
<>Practice" RFC.
<>
<>Once the coexistence document is published = as an RFC, the
<>SNMPv3 WG will have completed all chartered = work and will shut down.
<>
<>David = Harrington           =
<>dbh@enterasys.com      &n= bsp;  
<>co-chair, IETF SNMPv3 WG
<>
<>-----Original Message-----
<>From: Sharma, Tarun [mailto:tsharma@ipolicynet.com= ]
<>Sent: Thursday, May 29, 2003 4:44 AM
<>To: 'snmpv3@lists.tislabs.com'
<>Subject: Latest in snmpv3
<>Importance: High
<>Sensitivity: Personal
<>
<>
<>Hi
<>I have just joined this group. Can anybody = tell me whats
<>latest going on in snmpv3.
<>
<>Regards
<>
<>Tarun Sharma
<>

------_=_NextPart_001_01C32665.C19269BA--