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

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> 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.
> 
> I also do not want to get rid of <get>,  It works as intended.
> It is not a problem on small devices.

Andy, the problem with <get> has nothing to do with the size of the
device.  The problem is that <get> returns two things (running config
+ operational state) in one merged output document.  This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state).  This draft proposes a
fix for this, which makes <get> less useful.


/martin



> 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
> >
> >
> >