Conference azur::mcc

    Mahnaz,
    our sincere thanks for:
    	1) persevering
    	2) taking the time to document the details for us
    
    This sort of information is very useful to us in development - we are
    trying hard to build the best product we can, but you will appreciate
    there is a fine line between features/functions and things like sleep :-}
    
    I'd like to address your points one at a time...
    

1 - DNS: Inflexibility of location of MCC directories  
    Problem Detail:     They had a DNS naming plan/structure, and wanted to 
			maintain that. (At the root only one directory - 
			.Glaxo - One directory under that, for each country - 
			.GLAXO.US,  .Glaxo.UK , etc). They wanted me to put 
			all the MCC directories under the .GLAXO.US    But I 
			had to tell them that the only ones that I could put 
			there are .DNA_NODE and .MCC directories. The 
			DNA_NODESYNONYM and the  BACKTRANSLATIONs have to be 
			at the root. 
		        They were not very pleased with that!
			
    I know the customer is always right, but is this something like
    expecting the speed of light to be different? How did Glaxo get the
    impression that they could use the name space in the way that they
    wanted to - ie. that there would ONLY be one directory in the root?
    Other things (like ADVANTAGE/NETWORKS - n�e DECnet/OSI) put stuff in
    the root directories too.
    
    Is it that we did not explain adequately how MCC uses the name space or
    is it a more general problem that we haven't explained how to use
    naming services?


2 - DNS:   Access control problem
    Problem Solution:  This is a DNS known problem. 
 
    ok


3 - DNS:   Registration problem
    Problem detail: "CREATE DOMAIN" commands intermittently failed.
    Problem Cause:     The MCC TDF (Time Difference factor) did not match the 
		       DNS TDF!

    Hmm - it's a shame we let you do things wrong, and then return errors
    in quite unexpected places.
    
    I've entered a QAR (#1090) with a suggestion that the installation
    procedure check the MCC tdf against the DNS tdf (if it can determine
    it).


4 - DNS:   Object partially registered
    Recommendations:  (in relation to problems 1 to 4)
		      2 document are badly needed!
		      First, a MCC-DNS troubleshooting guide needs to be 
		      developed. This was raised in the notes file a long time
		      ago, and it was stated that there will be a MCC-DNS 
		      troubleshooting guide, but it has not materialized yet. 
		      Such a guide will eliminate a lot frustrations, and will 
		      make MCC a much easier product to use.

		      Second, a document explaining "how MCC works with DNS", 
		      must be developed. This document should explain 
		      directory structures, domains, objects, synonyms, links, 
		      what data is stored where, how data is accessed by 
		      MCC commands, etc, etc. This info will be invaluable for
		      people with more experience, and will help them plan and
		      troubleshoot MCC-DNS problems.
    
    Both are good suggestions - I'm not sure how much of this will appear
    in the MCC v1.2 doc set. Certainly there is more explanatory material
    in the v1.2 documentation about how to set up (we refer to it as
    deploying) MCC so that you may manage your network.


5 - Registration:  Cabletron Hubs 
    Problem detail: Customer was not satisfied with the fact that he could not 
	    	    register Cabletron Hubs as Ethernet Stations.

    From your description, I am unsure whether you mean that the Cabletron
    Hubs are not supporting the 802 XID and TEST messages (and hence would
    not be manageable as Ethernet Stations) or whether the Hub *does*
    support those messages and there is a problem with the Station AM.
    Please could you be a little more specific? Thanks.


6 - Registration:  Not able to register unreachable entities	
    Solution:      Known restriction. Will be fixed in V1.2

    As you say, fixed in v1.2


7 - Ethernet-AM problem with DECconcentrators
    Problem Solution: We upgraded to ELM AM - Customer seemed satisfied.

    ok

8 - Iconic Map: Drawing lines in iconic map

    Problem detail:  When connecting 2 objects to each other or when 
		     connecting an object to another line (ie: Line presenting
		     Ethernet), the Iconic map seemed to have the mind of 
		     its own!! 
		     There seemed to be problems/limitations with X & Y axis!!
		     ie: when trying to connect object A to Ethernet with a 
		     65 degree angle line, the line would change to a straight 
		     line!!!  This can be very annoying when one is building 
		     the map for almost a full day (ie: first time creating 
		     the map of the network) The customer was very annoyed!
    
    Fixed in v1.2 - there's a bug in v1.1 where the "snap to grid"
    algorithm was being overly helpful.


9 - Iconic Map: Names are too long. Want to be able to use the synonym


     Problem detail:  Customer did not like the very long names on the map! 
		      ie: .DOMAIN.BUILD1 ,   .GLAXO.US.DNA_NODE.VAX001
		      Wants to be able to use synonyms and not be restricted
		      to DNS names.

    This is currently on the list of suggested enhancements, and is
    unlikely to make it into v1.2
    
    Our thoughts in this area are to allow icons to be named in a way
    chosen by the customer (but with sensible defaults out-of-the-box).
    Right now you are constrained to displaying the fullname. We'd like to
    be able to customise this on a per-class basis, and even override it
    on a per-instance basis, to allow the name to display as:
    	1) full name
    	2) nothing
    	3) portion of the full name
    		a) left most part only
    		b) right most part only
    	4) some other identifier (such as IP name, Ethernet address, DECnet
    		Phase IV node name or address, etc.)

    
10 - Iconic Map: Not able to display non manageable objects 

     Issue detail:  Even if MCC could not manage the Cabletron Hub the 
		     customer wanted to be able to show it on the map,
		     so he could have a complete representation of his 
		     network.
    
    You will be able to do this in v1.2


11 - FCL: Need to be able to set alias (synonym) for any object (ie:Bridge 
     and Stations

    You do have some capabilities already, with DNS and MCC.
    For example, with DNS you can assign a synonym.
    With MCC, you can use SET DEFAULT ENTITY to establish a default entity
    	to apply to future commands, such as:
    		USE DEFAULT ENTITY NODE4 FOO
    		SHOW ALL COUNTERS		(to get NODE4 FOO's counters)
    		SHOW CIRCUIT * ALL COUNTERS	(to get counters for 
    						 NODE4 FOO CIRCUIT *)
    
    In addition, we have ideas of providing an additional MCC default
    mechanism in a release after v1.2 to allow you to specify the default
    namespace directory. This will be useful when dealing with (otherwise
    quite long) DNS names. Thus we might implement something like:
    		USE DEFAULT NAMESPACE DIRECTORY DEC:.lkg.bridges
    so that future DNS names will be looked up in the bridges subdirectory.


12 - Alarms: Creating alarms is hard and inconsistent

    Yes, you are quite right - this is an area that has received and will
    continue to receive much scrutiny. We'd like alarm creation (and all
    that entails) to be as simple and straightforward as possible).
    
    Our approach, so you understand it, has been to provide an extremely
    powerful general purpose capability. Now our attention needs to be
    placed on making it more usable and user-friendly. Expect to see major
    improvements in releases after v1.2

13 - Alarms: Need wild card support

    Agreed - this is on the list to do after v1.2


14 - Alarms: Limit for # of alarms ????????????
    
    Agreed - we have provided some of this information in the past and we
    can always do better.
    If you have some specific suggestions for case you would like us to
    document, please let us know - no promises, but it will give us a feel
    for what is needed by our customers.
		     
15 - Alarms:  Could not create an alarm for "Designated router address" 

    Alas, this is a current restriction and will not be lifted in v1.2.
    It's on the list for after v1.2


16 - Historian: Need wild card support for SHOW RECORDING

    We clearly understand the need.
    Partion=* is supported in v1.2
    Child entity wildcarding (NODE4 FOO CIRCUIT *) works since v1.2
    Global entity wildcarding (NODE4 *) works by the PM expanding the
    	wildcarding - hence it does not do "the right thing" for the user.
    	We know how we'd like to fix this, but it requires platform changes
    	so won't happen till after v1.2
    
    Also on our list of things for after v1.2, is a LIST RECORDING
    directive to show all recordings for a given domain.

17 - Exporter: Case sensitivity of Exporter to the Entity name 

     Problem detail:  A known bug. 
    
    Use of a DNS name is, indeed, case sensitive. However, things like
    DECnet Phase IV nodenames do work properly, we believe.


18 - Exporter: Need wild card support for SHOW EXPORTING

    Same as #16


19 - Exporter: Not able to export the Recorded data from the MIR
 
     Problem detail: Known bug.
    
    Fixed in v1.2

20 - Exporter:    Want to have an "archive" option in addition to "PURGE" 

    This is on the list for future work

21 - Reports: No Reports available for Bridge 

    Please would you indicate what reports you'd like - and we can see
    what we can do.
    
22 - Time:  Syntax is confusing and inconsistent, from FCL

    There's no doubt it's confusing - the result of taking what is allowed
    internally, and making it available to users, without the benefit of
    translating the capabilities into something usable. We do need a
    simpler way for the user to specify time - even I get confused!!!
    
23 - Time:  Using Time widget in Iconic Map is difficult 

    As in 22, the IMPM needs some attention too - there have been some
    improvements in v1.2, but we probably need to do some more work here.

24 - Error message:  confusing and misleading, at best!

    Please provide your info to Steve Jong (WORDY::JONG)

25 - Efficiency:   Run alarms more efficiently

    Frankly I don't know how to respond to this - anyone else?

26 - The "Ethernim convert utility" did not create the bridge and stations 
     com files!

    I don't know why this happened - anyone else?

27 - Iconic Map: Could not move a group of entities

    This is on the list of future work for after v1.2





Summary:

	This was my 3rd DECmcc installation & setup  and it still was quite
	painful!! 
    We apologise - but thank you for persevering!
    
    
    		I tried to make it as easy as possible for the customer,
	but there is only so much that can be done!
    Agreed.

        I know there has been a lot of good work put into this product,
        and I personally believe it has great potentials; but  in addition
        to bug fixes, we need to make it easier to use and a lot mor  user  
	friendly,  before it becomes a popular and competitive product.
    Well, usability has been a major concern with v1.2 (along with adding
    "necessary" features). There is a delicate balance between new features
    and usability. We are continuing to work hard in this area and
    appreciate your support and patience - especially as you have to
    represent us to our customers. 
    Thank You!

    Colin Strutt
    DECmcc Technical Leader

Hi,

	My name is Thien Doan working as network consultant in the same group
	with Mahnaz Mehr. Since she has brought out the comments from her
	customers, i will do my part to express customers comments that I have
	received in the past few months. My customers are the many large account
	that we have such as,

		AECL, Canada
		Hershey Chocolate, PA
		Lee County Gov't, FL
		GE, NY
		CORNING, NC

	...... and a few more.

	The list of my customers comments pretty much identical to the one
	that was provided in 0., plus a few more. In general, DECmcc is NOT
	as user-friendly ( or network manager-friendly) as the customer has
	expected. Yes, it's a complex system but it should allow the users
	to set it up and using it with minimal frustrations.

	Out of many, the most common problem is the setting of the namespace
	for MCC use.This is should be clearly written in a detailed document
	with samples of case-study to minimize the confusions and pains.
        I have posted several notes regarding this topic, please let me know if
	we can provide any help in putting this document together since we have
	some experience/recommendations from the real-world network managers.

	I also strongly agreed to Mahnaz in the following issues:
		
	1,2,3,5,6,9,12,16,17,18, and 19.

	I will be adding comments from customers as we continue to provide
	DECmcc-consultancies to our customers.


	
Thien Doan
Network Consulting Group

	
	

Re .1:

Colin,
                              
	In return I like to thank you for taking the time and responding
	to every issue. For people like me out in the field it means
	a lot to know that someone really cares to listen to our feedbacks;
	it makes thing that much easier...

>>  This sort of information is very useful to us in development - we are
>>  trying hard to build the best product we can, but you will appreciate
>>  there is a fine line between features/functions and things like sleep :-}
  
	I know. Since I have been working with DECmcc, I have got to know 
	some of the engineers over there and I know how hard everyone 
	works.....We all appreciate it! 


	I have some clarifications and follow ups on few of the issues.

RE: issue #1:
>>	Is it that we did not explain adequately how MCC uses the name space
>>	or is it a more general problem that we haven't explained how to use
>>	2  naming services?
 
	Frankly both. But perhaps mostly the first one! There is no document 
	that explains how MCC uses DNS. Is there? Answering questions like:
	What directories are used by what modules? where the directories 
	can/must reside in DNS?  what are the backtranslation directories 
	used for exactly? why the .MCC_Bridge_BackTranslation and 
	.DNA_BackTranslation &.....have to be at the root, is it MCC 
	restriction or OSI or DNS?    (neither I or customer are or should 
	be OSI or DNS *experts* to use MCC!) What if the customer buys 2 
	or more DECmcc, (2 DNS servers, 2 clearinghouses and one namespace)? 
	-which is similar to Easynet's case- What are do's and don'ts then?etc. 
	If there is such a document, please give me the pointer to it.

	Further, we (Digital) emphasis on "NameSpace planning". So the 
	customer goes and plans its namespace. But then we tell them, No! you 
	actually can not do it that way, cause MCC doesn't let you!!
	Other products such as RSM and DFS don't have any DNS directory 
	location restrictions; and that is what Glaxo has been using DNS for. 
	So to customer it is a MCC problem!
	Now, I understand that it is possible that this could be a Phase V 
	restriction (is it?) and if it is, we might hear complains about 
	that too!!
	


RE: issue #5. Cabletron Hubs

	Let's put it this way; the customer was under impression that
	he will be able to register his Cabletron hubs and do some "show" 
	and "test". And when it didn't work he was disappointed. That is all.
	Frankly I do not know much about Cabletron Hubs. But I do not
	assume there is anything wrong with Ethernet AM. Sorry if I implied
	that. I was just wondering if there is a list available as to
        what devices can and can not be managed/registered by Ethernet_AM.
        So the customer's expectation is set properly from the beginning.
        May be this is not a MCC engineering issue; but a field person like
	myself wouldn't know what works or doesn't work either until I 
	go to customer site (we certainly don't have these devices in house) 
	and the customer has been sold on the "Multivendor managability"!
 
	Now, since I wrote the report, in Ethernet AM documentation, under 
	the chapter titled: 
	"Attribute Descriptions"... "This chapter describes the attributes 
	for the station entity." !
	I found a table with the title "Ethernet Device implementation Types". 
	Could you expand on what that is? Is this the list of all, 
	devices that work with Ethernet_AM? or...?

	In any case, now that SNMP AM V1.1 is available this issue might 
	not be as important, cause many of the private MIBs are included 
	(I have that list) with SNMP AM and others can be developed.

        ....you asked for more clarification.... :-)


 

RE: issue #9: Names are too long on IMPM. Want to be able to use the synonym

	Assuming that all these issues will get priority points as they 
        are raised by more and more customers, I like to say this is one 
	of the issues that has been brought up by every customer. They 
	really don't like it!
 


RE: issue #11: Need to be able to set alias (synonym) for any object 

	What you suggested, is helpful if one would want to do several
	commands on the same entity. But if one is going to look at 
	different entities another mechanism, such as what is planed for
	future releases is required. It would have been nice to have it
	at V1.2.


	
RE: issue #14: Limit for # of alarms ????????

>>  	Agreed - we have provided some of this information in the past and we
>>  	can always do better.

 	Is this info documented somewhere? could you give me the pointer?

>>  	If you have some specific suggestions for case you would like us to
>>  	document, please let us know - no promises, but it will give us a feel
>>  	for what is needed by our customers.

	The limit for the # of alarms that can be handled by a system 
	such as what is recommended in the SPD: 		
		A 3100, with RZ55, with 32 meg of memory; 
	Plus default alarms polling values:
		Poll every 15 minutes...
	
	This then need to be expanded considering Historian and Exporter 
	polling.............

	Overall we need much performance and sizing information. It would 
	be very helpful if DSTEG and/or NPACE   performed some tests in 
	this area, and make the results available to everyone.
    


RE: issue #17: Case sensitivity of Exporter to the Entity name

>>  	Use of a DNS name is, indeed, case sensitive. However, things like
>>	DECnet Phase IV nodenames do work properly, we believe.
 

	In case of exporter, I could bet that I saw the problem caused 
	with Ph IV nodename! This customer doesn't even have Wave 1 (if that 
	is what you mean?) I'll try to look into it again!



RE: issue #21:  Reports: No Reports available for Bridge

	I did not nail down the customer on this, but what I could 
	think of top of my head that would be useful:
		
		- Line Utilization Reports
		- Report including Bridge Filtering data 
		- Error reports

	Any one else?



RE: issue #22:  FCL Time Syntax is confusing and inconsistent

	Don't mean to be pushy!! :-) But would there be improvement in V1.2?
	Would the documentation be corrected?



RE: issue #26:  

	I can't expect much on this one since even I can not recreate the 
	problem;....except some error message would have been helpful.



	By the way, thanks to all of you for all the fixes in 1.2 
	(issues #6, 8, 10, 16, and 19. Plus others not discussed here). 

	And the rest, hopefully soon :-) ...  when? :-)  just kidding!

	I will continue to provide the customer feedbacks, as we all agree 
	they are the most important, and I am sure it will help in 
	prioritizing the issue resolutions.

Thanks again,
Mahnaz

     RE: Note 1685.3 (MEHR::MEHR)
>
>    Now, since I wrote the report, in Ethernet AM documentation, under 
>    the chapter titled: 
>    "Attribute Descriptions"... "This chapter describes the attributes 
>    for the station entity." !
>    I found a table with the title "Ethernet Device implementation Types". 
>    Could you expand on what that is? Is this the list of all, 
>    devices that work with Ethernet_AM? or...?

 Any device that responds to a REQUEST-ID (MOP V3 or MOP V4) will return,
along with assorted other things, a field indicating what type of device
is responding (e.g. "Vitalink TransLAN 350 NPC25 Bridge"). 

 The possible (enumerated) values of this field are listed in the
table mentioned above. 

						Chris 

    Let me respond to some of your points in .3
    
RE: issue #1:
    On explaining DNS name spaces to MCC customers - we had planned to work
    on that during v1.2, but for some reason it never happened. Partly as 
    a result of your input, I asked again for this information to be put
    into the documentation. I'm pleased to report that a tech writer is
    working on this right now - so we should expect information to be
    included in the final v1.2 doc set, thus benefitting all customers.
    
RE: issue #9: Names are too long on IMPM. Want to be able to use the synonym
    We hear you.
    
RE: issue #11: Need to be able to set alias (synonym) for any object 
    Clearly it would (have) be(en) nice in v1.2. 
    
RE: issue #17: Case sensitivity of Exporter to the Entity name
    Any additional information you can provide to help us diagnose the
    problem would be helpful.
    
RE: issue #22:  FCL Time Syntax is confusing and inconsistent
    At this stage of v1.2 development, it seems highly unlikely that we
    will have the time to define and implement changes to the time syntax
    in either the FCL or IMPM. Also, there are probably other areas (such
    as ease in setting up alarm conditions or getting better names on the
    icons) that are of higher priority and used by more people.
    
    
    
    Hopefully other people will provide answers to other points (as Chris
    did for issue #5 in reply .4)
    
    Thanks for the continuing dialogue.
    
    Colin

re: Issue # 14 - Alarms: Limit for # of alarms ????????????
>>
>>
>>  Problem detail: Every time that this subject has been raised internally,
>>		    the response has been "It depends". This does not
>>		    work with the customer! We need guidelines.
>> 
>>  Recommendations: Engineering must provide guidelines, with "SPD's Minimum  
>>		     Recommendations" (a 3100 with RZ56, 32 meg) and the 
>>		     default polling values (ie: every 15 minutes, etc - They 
>>		     are in the documentation!)
>>

	I fully  agree  with  the  recommendation  based  upon  the min
	configuration.   The  DSTEG  group  is  doing  performance  and
	capacitiy characterizations and measurements.    The goal is to
	be able to have customers  or  firld  people  fill out a simple
	"profile"  of  their networking needs (ie  number  of  objects,
	frequency of polls, number of events, etc.)  and  have a simple
	table  or  other  process  to  determine the hardware  platform
	needed.

	Stay tuned, we're listening and working on it.

	JCE

    Issue 15, designated router changes.

    This is one of many side effects of not having a model of Routing
    layer. DECmcc really needs that as a separate module ( FM ? ).

    The "retargeting" in V1.2 is really a terrible kludge to go around that
    problem ( person setting up MCC "models" Routing, computers should do
    it). 

    There are many other routing problems that one cannot alarm on just
    because we don't model routing. 

    				regards,	
    					Wlodek