Conference azur::mcc

    Perhaps I misunderstand what you are asking, but I *think* you are
    using the term DNS to mean two different things, viz:
    	Distributed Name SPACE
    	Distributed Name SERVER
    
    We would recommend that for most customers they should strongly
    consider using a Distributed Name Space - ie. a single global name
    space - for all their objects. In this way, there can be no confusion
    about the name of a global entity no matter where it is specified.
    
    The next consideration would be, where to locate the DNS *servers*
    to support that name *space*. It is quite reasonable, and indeed
    probably recommended by the DNS folks, to have one (or more) DNS
    servers per LAN - thus the single distributed name space is supported
    by multiple name servers.
    
    The trick, of course, is to design which name space directories belong
    on which name servers, and where/when to duplicate name space
    directories across servers.  This topic is probably better addressed in
    the DNS conference(s).
    
    We have used DECdns for DECmcc's use inside our company - it took a bit
    of planning and forethought - so I have to believe that most other
    companies would also be able to use it too.
    
    Colin

    To expand a bit on what Colin said...
    
    The backtranslation directories do not have to be a single point of
    network contention. You DO have to decide where the "Master Replica"
    of the directories will reside (choose the nameserver that will have
    them) but you can have "Read Only Replicas" spread around the network
    so that the "sites" have local access to the information. Only CHANGES
    would have to travel back to the "master".
    
    You are right in realizing that the design of the namespace is critical
    to a sucessful deployment of DECmcc in your network but in the big
    picture, namespace design is just one of the factors in designing for
    deployment of any distributed application.
    
    I suggest that you consider including some expertise in namespace
    planning and deployment as part of the planning and proposals for
    this and other customers of DECmcc.
    
    s/rob

    Thanks Colin and Rob,
    
    I very appreciate You agree to suggest a single namespace, and let
    organise the nameservers to do the job.  But how far can we go ?
    
>    We have used DECdns for DECmcc's use inside our company - it took a bit
>    of planning and forethought - so I have to believe that most other
>    companies would also be able to use it too.
    
    Colin, what do you mean by this sentence ?  As I heard from our IS
    guys, they cannot use our corporate namespace at this time to store
    DECmcc objects.
    Is this in our case only because they do not have write access to the
    backtranslation directories, or because more severe network performance
    could arise ?
    
    Let's make a rough calculation.  In our country we use at least 150
    Terminal servers. I assume 100 similar sites within Digital across the
    world.  This means in total 15000 Terminal servers installed in our
    premises.  The same calculation can be done for LAN bridges, although I
    estimate only half of this number only.
    
    In order to be able to use at least our useful part of the backtranslation
    directories, we have to create at least 1 read only replica copy per
    lan, ideally 2 per lan, of ALL the DECmcc backtranslation directories.
    We can also assume that each directory is updated at least once a day,
    meaning, the whole directory will be "skulked" each day to each of the
    200 "read only replicas".  At the first glace this seems to me a hughe
    traffic.
    
    This seems to me a N square problem.  Each LAN will propagate about all
    its objects to ALL the read replicas of the network, because I assume
    that each object class is used at each site for at least one instance.
    This means also that the "skulking" load will increase with the square
    of the number of LANS where a management station is operational.
    (Or do I miss something ?)  With a N square theorem you very rapidly reach
    limits.  Is Digital as a company far under this limit, just around that
    limit or above this limit ?
    How many LAN sites within Digital e.g. use DECmcc right now to manage
    their objects spread on their LANs ?
    
    It is not to engineering to answer the following question, but if DEC
    fits within these limits, why do we still wait to start registering all
    DECmcc managed objects into our corporate DEC: namespace ?
    
    In short is there any guideline to say how many individually managed
    LAN sites we reasonably can support with todays version of DNS and
    DECmcc, if also these LAN sites have to be globally glued by a single
    namespace ?
    
    	Regards,
    	Dominique.

    What is the planned work-around registering a newly attached node when
    there is no access to the master directory replica?  I can easily
    envision a situation (mostly because it happened to me) in which the
    nameserver containing the master replica goes down for several hours.
    
    Such a condition, especially if you were trying to register and manage
    or monitor a critical node, would be unacceptable at best.
    
    -Dan

    re: .3
    
    We've had many discussions with the EASYnet folks about how to set up
    the corporate namespace to meet their needs, and to be usable by
    DECmcc. To the best of my knowledge, this has now been deployed.
    Perhaps someone from EASYnet wishes to comment?
    
    The major sticking points, as you observe, were around backtranslation
    directories - most specifically ensuring that only 'site registrars'
    could register things in the namespace. In concert with the DECdns
    team, we devised a scheme (which I believe is in the v1.2
    documentation) of DNS groups and appropriate access control schemes
    to make this feasible, straightforward and to not require excessive
    administrative overhead. 
    
    Clearly, with extremely large networks, such as our own, we have
    reached, if not exceeded the implementation, if not the design, goals
    of DECdns, as it applies to backtranslation directories. This topic,
    along with the more general one of how we migrate to X.500, will be
    the subject of discussions in the development group.
    
    Colin

    Colin,
    
    	I'm still curious about how DECmcc will be able to register or
    modify entity data in the event the master replica DNS server goes
    down.
    
     	What is the plan to get around this in X.500 ?
    
    	The use of a single master replica server is a foolish idea at
    best when you consider how applications like DECmcc, DECmessageQ, DFS,
    DQS, and others will use DNS.  X.500 is implemented the same way.  DNS
    used to have what was called a Secondary which became master in the
    event the master went down.  This was eliminated to comply more closely
    with X.500.
    
    	Would you please pass this note on to someone from EASYnet for
    review?
    
    Thanks,
    Dan