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

[Andy Bierman <[e-mail]>]

On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <[e-mail]> wrote:

> 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.
>
>
This "problem" exists for some new overloaded use of <get> that did not
exist before.
The <get> operation only mixes config=true and config=false. It never had
anything
to do with intended vs. applied.  IMO your proposed solution is not very
backward compatible
with simple systems that do not have delays between intended and applied.



>
> /martin
>


Andy


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