Conference azur::mcc

    
   > Is it still the case that MCC *requires* the default namespace on the
   > machine running MCC to be the namespace used by MCC ? 
    
  No such requirement exist. MCC can run on a system that does not have DNS
  server. But it needs to have DNS clerk running.
    
  >  This seems to have been the case for V1,
    
  I don't think so.
    
    
    By the by, can you the Error Message? That will give some insight.
    Also try registering some nodes, and post the errors.
    
    Thx.
    
    Jay Jesuraj
    

    As far as I know, MCC only uses the DEFAULT namespace. There is no
    place to specify to DECmcc the namespace to use.
    
    To make this work, append to the DNS$default_file.dat (I think that
    is the name) file created when you installed the DNS server, the
    content for the other namespace you want from a previous version
    of that file. DEC: is the typical one we use here. Then, make sure
    that all your DFS mount commands specify the DEC: namspace. An example
    mount command might be
    $ DFSCP MOUNT /system DEC:.eng.nac.dsad.netarch NET$ARCH /VOL="NETARCH"
    
    Hope this helps.
    
    s/rob

    
    reply .1 doesn't address the questions I asked in .0
    
    RE: .2
    
    I mentioned in .0 that if I put the required (non-default) namespace
    nickname on the front of the entity name I'm trying to register, then
    MCC *does* communicate with the nameserver that serves that namespace.
    However, REGISTERs still fail with a DNS- accessdenied error.
    
    I've done some more experimenting and I've found that it does seem to
    be necessary to use a private default namespace in order to be able to
    create any DNS objects from MCC (e.g. REGISTER, CREATE DOMAIN...).
    
    However, you can then do SHOWs on that registered object from a system
    where the default namespace is (say) DEC:.
    
    For example:
    
    On node HOWZAT, default namespace is CBN_REO:
    
    MCC> register bridge .bridges.test address=11-22-33-44-55-66
    
    works.
    
    On node KRIKIT, default namespace is DEC:
    
    MCC> register bridge CBN_REO:.bridges.test1 address=11-22-33-44-55-67
    
    fails, ***BUT***
    
    MCC> show bridge CBN_REO:.bridges.test all status
    
    works.
    
    What I don't understand is why the REGISTER command on KRIKIT fails. I
    saw MCC talking to the CBN_REO nameserver, and there's no difference in
    DNS access control between any nodes.
    
    Trevor
    
    

    
    RE: .0
    
    When you issue the following command
    
    >  MCC> register mcc cbn_reo:.mcc.krikit_director
    
    MCC tries to create object krikit_director in "CBN_REO:.MCC" directory,
    and (for MCC EFT 1.1 only) tries to create a softlink in .MCC_UID directory
    of your system's DNS default name space.
    
    In order to successfully register cbn_reo:.mcc.krikit_director, you
    need to have acces to both cbn_reo:.mcc directory and .MCC_UID directory 
    of your default name space.
    
    ------------------------------------------------
    
    RE: .3
    
    >    On node KRIKIT, default namespace is DEC:
    >
    >    MCC> register bridge CBN_REO:.bridges.test1 address=11-22-33-44-55-67
    >
    >    fails, ***BUT***
    
    The above MCC command creates bridge object test1 in "CBN_REO:.bridges",
    and tries to create the Bridge Backtranslation link in
    DEC:.MCC_BRIDGE_BACKTRANSLATION directory since your default
    namespace is DEC:. You probably do not have the WRITE access to
    DEC:.MCC_BRIDGE_BACKTRANSLATION directory.
    
    In order to register an object, you need to have accesses to your
    default
    name space.
    
    
    William
    

    
    Why does it try and create the ancilliary softlinks/backlinks in the
    default namespace, when the user has specified the one he wants to use
    ? Is it just a bug ? If so, are you intending to fix it ?
    
    Even if I had write access to DEC:.MCC, it's totally pointless to try
    and create a softlink to a different namespace !
    
    Trevor

    ref .5

      No it is not a bug. It is an architectural limitation as explained below.
      The problem extends to Synonym and all backtranslation softlinks.
Jay
   *********************************************************************


   Let us assume the the following environment:

      Node which has MCC is DIVNIT
      The default name space pointed by the clerk in DIVNIT is KAJUN_NS


      Consider the following MCC command :

      MCC> REGISTER NODE4 TRM_NS:DNS_NODE.BAIKO SYN BAIKO


      This command creates an object called BAIKO in the name space 
      TRM_NS under the subdirectory .DNA_NODE. The full name of this
      object is TRM_NS:.DNA_NODE.BAIKO.


      Further this command creates a synonym soft link called BAIKO in the 
      name space KAJUN_NS under the directory .DNA_NODESYNONYM. The full name 
      of the link is KAJUN_NS:.DNA_NODESYNONYM.BAIKO. The link target of this
      link is set to TRM_NS:.DNA_NODE.BAIKO.


      After this command the following two commands will work properly:


      MCC> DIR NODE4 TRM_NS:.DNA_NODE.BAIKO
      MCC> DIR NODE4 BAIKO

     (Note: This can be regarded as a FEATURE (???) because this enables 
            the user to place all the objects in one name space, and all
            soft links in  another name space.)




 The question raised in this note is "WHY DOESN'T MCC CREATE THE SYNONYM LINK
     in the name space TRM_NS where the object is created?"

  i) If we do so then the command 

     MCC> DIR NODE4 BAIKO 

     Will not work as MCC has no information about the name space to be used.

 ii) If you issue the command

      MCC> DIR NODE4 TRM_NS:.DNA_NODESYNONYM.BAIKO 

     MCC does not have the information to distinguish it as a synonym as opposed
     to other types of objects.

 iii) Can we issue the command

      MCC> DIR NODE4 SYN = TRM_NS:.DNA_NODESYNONYM.BAIKO 

      to indicate it is a synonym? 

      This is not a valid syntax.  Even if the syntax of this type were
      supported, supporting a similar one for the DNA_NODEBACKTRANSLATION
      soft links will be an "absolute mess".

                  
    
                  
       

 

     
       

    

    
    I would still say this was a bug. If you choose to call it a feature,
    then it is certainly a feature of dubious or extremely marginal
    utility.
    
    Surely, if the user specifies a namespace, it makes sense to use
    *entirely* the namespace that the user had specified. It seems that
    this would be fairly straightforward to do, and *far* more useful than
    the facility of being able to split your DNS information between
    multiple namespaces.
    
    DNS is complicated enough as it is, without MCC making it worse. MCC
    should work like all other products that use DNS:
    
    	- if the user doesn't specify a namespace, it should use the
    	  default namespace on the system.
    
    	- if the user does specify a namespace, you should only use the
          specified namespace.
    
    
    Trevor

The default  namespace  should  be  treated  as  a user preference (actually
system  manager  preference)  feature.   It  cannot  be  *relied*  on by any
product.

I, as  a  user/system  manager,  will  choose  *my*  default namespace to be
whatever  makes  most  sense for most of *my* DNS usage, thank you.  I *will
not*  choose  it for the convenience of some layered product! In particular,
we  cannot  run  our  general  user,  software  development cluster with the
default  namespace set to a private namespace for testing out MCC.  The only
namespaces  we  could  consider  setting  as  the  default would be DEC: and
PROTO_NS:.  Neither of those allow the MCC directories to be accessed.

Avoiding the  problems described in .6 is MCC's problem, not the customer's.
Some sort of "MCC> SET MCC DEFAULT NAMESPACE" command would be an acceptable
short-term  workround  (it could also be used to provide a directory tree to
use for creating all those MCC directories).

Graham

    I certainly have to agree with .-1 in this. I believe that DECmcc will
    run into exactly the same sorts of problems dictating namespace design
    and deployment that the Phase V field tests have seen and it will be
    a problem that will inhibit small sales to departments (where DEC has
    traditionally been able to penitrate large accounts) or small
    customers, and also to very large customers who will not be able to
    change how they do business or manage accross political boundrys
    and therefore cannot impliment GLOBAL management in the short term.
    
    There must be a supported way to separate out the authority and access
    rights requirements between the wide area or backbone network
    management and the local management or LAN managers.
    
    The current model of a single authority accross the network does not
    reflect how most actual networks are installed and managed.
    
    I have talked to dozens of customers in the last two months and what I
    have seen is that these customers have a very similar set of concerns
    that our own EASnet has and therefore will have the same problems and
    objections to the current restrictions in authority separation in
    the DECmcc director.
    
    s/rob

All operations performed on a object and any related softlinks MUST occur 
in the SAME namespace.  Further more, such behavior on the part of DECmcc
will break DECnet/OSI's use of DNS.   Please correct the code to contain
it sphere of reference to one namespace ... the default (first namespace
in the DNS$DEFAULT_FILE.DAT) is used if no namespace nickname is supplied
otherwise use the specifically referenced namespace for all operations
performed via clerk calles on behalf of the command issued.  That means
that the object and it's associated softlinks get put in the same namespace.
Any other behavior is a bug and should be QAR'd.   /Claudia

    I am convinced... We will  fix it in V1.2
    
    Thx. for all the input.
    
     Jesuraj