On 14/12/2016 14:09, Andy Bierman wrote:
On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <m...@tail-f.com
<mailto:m...@tail-f.com>> wrote:
Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>> wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue <mer...@gmail.com
<mailto:mer...@gmail.com>> 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:a...@yumaworks.com
<mailto:a...@yumaworks.com>]
> > *Sent:* Dienstag, 13. Dezember 2016 18:38
> > *To:* Eric Voit (evoit) <ev...@cisco.com <mailto:ev...@cisco.com>>
> > *Cc:* Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>;
MehmetErsue <mer...@gmail.com <mailto:mer...@gmail.com>>;
> > NetMod WG Chairs <netmod-cha...@ietf.org
<mailto:netmod-cha...@ietf.org>>; NetConf WG Chairs <
> > netconf-cha...@ietf.org <mailto:netconf-cha...@ietf.org>>;
NetMod WG <netmod@ietf.org <mailto:netmod@ietf.org>>; Netconf <
> > netc...@ietf.org <mailto:netc...@ietf.org>>
> > *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)
<ev...@cisco.com <mailto:ev...@cisco.com>>
> > 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 <mer...@gmail.com
<mailto:mer...@gmail.com>> 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
<a...@yumaworks.com <mailto:a...@yumaworks.com>>
> > > wrote:
> > > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> > > <j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> 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: +49 421 200 3587 Campus Ring 1 | 28759
Bremen | Germany
> > > > Fax: +49 421 200 3103
<http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org <mailto:netmod@ietf.org>
> > > > 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
> > > netc...@ietf.org <mailto:netc...@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org <mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
