Conference azur::mcc

>	Example: Each Phase V node has 3 distinct objects associated
>with it: the node object itself, its synonym object, and its backtranslation
>object.

Not all  Phase  V  nodes  have a synonym.  Nodes which are never accessed by
Phase  IV  applications  running on Phase V nodes have no need of a synonym.
Such nodes include all standalone routers and X.25 gateways.

Graham

    
    DNRS V4+ will create a synonym object for each node listed in the
    node database on ANCHOR. Even new nodes which come up using Phase V
    will still have to register in the database and thus have a synonym
    entry.
    

>    DNRS V4+ will create a synonym object for each node listed in the
>    node database on ANCHOR.

What is  DNRS?  Is  it the transition tool? I can certainly believe that the
transition  tool  will  create  synonym entries for nodes because most nodes
will  need  them.  However there are other ways to get your nodes registered
(e.g.   the  NCL  REGISTER command).  Nobody is forced to use the transition
tools.

>Even new nodes which come up using Phase V
>    will still have to register in the database and thus have a synonym
>    entry.

Why? If  someone  installs  a  new  router  running  Phase  V there are *no*
applications  that  can  use  the  synonym.   Phase  IV nodes do not use the
synonym:  they  use  their  local  name  to  address  database  and  Phase V
applications on Phase V nodes use the full Phase V nodename.

Are you  talking  about some Easynet policy decision? If so, it doesn't make
any  sense but doesn't alter the fact that there is no reason why a customer
should adopt the same (non-sensical) policy.

In general, do *not* assume that every named node has a synonym.

Graham

    
    Rather than debate EASYnet node registration policies, let me ask
    the base note question again and say that many nodes will have objects
    (including synonyms) in the Namespace. What access will MCC need to
    these DNS objects?
    

How MCC uses the namespace, specifically for Phase IV and PhaseIV/V 
transition is as follows (we are still ironing out the kinks with the 
Session Control folks and none of the Phase V stuff is set in concrete 
yet):


THE CURRENT PLAN
Starting with EFT update every MCC REGISTERed Phase IV node will have 
the following in the namespace:

	1) an entry under DNA$Node  -- e.g., DNA$Node.TOOK
	2) a softlink under DNA$NodeSynonym
		-- e.g., DNA$NodeSynonym.TOOK --> DNA$Node
	    (this synonym will be updated when the node goes to Phase V)
	3) a softlink of the backtranslation variety
		-- the placement of this softlink is still under discussion,
		   since we cannot generate a true Phase V style address
		   or towers for the Phase IV node before transition,
		   this softlink may end up in MCC$DNA4_BackTranslation
		   instead of DNA$BackTranslation

For V1.1 (not committed yet), we hope to have a way to allow the network 
manager to assign IDPs to existing areas so we can generate towers for 
Phase IV nodes before transition.


As far as access control goes, the network manager that is REGISTERing 
and DEREGISTERing nodes must have READ, WRITE, and DELETE (and probably 
TEST) access to all of the directories mentioned above.

Other MCC users need only READ (and maybe TEST?)  I haven't totally 
figured out TEST yet.

...kjn

I believe  the  following information represents the current Session Control
architecture.   This  doesn't yet cover synonyms in detail and there is risk
that even the parts described here may change!

1) Every  Phase  V  node  with an assigned name (using the RENAME directive)
will  attempt  to  keep  its  DNA$TOWERS  attribute  (i.e.   the  DNA$TOWERS
attribute  of the object with the name it has been given) up to date.  To do
this it will need write access to that object.

2) Because  of  the  recursive  nature  of the problem of determining access
control to the node object, Session Control assumes that the object has been
created  with world control access.  After it has set up the correct address
it  will  modify that access to close it down to providing write access only
from the node itself.

3) If, at any time, the node's address changes such that none of its current
towers are present in the DNA$TOWERS attribute then the manager will have to
reset the access to be world control so that steps 1 and 2 can happen again.

4) In   addition,   Phase   V   Session   Control  attempts  to  create  the
backtranslation   softlink  to  the  name.   It  will  create  the  softlink
directories  as required.  It will allow world write access to any directory
it  creates  and  will not change access on any softlinks.  We will probably
encourage customers to make the softlink directories have world write access
so  that  Session  Control  can create them correctly (this opens up nothing
worse than a denial of service attack).  However, if the customer wishes, he
can   create   the  directories  himself  (e.g.   he  may  wish  to  control
replication).   The  only requirement is that Session Control can create and
modify the backtranslation softlink itself.

Graham

When having these discussions, please remember that for the near term, 
at least, MCC is operating on Phase IV nodes in a Phase IV network.  

We are working with the groups producing transition tools and will 
be synched up with them when we ship V1.0.  As things are changing 
almost on a daily basis, this is the best we can do.

We will do the best we can to make sure that all information necessary 
for transition to Phase V (that can be determined in advance and in an 
automatic way) in associated with the Phase IV nodes registered by MCC.

...kjn

They way DECmcc and DECnet Phase V use DNA$BackTranslation.'area' is not
the same -- DECmcc used DNA$BackTranslation.0001 not DNA$BackTranslation.%x0001.
/cp