The fact that a draft has been adopted by a WG does not mean it will get finished and published as a standard. I have seen documents dying, I have seen entire WGs dying.
So do the client/server/crypto/... configuration modules need any special handling by the server or not? If the answer is no, we can close this specific discussion thread. /js On Wed, Mar 29, 2023 at 02:57:46PM +0000, Kent Watsen wrote: > > Perhaps Kent can help us by summarizing why he believes copying is > > needed, i.e., why lazy references by name do not work for credentials > > stored in TPMs. > > The truststore and keystore use-case entails the following concepts from > the system-config draft: > > - Inactive Until Referenced > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-inactive-until-referenced > > - Configuring Descendant Nodes of a System-defined Node (keystore draft > only) > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01#name-configuring-descendant-node > > There is no inherent desire to copy these system-defined nodes into > <running> (nor in their entirety). The *published* version of those two > drafts only say to do so now because 1) that text was written before > system-config's originating I-D existed, 2) to ensure, e.g., "mandatory > true" nodes in <running> would exist, and 3) because that text hasn't > been updated since the system-config draft was adopted. > > Rob raised a very good point in his recent AD-review that these > sections should not say that system-defined nodes have to be > copied into <running>, so as to leave the door open for lazy > referenced to the <system> defined nodes. > > Additionally, these sections define behaviors & mechanics about the > immutability nature of the data, when really such should be defined > only in the system-config and immutable-flag drafts. That said, I > don't want to introduce a normative reference to those drafts that > would result in a MISREF. > > Kent > > > > Concerning the larger discussion about validation of running vs > > validation of intended: During NMDA developed, it became clear that > > some not quite relevant NETCONF implementations do actually validate > > intended when you asked them to validate running. And what happens > > between running and intended is not covered by any standards as of > > today. Is this bad? In a way yes and no. It is bad because some > > vcendors may read this as an invitation to do things that really mess > > up a client's expectations but it is perhaps also good since the > > distinction acknowledges reality. > > > > The discussion around system config is old (much older than the I-D) > > and this is a grey area and I assume that every bigger server has some > > places somewhere where it "cheats" a bit to deal with the problem. > > There is the option to just leave it like that, i.e., to trust that > > vendors will understand to not go over board with magic system config > > "cheats" or to work out solutions that may introduce another datastore > > or solutions to tag config in running that is not really under the > > control of a client (immutable flags play in here and perhaps the WG > > needs to discuss whether really both a system datastore and immutable > > flags are needed - at the end immutable config is coming from > > somewhere). > > > > The only lazy binding mechanism we have is to refer to resources by > > name. If the name resolution does not work out, the relevant config is > > not applied. This kind of works if data models are designed for it but > > this adds complexity to the modeling process. > > > > /js > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://constructor.university/> > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
