Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <[e-mail]> wrote:
>
>> Hi Andy,
>>
>>
>>
>> > This architectural change needs to be implemented in various protocols.
>>
>> > I am not sure a 6241bis is the best approach because it is not clear
>> which
>>
>> > servers really need to implement the revised datastores.
>>
>>
>>
>> I agree fully. This is the reason why I wrote in my mail:
>>
>>
>>
>> >> - a new protocol- and language-independent standard document (RFC XYZ)
>> defining the generic datastore concept and framework and describing its use
>> (based on and following the DT solution draft),
>>
>> >> - a RFC6241bis draft removing the current datasore concept
>> specification, and getting rid of well-known issues e.g. with the <get>
>> operation,
>>
>>
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup from RFC 6241.
> IMO the new datastores can be defined in a new document that does not
> redefine the existing datastores.

As for candidate, it is optional and we all know that it is quite
problematic if concurrent access of multiple clients is
possible. Therefore, it would IMO be a good riddance.

Lada

>
> I also do not want to get rid of <get>,  It works as intended.
> It is not a problem on small devices.  It is not a problem on large devices
> if
> sufficient filtering is used.  It does not differentiate between intended
> and applied config
> or understand different types of config=false nodes.  Use a new operation to
> add these features.
>
>
>
>
>
>
>> Mehmet
>>
>
>
> Andy
>
>
>
>>
>>
>> *From:* Andy Bierman [mailto:[e-mail]]
>> *Sent:* Dienstag, 13. Dezember 2016 18:38
>> *To:* Eric Voit (evoit) <[e-mail]>
>> *Cc:* Ladislav Lhotka <[e-mail]>; MehmetErsue <[e-mail]>;
>> NetMod WG Chairs <[e-mail]>; NetConf WG Chairs <
>> [e-mail]>; NetMod WG <[e-mail]>; Netconf <
>> [e-mail]>
>> *Subject:* Re: [netmod] [Netconf] WG adoption poll
>> draft-nmdsdt-netmod-revised-datastores-00
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) <[e-mail]>
>> wrote:
>>
>> I support adoption, and like Mehmet's thinking as well.
>>
>> Also worth focusing on is transport protocol independent yang filtering.
>> So along with how to frame get operations against one of the datastores,
>> how do you know which subtrees/nodes should be included/excluded.
>>
>>
>>
>>
>>
>> This architectural change needs to be implemented in various protocols.
>>
>> I am not sure a 6241bis is the best approach because it is not clear which
>>
>> servers really need to implement the revised datastores.  Since RD is
>> purely optional
>>
>> to implement, it should not obsolete 6241 in any way.  It should be
>> possible
>>
>> to add new operations and/or new parameters to existing operations without
>>
>> needing to redefine what is already there.
>>
>>
>>
>> The new protocol features need to explain how to include/exclude subtrees.
>>
>> IMO we should only support YANG defined data.  This allows the solutions
>>
>> to be generalized and reusable across protocols (e.g., using YANG
>> extensions).
>>
>>
>>
>>
>>
>> Eric
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>
>> > From: Netconf, December 9, 2016 7:49 AM
>> >
>> > Hi Mehmet,
>> >
>> > I think I could just sign your text at the bottom.
>> >
>> > Lada
>> >
>> > > On 9 Dec 2016, at 13:25, MehmetErsue <[e-mail]> wrote:
>> > >
>> > > Hi All,
>> > >
>> > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
>> adopt and
>> > finalize the DT draft in NETMOD WG, which I still support.
>> > >
>> > > I believe the bigger issue is to agree on a plan concerning the
>> related work
>> > and the re-organization of existing standards. As a matter of fact this
>> plan will
>> > lead to updating the charter of two WGs and the work we are going to
>> start.
>> > >
>> > > I see the DT document as a datastore solution proposal. There are
>> different
>> > gaps and issues which still need to be addressed and the solution
>> proposal
>> > needs yet to be discussed and finalized. The document is providing
>> information
>> > on the history, explaining the need for a generic solution as well as is
>> discussing
>> > different scenarios. As such I believe the datastore solution proposal
>> from the
>> > DT should be published with the intended status Informational RFC.
>> > >
>> > > Based on the finalized and agreed datastore solution we should do
>> different
>> > updates to existing documents in NETCONF and NETMOD WGs. With this
>> > action we can also fix well-known issues.
>> > >
>> > > Concerning the NETCONF WG I would see it as valuable if we develop:
>> > > - a RFC6241bis draft removing the current datasore concept
>> > > specification, and getting rid of well-known issues e.g. with the
>> > > <get> operation,
>> > > - a new protocol- and language-independent standard document (RFC XYZ)
>> > > defining the generic datastore concept and framework and describing
>> > > its use (based on and following the DT solution draft),
>> > > - adding potential extensions to RFC6241bis (following the DT draft
>> > > and with a normative reference to RFC XYZ),
>> > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
>> > > draft and with a normative reference to RFC XYZ),
>> > >
>> > > Concerning the NETMOD WG I would see it as valuable if we develop:
>> > > - RFC7950bis deleting protocol-dependent details and specifying the
>> > > datastore usage with YANG on a generic level (with a normative
>> > > reference to RFC XYZ),
>> > > - adding potential extensions to RFC7950bis, e.g. concerning the
>> > > proposed <notification> element,
>> > > - possibly an RFC 6244bis to describe architectural aspects. However
>> RFC6244
>> > is Informational and a RFC6244bis would be still Informational. I'm not
>> sure
>> > whether this is really necessary. The DT proposal does already describe
>> such a
>> > solution and can be seen as an update to RFC 6244.
>> > > - RFC6087bis giving guidelines on how to use YANG with the new
>> datastore
>> > concept.
>> > >
>> > > Referring to Lada's proposal concerning the spin off document from
>> > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
>> > provided in the corresponding protocol RFCs, i.e.
>> > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
>> > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
>> > >
>> > > Hope this helps as a starting point on the way to a good plan.
>> > >
>> > > PS: As Benoit suggested some time ago we might also consider to rename
>> > NETCONF WG as it is not only on NETCONF protocol anymore.
>> > >
>> > > Regards,
>> > > Mehmet
>> > >
>> > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman <[e-mail]>
>> > wrote:
>> > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
>> > <[e-mail]> wrote:
>> > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
>> > > >
>> > > > >
>> > > > > I disagree that the datastore model is a protocol specific aspect.
>> > > > > I consider datastores an architectural component binding data
>> > > > > models and protocols together. In fact, the 'traditional'
>> > > > > datastore model
>> > > >
>> > > > I would agree with this if datastores were a general concept in
>> YANG, but
>> > the revised-datastores draft explicitly introduces the "intended" and
>> "applied"
>> > datastores that may be irrelevant to other protocols using YANG, and even
>> > needn't be used in all NETCONF implementations. I wouldn't call this "an
>> > architectural component" of YANG.
>> > > >
>> > >
>> > > An architectural component of this new management framework (that does
>> > > not have a name). The fact that not all protocols may expose all
>> > > datastores is IMHO not a reason that the datastore model is not an
>> > > architectural framework.
>> > >
>> > > > If you are saying that it will have nontrivial impact on YANG, I
>> would like to
>> > see it explained in sec. 6.3. Without this information I am quite
>> reluctant to
>> > agree with the adoption.
>> > >
>> > > An operational state datastore has implications how one writes data
>> > > models. It may not directly affect YANG itself but surely the usage of
>> > > YANG.
>> > >
>> > > > See above - architectural aspects need to be relevant to all
>> protocols.
>> > >
>> > > Yes, but relevant to all protocols does not mean every protocol needs
>> > > to expose say all datastores. But every protocol should be clear about
>> > > how what it exposes relates to the architectural framework.
>> > >
>> > >
>> > >
>> > > There is a "current solution" consisting of hard-wired object
>> > > semantics (e.g., ifAdminStatus and ifOperStatus).  This solution does
>> > > not require special protocols or datastores, but it is being replaced
>> by a
>> > generic solution.
>> > >
>> > > If the "generic" solution requires special procedures which differ on
>> > > each protocol, then it might end up be worse than the hard-wired
>> solution
>> > that works on every protocol.
>> > > So I agree with Juergen that this is primarily an architectural issue.
>> > >
>> > >
>> > > /js
>> > >
>> > > Andy
>> > >
>> > >
>> > >
>> > > --
>> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> > > Fax:   [phone]         <http://www.jacobs-university.de/>
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> > > --
>> > > Cheers,
>> > > Mehmet
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Netconf mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netconf
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C