On Mon, Jun 27, 2016 at 7:53 AM, Kent Watsen <kwat...@juniper.net> wrote:
> [as a contributor] > > > > So, I see a strong preference for Option B which is all very logical, as > Acee points out. But Option B I see as being a fundamental change to > RFC6241, so if the netmod WG takes that decision, then it is stamping on > the netconf WG. Perhaps the WG should be merged, now that 6020bis is on > its way, but for the moment, I believe that changes to NETCONF need the > consensus of the NETCONF WG. > > > > I disagree. > > I have implemented NETCONF and RESTCONF and I do not see any problems with > > adding additional (optional) datastores. > > > > > > KENT > Right, but mapping the solution to drafts is key. For instance, > would there be one draft to define the conceptual model and then two other > drafts for mapping that model to NETCONF and RESTCONF? And if so, to > Tom’s point, should those drafts go through the NETCONF WG? > > > I don't have any plans to implement this new work. I expect it to be similar to the "candidate" datastore. If I do not support the candidate datastore, the added cost to my implementation is ZERO. RFC 6241 uses an extensible design for datastores. (Parameter is a container with a choice of N empty leafs). Adding a new leaf that represents a datastore is almost free in NETCONF. (a few augment statements). The <edit-config> and <commit> operations do not specify an exact validation procedure for datastores. YANG defines the validation rules for datastores. IMO YANG needs to be revised, not NETCONF. > > > > Tom Petch > > > > Andy > > > > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
