Conference azur::mcc

	Christophe,

		One piece of information that might be interesting to you
	is that in V1.3 the SNMP AM will allow you to create multiple icons
	for the same proxy agent address. Refer to the SNMP AM use guide to
	find out how to do it.

	Rahul.

    We also have a similar issue for managing other OSI management
    stations. In our recent demo at Interop with Northern Telecom,
    we actually managed DPN's through the NT-IWS DPN management 
    system. We had an icon for the IWS and icons for the DPNs that
    we could only access via the IWS. Stella Ko can tell you how
    she was able to do it. The additional info to map requests
    for a DPN to the IWS was actually done via registration so
    that you could select a DPN but the connection went to the IWS.
    
    This is a general impm issue that we need to address in general
    rather than do Ultrix or SNMP specific fixes. We need a generally
    implemented method to support entities that are on the other side
    of proxies, mediators, or other management systems. We need it
    for SNMP, SMP, OSI CMIP, and DEC CMIP.
    
    wally

.1 Rahul, thank you for your answer. I'll get a copy of the SNMP AM use manual
   from the net. Unfortunately I don't think this nice feature will allow me
   to cope with our problem since there must be a way to tell the proxy agent 
   which entity you want to perform management action on.
   This might be achieve in :
	
	- the IP layer by using a different IP address for each entity
	  behind the proxy agent.

	- the UDP layer by using a specific UDP port address for each entity.

	- the SNMP layer by using a dedicated MIB variable : the problem
	  would then be to combine this variable with each SNMP SET, GET
	  or GET-NEXT request. Othervise the proxy agent would not be able 
	  to know the entity the request is send to.


All in all the advantage of using different IP addresses is that it doesn't 
necessitate any DECmcc modification (I wouldn't like to ask you to write
a specific Stratacom patch for the SNMP AM but anyhow if somebody think 
this is a general DECmcc issue and propose a global solution ...)


.2 Wally, I'll try to get in touch with Stella (did she use SNMP to manage
   DPNs ?).
   Anyway I quite agree with you : it's a global issue which should be solved
   whatever proxy agent you will use. Yet it's not only a matter of DECmcc
   and I'm afraid SNMP or CMIP don't include such authentification mechanism.


Ch.

RE: 4209.3

>   Unfortunately I don't think this nice feature will allow me
>   to cope with our problem since there must be a way to tell the proxy agent 
>   which entity you want to perform management action on.

 One way of doing this (supported by SNMP AM V1.3) is to use the
Community Name as a sub-identifier.

.4 You're right ! We might use such a solution provided the association 
between the icon and the community name would be automatic (I can't imagine
a customer performing a OPERATION - VIA ... command each time before he 
accesses an entity by double-clicking on the corresponding icon. 
If, for example, he forgets to modify the VIA password he will then access an 
other entity than the one he believes to look at (in fact the previous IPX node
he had a look at) ... this would lead to an extreme confusion).

As far as I know there is no such reference attribute that might be defined
once and for all. Futhermore, a reference attribute wouldn't do since it must
be associted to each icon (assuming there are N icons representing the same
entity) and not to the proxy agent's entity (there is only one).

Is there a way to make it automatic ?

thanks, Ch.

It works !
After reading the SNMP use manual, I've tested the following fcl command

MCC> register snmp ipx1 proxy agent address = a.b.c.d read community name -
_MCC> = "xxxxxx" , write community name = "yyyyyy" 

available with V1.3 of the SNMP AM and it works (I've multiple icons ipx1,
ipx2, ipx3, ... and each snmp request contains a different community name.

The only thing that remains to be done is now to translate the snmp request to
the appropriate proprietary protocol on the proxy agent depending on the 
community name used.


thanks to all.

Christophe

	Please refer to note 5090.

	Rahul.