On 3/26/19 01:51, Juergen Schoenwaelder wrote:
> Qin,
> 
> the idea should be to make things simpler, not more complex. Perhaps
> it is not necessary to expose N options to reset a device. Perhaps a
> simple "factory-reset" RPC which resets all relevant datastores in an
> implementation specific manner is sufficient. Why expose more details
> to the management client?

This would certainly make it simpler from the RPC standpoint.  However,
if one can <get-data> from the factory-default DSes, I still think there
is a need to know what factory-default DS maps to what other DS (in the
case where there might be multiple that are different).

Joe

> 
> /js
> 
> On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote:
>> Joe,
>>
>>
>> -----邮件原件-----
>> 发件人: netmod [mailto:[email protected]] 代表 Joe Clarke
>> 发送时间: 2019年3月25日 22:14
>> 收件人: [email protected]
>> 主题: [netmod] Question on draft-wu-netmod-factory-default
>>
>> I support the need for being able to reset a DS to its factory default.
>> However, I have a question on the current design of the model and the 
>> "factory-default" DS.
>>
>> It seems to me that this is a single DS that might have been intended to 
>> reset running or startup.  However, what if I have different DSes that each 
>> have unique factory default data? 
>>
>> [Qin]:We start with a simple case, you case could be addressed by invoking 
>> multiple rpc with each rpc to allow reset a set of datastores.
>>  If I choose to extend factory-default with a new identity of my other DS, 
>> how can I indicate that the target DS will be reset to _that_ DS?  Does that 
>> make sense?
>>
>> [Qin]: In simple case, target DS will only be reset by a single factory 
>> datastore. If there is a new factory datastore could be derived from that 
>> DS, I think target DS should be changed to reset that new factory datastore.
>>
>> Or if I do a <get-data> on a factory-default DS, how do I know what other 
>> DSes does this DS pertain?  Perhaps the server will use this to reset a 
>> given DS, but how would a user know that (other than perhaps naming of the 
>> factory-default DS)?
>>
>> Maybe the module needs a mapping to let the client know what DS will be used 
>> to reset what other DS?
>> [Qin]: So your point is should we allow multiple source, multiple target in 
>> the same RPC, will think it over. Thanks.
>> Joe
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to