Conference azur::mcc

.0>    1) Why do we need to have a Control FM from the EMA architecture
.0>       pointofview? In order to provide (in the future) the peer-to-peer
.0>       communications between directors?
    The Control FM is merely used to act as the "null" FM between the
    PM layer and the AM layer. One might consider that it provides direct
    access to the primitive management functions that the AMs support. As
    such, its existence demonstrates that there may be missing functions
    (ie. missing FMs) - after all, if there we sufficient capable FMs,
    you would not need access to the primitive management services that
    the AMs provide.
    
.0>    
.0>    2) When will we have implemented the Director-to-Director communications
.0>       in the DECmcc product? Which is the status of ISO protocol for this
.0>       kind of communication? Infact i know that it will be different from
.0>       the standard CMIP, which must be used in the director-entity 
.0>       communication.
    Communications between directors is a complex subject. There are at
    least three flavors to this:
    	1/ MCC (or other EMA compliant directors) to non-MCC directors
    		which can be accomplished today via appropriate AM and/or
    		PM components (or one MM acting as both PM and AM)
    	2/ communication between management modules on different MCCs,
    		which we refer to as Kernel-to-Kernel communication. This
    		concept is introduced in the SRM, and will be implemented
    		partially in the Ultrix version of MCC. Widespread
    		implementation, particularly between VMS and Ultrix directors
    		is likely to occur later.
    	3/ communication between directors, for the purposes of
    		coordinating management activity on one entity between two
    		or more directors, which is what we call (real) Director-
    		to-Director communications, is probably further out than
    		item 2 above.
    In terms of CMIP, which is now an international standard - this is
    not sufficient to do 2/ and 3/ from the above; it can only handle 1/
    and will be used to that end.
    
.0>    
.0>    3) We will present EMA like solution for the Enterprise Management. 
.0>       DECmcc will be a Network Management solution until 2.0 (and 3.0 ?)
.0>       Is it true? Which will be the DEC strategy in order to cover also 
.0>       Application & systems management's needs, while we are waiting 
.0>       for the same functions under EMA/DECmcc platform?
    MCC will be managing more than "just" networks when it first ships.
    It will be used to manage applications and applications-related stuff.
    For example, MCC's own management, and management of name servers and
    name server clerks will be via MCC.
    Sometime soon after, one might expect some system management, and
    management of additional applications.
    Thus you do not have to wait for v2.0 or v3.0 for us to cover more than
    just networks. However, for widespread adoption of MCC, you will
    probably need to ask other groups when they plan to be managed via MCC.
    
.0>    
.0>    4) When and how will we have any relationship between  MIR and Object
.0>       oriented technology? 
    Expect there to be work in this area as we adopt version 2 of the
    Entity Model, which is being worked on right now.
    
.0>    
.0>    5) Are there any plans to integrate the DNS management under EMA/DECmcc
.0>       platform? Otherwise the customer could say: You're proposing an
.0>       integrated management of all entities, but a separeted management for
.0>       the DNS (with obvious considerations of different skills, different
.0>       interface....)
    Sure is. With the DECnet/OSI Phase V AM, there will be support for
    management of the DNS Name Server and DNS Clerk. Sometime later, we are
    hoping that the DNS group will implement a Name Space AM, so one can
    manage the name space (creating directories, browsing entries,
    modifying ACEs, etc.).
    
    
    Hope these help.....
    Colin

Colin,
it is more clear, but i'd like to understand well (those questions will 
be probably the customer's questions..). So few questions again...

>    The Control FM is merely used to act as the "null" FM between the
>    PM layer and the AM layer. One might consider that it provides direct
>    access to the primitive management functions that the AMs support. As
>    such, its existence demonstrates that there may be missing functions
>    (ie. missing FMs) - after all, if there we sufficient capable FMs,
>    you would not need access to the primitive management services that
>    the AMs provide.


Why is it divided by the Director's Executive Component? 
        
>    	1/ MCC (or other EMA compliant directors) to non-MCC directors
>    		which can be accomplished today via appropriate AM and/or
>    		PM components (or one MM acting as both PM and AM)

Does this mean that it will not possible (also in the future) a 
peer-to-peer communication between different System Management (for 
example EMA/director and AT&T Accumaster Integrator) ? 
Or is it the current solution, while we are waiting an other ISO standard
protocol ? Which is the current status of OSI/NETWORK MANAGEMENT 
FORUM's? 

>    	2/ communication between management modules on different MCCs,
>    		which we refer to as Kernel-to-Kernel communication. This
>    		concept is introduced in the SRM, and will be implemented
>    		partially in the Ultrix version of MCC. Widespread
>    		implementation, particularly between VMS and Ultrix directors
>    		is likely to occur later.

Which version (if it is possible) ?

>    	3/ communication between directors, for the purposes of
>    		coordinating management activity on one entity between two
>    		or more directors, which is what we call (real) Director-
>    		to-Director communications, is probably further out than
>    		item 2 above.

Without this functionality, we will not have the possibility to manage 
the same entity through different DECMCC directors. Do i understand 
well?

    
 >   However, for widespread adoption of MCC, you will
 >   probably need to ask other groups when they plan to be managed via MCC.
  
    OK, but we know which are the System Management solution (for 
example VPA, DECcp, Data Center Monitor, ENOP..) today. Which could be 
our strategy for customer's needs (in both System and Network Management 
areas)? Are there any specific plans to migrate those tools under EMA 
platform and, if yes, when?   

>    Expect there to be work in this area as we adopt version 2 of the
>    Entity Model, which is being worked on right now.
 
     In which DECmcc's version will we have these new Entity Model? Will 
Object oriented method require any changes also in the "DNS 
architecture" ?
    
    Thanks for your attention
    Giuseppina
    

.2> >    The Control FM is merely used to act as the "null" FM between the
.2> >    PM layer and the AM layer. One might consider that it provides direct
.2> >    access to the primitive management functions that the AMs support. As
.2> >    such, its existence demonstrates that there may be missing functions
.2> >    (ie. missing FMs) - after all, if there we sufficient capable FMs,
.2> >    you would not need access to the primitive management services that
.2> >    the AMs provide.
.2> 
.2> 
.2> Why is it divided by the Director's Executive Component? 
.2>         
    I'm sorry, but I don't understand your question, at all.
    
.2> >    	1/ MCC (or other EMA compliant directors) to non-MCC directors
.2> >    		which can be accomplished today via appropriate AM and/or
.2> >    		PM components (or one MM acting as both PM and AM)
.2> 
.2> Does this mean that it will not possible (also in the future) a 
.2> peer-to-peer communication between different System Management (for 
.2> example EMA/director and AT&T Accumaster Integrator) ? 
.2> Or is it the current solution, while we are waiting an other ISO standard
.2> protocol ? Which is the current status of OSI/NETWORK MANAGEMENT 
.2> FORUM's? 
.2> 
    On the contrary - it is possible right now. All that is required is for
    the appropriate AM/PM to implement the appropriate management protocols
    (such as the NMF, or NMP for Accumaster, or NMVT for NetView, etc.)
    The exact capabilities depend more on the AM/PM than on MCC per se.
    
    It is not clear that peer-to-peer communication means the same thing to
    everybody. Right now, the AM/PM solution seems to do just fine and may
    alo be sufficient for the long term. Protocol is but one of the
    considerations - management functions and managed objects are equally
    important.
    
    The NMF has published a set of agreements this June (which are more
    encompassing than the previous set published last year) -
    implementations are being produced by a number of companies for
    demonstrating this year and next.
    
.2> >    	2/ communication between management modules on different MCCs,
.2> >    		which we refer to as Kernel-to-Kernel communication. This
.2> >    		concept is introduced in the SRM, and will be implemented
.2> >    		partially in the Ultrix version of MCC. Widespread
.2> >    		implementation, particularly between VMS and Ultrix directors
.2> >    		is likely to occur later.
.2> 
.2> Which version (if it is possible) ?
.2> 
    After MCC v1.1 - like VMS, we are not publishing contents of future
    versions.
    
.2> >    	3/ communication between directors, for the purposes of
.2> >    		coordinating management activity on one entity between two
.2> >    		or more directors, which is what we call (real) Director-
.2> >    		to-Director communications, is probably further out than
.2> >    		item 2 above.
.2> 
.2> Without this functionality, we will not have the possibility to manage 
.2> the same entity through different DECMCC directors. Do i understand 
.2> well?
.2> 
    This is not the case. You can manage one entity from multiple
    directors - all you can't do is coordinate the management requests.
    Thus if two users (just like with NCP today) try to perform operations
    on the same entity, they will not interfere (ie. each operation will
    complete, and each will be serialised) but the end result may be not
    what was desired.  This is not usually a major concern - we've been
    managing DECnet, Bridges and terminal servers this way for years and
    you may not have even realised it.
    
.2>  >   However, for widespread adoption of MCC, you will
.2>  >   probably need to ask other groups when they plan to be managed via MCC.
.2>   
.2>     OK, but we know which are the System Management solution (for 
.2> example VPA, DECcp, Data Center Monitor, ENOP..) today. Which could be 
.2> our strategy for customer's needs (in both System and Network Management 
.2> areas)? Are there any specific plans to migrate those tools under EMA 
.2> platform and, if yes, when?   
.2> 
    I'll leave this to the appropriate groups to "volunteer" their plans
    as they see fit.
    
.2> >    Expect there to be work in this area as we adopt version 2 of the
.2> >    Entity Model, which is being worked on right now.
.2>  
.2>      In which DECmcc's version will we have these new Entity Model? Will 
.2> Object oriented method require any changes also in the "DNS 
.2> architecture" ?
.2>     
    As above, we won't comment on the exact version or timescale you might
    expect to see such support - but be assured that it is after v1.1

>.2>  >   However, for widespread adoption of MCC, you will
>.2>  >   probably need to ask other groups when they plan to be managed via MCC.
>.2>   
>.2>     OK, but we know which are the System Management solution (for 
>.2> example VPA, DECcp, Data Center Monitor, ENOP..) today. Which could be 
>.2> our strategy for customer's needs (in both System and Network Management 
>.2> areas)? Are there any specific plans to migrate those tools under EMA 
>.2> platform and, if yes, when?   
>.2> 
>    I'll leave this to the appropriate groups to "volunteer" their plans
>    as they see fit.
>    

I will answer for ENOP, as project manager.  ENOP is committed to migrate to
DECmcc, this migration is under development and you may expect it  to be
completed around DECmcc V1.1 timeframe. 

It is too early to give you more details, but our commitment is to migrate ENOP
to DECmcc for the next version of ENOP.

Hope this helps,

Best regards,

Marc.

    Regarding the OSI/NMF context, DIGITAL has indicated it will
    participate to some of the OSI/NMF showcase events.
    
    In this context connection to other Network management systems
    with a combination of AM/PM seems to be the direction that we'll
    take.
    
    Pierre

    ENOP Stands for "ENS Network Operations Platform". It provides a set of
    network alert and alarm management functionalities to deliver tailored
    network control center solutions for complex multivendor networks.  

    It is not a product, nor an ASSET, but a service tool sold as part of
    the service delivered by the ENS group.

    For more information or documentation, please contact Gerry Poortvliet, or 
    Jay Borden (@VBO or BONNET::).  
           
    

	1. Is there a Program which assists/encourages 3rd parties, other 
	   vendors, to develop AM's interfacing their products to MCC?

	2. If the response to 1 is Yes, do we have any names, or at least 
	   numbers, of actual and planned, which could be used in Customer 
	   situations?


Thanks,
	Joe. Valbonne EIC.

re .8
>
>	1. Is there a Program which assists/encourages 3rd parties, other 
>	   vendors, to develop AM's interfacing their products to MCC?
>
	Yes.   See note 661.1

>
>	2. If the response to 1 is Yes, do we have any names, or at least  
>	   numbers, of actual and planned, which could be used in Customer  
>	   situations? 
>	
	
	Contact Earl (DELNI::) Ingalls (manager of the Strategic Vendor
	Program) or Jon Goodridge (TOOK::JSG) for more info.

/doug

Joe,

	In Valbonne, Antoine Biondi is your man.  He is responsible for the
marketing of EMA in Europe and signing up European Strategic Vendors.  Some
are already on board (ASCOM, Eritel, British Telecom) and several more in the
pipeline.  Some susidiaries have begun an SVP support effort with resource
in the country dedicated to help the production of foreign AM's.


/Chris.

    Chris ,
    
    Regarding Europe , Antoine Biondi is the contact for Public SVP (ie
    Telecom market , or rather the management of what's inside the Public
    network ) ; since October , Norman Valentine (@VBO) is the European SVP
    manager for Private networks ( Ascom  etc ..) . Also to my knowledge Eritel 
    and British Telecom that you mentionned aren't part officially of
    the SVP (Ascom was announced in DEcworld 90) .
    regards .
    
    MaRc