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

[Andy Bierman <[e-mail]>]

On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <[e-mail]> wrote:

>
>
> On 14/12/2016 14:09, Andy Bierman wrote:
>
>
>
> 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.
>
>
> 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?
>
>

I do not understand the new solution because it has not been well-defined.

In the old solution, I have 2 leafs /foo and /foo-state.
I can retrieve both of these leafs at once with <get>.
I can decide if /foo and /foo-state are the values I expect.

But if I overload /foo such that it represents different semantics in
different datastores, now a retrieval operation can only get 1 at a time.
If I set /foo, then get-state(/foo), how do I know the config value for /foo
has not changed in the meantime?  If the server returns 2 /foo leafs in the
same
message body, then it is no longer YANG schema-valid (only 1 /foo node is
allowed)

The  <get> operation does not overload objects with different semantics.
Only a new server that eliminates /foo-state is overloading the semantics
of /foo.
The ability to retrieve /foo-state is lost for a client that only knows
<get> (and not <get-state).
This does not mean <get> is broken.  It just means the ability to access
/foo-state is removed.


Thanks,
> Rob
>
>
Andy


>
>
>
>
>>
>> /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
>> > >
>> > >
>> > >
>>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>
>