Conference azur::mcc

I am  interested in comments on this from other entity implementors and from
MCC developers and EMARG members.  For that reason, I have cross-posted this
note in the EMA notes conference.

Graham

    re; .0
    
    I agree with you but for a different set of problems.
    
    Today we can have a computer system that is running both DECnet and
    TCP/IP. I would also only want one Icon on the map to represent the
    physical computer system (note that the system could also be a
    "Station" in order to do hardware testing at the Ethernet levels).
    
    A future problem will be when a node4 is changed to a node (sure wish
    they used node5 for this) when they install the appropriate new version
    of VMS sometime next year.
    
    s/rob

    The word "Node" is right, it's the Node4 that's wrong. But that was our
    architectural error by not mapping (architecturally) a Phase 4 node in
    as a different module of a node. Ah well, you live and learn.
    
    In the future, all those kinds of nodes/systems (either word means the
    same thing) ought to be viewed as just different configurations of a
    node (where a configuration is just a set of modules that happen to be
    installed in the node=system). Note that VMS will/should be moduled as a
    Module, not a global entity. The same holds for the LAT module (that's
    what makes a node a terminal server) etc. etc. etc.
    
    Mark

 
>    In the future, all those kinds of nodes/systems (either word means the
>    same thing) ought to be viewed as just different configurations of a
>    node (where a configuration is just a set of modules that happen to be
>    installed in the node=system). Note that VMS will/should be moduled as a
>    Module, not a global entity. The same holds for the LAT module (that's
>    what makes a node a terminal server) etc. etc. etc.
 
Ah, but there you have the two problems:

1) The  future  is  not  now  or  even close.  Many things are not currently
modules and not likely to be in the short term.

2) Some  things  will  *never*  be  modules.   For many reasons, alternative
management protocols will continue to exist for ever.  Not all of those will
have mediators to make them look like CMIP.  Many customers won't want their
management  to  have  to  use CMIP (that is why MCC allow for many different
AMs).

The problem  is  that  MCC's view of the system is too closely bound up with
the DNA notion of Node.  The Node is just one specific global entity class.

Graham

    Re: .0
    
    Graham, there has been a lot of thought behind what's provided in the
    first release of MCC and the iconic map. In addition, there has been,
    and will continue to be, much thought about the restrictions and how to
    remove them and the effects the changes would have.
    
    Rather than produce a complete tome on the area, let me list a few
    thoughts for your consideration.
    
    What does an icon represent? Currently, a global entity. Could be
    changed to be a DNS full name - initially this would also be just a GE,
    but we might anticipate DNS full names being applied to child entities
    (this arising out of conversations considering how to model SNA
    entities). Then, we might also want to remove the restriction that only
    entities represented by full names be shown as icons - during recent
    discussions with the Telecomms Engineering developers in VBE, they
    provided reasons to show non-global and non-full name things as icons.
    
    What does the icon mean to the user? As previous replies have pointed
    out, in general, the GE class code (eventually) will tell you nothing
    about the sort of device it represents. Probably only the user will
    know how they want to represent the device visually - out trick is to
    present to the user constructing a map (manually or automatically) a
    reasonable set of choices (or a reasonable default) that might apply to
    the device. I believe the user will get a choice of icons even in the
    first release of the PM (someone please correct me if this is wrong).
    
    Also, to the software, we have the problem of determining the class to
    be used in a management request initiated from the user interface.
    (This problem applies to both the command line and the iconic user
    interface). When we look at OSI SMI we see that the name of an object
    and its class are completely distinct. We need to solve the whole
    problem of OSI style names and separation of name and class as part of
    our work to support OSI completely.
    
    More thinking will clearly be applied to this whole area before
    solutions will start to appear in products. But I would like to assure
    you that we are thinking about some of these things.
    
    Colin

    re: .1 
    
    Where is the EMA Notes conference? Is it restricted?
    
    -Jerry
    

    
    
    
                           Enterprise Management Architecture
    Created: 22-NOV-1988 10:15          67 topics         Updated:
    16-DEC-1990 07:32
    
    
         Entry name:  EMA
         File:        FILES::EMA$:[NOTES]EMA.NOTE;2
         Moderator:   CHATTY::KATHY
    
         Access is not restricted
         Keyword creation is restricted
         Notes may be written