Andy Bierman <[email protected]> wrote: > Hi, > > I like this draft -- even more than I like datastores. > Looks like some thought went into the terminology section. > > One minor concern: > > sec. 4.1: > > On a traditional NETCONF implementation, <running> and <intended> are > always the same. > > > The intended datastore is completely proprietary. > Is that part of the architecture or are there any plans for the standards > to have some purpose for the intended datastore?
The idea was to have a defined place for the "intended configuration" in the common architecture, even if there are no current standard mechanism that affects it. If such mechanisms are added, they can be defined in terms of the datastores in this architecture. > I want to support 2 datastores that don't fit your descriptions very well: > > factory: read-only config representing the values that a factory reset > would use. Allows copy-config to support a factory config reload. > > library-config: needed as a bootstrap datastore with the module/bundle > configuration. Like the ietf-yang-library, but the config does not exactly > match > the structure of the YANG library. > > Can vendors add datastores to a server? > Or is this IANA-registered? And/or hard-wired in RFCs? The draft has a section about what is needed to define dynamic datastores. IMO this should be generalized to any datastore. The datastore names are identities, so vendors can define their own datastores. Currently there is no explicit mechanism for a server to advertise which datastores is supports, other that the advertisment of features in "ietf-datastore". Maybe we should add an explicit list of supported datastores (but this will be protocol-dependent, since some protocols might not expose all datastores). /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
