Conference azur::mcc

Well,

	Part of your problem will be fixed with field test update.

1)  The entity in question must be reachable to register it.  This is a
    version 1.0 restriction.

    We are entertaining the suggestion you (along with others) made for
    version 1.1.  The problem we have found with extensive testing is 
    that there is no way for us to discern the difference between,
        a) the entity exists, but is not reachable at this time
	b) the user made a spelling error

    The spelling error conditions result in an incredibly cluttered 
    namespace.  In addition, since Phase V uses the namespace to find 
    addresses any extraneous clutter can cause problems with auto-boot,
    auto-register, etc.

    I expect that once we allow users to register unreachable entities,
    we will get SPRs saying that the system should not allow the user
    to register non-existant entities (i.e., catch spelling errors).

2)  The `good' news is that with EFTU, when a register fails, it 
    rolls back the namespace (if it can - assuming MCC put the entry
    into the namespace)

...kjn

>    We are entertaining the suggestion you (along with others) made for
>    version 1.1.  The problem we have found with extensive testing is 
>    that there is no way for us to discern the difference between,
>        a) the entity exists, but is not reachable at this time
>	 b) the user made a spelling error

You certainly can tell the difference.  You (MCC) currently DEMAND that 
the name be registered the the local nodes NCP database. Last time I tried to
register a node4 that was was not in the local NCP database, I got an ugly
error message that was just about impossible to decode!  How else do you expect
to be able to even try and contact that node if you (or NCP on your behalf)
cant translate the node name into a number.

If it is not there then it must be a spelling error? Easy?  

>2)  The `good' news is that with EFTU, when a register fails, it 
>    rolls back the namespace (if it can - assuming MCC put the entry
>    into the namespace)

More like bad news.  How bout a little bit of 'human' design.  What happens
when I run my command file that registers nodes?  Do I have to read the log
file and edit it apart by hand, and then do it all over again?  Thats
totaly BULL&$%^ for a place like HUGHES or BOEING or GE or DUPONT or ANY OTHER
LARGE CUSTOMER.

REGISTER NODE4 FRED

	Of Course this works just fine!

Some time later, the system owner of FRED installs some layered products and 
another controller or two, so the net manager want to register the new 
information.

So, mr(ms) Net_manager tries:

REGISTER NODE4 FRED

	Of course this fails!  What a loser.  You need to:
	1.)	DEREGISTER FIRST
	2.)	REGISTER only when FRED is up, but of course FRED is
		owned by a R&D group, and is only running from 10PM to 4 AM, so
		tough luck, come in in the middle of the night.

Requiring that the net manager DREGISTER the node first in order to add the
new information us TOTALLY UNACCEPTABLE.  You need to allow multiple register
commands and update the information as needed. See the base note (AGAIN) for
what would be acceptable.

    Dave, you're absolutely right about this.  But we need to understand
    the user model a little better before we fix the problem.  Is the
    design center a small network, where nodes are registered one at a
    time, or a large one, where nodes are registered in bunches?  It makes
    a difference.

Hold it!!  Some vital piece of information seems to be missing here.

If the user should add a new line or controller subsequent to the 
register of the node, there is no reason to deregister and reregister.  
Why not just register the line?

	REGISTER NODE4 fred LINE sva-0


...kjn

kjn>>  First I don't like the tone of the 154.2 entry.  Please try to 
kjn>>  remain civil

<<< Note 154.2 by RACER::DAVE "Dave Lyons - Networks DCC - 226-5934 - LKG2-1/S4" >>>
                    -< Thanks for the really usefull reply >-

>    We are entertaining the suggestion you (along with others) made for
>    version 1.1.  The problem we have found with extensive testing is 
>    that there is no way for us to discern the difference between,
>        a) the entity exists, but is not reachable at this time
>	 b) the user made a spelling error

- You certainly can tell the difference.  You (MCC) currently DEMAND that 
- the name be registered the the local nodes NCP database. Last time I tried to
- register a node4 that was was not in the local NCP database, I got an ugly
- error message that was just about impossible to decode!  How else do you expect
- to be able to even try and contact that node if you (or NCP on your behalf)
-  cant translate the node name into a number.

-  If it is not there then it must be a spelling error? Easy?  

kjn>>  Don't forget that MCC deals with more entities than DECnet ones.  
kjn>>  We must deal with all entities in a consistent fashion.
kjn>>  Most entities don't have routing databases - it's unique to DECnet 
kjn>>  and Bridges.  They only consistent way that we have to figure out
kjn>>  what is real and what is not is by trying to contact the entity.
kjn>>  The AM can front for the entity if it so chooses.

kjn>>  Thank you for your suggestion that we modify our error reporting
kjn>>   This will be enhanced in EFT update.

>2)  The `good' news is that with EFTU, when a register fails, it 
>    rolls back the namespace (if it can - assuming MCC put the entry
>    into the namespace)

-  More like bad news.  How bout a little bit of 'human' design.  What happens
-  when I run my command file that registers nodes?  Do I have to read the log
-  file and edit it apart by hand, and then do it all over again?  Thats
-  totaly BULL&$%^ for a place like HUGHES or BOEING or GE or DUPONT or ANY OTHER
-  LARGE CUSTOMER.

kjn>>  Hey,  at least the name is not hanging around in the namespace.  
kjn>>  You objected to having to deregister before you could register 
kjn>>  again - we fixed that.

kjn>>  Using a global namespace and managing a heterogenous set of  
kjn>>  devices in a consistent fashion presents some interesting problems.
kjn>>  Things will not always work in a manner made possible by DECnet.


...kjn

RE: 154.6 by TOOK::NELSON
    
kjn>>  Most entities don't have routing databases - it's unique to DECnet 
kjn>>  and Bridges.  They only consistent way that we have to figure out

    Actually, Bridges suffer the same problem on REGISTER (i.e., no local
    database to access in determining the existence of a Bridge).
    
    I believe the current list of AMs that don't have a local database
    to check for entity existence include all except DECnet IV/V and 
    SNMP. Examples:
    
    	- LAN Bridge AM
    	- Ethernet Station AM
    	- Terminal Server AM
    	- TransLAN AM
    	- Stock AM :-)
    
    From the management standpoint, changing the behavior of MCC to allow the
    REGISTERing of currently unreachable entities *that are not verifiable*
    can create a messy namespace (as Kathy Jo mentioned). Whether
    protecting the user in this way is good or bad remains to be seen.
    
    HOWEVER, I don't buy the "consistent fashion" argument as it relates
    to the REGISTER directive: 

kjn>>  We must deal with all entities in a consistent fashion.
kjn>>  Most entities don't have routing databases - it's unique to DECnet
        
    I believe that, with X0.10.4 of MCC, Node4 is using the "standard"
    dataflow for REGISTER (CALL_ACCESS REGISTER + SHOW IDENTS, as opposed
    to special case code in the Configuration FM).
    
    If this is the case, then why shouldn't the DNA4 AM allow *verifiably
    existing* (but currently unreachable) Node4 entities from being added
    to the namespace?
    

    MCC> REGISTER NODE4 WANDA
    Entity not reachable or does not exist; keep trying?  HELP
    The entity you are trying to register is not responding.
    The entity may be unreachable, or it may not exist
    (you might have misspelled the name).
    Answer YES to force repeated attempts to register the node;
    answer NO to stop registration attempts.
    
    Entity not reachable or does not exist; keep trying?  YES
    
    Registration Successful.
    MCC>

    RE: .5
    
    REGISTER NODE$ FRED LINE SVA-0
    
    This does not make it in the real world.  As the person who runs MCC,
    and does not own the hardware, I may not even know where the hardware
    is, or even what was added to it. I would never know what noe object
    there are.  Maybe, as a general operation, I want to
    
    REGISTER NODE4 *
    
    and cause all those nodes in my current database to be re-registered
    and updated if they are reachable. How else am I going to find out all
    those systems that now support the ELF version 3 object that has a new
    and improved, user friendly interface, and get updates on other
    information as well?
    
    The basic issue is not "Is there a way to do it?", because in most
    cases, there is.
    
    The basic Issue is "IS THERE A SIMPLE, EASY TO UNDERSTAND, USER
    FRIENDLY WAY TO DO IT?", which in many cases, there is not.
    
    

RE: The comment that NODE, NODE4, and SNMP are 'special' because they happen
	to have databases that can be checked during register commands.

These three cases are not Specail, they are the NORM, everything else is
special.

A quick look at the network in this building, which is by far abnormal in
its use of bridges, terminal servers and DEMPR's, shows that about 60%-70%
of the object that will end up in the databas are NODES of some sort (PIV, PV,
TCP).

That seems to clearly make the statement that node registrations are the norm,
even though there are only 3 AMs, vs all the other AMs.

This is skewed even more by the fact that here in LKG, we tend to use bridges,
DS200s and DEMPRs like popcorn.(1)  In EVERY customer network I have EVER looked
at, the numbers of these devices used has been SIGNIFICANTLY less.  Somewhere
near 1/6th of those used here.  That would make the NODEx registration represent
80%-95% of those objects in the network database.

The comment was made that MCC should not do special cases, and I agree, but lets
look at what the special cases are with both eyes open.

DRL

Note 1:
	The OCC at the end of the office row I am in has 3 DEMPRs, 2 DS200s
	and a DELNI for 11 people.  In most cuetomers sites, they would not
	tolerate that level of wasted ports on devices.  Not only would they
	'FILL' the ports, they tend to use other (third party) devices in their
	place.  These devices have 2 major features:

	1.  Lots more ports, so there are fewer of them
	2.  They support SNMP, so the fall into that 'Special' case anyway,
		skewing the numbers even more.

    Re: the last few.
    
    I agree with most of what you're saying.
    
    There are certainly more Phase IV, Phase V, and SNMP nodes present
    than almost any other entity on the network.�  Certainly these three
    are the most important.� 
    
    Since DEMPRs aren't manageable by MCC, the number of them in a network
    doesn't affect the current discussion (but then it would be nice
    to provide the capability of at least cataloging/mapping components like
    Repeaters, DELNIs, Transcievers, Segments, etc. from MCC...).
    
    The question I asked in note 154.7 is atill outstanding (that is:
    Why should entities, that can be verified to exist but are currently 
    not responding, be prevented from REGISTERing?).
    
    MCC should *definitely* be made more user friendly (it's just gonna
    take awhile...)
    
    						Chris
    
    �Please note that if the network is Ethernet LAN based, the Ethernet
     *Station* entity will be more plentiful than any other. Once MCC
     gets Events, Auto-Configuration/Topology, and Relationships, the
     utility of Station will become more obvious...
    
    �Are there any customers out there using large numbers of Terminal
     Servers to connect to a fewer number of VAXen? You know, the ones
     that haven't trashed all their terminals for VAXstation 3100s?

After some off-line discussions with Pete Savage, I have a better understanding
of how these issues will be addressed (via Autoconfigure FM) in future releases.

I would like to consider this discussions main topics closed, as MCC
development is clearly (to me, at least) heading in the right direction.

There were some side topics raised that still may be of interest, however.

DRL

RE: .11
	>Since DEMPRs aren't manageable by MCC, the number of them in a network
	>doesn't affect the current discussion 
	DEMPRs may not be manageable, but there are third party replacements
	which are, and customers do buy them because of that feature. (As well
	as lower cost per port, more functionality, and other features.) 
	Besidesd, at point in the future, DEC may offer boxes that ARE 
	managable.

RE: .11
	>Why should entities, that can be verified to exist but are currently 
	>not responding, be prevented from REGISTERing?
	I agree, MCC should not prevent it at all....

RE: .11 Note (1)
	Hopefully, some FMs will know about registration of entitys with
	multiple classes EG, NODE & STATION or BRIDGE & LAN_MONITOR, so that
	only one "registyration" need be done that would add the object in
	question where ever it was appropiate. This, of course, would be in
	some future release, not V1.0.

RE: .11 Note (2)
	You are joking, of course. I see locations where there are hundreds
	of terminal servers and only a few hosts much of the time.  This is
	mostly in the comercial markets, while the engineering markets tend
	high densitys of workstations.