On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <a...@cisco.com> wrote:
> Hi Andy, > > From: Andy Bierman <a...@yumaworks.com> > Date: Tuesday, July 12, 2016 at 12:17 PM > To: Lou Berger <lber...@labn.net> > Cc: Acee Lindem <a...@cisco.com>, netmod WG <netmod@ietf.org> > 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. > > > If they are meant to be supported independently, why wouldn’t they be > separate models? > > YANG features can be used and they can still be supported independently. > Thanks, > Acee > > Andy > > Why is that progress? > > > Andy > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
