Conference azur::mcc

1677.0. "DECmcc directories: common vs. site-specific" by CRONIC::LEMONS (And we thank you for your support.) Fri Oct 18 1991 19:11

[Other notes detailing some of our trials and tribulations in using DECmcc with
Digital's corporate, public namespace are recounted in notes 88, 613, 1544 and
1578]

Now that I'm able to use the corporate namespace to register some things, I see
a gigantic Catch-22, at the heart of which are the trade-offs between keeping 
local, site-specific information and root, corporate-common level information.
In what follows, I'm ASSuming that one site's DECmcc director can not use another
site's director's defined entities, unless the backtranslations occur at a 
common root level in the namespace, most likely '.'.

Take, for example, terminal servers.  While the terminal server entity would
probably be registered as something like .sitecode.S.TERMINAL_SERVER.tsname, the
backtranslation for this entity would go to the single, root level terminal
server backtranslation directory .MCC_TERMINAL_SERVER_BACKTRANSLATION.  Now,
imagine that all of the tens of thousands of terminal servers within Digital 
backtranslate to this same directory.  Grim, no?  So, this makes a case for
keeping backtranslation directories at the site level.  Apparently, there is
an undocumented logical name, still supported in DECmcc V1.2, that will allow
this to happen.  I believe that this logical name is 'all or nothing'; in that,
it will keep ALL directories local, or none.  Please correct me if necessary.

On the other hand, take bridges.  Unlike terminal servers, it's easy to make a
case for several groups accessing the same bridges (local site network
management AND Corporate Telecommm, for instance).  So, here it seems necessary
to have one backtranslation directory shared by the corporation.  The 'good' is
full visibility by all directors; the 'bad' is a potential large backtranslation
directory that may become a performance bottleneck.

Some of the issues seem to be:

1) what are the backtranslation directories used for?
2) how do root-level and non-root-level backtranslation directories effect
entity information sharing by multiple directors?
3) what DECmcc directories should be considered corporate common (node and DTSS
server are clearly in this category), and which (if any) site-specific (terminal
servers? concentrators?)?

Please contribute your ideas to this.  We're poised to make a choice that may
require massive amounts of effort later on to un-do.

Thanks!
tl

Hi,

In the case where 'corporate' may need to do work on a site level object, I
believe this will be covered. I've had brief hallway encounters with John
Regan, and I believe access will be set at site levels, with corporate
getting extended rights to the NS (this was mainly discussed with node
objects but it may also apply for other objects). You'll have to double-check
with John to confirm this though. If this is going to be the case I would
tend to think you would want to keep things BELOW the root for the reasons
you stated. Also at this point, what is best for corporate will be a
properly functioning and maintainable NS. If these backtranslations break
or become unmanageable it does no one any good. Corporate will deal with
their own access needs, but lets make sure things get set up to work for
the long term now.

best regards,
brad...


ps. are you managing node4's from DEC: yet???