Hi Andy, > No customer would ever let us take away this tenet, no matter what RFC comes > out.
What tenet? That <running> is valid or that the representation returned to clients is valid? No one is talking about <running> (on the server) not being valid, the only nuance is in *how* the server validates <running>, which is being discussed. RFC 8342 shows that some transformations (like template expansions and removing inactive config) must occur *prior* to YANG-validation. Wouldn't it be nice to implement such features someday? Regarding "no customers", in case it helps, Juniper devices validate <running> vis-a-vis validating <intended> (after template expansion and removing inactive config), and their customers are happy. > There are corner cases where a server is executing with a <running> datastore > that does > not pass all YANG constraints and all description-stmt semantics. > > For example, there are data models with top-level mandatory NP-containers. > Loading the empty YANG module causes the datastore validation to fail. Modules should not have mandatory nodes when first set as "implemented". Such is bad API design IMO. This should be captured in RFC 8407...and, ideally, be tested for during publication process. > Our server has a mode where it will start with a bad <running> datastore > and allow an operator to fix the config. No edit-config to running or commit > will > succeed unless all validation passes (that is specified in 6241). Yep, my server does the same. > There are lots of complex implementation-specific ways to get the server > datastores loaded at runtime. > Code runs and then <running> is setup somehow. The idea that <running> must > be totally empty > unless a client has set the data seems to be an NMDA thing. > IMO it is not a good idea to make NMDA even more complicated to handle minor > corner-cases. AFAICT , nothing changes to the logic you described. Also, these are not minor corner-cases. > Andy K. // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
