On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > > On 12/07/2016 18:05, Andy Bierman wrote: > > > > On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <rwil...@cisco.com> wrote: > >> Hi Andy, >> >> On 12/07/2016 17:17, Andy Bierman wrote: >> >> >> >> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger < <lber...@labn.net> >> 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. >> >> My personal view is that I think that it makes the models simpler, with >> less duplication. >> >> E.g. I also see that it makes it easier for a client to fetch all of the >> information associated with a particular feature in a single sub tree >> rather that needing to merge data from two separate config & state sub >> trees. >> >> > This is your opinion. > I think separate makes it easier to read, especially if the monitoring data > is relevant regardless of how associated configuration was done. > > This is easily achievable by filtering (e.g. only return config false > leaves + config true structural nodes). > > Filtering is not widely implemented or implemented correctly. IMO it is up to the data model designers how they want to organize their data. I have not heard any valid reasons why a generalized solution is even needed, let alone why separate config and state needs to be avoided. Andy > > > > >> >> 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) >> >> I thought that it was config that was originally driving YANG because >> there is already a solution for state data (SNMP). Hence, I would have >> thought that the most common case would be that YANG is used just for >> config, or config & state. So, I think that it makes sense to optimize >> models for these scenarios. >> > > > This is marketing. > Do you have any technical arguments? > > Yes, I gave them below: I don't see that merging config and state prevents > entities from only monitoring state if they wish. > > Thanks, > Rob > > > > >> >> >> 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. >> >> Both datastore draft solutions allow for system created config entries. >> So in both drafts the operational state datastore can instantiate whatever >> config nodes are necessary to parent config false state nodes. >> >> I also don't think that separate monitoring subtrees are going to be >> banned, they should be used where appropriate. It is just that it will be >> no longer be required to have separate state subtrees purely because of >> potential differences in the lifetime of config vs state objects (e.g. >> interfaces vs interfaces-state). >> >> I would be very happy if "interfaces" and "interfaces-state" could be >> merged into "interfaces" as a new/updated interfaces YANG model that draft >> models could be updated to use. I understand that would be a impactful >> change to make (but seemingly mostly on IETF models that haven't yet been >> standardized). But I hope that we are going to have to live with the YANG >> model structure for a long time, and if we still have an opportunity to >> "fix" a fairly big wart then I think that it would be good to do so. >> >> > I can't say if the pre-provisioning model in ietf-interfaces should be > generalized. > I have not seen any good general solutions for combining config and state. > > > > > >> Rob >> > > Andy > > >> >> 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
