Hi All,
[NETMOD CCed as this is relevant to the revised DS draft] > > > > I wrote it already several times: I support(ed) Mehmet's proposal to > > > > make the revised-datastores I-D informative. The document was adopted > > > > as a Standard Track WG item although I didn't see anything close to > > > > rough consensus during the adoption poll. > > > > > > > It appears to me that there is consensus to making this a standards track > > > solution. > > > > > Where is any evidence of this? > > I think there was approval in the room in Seoul, and it is being confirmed on > the mailing list. It is correct that we agreed in Seoul to start a consensus call on both maillists for the adoption of the DT draft and executed such an adoption call. However we did not have any decision on the intended draft status in Seoul and did not have any agreement during the adoption call. I explained my concerns on the currently indicated status being standard track and did not hear any other argument. It is correct that we need a standard track document for the new DS framework - to provide a basis for other RFCs to develope. However the current DT solution draft has not been prepared as a standard track document nor it has standard relevant content. Such concept description is usually prepared as an architecture document (see example in <https://tools.ietf.org/html/rfc6244> RFC 6244). As I stated earlier I believe “a new protocol- and language-independent standard document” should be prepared defining the generic datastore framework (based on and following the concept in the DT solution draft). IMO the intended status of the DS draft is still open and subject to decide. Regards, Mehmet From: Netconf [mailto:[email protected]] On Behalf Of Andy Bierman Sent: Wednesday, December 28, 2016 6:37 PM To: Ladislav Lhotka <[email protected]> Cc: Netconf <[email protected]> Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka <[email protected] <mailto:[email protected]> > wrote: > On 27 Dec 2016, at 19:34, Andy Bierman <[email protected] > <mailto:[email protected]> > wrote: > > > > On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka <[email protected] > <mailto:[email protected]> > wrote: > > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder > > <[email protected] > > <mailto:[email protected]> > wrote: > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > >> > >>> > >>> A remote API for management applications was our original target and > >>> this is where YANG is doing well (and we apparently still have work to > >>> do to improve things). > >> > >> By "management application" I mean a specific implementation with a fixed > >> set of datastores and precise semantics. I do argue that neither RFC 6241, > >> nor "revised-datastores" nor any other *specific* setup of datastores is > >> going to work for all use cases, yet the protocols and YANG can be pretty > >> universal. > >> > >> We have already seen YANG being used in areas that are, strictly speaking, > >> not supported by 6020/7950. Rather than tolerating such uses (which is a > >> slippery slope), I would prefer to make them - within reasonable limits - > >> officially supported. > >> > > > > This is too abstract for me. What do you suggest to change in the > > revised datastore architecture? I do believe that having a number of > > well defined datastores with specific semantics is necessary for > > having interoperability. > > I wrote it already several times: I support(ed) Mehmet's proposal to make the > revised-datastores I-D informative. The document was adopted as a Standard > Track WG item although I didn't see anything close to rough consensus during > the adoption poll. > > > > It appears to me that there is consensus to making this a standards track > solution. Where is any evidence of this? I think there was approval in the room in Seoul, and it is being confirmed on the mailing list. > > Datastores allow universal concepts about managed data to be standardized > across multiple protocols. In a protocol, the datastore name serves as > an input parameter value. It needs to be normative in order for a > standards-track protocol to use it. For the protocol, the RPC parameter needs to be normative, not a particular datastore name or semantics. > > Changing standards track status never addresses real technical problems. > I do not understand your objections or alternate proposals. I think this proposal will lead to rather significant changes to the protocols and YANG, and their extent IMO isn't clear yet. For one, the draft aims at moving validation from "running" to "intended". But if "intended" is optional to implement (sec. 6.1), I don't get how validation in YANG can be (re)defined to apply also to implementations that don't have "intended". It should be possible to add new operations to NETCONF and new query parameters to RESTCONF that support the operator requirements, and still preserve existing operations. I am not in favor of rewriting operations that move the validation to 'intended'. That would not be backward-compatible so it is a non-starter. What I would like to do is to make protocols and YANG work equally well for all datastore architectures so that the protocols and YANG needn't be changed each time the current architecture is found to require adjustments. This does not make sense to me. First, I do not care about non-standard, private architectures, just the standard architecture. Applications cannot be forced to hard-wire all the details about configuration management. Let's not go back to data silo architecture. The standards need to expose the details in a common framework to enable data-driven automation tools. That means the protocols and the data models have to support a standard datastore framework. > > My Applicability Statement concerns are related to developers deciding > if a server implementation needs to expose 'intended' and 'applied'. > I would like a definitive statement like "If an intended value takes more > than 5 seconds > to become applied (due to implementation, not missing hardware), then > the 'intended' and 'applied' datastores SHOULD be supported." > > I think the definitions of the datastores apply to all servers, and the > set of new datastores is the correct and the semantics are clear. For some servers running-intended-applied is way too complicated, and good old "running" may be all that's needed. Agreed. These servers do not need to implement the new datastores. The same is true for the 'candidate' and 'startup' datastores already. Lada Andy > > > Lada > > Andy > > > > > > /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/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
