On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <rwil...@cisco.com> wrote:
> Hi Alex, > > > What you describe is close, but not quite what either of the two datastore > solutions are proposing. > > In this case, the two solutions in both proposed drafts would contain: > - intended config doesn't contain the list entries > - applied config doesn't contain the list entries > - operational state datastore contains the system created (config true) > list entries + descendant config false nodes. > > The reason why these system created entries are not in the applied > configuration is because of the requirement from > draft-ietf-netmod-opstate-reqs state that "intended config" = "applied > config" if the system has converged and all configuration has been > successfully applied. > > But, yes, the reason for allowing system created config true entries in > the operational state datastore is to solve this problem. > > I do not agree with Alex that config=true can mean "no client can ever set this value". It can only if NACM is configured to disable client write access. I understand how one might want to use server-created values in validation rules but YANG does not support that right now (for config=false). The line between server-created config and operational state is confusing at best. Rob > > Andy > > On 13/07/2016 10:49, Alex Campbell wrote: > > Isn't that exactly what the proposed applied configuration datastore is > for? > If a device doesn't allow management stations to create or remove list > entries, but still creates or removes list entries itself, then it can > publish them through the applied configuration datastore, while leaving the > intended configuration datastore empty. Operational data can be contained > inside those list entries which exist in the applied configuration store, > instead of needing a separate tree to contain it. > > - Alex > > > > > ------------------------------ > *From:* netmod <netmod-boun...@ietf.org> <netmod-boun...@ietf.org> on > behalf of Andy Bierman <a...@yumaworks.com> <a...@yumaworks.com> > *Sent:* Wednesday, 13 July 2016 4:17 a.m. > *To:* Lou Berger > *Cc:* netmod WG > *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF > YANG Model Structure > > > > On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net> wrote: > >> Acee, >> >> I personally was assuming we'd follow 3, but I'd like to understand >> the implication of 2 as I'm not sure I really understand what you're >> thinking here. Can you elaborate what you're thinking here? >> >> Thanks, >> >> Lou >> ..... >> > 3. #2 plus collapse the config (read-write) and system-state >> > (read-only) into common containers. No more branching of >> > <model-name>-config and <model-name>-state at the top level of the >> model. >> >..... > > > > I would really like to understand what problem (3) is supposed to solve. > > Most of the foo-state variables are for monitoring. > This information is useful even if the server uses proprietary > configuration mechanisms. > (e.g., the way the SNMP world has worked for 30 years) > > If you forbid separate monitoring subtrees and force the data to be > co-located > with configuration, that means the standard monitoring will not be > supported > unless the standard configuration is also supported. Why is that progress? > > > Andy > > > > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
