Question regarding Vendor Config File

[Prashant Upadhyaya]

Thanks Manny and Dan, that was very helpful !

Regards
-Prashant


On Thu, Jul 23, 2015 at 9:59 AM, Manny Veloso <manny.veloso at smartrg.com>
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 <users-bounces at lists.genieacs.com> on behalf of Dan Morphis
> <dan at milkcarton.com>
> Reply-To: Community support for GenieACS users <users at lists.genieacs.com>
> Date: Tuesday, July 21, 2015 at 12:51 PM
> To: Community support for GenieACS users <users at lists.genieacs.com>
> 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 <
> praupadhyaya at gmail.com> 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
>> Users at lists.genieacs.com
>> http://lists.genieacs.com/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.genieacs.com
> http://lists.genieacs.com/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genieacs.com/pipermail/users/attachments/20150727/65b029e1/attachment.html>