> On Jul 28, 2017, at 2:11 PM, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > On Fri, Jul 28, 2017 at 11:34:38AM -0700, Mahesh Jethanandani wrote: >> >>>>> >>>>> As a result of remnant configuration, the semantic constraints >>>>> defined in the data model cannot be relied upon for <operational>, >>>>> since the system may have remnant configuration whose constraints >>>>> were valid with the previous configuration and that are not valid >>>>> with the current configuration. Since constraints on "config false" >>>>> nodes may refer to "config true" nodes, remnant configuration may >>>>> force the violation of those constraints. The constraints that may >>>>> not hold include "when", "must", "min-elements", and "max-elements”. >>>> >>>> Should this be a ‘may not’ or a ‘MUST NOT’? How does one decide whether >>>> constraints will apply or not? >>>> >>> >>> Mahesh, >>> >>> you report the actual operational state - if the actual operational >>> state violates constraints, you still report it. What else would you >>> do? >> >> Then what you are suggesting is a MUST NOT. That constraints like “when”, >> “must”, “min-elements”, and “max-elements” MUST NOT be enforced in case of >> operational state. >> > > For <operational>, the constraints are likely more a client-side > utility (if at all); a client can check whether constraints are > violated and if so this can be seen as an _indication_ that the server > may be in a 'bad state'. Note that this can be a transient 'bad state' > and also note that we do not have atomic snapshots of state and hence > what the client sees may also be violating constraints due to changes > of <operational> while retrieving state. Hence, a violation of > constraints noticed on the client side remains just an _indication_ of > a possible 'bad state'. > > I think writing "MUST NOT enforced" is not helpful since what would > that enforcement be? Not reporting state that does not exist? This > will make everybody troubleshooting networks cry. It is essential to > see the truth and not a beautified view of the uglyness if you > troubleshoot a network. Or do you have a different idea what > 'enforced' would mean? If we do not define 'enforced', then saying > 'MUST NOT enforced' is somewhat pointless. (This is very different > from configuration datastores where we can reject edits if they > violate contraints; we can't reject operational state.)
Juergen, I am putting on an server implementors hat and wondering how to parse the statement - The constraints that may not hold include "when", "must", "min-elements", and "max-elements”. As you suggest, the server cannot ignore operational state or not report it. In essence the server is not “enforcing" the must statement even if it exists. It ignores it and all the other constraints when it reports the operational state. The client may, as you suggest “enforce" the constraints if it chooses to. Although, there also what does it mean for the client to not report something from the <operational> that the server has reported? It is after all a state, as you rightly point out. Constraints therefore have no meaning in <operational> datastore and SHOULD be ignored. How about saying something to that effect? Saying “may not” is at best ambiguous and at worst confusing. Thanks. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> Mahesh Jethanandani mjethanand...@gmail.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
