Best strategy to model a service when the end configuration will change in the end device when applied

[Andre Gustavo Albuquerque]

Hi,

I am wondering if there is a best practice to deal with the mapping logic when the end configuration changes when it is applied.

I can give the simple example of device local user credentials:

• For security reasons, it is very common to enable service password-encryption or similar commands in Cisco devices. The end result is that you can apply a configuration with a password in clear text but it will be coded and stored encrypted. So, the mapping logic would contain the clear text password but the end result would not.

In this case, I am not sure if the service would sync after applied. In any case, what would be the best strategy to mimic this behavior if I build a service to manage the device local user database? (i.e.: apply the configuration, reads the end result and reflect it back to the yang model)

If anyone has already done something along these lines, please let me know.

Thanks

[vleijon]

For a lot of the cases you mention we have what is called "secrets handling", so if you have an ios device that has automated encryption NSO will save the encrypted secrets in a special table and use those for comparison purposes. There are sometimes ned-settings for this as well.

There are some options here, you can certainly do a sync-from if you want, especially if you don't want the unencrypted password exposed in NSO, but for some of the big NEDs this ought to just work without bringing you out of sync.

[Andre Gustavo Albuquerque]

Thanks for the response, but I was referring to the mapping logic of a service yang model to a device yang model.

You have just described the process of building the device yang model from the device native configuration, which should be handled by the NED.

The best approach to build the mapping logic for the service in such cases is still unclear to me.

Cheers