Conference azur::mcc

	I guess the answer to your question is no. You cannot register two
	entities with the same identifier. (Internet address is one of the
	alternate identifiers for the SNMP entity).

	rahul.

RE: base note

>    Could we provide ability to use same network address (Internet)
>    for several objects in the map and use other (e.g. SNMP community
>    string) coding for object identification.

 The scheme you mention (same IPAddress + different Community Names used to
identify the object) is also one way of implementing an SNMP Proxy Agent
(e.g. DECagent 90). The IPAddress would point at the Proxy Agent, while
the Community Name would provide the identifier (e.g. Ethernet Address)
of the entity to be managed.

 Since IPAddress and InternetName are SNMP global entity Identifiers
(and since Identifiers must uniquely identify the entity), what you're
asking for can't be supported cleanly on the Iconic Map with just the
SNMP AM.

							Chris

re: .2
    
> The scheme you mention (same IPAddress + different Community Names used to
>identify the object) is also one way of implementing an SNMP Proxy Agent
>(e.g. DECagent 90). The IPAddress would point at the Proxy Agent, while
>the Community Name would provide the identifier (e.g. Ethernet Address)
>of the entity to be managed.

    This is exactly what this customer refers. They want obviously
    utilise proxy processes/systems/agents for distributing management.
    Where I could get more information on Proxy agent and its use?
    
> Since IPAddress and InternetName are SNMP global entity Identifiers
>(and since Identifiers must uniquely identify the entity), what you're
>asking for can't be supported cleanly on the Iconic Map with just the
>SNMP AM.

    Is this question of storing in MIR or just Iconic Map?
    I would think that same IPAddress might appear in different domain
    (and map) rather than displaying it twice (and pointing to different
    Manageable object) on map.  
    What you mean with "supported cleanly"?
    What components of DECmcc (Iconic Map, Kernel/MIR Routines, SNAMP AM)
    should be modified for such support ?
    
    Thanks,	Olli
    

    I succeeded to find Common Agent F.S. V1.0 from next door.
    This document partly covers my first question (in .3).
    However it could be utilised together with DECmcc in this customer
    Environment (both public view to transmission network + multiple 
    private views to virtual customer networks)? Could anyone elaborate?
    
    P.S. Today in public side it's mainly question of ciscos and Stratacom.
    
    Olli

RE: 2423.3    Proxy systems/processes/agents...

>>   (e.g. DECagent 90)...
>
>    Where I could get more information on Proxy agent and its use?
>

 The ENGINE::HUB_MGMT conference has some information about DECagent 90
 and also the Hubview management stuff.

>> Since IPAddress and InternetName are SNMP global entity Identifiers
>>(and since Identifiers must uniquely identify the entity), what you're
>>asking for can't be supported cleanly on the Iconic Map with just the
>>SNMP AM.
>
>    Is this question of storing in MIR or just Iconic Map?

 SNMP Global Entities are registered in the MCC (Local or DECdns)
 namespace. SNMP Global Entities have three identifiers: Name, Address,
 and Synonym. No two SNMP Global Entities can be registered with the
 same Name, Address, *or* Synonym. No two Global Entities can be registered
 with the same Name (DNS FullName). 

>    I would think that same IPAddress might appear in different domain
>    (and map) rather than displaying it twice (and pointing to different
>    Manageable object) on map.  

 The same SNMP Global Entity can appear in multiple MCC domains. I don't
 understand what the rest of the above sentence means (I'm beginning to
 suspect that we're talking about different things, but using the same
 words (e.g., "Proxy").

>    What you mean with "supported cleanly"?

 To use the DECagent 90 as my proxy agent example:
 
 One DECagent 90, with one IPAddress, manages multiple devices (Bridges
 and Repeaters that are managed with RBMS, Terminal Servers that are
 managed with MOP RC, etc).

 This DECagent 90 can currently be registered as an SNMP entity (Icon
 appears on the map, etc).

 To manage the Bridge, we must:

	1. Set the PASSWORD qualifier to <address-of-bridge>
	2. Select DECagent 90 icon on the map
	3. Expand icon and look at/manipulate BRIDGE MIB.

 To manage the Terminal Server:

	4. Set the PASSWORD qualifier to <address-of-bridge>
	5. Select the SAME DECagent 90 icon on the map
	6. Expand icon and look at/manipulate TS MIB.

 This to me is not "clean support". Clean support to me is an icon for
 each device (DECagent, Bridge, AND Terminal Servers) being managed,
 NOT the selection of the device being managed with a qualifier like
 PASSWORD.


>    What components of DECmcc (Iconic Map, Kernel/MIR Routines, SNAMP AM)
>    should be modified for such support ?

 SNMP AM changes won't help.
 Iconic Map changes won't help.
 Kernel/MIR Routine changes won't help (unless we want to eliminate
  uniqueness of identifiers as a requirement).

 We're probably talking about the creation of a new class of entity
 (a new MCC AM or FM, using the services provided by SNMP AM)...

						Chris

    Re. .5
    
>> SNMP Global Entities are registered in the MCC (Local or DECdns)
> namespace. SNMP Global Entities have three identifiers: Name, Address,
> and Synonym. No two SNMP Global Entities can be registered with the
> same Name, Address, *or* Synonym. No two Global Entities can be registered
> with the same Name (DNS FullName). 

     Ok. it's DNS FullName, so Synonyms or Names specific to certain
     network (in this case = a customer) don't have to be unique.
    
>> same SNMP Global Entity can appear in multiple MCC domains. I don't
> understand what the rest of the above sentence means (I'm beginning to
> suspect that we're talking about different things, but using the same
> words (e.g., "Proxy").

    Forget this in .4. I was refering to a different thing - utilising
    router boxes but filtering TCP/IP - this allows using same address
    more than once but limits management access to local LAN only.
    Could be via proxy system but as we can't support it...

>> To use the DECagent 90 as my proxy agent example:
> 
> One DECagent 90, with one IPAddress, manages multiple devices (Bridges
> and Repeaters that are managed with RBMS, Terminal Servers that are
> managed with MOP RC, etc).
>
> This DECagent 90 can currently be registered as an SNMP entity (Icon
> appears on the map, etc).
>
> To manage the Bridge, we must:
>
>	1. Set the PASSWORD qualifier to <address-of-bridge>
>	2. Select DECagent 90 icon on the map
>	3. Expand icon and look at/manipulate BRIDGE MIB.
>
> To manage the Terminal Server:
>
>	4. Set the PASSWORD qualifier to <address-of-bridge>
>	5. Select the SAME DECagent 90 icon on the map
>	6. Expand icon and look at/manipulate TS MIB.
>
> This to me is not "clean support". Clean support to me is an icon for
> each device (DECagent, Bridge, AND Terminal Servers) being managed,
> NOT the selection of the device being managed with a qualifier like
> PASSWORD.
    
    Also the order looks logically wrong !
    I would assume that 
    
    	1. Select icon from Map
    	2. Expand it different proxy classes supported or proxy 
    	   object instances present
    	3. Select class and give address, or
    	   (preferably) click object instance icon
    
    would be something to expect. The latter won't allow Proxy objects
    at higher level map, but might be satisfactory for specific purposes.
    This does not however solve the requirements for a LAN manager or
    Terminal network manager..
    
    Thanks,		Olli	

>> To manage the Bridge, we must:
>>
>>	1. Set the PASSWORD qualifier to <address-of-bridge>
>>	2. Select DECagent 90 icon on the map
>>	3. Expand icon and look at/manipulate BRIDGE MIB.
>>
>> To manage the Terminal Server:
>>
>>	4. Set the PASSWORD qualifier to <address-of-bridge>
>>	5. Select the SAME DECagent 90 icon on the map
>>	6. Expand icon and look at/manipulate TS MIB.
>>
>> This to me is not "clean support". Clean support to me is an icon for
>> each device (DECagent, Bridge, AND Terminal Servers) being managed,
>> NOT the selection of the device being managed with a qualifier like
>> PASSWORD.
>    
>    Also the order looks logically wrong !
>    I would assume that 
>    
>    	1. Select icon from Map
>    	2. Expand it different proxy classes supported or proxy 
>    	   object instances present
>    	3. Select class and give address, or
>    	   (preferably) click object instance icon
>    
>    would be something to expect...


 I documented how it would work now (with V1.2), not how it should
 reasonably work! 

 Managing a DECbridge 90 through a DECagent 90 would require the
 steps outlined in my note...


>    The latter won't allow Proxy objects
>    at higher level map, but might be satisfactory for specific purposes.
>    This does not however solve the requirements for a LAN manager or
>    Terminal network manager..


 Aren't there (at least) two distinct ways of looking at this:

 1. Proxy Agent as a "gateway" to the entity being managed -

    This is what I was referring to in my earlier notes. An example of
    this is the FDDI AM, which uses a DECconcentrator or FDDI DECbridge
    to translate RBMS requests to SMT frames (FDDI Station is a global
    entity - "gateways" are assigned on a per ring/domain basis). 
    One could possibly specify the Proxy Agent in the VIA MANAGER
    qualifier (and/or have a list of proxy agents associated with a given
    managed object).

    This approach might be easy to implement for DECagent 90 as currently
    defined (i.e., use a "special" AM that defines a new global entity
    and calls SNMP AM to do the "real" work)...

 2. Proxy Agent is the Global Entity, while objects being managed
    are Children of the Proxy Agent -

    This appears to be the approach you mentioned above. Some issues
    with this approach (given the current DECmcc implementation):

      - IMPM does not support specifying of child entity instances,
	one must display ALL INSTANCES and then select one. This
	forces the Proxy Agent to know all entities it manages (all
	instances, not just all classes). Of course this instance
	information could be specified by the user before making
	a request...

      - On failure of Proxy Agent, a new Proxy Agent (icon) must be
	selected to manage the same entity.


						Chris

    re . 7
    
    I agree what you say Chris. 
    
> Aren't there (at least) two distinct ways of looking at this:
>
> 1. Proxy Agent as a "gateway" to the entity being managed -
>
>    This is what I was referring to in my earlier notes. An example of
>    this is the FDDI AM, which uses a DECconcentrator or FDDI DECbridge
>    to translate RBMS requests to SMT frames (FDDI Station is a global
>    entity - "gateways" are assigned on a per ring/domain basis). 
>    One could possibly specify the Proxy Agent in the VIA MANAGER
>    qualifier (and/or have a list of proxy agents associated with a given
>    managed object).
>
>    This approach might be easy to implement for DECagent 90 as currently
>    defined (i.e., use a "special" AM that defines a new global entity
>    and calls SNMP AM to do the "real" work)...
>
> 2. Proxy Agent is the Global Entity, while objects being managed
>    are Children of the Proxy Agent -
>
>    This appears to be the approach you mentioned above. Some issues
>    with this approach (given the current DECmcc implementation):
>
>      - IMPM does not support specifying of child entity instances,
>	one must display ALL INSTANCES and then select one. This
>	forces the Proxy Agent to know all entities it manages (all
>	instances, not just all classes). Of course this instance
>	information could be specified by the user before making
>	a request...
>
>      - On failure of Proxy Agent, a new Proxy Agent (icon) must be
>	selected to manage the same entity.

    I'll think both examples are important. Will the VIA MANAGER
    type function be considered per product or as "architected
    solution" ? 
    Also the recovery point is important (2.)
    
    As I'm not an expert in Common Agent / DECmcc V2 discussion,
    can this approach be used to distribute also DECmcc itself ?
    I mean implementing proxy agent as PM/PE for DECmcc.
   
    Will this pose new challenges of duplicating information/providing 
    distributed database for MIR ?
    I mean your reference to child entity...
   
    Olli