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

[Robert Wilton <[e-mail]>]

On 14/12/2016 14:09, Andy Bierman wrote:
>
>
> On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Andy Bierman <[e-mail] <mailto:[e-mail]>> wrote:
>     > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <[e-mail]
>     <mailto:[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.

I've been informed (repeatedly ;-) that <running> has always only ever 
meant intended configuration.  I.e. that it is reasonable behaviour for 
a system to accept config into <running> and then fail to apply that 
configuration for some reason (daemon is unavailable, linecards is down, 
resources have been exceeded, programming error, etc).  If this 
interpretation is correct then the NETCONF <get> operation is poorly 
defined because it is mixing "intended configuration of the system" 
along with "actual running state".

What NETCONF <get> should really be providing is "actual configuration 
in use by the system" along with "actual running state".  Of course this 
is effectively what the new operational state datastore is defined as 
containing.

If I understand it correctly, I think that Andy's point is that for lots 
of systems "intended configuration of the system" and "actual 
configuration of the system" are effectively one and the same thing.  If 
this is the case then it should be easy for clients/servers to migrate 
from an existing <get> request to a <get-data> request that just returns 
the data from the operational state datastore.  It sounds like the 
actual data returned in both cases should be the same?

Thanks,
Rob


>
>
>
>     /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]
>     <mailto:[e-mail]>]
>     > > *Sent:* Dienstag, 13. Dezember 2016 18:38
>     > > *To:* Eric Voit (evoit) <[e-mail] <mailto:[e-mail]>>
>     > > *Cc:* Ladislav Lhotka <[e-mail] <mailto:[e-mail]>>;
>     MehmetErsue <[e-mail] <mailto:[e-mail]>>;
>     > > NetMod WG Chairs <[e-mail]
>     <mailto:[e-mail]>>; NetConf WG Chairs <
>     > > [e-mail] <mailto:[e-mail]>>;
>     NetMod WG <[e-mail] <mailto:[e-mail]>>; Netconf <
>     > > [e-mail] <mailto:[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] <mailto:[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]
>     <mailto:[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] <mailto:[e-mail]>>
>     > > > wrote:
>     > > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
>     > > > <[e-mail]
>     <mailto:[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/ <http://www.jacobs-university.de/>>
>     > > > >
>     > > > > _______________________________________________
>     > > > > netmod mailing list
>     > > > > [e-mail] <mailto:[e-mail]>
>     > > > > https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > > > > --
>     > > > > Cheers,
>     > > > > Mehmet
>     > > >
>     > > > --
>     > > > Ladislav Lhotka, CZ.NIC Labs
>     > > > PGP Key ID: E74E8C0C
>     > > >
>     > > >
>     > > >
>     > > >
>     > > > _______________________________________________
>     > > > Netconf mailing list
>     > > > [e-mail] <mailto:[e-mail]>
>     > > > https://www.ietf.org/mailman/listinfo/netconf
>     <https://www.ietf.org/mailman/listinfo/netconf>
>     > >
>     > > _______________________________________________
>     > > netmod mailing list
>     > > [e-mail] <mailto:[e-mail]>
>     > > https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > >
>     > >
>     > >
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod