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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>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?
<p>To be really consistent with both rfc's, the implemention could be as
follows:
<ul>
<li>
Set snmpEngineBoots to <b>0 </b>when the SNMP&nbsp;agent is first installed.</li>

<li>
Do not provide a MIB instance to snmpEngineBoots when it is 0.</li>
</ul>
This implementation could cover the descriptions in the two rfc's:
<p><b><i>rfc3414, Section 2.2</i></b>
<br>When an SNMP engine is first installed, it sets its local values of
snmpEngineBoots and snmpEngineTime to zero.
<p><b><i>rfc3414, Section 2.4</i></b>
<br>UsmSecurityParameters ::=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; msgAuthoritativeEngineBoots INTEGER
(0..2147483647),
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; msgAuthoritativeEngineTime INTEGER
(0..2147483647),
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...
<p><b><i>rfc3411 Section 5</i></b>
<br>snmpEngineBoots&nbsp; OBJECT-TYPE
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTEGER (1..2147483647)
<p>Comments would be appreciated.
<p>Thanks,
<br>Ann</html>

--------------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 <snmpv3-archive@lists.ietf.org>; 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 <christen@csee.usf.edu>
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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: Ann Lo <siu-ling-ann.lo@alcatel.com>
cc: snmpv3@lists.tislabs.com
Subject: Re: snmpEngineBoots
In-Reply-To: <3EB3088D.5E5D9617@alcatel.com>
Message-ID: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <randy_presuhn@mindspring.com>
To: <snmpv3@lists.tislabs.com>
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" <dbh@enterasys.com>
To: <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: "C. M. Heard" <heard@pobox.com>,
        "Snmpv3@Lists.Tislabs.Com (E-mail)" <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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)" <bwijnen@lucent.com>
To: "Harrington, David" <dbh@enterasys.com>, 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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "Snmpv3@Lists.Tislabs.Com (E-mail)" <snmpv3@lists.tislabs.com>
Subject: Re: draft-ietf-snmpv3-coex-v2-03
In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA88C979@NHROCMBX1.ets.enterasys.com>
Message-ID: <Pine.LNX.4.10.10305050934170.15142-110000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1906178487-1052152813=:17169"
Content-ID: <Pine.LNX.4.10.10305050950170.23201@shell4.bayarea.net>
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: <Pine.LNX.4.10.10305050950171.23201@shell4.bayarea.net>

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: <Pine.LNX.4.10.10305050940120.17169@shell4.bayarea.net>
Content-Description: Re: coex doc update (fwd)

Return-Path: <owner-snmpv3@lists.tislabs.com>
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 <heard@shell4.bayarea.net>; 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 <heard@bayarea.net>; 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 <heard@pobox.com>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "Snmpv3@Lists.Tislabs.Com (E-mail)" <snmpv3@lists.tislabs.com>
Subject: Re: coex doc update
In-Reply-To: <Pine.LNX.4.10.10304152253010.15979-100000@shell4.bayarea.net>
Message-ID: <Pine.LNX.4.10.10304161034260.12895-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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" <heard@pobox.com>
CC: snmpv3@lists.tislabs.com
Subject: Re: snmpEngineBoots
References: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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" <randy_presuhn@mindspring.com>
To: <snmpv3@lists.tislabs.com>
References: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net> <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" <siu-ling-ann.lo@alcatel.com>
> To: "C. M. Heard" <heard@pobox.com>
> Cc: <snmpv3@lists.tislabs.com>
> 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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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 <randy_presuhn@mindspring.com>
CC: snmpv3@lists.tislabs.com
Subject: Re: snmpEngineBoots
References: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net> <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" <siu-ling-ann.lo@alcatel.com>
> > To: "C. M. Heard" <heard@pobox.com>
> > Cc: <snmpv3@lists.tislabs.com>
> > 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 <snmpv3-archive@lists.ietf.org>; 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" <randy_presuhn@mindspring.com>
To: "Ann Lo" <siu-ling-ann.lo@alcatel.com>
Cc: <snmpv3@lists.tislabs.com>
References: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net> <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" <siu-ling-ann.lo@alcatel.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <snmpv3@lists.tislabs.com>
> 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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: Ann Lo <siu-ling-ann.lo@alcatel.com>
cc: snmpv3@lists.tislabs.com
Subject: Re: snmpEngineBoots
In-Reply-To: <3EB6C877.9F0B7D61@alcatel.com>
Message-ID: <Pine.LNX.4.10.10305051721520.24715-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>,
        Randy Presuhn <randy_presuhn@mindspring.com>
From: "David T. Perkins" <dperkins@dsperkins.com>
Subject: Re: snmpEngineBoots
Cc: snmpv3@lists.tislabs.com
In-Reply-To: <3EB6F015.E7276015@alcatel.com>
References: <Pine.LNX.4.10.10305050728240.30569-100000@shell4.bayarea.net>
 <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" <siu-ling-ann.lo@alcatel.com>
>> > To: "C. M. Heard" <heard@pobox.com>
>> > Cc: <snmpv3@lists.tislabs.com>
>> > 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 <snmpv3-archive@lists.ietf.org>; 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" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: <snmpv3@lists.tislabs.com>
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

<snip>.
>
>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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
Subject: draft-ietf-snmpv3-coex-v2-04.txt
In-Reply-To: <Pine.LNX.4.10.10305050934170.15142-110000@shell4.bayarea.net>
Message-ID: <Pine.LNX.4.10.10305070602360.20287-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks much for the informative replies from C.M. Heard, Randy Presuhn,
and David Perkins.
<p>In case this might be useful, a summary of answers to my questions are:
<ul>
<li>
<b><i>msgAuthoritativeEngineBoots</i></b> is 0 in a Request message when
the authoritative engine id is empty.</li>

<ul>
<li>
rfc3414 (USM)&nbsp;Section 3.1 (6) (c)</li>
</ul>

<li>
<b><i>snmpEngineBoots </i></b>starts from the value 1 when the SNMP&nbsp;agent
is up and running.</li>
</ul>
Regards,
<br>Ann
<br>&nbsp;</html>

--------------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 <snmpv3-archive@lists.ietf.org>; 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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: "C. M. Heard" <heard@pobox.com>,
        "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>, snmpv3@lists.tislabs.com
From: "David T. Perkins" <dperkins@dsperkins.com>
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"

<html>
<body>
HI,<br><br>
You didn't include the case I sent you. That is, when you are<br>
using noAuth/noPriv, the value in a request is not verified by<br>
the &quot;agent&quot;, and a value of zero, is a nice choice. <br><br>
At 06:40 PM 5/6/2003 -0700, Ann Lo wrote:<br>
<blockquote type=cite class=cite cite>Thanks much for the informative
replies from C.M. Heard, Randy Presuhn, and David Perkins. <br><br>
In case this might be useful, a summary of answers to my questions are: 
<ul>
<li><b><i>msgAuthoritativeEngineBoots</i></b> is 0 in a Request message
when the authoritative engine id is empty. 
<ul>
<li>rfc3414 (USM) Section 3.1 (6) (c) 
</ul>
<li><b><i>snmpEngineBoots </i></b>starts from the value 1 when the SNMP
agent is up and running. 
</ul>Regards, <br>
Ann </blockquote><br>
Regards,<br>
/david t. perkins</body>
</html>

--=====================_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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
A revised summary of answers to my questions on snmpEngineBoots are:
<ul>
<li>
<b><i>msgAuthoritativeEngineBoots</i></b> is 0 in a Request message when
the authoritative engine id is empty.</li>

<ul>
<li>
rfc3414 (USM) Section 3.1 (6) (c)</li>
</ul>

<li>
<b><i>msgAuthoritativeEngineBoots </i></b>can also be 0 in messages with
security level set to <i>noAuth/noPriv</i>.</li>

<ul>
<li>
The value of this field is ignored for <i>noAuth/noPriv.</i></li>

<li>
rfc3414 (USM)&nbsp;Section 3.1.</li>
</ul>

<li>
<b><i>snmpEngineBoots </i></b>starts from the value 1 when the SNMP agent
is up and running.</li>
</ul>
Thanks,
<br>Ann
<br>&nbsp;</html>

--------------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 <snmpv3-archive@lists.ietf.org>; 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" <sean@mibtonix.com>
To: <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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 <moulton@snmp.com>
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" <sean@mibtonix.com> 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 <snmpv3-archive@lists.ietf.org>; 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" <randy_presuhn@mindspring.com>
To: <sean@mibtonix.com>, <snmpv3@lists.tislabs.com>
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" <sean@mibtonix.com>
To: <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <randy_presuhn@mindspring.com>
To: <snmpv3@lists.tislabs.com>
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" <moulton@snmp.com>
> To: <sean@mibtonix.com>
> Cc: <snmpv3@lists.tislabs.com>
> 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 <snmpv3-archive@lists.ietf.org>; 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 <siu-ling-ann.lo@alcatel.com>
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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>Is there any chance that there might be a limitation on the use of community
names in rfc2576 and the recent draft?
<p>An example in v1 is as follows:
<ul>
<li>
In v1, we may use a community name, say "NetMgr", for access and the same
community name for traps.</li>

<li>
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".</li>

<li>
For traps, we may define trap destinations to be "138.120.1.1" only.</li>
</ul>
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"&nbsp;should
be checked against three source addresses. Outgoing notifications using
the community name "NetMgr" should be sent to one destination address only.
<p>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?
<p>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&nbsp;managers supporting only v1?
<p>Your information would be appreciated.
<p>Regards,
<br>Ann</html>

--------------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 <snmpv3-archive@lists.ietf.org>; 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 <istoica@cs.berkeley.edu>
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 <snmpv3-archive@lists.ietf.org>; 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" <mirela@newsite.com.br>
To: <mirela@ieee.org>
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 <snmpv3-archive@lists.ietf.org>; 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" <mirela@newsite.com.br>
To: <mirela@ieee.org>
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 <snmpv3-archive@lists.ietf.org>; 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)" <bwijnen@lucent.com>
To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <rfrye@vibrant-1.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155019C23FD@nl0006exch001u.nl.lucent.com>
Message-ID: <Pine.LNX.4.10.10305201815510.14960-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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 <mikek@muonics.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155019C23FD@nl0006exch001u.nl.lucent.com>
Message-ID: <Pine.BSF.4.44.0305201821000.33115-100000@slepton.muonics.com>
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)" <bwijnen@lucent.com>
> To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
> 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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
Subject: RE: draft-ietf-snmpv3-coex-v2-04.txt
In-Reply-To: <Pine.BSF.4.44.0305201821000.33115-100000@slepton.muonics.com>
Message-ID: <Pine.LNX.4.10.10305202124300.21507-100000@shell4.bayarea.net>
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 <snmpv3-archive@lists.ietf.org>; 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 <schoenw@ibr.cs.tu-bs.de>
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		<http://www.iu-bremen.de/>


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 <snmpv3-archive@lists.ietf.org>; 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)" <bwijnen@lucent.com>
To: "SNMPv3 (E-mail)" <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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 <dchuang@juniper.net>
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 <snmpv3-archive@lists.ietf.org>; 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 <dchuang@juniper.net>, snmpv3@lists.tislabs.com
From: "David T. Perkins" <dperkins@dsperkins.com>
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 <snmpv3-archive@lists.ietf.org>; 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 <iesg-secretary@ietf.org>
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 
<draft-ietf-snmpv3-coex-v2-04.txt> 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 <snmpv3-archive@lists.ietf.org>; 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 <iesg-secretary@ietf.org>
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 
<draft-ietf-snmpv3-coex-v2-04.txt> 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 <snmpv3-archive@lists.ietf.org>; 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" <tsharma@ipolicynet.com>
To: "'snmpv3@lists.tislabs.com'" <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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN 
class=345464308-29052003>Hi</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=345464308-29052003>I have just joined 
this group. Can anybody tell me whats latest going on in 
snmpv3.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=345464308-29052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=345464308-29052003>Regards</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=345464308-29052003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=345464308-29052003>Tarun 
Sharma</SPAN></FONT></DIV></BODY></HTML>

------_=_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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: "Sharma, Tarun" <tsharma@ipolicynet.com>, <snmpv3@lists.tislabs.com>
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 <snmpv3-archive@lists.ietf.org>; 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" <dbh@enterasys.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "Snmpv3@Lists.Tislabs.Com (E-mail)" <snmpv3@lists.tislabs.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Latest in snmpv3</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D391003522-29052003><FONT face=3DArial color=3D#0000ff =

size=3D2>Whoops! Typo. </FONT></SPAN></DIV>
<DIV><SPAN class=3D391003522-29052003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D391003522-29052003><FONT face=3DArial color=3D#0000ff =
size=3D2>SNMPv3=20
has become full standard, not SNMPv2.</FONT></SPAN></DIV>
<DIV><SPAN class=3D391003522-29052003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D391003522-29052003><FONT face=3DArial color=3D#0000ff =

size=3D2>dbh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Wijnen, Bert =
(Bert)=20
  [mailto:bwijnen@lucent.com]<BR><B>Sent:</B> Thursday, May 29, 2003 =
4:42=20
  PM<BR><B>To:</B> Harrington, David<BR><B>Subject:</B> RE: Latest in=20
  snmpv3<BR><B>Sensitivity:</B> Personal<BR><BR></FONT></DIV><!-- =
Converted from text/plain format --><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----<BR>&gt; From: =
Harrington,=20
  David [<A=20
  =
href=3D"mailto:dbh@enterasys.com">mailto:dbh@enterasys.com</A>]<BR>&gt; =
Sent:=20
  donderdag 29 mei 2003 22:18<BR>&gt; To: Sharma, Tarun;=20
  snmpv3@lists.tislabs.com<BR>&gt; Subject: RE: Latest in snmpv3<BR>&gt; =

  Sensitivity: Personal<BR>&gt;<BR>&gt;<BR>&gt; Hi =
Tarun,<BR>&gt;<BR>&gt; You've=20
  joined us a bit late.<BR>&gt;<BR>&gt; The SNMPv3 WG has completed all =
its=20
  chartered work on<BR>&gt; developing the SNMPv3 standard, and SNMPv2 =
has=20
  become a full<BR>&gt; standard of the IETF.<BR>&gt;<BR>SNMPv2 has =
becoem full=20
  standard ??? ;-)<BR><BR>&gt; The document that describes coexistence =
between=20
  SNMPv1,<BR>&gt; SNMPv2C, and SNMPv3 has been completed and has been =
sent=20
  to<BR>&gt; the IESG for approval and for publication as a "Best=20
  Current<BR>&gt; Practice" RFC.<BR>&gt;<BR>&gt; Once the coexistence =
document=20
  is published as an RFC, the<BR>&gt; SNMPv3 WG will have completed all=20
  chartered work and will shut down.<BR>&gt;<BR>&gt; David=20
  =
Harrington&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR=
>&gt;=20
  =
dbh@enterasys.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<B=
R>&gt;=20
  co-chair, IETF SNMPv3 WG<BR>&gt;<BR>&gt; -----Original =
Message-----<BR>&gt;=20
  From: Sharma, Tarun [<A=20
  =
href=3D"mailto:tsharma@ipolicynet.com">mailto:tsharma@ipolicynet.com</A>]=
<BR>&gt;=20
  Sent: Thursday, May 29, 2003 4:44 AM<BR>&gt; To:=20
  'snmpv3@lists.tislabs.com'<BR>&gt; Subject: Latest in snmpv3<BR>&gt;=20
  Importance: High<BR>&gt; Sensitivity: Personal<BR>&gt;<BR>&gt;<BR>&gt; =

  Hi<BR>&gt; I have just joined this group. Can anybody tell me =
whats<BR>&gt;=20
  latest going on in snmpv3.<BR>&gt;<BR>&gt; Regards<BR>&gt;<BR>&gt; =
Tarun=20
  Sharma<BR>&gt;<BR></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_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 <snmpv3-archive@lists.ietf.org>; 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" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: "Sharma, Tarun" <tsharma@ipolicynet.com>
cc: "'snmpv3@lists.tislabs.com'" <snmpv3@lists.tislabs.com>
Subject: Re: Latest in snmpv3
In-Reply-To: <4FB6F321746ED4118A0500508BD8A24002184121@cinthol.india.ipolicynet.com>
Message-ID: <Pine.LNX.4.10.10305291241570.7034@shell4.bayarea.net>
X-Cursor-Pos: cc 0
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-120191071-1054237320=:7034"
Content-ID: <Pine.LNX.4.10.10305291318120.20834@shell4.bayarea.net>
Sender: owner-snmpv3@lists.tislabs.com
Precedence: bulk

---2133786286-120191071-1054237320=:7034
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.10305291318121.20834@shell4.bayarea.net>

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 <snmpv3-archive@lists.ietf.org>; 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" <tsharma@ipolicynet.com>
To: "'Harrington, David'" <dbh@enterasys.com>,
        "Sharma, Tarun"
	 <tsharma@ipolicynet.com>, 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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Latest in snmpv3</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi David,</FONT>
<BR><FONT SIZE=3D2>Thanks for your reply.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>Now can you please tell me any other groups which =
might have some development/discussion going on snmpv3 or snmp.</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
</P>

<P><FONT SIZE=3D2>Tarun Sharma</FONT>
<BR><FONT SIZE=3D2>MTS,</FONT>
<BR><FONT SIZE=3D2>Ipolicy Networks,</FONT>
<BR><FONT SIZE=3D2>47467 Fremont Blvd., Fremont CA</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

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

</BODY>
</HTML>
------_=_NextPart_001_01C32665.C19269BA--