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]<mailto:[email protected]>> on 
behalf of Dan Morphis <[email protected]<mailto:[email protected]>>
Reply-To: Community support for GenieACS users 
<[email protected]<mailto:[email protected]>>
Date: Tuesday, July 21, 2015 at 12:51 PM
To: Community support for GenieACS users 
<[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
http://lists.genieacs.com/mailman/listinfo/users


_______________________________________________
Users mailing list
[email protected]
http://lists.genieacs.com/mailman/listinfo/users

Reply via email to