requested repost ... this came while i was away on travel

[[e-mail]]

we were asked to forward this to the list, and it doesn't seem that anyone
else has, so i will

please forgive me if i missed it and this is a duplicate

regards,
jdc

-----------------------------------------------------------------------------

Return-Path: <[e-mail]>
Received: from gatekeeper.mcimail.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP)
	id AA13873; Tue, 24 Oct 95 14:27:13 -0400
Received: from mailgate.mcimail.com (mailgate.mcimail.com [166.38.40.3]) by gatekeeper.mcimail.com (8.6.12/8.6.10) with SMTP id SAA01608; Tue, 24 Oct 1995 18:23:51 GMT
Received: from mcimail.com by mailgate.mcimail.com id ak04527;
          24 Oct 95 18:25 WET
Date: Tue, 24 Oct 95 13:22 EST
From: Wedge Greene <[e-mail]>
To: Deirdre Kostick <[e-mail]>, Jeffery Case <[e-mail]>,
        Steve Waldbusser <[e-mail]>,
        Keith McCloghrie <[e-mail]>
Subject: Major problem with "Updated Intro document"
Message-Id: <92951024182229/[e-mail]>
Status: RO

Unable to get this into the list.  Please post.

Forwarded message:
_________________________________________________________________
Date:     Fri Oct 20, 1995 03:30 pm CDT
From:     Wedge Greene / MCI ID: 554-0088
 
TO:       SNMPv2-list(EMS)
          EMS: INTERNET
          MBX: [e-mail]
CC:       Erik Fretheim / MCI ID: 607-1804
CC:       Anil Prasad / MCI ID: 750-2332
CC:       Pat Moran / MCI ID: 283-9170
Subject:  Major problem with "Updated Intro document"
Message-Id: 33951020202533/0005540088NA3EM
 
After consideration, as we understand the documents and based on
the written exchanges of the working committee, MCI Data Services
cannot accept the loss in functionality represented by the
changes in (draft-ietf-snmpv2-coex-ds-03.txt) item 2 below, trap
forwarding/source identification, of the edits we understand
Keith was requested to make for the specific problem identified
by 'bok' below.  

MCI Data Services runs one of the largest SNMP managed networks
in the world.  We cannot accept this (possible) loss of
functionality.  If this functionality continues to be missing in
the proposed standard, we will not deploy SNMPv2, as proposed, in
the management of our data networks.

Ideally, we would like to have a context wrapper for traps.

We would accept (reference: from bok to Keith) "Option 2", the
proposed two new MIB objects, mentioned below in the message
extract, as adding necessary functionality.  This would allow us
to continue deployment plans for SNMP upgrades when available
from vendors.  We would recommend that the 'optional' be replaced
by 'required' so all traps always contain these objects.

We would also accept other proposals which (1) allow specific,
immediate identification of the original-originator address for a
trap, and (2) do not involve extraction of this information from
the community string.  

We do not wish to be alarmist, but feel the time constraints of
the working group addenda require us to bring this issue forward.
However, we recognize our exposure to these documents is brief;
if someone could show us how/where else this functionality is
contained in the draft posting, that might also help us clear our
objections.

- wedge

------------------------------------------------------------------
Wedge Greene & Erik Fretheim
Systems Design and Planning, Data Services Division, MCI
phone [phone]  Richardson, TX USA
[e-mail]
------------------------------------------------------------------
====================================================================
Referenced message:
Source-Date: Wed, 18 Oct 95 10:04:24 PDT
From:     Keith McCloghrie
          [e-mail]
From:     [e-mail]
------------------------------------------

draft-ietf-snmpv2-coex-ds-03.txt
--------------------------------

 
2. Section 3.1.2 (pg 9), step #2: specifies procedures for a SNMPv2-Proxy
   to translate a received SNMPv1-Trap into an equivelant SNMPv2-Trap.

   What should the proxy do with the agent_address field from the received
   SNMPv1-Trap?  Especially if it is different than the value of the 
   udp-from-address in the udp header of the received packet?

   NOTE: as currently specified, there is a loss of functionality going
         to SNMPv2-Traps from SNMPv1-Traps.  This is because in SNMPv1, 
      a trap could be sent on the behalf of some other originator 
         (i.e., agent_addr != udpHdr.from_addr).

   In SNMPv2-Classic and snmpv2*, this was not an issue because the 
   CONTEXT in the SNMPv2-Trap was a globally unique identifier of the 
   originating snmp entity.  In the Community-based SNMPv2 (SNMPv2C), 
   the community string is *not* globally unique; so therefore, cannot 
   be used to identify the originator of the SNMPv2-Trap.

   SOLUTION:

   The easiest way out is to simply blow it off and accept this reduction
   in functionality over SNMPv1-Traps.

   One alternate solution is to define a new MIB Object (or a pair of
   new mib objects - preferred) as follows:

      Option 1:  snmpTrapOriginator     SYNTAX IpAddress

      Option 2:  snmpTrapOriginTDomain  SYNTAX TDomain
           snmpTrapOriginTAddress SYNTAX TAddress

   which are optionally appended to the Trap variable-binding list
   if the originating address is different from the transport 
   from_addr.  The advantage of using Option 2 is that it solves
   the general problem of sending SNMPv2 Traps & Informs on behalf
   of others; and not just solve it for SNMPv1-to-SNMPv2 Trap Proxy.

   The elements of procedure for Notification processing would need 
   to be modified such that, not only might the last varbind be an 
   instance of snmpTrapEnterprise.0, the snmpTrapOrigin* varbinds
   may optionally appear as well.  Before or after snmpTrapEnterprise?

   In the interest of moving the documents along, I'll accept just
   blowing off this issue and accepting the reduction in functionality
   over SNMPv1-Traps.  This, despite the fact that our existing product
   relies on this SNMPv1-Trap capability and my only alternative will be
   to build an enterprise-specific work-around to this SNMPv2C deficiency.