First, the term “YANG server” sounds odd to me.  I know what you mean, but I 
haven’t seen this defined before.  Maybe just saying a device or host is 
sufficient?

[Qin]: Right, “host”, in my opinion, is not a term used in the context of 
NETCONF, it is also usually referred to end device in many cases, I prefer to 
use device. The device should have YANG capability.

Seems like suggestions from Martin and Jürgen will sort this out.

When you talk about the datastore to be reset, you list <running>, <startup>, 
and <candidate>.  You state that each will receive the contents of 
<factory-default>.  The <candidate> DS wouldn’t need that.  I think it would 
just be zeroed out.

[Qin]: I have no strong opinion for this, <candidate> is also part of 
read-write configuration datastores, we could reset <candidate>, but I think it 
is not recommended based on what you say.

That’s my point.  I don’t think you want to really do anything with 
<candidate>.  Resetting <startup> and for runtime, <running> would seem to be 
sufficient (modulo other DSes the system may support).


I think the RPC should reset any and all non-derived read-write datastores and 
not imply that a specific DS’s contents (i.e., the factory-default DS) is 
copied to them.  This way, other DSes would just be handled by this RPC based 
on implementation.  The <factory-default> can exist as the factory default 
contents for <startup>.
[Qin]: We have decoupled <factory-reset> rpc from <factory-default> datastore, 
since <factory-default> datastore is defined as optional datastore in the 
current version, <factory-default> content can be specified in many different 
ways, not limited to take content of <factory-default> datastore.
Also <factory-default> content is referred to preconfigured initial 
configuration that can be used to initialize the configuration of a server.
These will address your comment.

You still mention that you copy these contents as part of the RPC (or maybe I 
misread).  This is what led to my confusion.

Joe

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

Reply via email to