Thanks Manny and Dan, that was very helpful ! Regards -Prashant
On Thu, Jul 23, 2015 at 9:59 AM, Manny Veloso <[email protected]> wrote: > The vendor config file in TR-069 represents different things depending > on the model and the vendor. > > Are you talking > about InternetGatewayDevice.DeviceInfo.Vendor-ConfigFile? Or > IGD.DeviceConfig.ConfigFile? Or config files in general? > > In general, the config file is a static list of device parameters. A > config file that’s pushed to 50 devices will make all the devices the same, > mostly*. > > In TR-069, you can tell the device to download and upload the config > file. Downloading the config will replace the current running configuration > with whatever configuration is in the config file. Devices will generally > totally overwrite the running config with the config file settings (ie: > generally the device won’t merge the running config and the downloaded > config - it’ll use the downloaded config as the running config, and throw > the old running config away). Uploading the config tells the CPE to POST > the config file to somewhere you specify. > > Depending on the device, you can see the config file name and some other > data in the IGD.DeviceInfo.Vendor-ConfigFile. The info there isn’t really > that useful. > > In some devices you can grab the running config file by using > IGD.DeviceConfig.ConfigFile. Theoretically you can take that and push it > back onto the device. > > In an ACS, the config file usually is a blob. > > The format is pretty much implementation dependent. In our devices it’s > the running config, but values that are default values are not in the file. > > Usually ACSs don’t manage config files, they manage settings. Settings > can be dynamic per device, which makes them valuable. Config files are > usually pushed at the factory, and contain the static plant stuff. Of > course, everyone can do things differently. I know of one customer that > generates config files on the fly and pushes them to a device via an ACS. > There are other customers who use the ACS to manage everything, and the > config file is totally generic. > > You can do lifecycle management for a config file, but at a minimum that > requires that you version the config file and have a way of getting that > version in the ACS. Then you can start using the ACS to detect when things > are out-of-date. > > As Dan says, config files are useful, but dynamic data is probably > better managed via an ACS - unless your back-end service already generates > config-file friendly output. > -- > Manny Veloso > Sr. Solutions Engineer > Smartrg.com > > From: Users <[email protected]> on behalf of Dan Morphis > <[email protected]> > Reply-To: Community support for GenieACS users <[email protected]> > Date: Tuesday, July 21, 2015 at 12:51 PM > To: Community support for GenieACS users <[email protected]> > Subject: Re: Question regarding Vendor Config File > > I can shed some light. The vendor config file is the configuration file > you upload to the CPE usually through the GUI on the CPE. The format of the > file will be specific to the CPE vendor. The config file for SmartRG (and > other Broadcom based CPEs) is an XML representation of the TR069 object > model of the device. While the older Thomson's its in ini file format. > > Currently, you have to manually tell the CPE to download the > configuration file. Be aware though, when the CPE applies the config file, > it will be factory defaulted. So if you send the config file to any CPE's > that have customers assigned to it, you will need to set the pppoe > credentials and other settings specific to your environment. > > On Tue, Jul 21, 2015 at 2:05 AM, Prashant Upadhyaya < > [email protected]> wrote: > >> Hi, >> >> I have a few questions regarding the concept of Vendor Config File in >> TR-069. >> What does it exactly represent for ACS ? >> Is it a snapshot of _all_ the parameters of a CPE at a single place (the >> root model supported by CPE as well as vendor specific extensions) ? >> How is the lifecycle of this config file managed. >> Eg. if the version at CPE and ACS mismatch, then ACS should ask CPE to >> download it. >> But how would the version typically change at the ACS itself ? Eg. should >> the ACS bump up the version everytime the operator changes some CPE >> parameter at ACS or is there some different scenario. >> Can the version change at CPE automatically and in that case, should the >> CPE ask the ACS to upload it. >> >> Basically, if somebody can shed more light on this concept in TR-069 >> from their practical experience, that will be great. >> >> Regards >> -Prashant >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.genieacs.com/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.genieacs.com/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.genieacs.com/mailman/listinfo/users
