On Tue, Apr 5, 2016 at 9:40 AM, Rajiv Asati (rajiva) <[email protected]> wrote:
> > 1) It would be useful to expand section 4.3 a bit more to add another > example of the tree with some specifics that cater to most of the protocols > work being done in other WGs. Something along the line of the following: > > Config (intended) > State (derived with or without applied) > Notification > RPC > .. > > > I don't know if one-size-fits-all will be that helpful. The YANG ABNF is the template for these statements. There are specific guidelines about using units, etc. > Authors of numerous YANG models could refer to the above guideline and use > it as a starting point. > > 2) It would be helpful if the guideline suggested a preference (yes, > recommendation would be better) for keeping applied state anehd derived > state together (in the same container, per each field) or separate > (containers); > There is some text already. Some aspects of YANG are left to the designer preferences. Clearly, if state data is within the config node for some functionality then it can only exist if the config exists. The ietf-interfaces module separates state because interfaces that are not in use need to be identified. In CLI they are mixed and every interface is present in "show interfaces", even if "shutdown" is the only config. Why doesn't YANG follow the CLI model? Not sure, but I guess the designers liked separate interfaces and interfaces-state containers. IMO the YANG is cleaner but probably more complicated to use. > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > Andy > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis > > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
