Hi Cisco Team,

I would like to engage you in some discussion regarding the way CCA configures a system when building one from scratch, i have found some things that didnt make sense i would like to actively find out some reasoning behind such things.

1. Excessive Code being placed in the system:
   
   I finished designing a UC-500 system last night for deployment today, as per normal i go through the configuration in a txt file and check the config to make sure that CCA programmed it the way i had instructed it to. As it turned out CCA had done quite a good job at it, not like in past versions where only partial code would be put in and sometimes complete sections missing, so a good job on that. However i have noticed now that the design/engineering team have gone from one of the spectrum to the other, what i mean is that i am finding excessive code being left behind or intentionally placed into the system, such as;
   
   * Ephone Hunts: After i had asked CCA to program in a BACD it decided to include 10 extra ephone-hunt sequential for no reason, it is of my opinion this is dormant code and quite excessive and should not be left behind, for some this could make diagnosing and config analysys much harder as you have to work out at the time if this is just left behind code or if it is actually being used, it also inflates the configuration, when it really should be lean and only have in it what is required of the system functions/features.
   
   * Dial-Peers: Whilst it is so good that CCA lets you delete all the non essential or not required dial-peers, it is still leaving behind too much config that is not required, for instance, i had disabled the BRI in the Telephony Wizard i.e instructing CCA that they are not being used, however when writing the config CCA included dial-peers ALL_BRI and a Trunk Group?? What is the reasoning for this? This is excessive code and again can make for harder debugging as the BRI dial-peers will show up in the matches and can cause some confusion when diagnosing a system... Yes i understand that to TAC and other long term serving Cisco engineers this wouldn't be a problem, but iin honesty you need to think from a field engineers perspective and also from those who may not follow the Cisco straight an narrow path.
   
   
   * Ephone-DN's: After going through the Wizard and instructing it to provide me 3 digit extensions, and then renumbering those extensions to 1XX instead of the default 2XX or 3XX it uses, i checked the config after it has been written and it creates the full amount of DN's allowable as blank DN's, and to make matters worse, it had them in the 2XX range, this poses an issues in that the auto-registration would place a new phone into a different extension range so there is no way to drop ship a phone to a client if a new one is ordered, it would require remote programming if able to ensure that correct programming was in place for the new phone prior to being shipped out, but as you can appreciate this will not be the case in quite a many deployments.
   
   
2. Unable to type Hostname in a certain way:
   
   I understand and appreciate that Cisco might have certain views about how things should be done, but this should not be imposed onto the end user but more so just recommended or provided as a guide, in CCA if i want to type a Hostname such as this"UC500-CPE-01" i am unable to do so, i have to do it as either a complete word and join them together or just place three characters and then go to the CLI and change it... Is there any way this can be changed to allow the user to place in there the format in which may be a policy and or part of the network design?

There are other small inconstancies, but the two i have listed are the ones that can or have the potential to cause greater issues (No so much with the latter), but i must point out that i have always worked on the premise that Lean is good, too much configuration leads to bloating and bloating leads to problems.

Is there a way we can disucss this and how CCA could potentialy handle these scenarios?

I look forward to the discussion on this.

Cheers,

David.

(PS) Love the way CCA 2.2.1 works, it is a massive improvement on previous version and the Engineers and Design team should be congratz on a great job.