On Tue, Dec 10, 2024 at 12:05 PM Kent Watsen <[email protected]> wrote:
> Hi Andy, > > I do not have any objections to this draft (or any plans to implement it). RFC 7950 and 8342 are clear enough about <running> validation. Andy > NMDA never defined a "client-only" <running> datastore. > > Because there’s no such thing as a client datastore? IMO, datastores > only exist with a server. What the client gets from the server seems more > like a representation. > > > It requires that <running> MUST be valid without explaining how that > differs from RFC 7950. > > Again? This has been subject to a lot of discussion. I agree that RFC > 8342 isn’t as clear as it could've been, but it’s pretty obvious that it > meant the <intended> is subject to validation. > > > > If it doesn't, then dangling leafrefs, false must-stmt, and incorrect > when-stmt results cannot be ignored. > > They are not being ignored - where do you see that? The -10 draft adds > language specific to handling the concern around dangling leafrefs. > > > > YANG validation rules are defined in terms of config=true or false, not > datastores. > > True, and that part doesn’t change. > > > > The server is not aware if a client is NMDA or non-NMDA unless it uses > an NMDA operation. > > …or if server uses a protocol (hopefully NC/RC-next) that requires > NMDA-aware clients. > > > > It seems like a 8342-bis would be more appropriate than yet-another > optional add-on (system). > > I like the idea of an 8342-bis, but I don’t think it should block this > draft. > > FWIW, I created an NMDA-next issue tracker here: > https://github.com/netmod-wg/nmda-next/issues > > > Kent // contributor > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
