Rob, Thank you for the effort, it¹s really useful.
Gert On 2016-15-01 19:21, "netmod on behalf of Robert Wilton" <netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote: >Hi, > >Over the last week or so there has been quite a lot of discussion and >longs threads regarding applied configuration and system-controlled >entries. > >To try and bring that thread to an explicit conclusion I have tried to >summarize (at least from my POV) where I think these discussions have >reached, hopefully get feedback from others, and make any updates to the >requirement draft that may be required. > >I think that there were broadly three different threads to the >discussions: > > >1) Lada requested that the requirement text in requirement 1D be >loosened so that the applied configuration schema doesn't have to be a >subset of the intended configuration schema. The aim of the loosening >of this text is to allow system-controlled entities (such as interfaces >that always exist) to be put in the applied configuration. > >Personally, I'm opposed to this change, since the relationship between >intended and applied was explicitly discussed and it was confirmed that >the schema for the two was expected to be the same so that they can be >easily compared. > >Is there any other support for loosening the requirement text as per >Lada's suggestion? Gert> (1) In my response to Lada, I expressed the view the text in 1D allowed the use case he had in mind. In his case there is no intended config pushed to the server, hence there is no "corresponding applied configuration². That said I don¹t see the need to change the wording but would argue that Lada¹s use case is covered by the current text (see also (2)). > > >However, there is still a related corner case that hasn't been raised >yet, but may be useful to consider, which is where a systems default >setting differs from the one defined in an associated YANG module. > >To take an example, a YANG module for LLDP might use a global >P-container to indicate whether the LLDP protocol is enabled on the >device. However, for a particular vendors device, the default behaviour >for LLDP may be that is enabled globally. Gert> indeed a valid scenario > >If a operator is configuring the device via YANG and pushes down their >initial config (using a config replace semantics to replace the entire >existing configuration of the device), and the config that is pushed >down doesn't include the P-container to explicitly enable LLDP then I >think the expectation is that the device should disable LLDP when >processing the config request (even though it the device's default). >Further, all the time that the device doesn't match the implicit >intended p-container node state (of non-existence), it should report an >applied p-container node to indicate that LLDP is actually enabled on >the device even though the intended behaviour is that it be disabled. > >In essence I'm saying that the intended configuration includes all >explicit data nodes, any default node values in scope, and also any >nodes in scope that have an implicit schema default value of >non-existence (i.e. the feature is not enabled). > >Do others agree with my interpretation of intended configuration for >this scenario? Gert> (2) Perhaps we should to distinguish the modelling aspect from the usage aspect: -modeling: Whatever the model contains as applied state should also modelled as intended state and should also include default values (guess this is in line with your understanding) -usage: A client may not make full use of intended configuration for a given server and could rely upon default values in the applied config. In that case the intended config (in use) covers a subset of the applied config (see (1)). > > > >2) Separately, there has been a suggestion from Lada (also supported by >Gert?) such that the applied configuration always explicitly reports >default values (e.g. like the report-all option in RFC 6243). > >I generally support this suggestion because I think it solves the >problem that a server can't indicate a difference between a leaf not >being configured at all and leaf that is configured with the default >value. However, I would see it that the YANG schema for both intended >and applied configuration is still the same, and hence I don't see any >direct need to modify the requirements draft. I think that all three >proposed solutions are able to support this, and hence this issue can >probably be deferred until a general solution approach has been agreed. > >Is anyone against deferring this discussion until a general solution >approach has been agreed? Gert> too many negations in this phrase to answer with a simple yes or no :-). I am in favour of deferring > > > >3) Finally, there has been some proposals on the exact semantics of how >the config handling should work, but this has been agreed to be deferred >until the basis for a solution has been chosen. Gert> also here I am in favour of deferring > >Rob > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
