Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Martin, et al, 

On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>"Acee Lindem (acee)"  wrote:
>> 
>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>> >
>> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> >> wrote:
>> >> 
>> >>> 
>>  On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>  wrote:
>>  
>>  On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>  
>> > I hope that nobody disagrees that the operational state design and
>> >how 
>> > to structure the models are the two blocking factors to publish
>>YANG
>> > models. If you disagree or don't see this, let me know, I should
>> > communicate better.
>>  
>>  Even if it may spoil your day, I disagree that there is a blocking
>>  factor that should stop us from publishing models. There seem to be
>>  ways to address the requirements without having to block all work
>>or
>>  to redo what that we have published. But sure, if you make it a
>>  blocking factor, it will be one.
>> >>> 
>> >>> I agree with Juergen. It is not clear to me how the proposed split
>> >>>between intended and applied configuration is supposed to affect the
>> >>>data models we are working on.
>> >> 
>> >> 
>> >> As I understand it, solution #1 affects the models themselves,
>>whereas
>> >>solutions #2 and #3 are transparent to the models.
>> >
>> >Then #1 looks like a non-starter to me.
>> 
>> I’d like to point out that we also have the requirement to allow
>>retrieval
>> of derived-state along with intended-config and applied-config. This
>>will
>> require modification to most of the existing YANG drafts as most now
>>have
>> separate trees for config and operational state.
>
>I don't agree with the conclusion that changes are needed due to this
>requirement.
>
>Solution #1 ("openconfig") requires changes to handle applied config.
>Solution #2 ("kent's") does not.
>
>Both solutions #1 and #2 use separate nodes for derived state.
>
>It might appear as #1 and #2 are very different in their handling of
>derived state, since #1 put all config false nodes directly under the
>config true nodes, whereas #2 in some cases have a top-level
>"xxx-state" config false node.
>
>But in fact #2 allows the solution in #1 as one special case.  The
>reason that RFC 7223 has a separate list for derived state interfaces
>is to allow for non-configured interfaces to be monitored.  If this
>was not a requirement, all config false nodes could (would) have been
>defined in the config true interface list.

I see that this is discussed in the latest version of
draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
the operational state in the same subtree as the config state if it would
not exist if not configured. Is “appropriate” a recommendation?

   Careful consideration needs to be given to the location of
   operational state data.  It can either be located within the
   configuration subtree for which it applies, or it can be located
   outside the particular configuration subtree.  Placing operation
   state within the configuration subtree is appropriate if the
   operational values can only exist if the configuration exists.


However, we currently have many YANG models in progress where the config
and state trees are separate subtrees. If we all agree with the opstate
requirement for derived state, perhaps it is time to get the word out and
modify these models.

Thanks,
Acee 



>
>
>/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 08 Jan 2016, at 13:57, Acee Lindem (acee)  wrote:
> 
> Hi Martin, et al, 
> 
> On 1/8/16, 2:54 AM, "Martin Bjorklund"  wrote:
> 
>> Hi,
>> 
>> "Acee Lindem (acee)"  wrote:
>>> 
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>> 
 
> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> 
> 
> 
> 
> 
> 
> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
>> 
>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>  wrote:
>>> 
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> 
 I hope that nobody disagrees that the operational state design and
 how 
 to structure the models are the two blocking factors to publish
>>> YANG
 models. If you disagree or don't see this, let me know, I should
 communicate better.
>>> 
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models. There seem to be
>>> ways to address the requirements without having to block all work
>>> or
>>> to redo what that we have published. But sure, if you make it a
>>> blocking factor, it will be one.
>> 
>> I agree with Juergen. It is not clear to me how the proposed split
>> between intended and applied configuration is supposed to affect the
>> data models we are working on.
> 
> 
> As I understand it, solution #1 affects the models themselves,
>>> whereas
> solutions #2 and #3 are transparent to the models.
 
 Then #1 looks like a non-starter to me.
>>> 
>>> I’d like to point out that we also have the requirement to allow
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This
>>> will
>>> require modification to most of the existing YANG drafts as most now
>>> have
>>> separate trees for config and operational state.
>> 
>> I don't agree with the conclusion that changes are needed due to this
>> requirement.
>> 
>> Solution #1 ("openconfig") requires changes to handle applied config.
>> Solution #2 ("kent's") does not.
>> 
>> Both solutions #1 and #2 use separate nodes for derived state.
>> 
>> It might appear as #1 and #2 are very different in their handling of
>> derived state, since #1 put all config false nodes directly under the
>> config true nodes, whereas #2 in some cases have a top-level
>> "xxx-state" config false node.
>> 
>> But in fact #2 allows the solution in #1 as one special case.  The
>> reason that RFC 7223 has a separate list for derived state interfaces
>> is to allow for non-configured interfaces to be monitored.  If this
>> was not a requirement, all config false nodes could (would) have been
>> defined in the config true interface list.
> 
> I see that this is discussed in the latest version of
> draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put
> the operational state in the same subtree as the config state if it would
> not exist if not configured. Is “appropriate” a recommendation?
> 
>   Careful consideration needs to be given to the location of
>   operational state data.  It can either be located within the
>   configuration subtree for which it applies, or it can be located
>   outside the particular configuration subtree.  Placing operation
>   state within the configuration subtree is appropriate if the
>   operational values can only exist if the configuration exists.
> 
> 
> However, we currently have many YANG models in progress where the config
> and state trees are separate subtrees. If we all agree with the opstate
> requirement for derived state, perhaps it is time to get the word out and
> modify these models.

I don't think that we all agree. :-)

Lada

> 
> Thanks,
> Acee 
> 
> 
> 
>> 
>> 
>> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Martin Bjorklund]

Hi,

"Acee Lindem (acee)"  wrote:
> 
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >> wrote:
> >> 
> >>> 
>  On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>  wrote:
>  
>  On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>  
> > I hope that nobody disagrees that the operational state design and
> >how 
> > to structure the models are the two blocking factors to publish YANG
> > models. If you disagree or don't see this, let me know, I should
> > communicate better.
>  
>  Even if it may spoil your day, I disagree that there is a blocking
>  factor that should stop us from publishing models. There seem to be
>  ways to address the requirements without having to block all work or
>  to redo what that we have published. But sure, if you make it a
>  blocking factor, it will be one.
> >>> 
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >> 
> >> 
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
> 
> I’d like to point out that we also have the requirement to allow retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state.

I don't agree with the conclusion that changes are needed due to this
requirement.

Solution #1 ("openconfig") requires changes to handle applied config.
Solution #2 ("kent's") does not.

Both solutions #1 and #2 use separate nodes for derived state.

It might appear as #1 and #2 are very different in their handling of
derived state, since #1 put all config false nodes directly under the
config true nodes, whereas #2 in some cases have a top-level
"xxx-state" config false node.

But in fact #2 allows the solution in #1 as one special case.  The
reason that RFC 7223 has a separate list for derived state interfaces
is to allow for non-configured interfaces to be monitored.  If this
was not a requirement, all config false nodes could (would) have been
defined in the config true interface list.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Wed, Dec 23, 2015 at 10:05:46PM +, Robert Wilton wrote:
> 
> Personally, ignoring all the backwards compatibility issues, I would 
> prefer that interfaces and interfaces-state were a combined single list 
> (as proposed by OpenConfig).  E.g. something along the lines of:
>  - the system can still provide an operational list of discovered 
> interfaces so that clients can know what is there.
>  - but management agents would be expected to explicitly configure 
> (i.e. create an entry for) all interfaces for which it wanted to 
> retrieve data for.
>

A clear separation of config from operational state is one of the
outcomes of the IAB workshop documented in RFC 3535 and it is one of
the key foundations of both NETCONF and YANG. Config and operational
state have different and _independent_ lifetimes - you can have config
for resources that are not present and you can have operational state
for resources that are present but not configured. In addition, the
data models for operational state are often not the same as the data
models for configuration. Merging all things back into a single list
with a single keying (naming) structure gets us back into the mess we
were in with SNMP.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 28 Dec 2015, at 15:24, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Dec 23, 2015 at 10:05:46PM +, Robert Wilton wrote:
>> 
>> Personally, ignoring all the backwards compatibility issues, I would 
>> prefer that interfaces and interfaces-state were a combined single list 
>> (as proposed by OpenConfig).  E.g. something along the lines of:
>> - the system can still provide an operational list of discovered 
>> interfaces so that clients can know what is there.
>> - but management agents would be expected to explicitly configure 
>> (i.e. create an entry for) all interfaces for which it wanted to 
>> retrieve data for.
>> 
> 
> A clear separation of config from operational state is one of the
> outcomes of the IAB workshop documented in RFC 3535 and it is one of
> the key foundations of both NETCONF and YANG. Config and operational
> state have different and _independent_ lifetimes - you can have config
> for resources that are not present and you can have operational state
> for resources that are present but not configured. In addition, the
> data models for operational state are often not the same as the data
> models for configuration. Merging all things back into a single list
> with a single keying (naming) structure gets us back into the mess we
> were in with SNMP.

I agree. A good example is in ietf-routing: static routes are part of 
configuration but in state data they only appear in RIBs together with protocol 
originated-routes - there is no representation of static routes per se in state 
data. Data models for configuration and state data can indeed be rather 
different.

I would also add that IMO state data can in general be expected less 
standardised than configuration because they often need to be closer to the 
underlying device implementation.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Randy Presuhn]

Hi -

>From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
>Sent: Dec 28, 2015 6:24 AM
>To: Robert Wilton <robert.pub...@wilton.org.uk>
>Cc: "netmod@ietf.org" <netmod@ietf.org>
>Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>On Wed, Dec 23, 2015 at 10:05:46PM +, Robert Wilton wrote:
>> 
>> Personally, ignoring all the backwards compatibility issues, I would 
>> prefer that interfaces and interfaces-state were a combined single list 
>> (as proposed by OpenConfig).  E.g. something along the lines of:
>>  - the system can still provide an operational list of discovered 
>> interfaces so that clients can know what is there.
>>  - but management agents would be expected to explicitly configure 
>> (i.e. create an entry for) all interfaces for which it wanted to 
>> retrieve data for.
>>
>
>A clear separation of config from operational state is one of the
>outcomes of the IAB workshop documented in RFC 3535 and it is one of
>the key foundations of both NETCONF and YANG. Config and operational
>state have different and _independent_ lifetimes - you can have config
>for resources that are not present and you can have operational state
>for resources that are present but not configured. In addition, the
>data models for operational state are often not the same as the data
>models for configuration. Merging all things back into a single list
>with a single keying (naming) structure gets us back into the mess we
>were in with SNMP.

This assumes that separation of config from operational state
is best represented in naming.   I think trying to get one's naming 
architecture to simultaneously and consistently encode too many
aspects of whatever is being modelled brings some of the messiness that 
concerns you. Perhaps it's finally time to consider what the intended
semantics of the NETCONF / YANG naming architecture really are,
to stop trying to overload them further, and figure out what means
are appropriate for all those other semantics folks have tried to
foist onto naming.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
lho...@nic.cz<mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen 
>> <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>><netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
>>lho...@nic.cz<mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>>>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the operational state design and
>>>>>how
>>>>> to structure the models are the two blocking factors to publish YANG
>>>>> models. If you disagree or don't see this, let me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>> factor that should stop us from publishing models. There seem to be
>>>> ways to address the requirements without having to block all work or
>>>> to redo what that we have published. But sure, if you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.


A NETCONF  with a subtree filter  can retrieveg both config and non-config 
subtrees
at the same time.  A new RPC can be added (or existing  RPC extended) to
filter various conditions.  I don't see how the YANG data layout affects the 
definition
of "rpc" statements in another module.

There is the requirement to be able to do the retrievals but there is also this 
requirement:


 C.  The mappings needs to be programmatically consumable

Now, if the derived-state nodes are located with the config-nodes, then this is 
readily satisfied. Another way of satisfying the requirement may be structural 
and naming conventions but this is not as sure as co-location.

Thanks,
Acee



Thanks,
Acee


Andy



>
>Lada
>
>>
>> Kent
>>
>>
>>
>>> Lada
>>>
>>>>
>>>>> I hope that nobody really believes that because some people in IETF
>>>>>(or
>>>>> in any other SDOs) thinks that what those operators want is a bad
>>>>>idea,
>>>>> those operators will not get what they request/pay for from their
>>>>>suppliers.
>>>>
>>>> To be fair, those operators also tell us that they use protocols that
>>>> are not IETF protocols and it remains somewhat unclear what those
>>>> protocols are we are expected to optimize data model solutions for.
>>>>
>>>> /js
>>>>
>>>> --
>>>> 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/>
>>>>
>>>> _

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)  wrote:

>
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >> wrote:
> >>
> >>>
>  On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>  wrote:
> 
>  On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> 
> > I hope that nobody disagrees that the operational state design and
> >how
> > to structure the models are the two blocking factors to publish YANG
> > models. If you disagree or don't see this, let me know, I should
> > communicate better.
> 
>  Even if it may spoil your day, I disagree that there is a blocking
>  factor that should stop us from publishing models. There seem to be
>  ways to address the requirements without having to block all work or
>  to redo what that we have published. But sure, if you make it a
>  blocking factor, it will be one.
> >>>
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >>
> >>
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
>
> I’d like to point out that we also have the requirement to allow retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state. Note that this is
> discussed in sections 6, 7.3, and 7.4 of
> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>
>
A NETCONF  with a subtree filter  can retrieveg both config and
non-config subtrees
at the same time.  A new RPC can be added (or existing  RPC extended)
to
filter various conditions.  I don't see how the YANG data layout affects
the definition
of "rpc" statements in another module.


Thanks,
> Acee
>


Andy


>
>
> >
> >Lada
> >
> >>
> >> Kent
> >>
> >>
> >>
> >>> Lada
> >>>
> 
> > I hope that nobody really believes that because some people in IETF
> >(or
> > in any other SDOs) thinks that what those operators want is a bad
> >idea,
> > those operators will not get what they request/pay for from their
> >suppliers.
> 
>  To be fair, those operators also tell us that they use protocols that
>  are not IETF protocols and it remains somewhat unclear what those
>  protocols are we are expected to optimize data model solutions for.
> 
>  /js
> 
>  --
>  Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>  Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>  Fax:   +49 421 200 3103 
> 
>  ___
>  netmod mailing list
>  netmod@ietf.org
>  https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >
> >--
> >Ladislav Lhotka, CZ.NIC Labs
> >PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >___
> >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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <a...@cisco.com> wrote:

>
>
> From: Andy Bierman <a...@yumaworks.com>
> Date: Wednesday, December 23, 2015 at 10:46 AM
> To: Acee Lindem <a...@cisco.com>
> Cc: Ladislav Lhotka <lho...@nic.cz>, Kent Watsen <kwat...@juniper.net>, "
> netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <a...@cisco.com>
> wrote:
>
>>
>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>>
>> >
>> >> On 23 Dec 2015, at 04:06, Kent Watsen <kwat...@juniper.net> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> >><netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>> >>
>> >>>
>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>> >>>><j.schoenwael...@jacobs-university.de> wrote:
>> >>>>
>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>> >>>>
>> >>>>> I hope that nobody disagrees that the operational state design and
>> >>>>>how
>> >>>>> to structure the models are the two blocking factors to publish YANG
>> >>>>> models. If you disagree or don't see this, let me know, I should
>> >>>>> communicate better.
>> >>>>
>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>> >>>> factor that should stop us from publishing models. There seem to be
>> >>>> ways to address the requirements without having to block all work or
>> >>>> to redo what that we have published. But sure, if you make it a
>> >>>> blocking factor, it will be one.
>> >>>
>> >>> I agree with Juergen. It is not clear to me how the proposed split
>> >>>between intended and applied configuration is supposed to affect the
>> >>>data models we are working on.
>> >>
>> >>
>> >> As I understand it, solution #1 affects the models themselves, whereas
>> >>solutions #2 and #3 are transparent to the models.
>> >
>> >Then #1 looks like a non-starter to me.
>>
>> I’d like to point out that we also have the requirement to allow retrieval
>> of derived-state along with intended-config and applied-config. This will
>> require modification to most of the existing YANG drafts as most now have
>> separate trees for config and operational state. Note that this is
>> discussed in sections 6, 7.3, and 7.4 of
>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>
>>
> A NETCONF  with a subtree filter  can retrieveg both config and
> non-config subtrees
> at the same time.  A new RPC can be added (or existing  RPC extended)
> to
> filter various conditions.  I don't see how the YANG data layout affects
> the definition
> of "rpc" statements in another module.
>
>
> There is the requirement to be able to do the retrievals but there is also
> this requirement:
>
>  C.  The mappings needs to be programmatically consumable
>
>
> Now, if the derived-state nodes are located with the config-nodes, then
> this is readily satisfied. Another way of satisfying the requirement may be
> structural and naming conventions but this is not as sure as co-location.
>
>
There can be meta-data returned (XML attributes) that identify the
additional properties.
This is better co-location since the pattern cannot be unintentional (as it
can with the
config-within-state containers).



> Thanks,
> Acee
>
>
Andy


>
>
> Thanks,
>> Acee
>>
>
>
> Andy
>
>
>>
>>
>> >
>> >Lada
>> >
>> >>
>> >> Kent
>> >>
>> >>
>> >>
>> >>> Lada
>> >>>
>> >>>>
>> >>>>> I hope that nobody really believes that because some people in IETF
>> >>>>>(or
>> >>>>> in any other SDOs) thinks that what those operators want is a bad
>> >>>>>idea,
>> >>>>> those operators will not get what they request/pay for from their
>> >>>>

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 11:18 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:


From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz<mailto:lho...@nic.cz>>, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
lho...@nic.cz<mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen 
>> <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>><netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
>>lho...@nic.cz<mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
>>>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the operational state design and
>>>>>how
>>>>> to structure the models are the two blocking factors to publish YANG
>>>>> models. If you disagree or don't see this, let me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>> factor that should stop us from publishing models. There seem to be
>>>> ways to address the requirements without having to block all work or
>>>> to redo what that we have published. But sure, if you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how the proposed split
>>>between intended and applied configuration is supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the requirement to allow retrieval
of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.


A NETCONF  with a subtree filter  can retrieveg both config and non-config 
subtrees
at the same time.  A new RPC can be added (or existing  RPC extended) to
filter various conditions.  I don't see how the YANG data layout affects the 
definition
of "rpc" statements in another module.

There is the requirement to be able to do the retrievals but there is also this 
requirement:


 C.  The mappings needs to be programmatically consumable

Now, if the derived-state nodes are located with the config-nodes, then this is 
readily satisfied. Another way of satisfying the requirement may be structural 
and naming conventions but this is not as sure as co-location.


There can be meta-data returned (XML attributes) that identify the additional 
properties.
This is better co-location since the pattern cannot be unintentional (as it can 
with the
config-within-state containers).

This may be an option for published models. However, for models in development, 
wouldn’t it be easier to just move the nodes rather than defining the 
relationships in meta-data?

Thanks,
Acee




Thanks,
Acee


Andy



Thanks,
Acee


Andy



>
>Lada
>
>>
>> Kent
>>
>>
&

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi Andy,

On 23/12/2015 21:35, Andy Bierman wrote:



On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton 
<robert.pub...@wilton.org.uk <mailto:robert.pub...@wilton.org.uk>> wrote:


Hi,

On 23/12/2015 18:22, Acee Lindem (acee) wrote:



From: Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 11:18 AM
To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>, Kent
Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
    <mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
<a...@cisco.com <mailto:a...@cisco.com>> wrote:



From: Andy Bierman <a...@yumaworks.com
<mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz
<mailto:lho...@nic.cz>>, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>>, "netmod@ietf.org
    <mailto:netmod@ietf.org>" <netmod@ietf.org
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
<a...@cisco.com <mailto:a...@cisco.com>> wrote:


On 12/23/15, 3:22 AM, "netmod on behalf of
Ladislav Lhotka"
<netmod-boun...@ietf.org
<mailto:netmod-boun...@ietf.org> on behalf of
lho...@nic.cz <mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen
<kwat...@juniper.net
<mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of
Ladislav Lhotka"
>><netmod-boun...@ietf.org
<mailto:netmod-boun...@ietf.org> on behalf of
lho...@nic.cz <mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100,
Benoit Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the
operational state design and
>>>>>how
>>>>> to structure the models are the two
blocking factors to publish YANG
>>>>> models. If you disagree or don't see this,
let me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree
that there is a blocking
>>>> factor that should stop us from publishing
models. There seem to be
>>>> ways to address the requirements without
having to block all work or
>>>> to redo what that we have published. But
sure, if you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me
how the proposed split
>>>between intended and applied configuration is
supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the
models themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi,

On 23/12/2015 18:22, Acee Lindem (acee) wrote:



From: Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 11:18 AM
To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>, Kent 
Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>, 
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org 
<mailto:netmod@ietf.org>>

Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
<a...@cisco.com <mailto:a...@cisco.com>> wrote:



From: Andy Bierman <a...@yumaworks.com
<mailto:a...@yumaworks.com>>
Date: Wednesday, December 23, 2015 at 10:46 AM
To: Acee Lindem <a...@cisco.com <mailto:a...@cisco.com>>
Cc: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>,
Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>>, "netmod@ietf.org
    <mailto:netmod@ietf.org>" <netmod@ietf.org
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01



On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
<a...@cisco.com <mailto:a...@cisco.com>> wrote:


On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav
Lhotka"
<netmod-boun...@ietf.org
<mailto:netmod-boun...@ietf.org> on behalf of
lho...@nic.cz <mailto:lho...@nic.cz>> wrote:

>
>> On 23 Dec 2015, at 04:06, Kent Watsen
<kwat...@juniper.net <mailto:kwat...@juniper.net>> wrote:
>>
>>
>>
>>
>>
>>
>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav
Lhotka"
>><netmod-boun...@ietf.org
<mailto:netmod-boun...@ietf.org> on behalf of
lho...@nic.cz <mailto:lho...@nic.cz>> wrote:
>>
>>>
>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>>><j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
>>>>
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit
Claise wrote:
>>>>
>>>>> I hope that nobody disagrees that the
operational state design and
>>>>>how
>>>>> to structure the models are the two blocking
factors to publish YANG
>>>>> models. If you disagree or don't see this, let
me know, I should
>>>>> communicate better.
>>>>
>>>> Even if it may spoil your day, I disagree that
there is a blocking
>>>> factor that should stop us from publishing
models. There seem to be
>>>> ways to address the requirements without having
to block all work or
>>>> to redo what that we have published. But sure, if
you make it a
>>>> blocking factor, it will be one.
>>>
>>> I agree with Juergen. It is not clear to me how
the proposed split
>>>between intended and applied configuration is
supposed to affect the
>>>data models we are working on.
>>
>>
>> As I understand it, solution #1 affects the models
themselves, whereas
>>solutions #2 and #3 are transparent to the models.
>
>Then #1 looks like a non-starter to me.

I’d like to point out that we also have the
requirement to allow retrieval
of derived-state along with intended-config and
applied-config. This will
require modification to most of the existing YANG
drafts as most now have
separate trees for config and operational state. Note
that this is
discussed in sections 6, 7.3, and 7.4 of
https://www.

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton <robert.pub...@wilton.org.uk
> wrote:

> Hi,
>
> On 23/12/2015 18:22, Acee Lindem (acee) wrote:
>
>
>
> From: Andy Bierman < <a...@yumaworks.com>a...@yumaworks.com>
> Date: Wednesday, December 23, 2015 at 11:18 AM
> To: Acee Lindem < <a...@cisco.com>a...@cisco.com>
> Cc: Ladislav Lhotka <lho...@nic.cz>, Kent Watsen <kwat...@juniper.net>, "
> netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
> On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <a...@cisco.com>
> wrote:
>
>>
>>
>> From: Andy Bierman <a...@yumaworks.com>
>> Date: Wednesday, December 23, 2015 at 10:46 AM
>> To: Acee Lindem <a...@cisco.com>
>> Cc: Ladislav Lhotka <lho...@nic.cz>, Kent Watsen <kwat...@juniper.net>, "
>> netmod@ietf.org" < <netmod@ietf.org>netmod@ietf.org>
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>
>>
>>
>> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <a...@cisco.com>
>> wrote:
>>
>>>
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>>>
>>> >
>>> >> On 23 Dec 2015, at 04:06, Kent Watsen < <kwat...@juniper.net>
>>> kwat...@juniper.net> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>> >>< <netmod-boun...@ietf.org>netmod-boun...@ietf.org on behalf of
>>> lho...@nic.cz> wrote:
>>> >>
>>> >>>
>>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>> >>>>< <j.schoenwael...@jacobs-university.de>
>>> j.schoenwael...@jacobs-university.de> wrote:
>>> >>>>
>>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> >>>>
>>> >>>>> I hope that nobody disagrees that the operational state design and
>>> >>>>>how
>>> >>>>> to structure the models are the two blocking factors to publish
>>> YANG
>>> >>>>> models. If you disagree or don't see this, let me know, I should
>>> >>>>> communicate better.
>>> >>>>
>>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>>> >>>> factor that should stop us from publishing models. There seem to be
>>> >>>> ways to address the requirements without having to block all work or
>>> >>>> to redo what that we have published. But sure, if you make it a
>>> >>>> blocking factor, it will be one.
>>> >>>
>>> >>> I agree with Juergen. It is not clear to me how the proposed split
>>> >>>between intended and applied configuration is supposed to affect the
>>> >>>data models we are working on.
>>> >>
>>> >>
>>> >> As I understand it, solution #1 affects the models themselves, whereas
>>> >>solutions #2 and #3 are transparent to the models.
>>> >
>>> >Then #1 looks like a non-starter to me.
>>>
>>> I’d like to point out that we also have the requirement to allow
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This will
>>> require modification to most of the existing YANG drafts as most now have
>>> separate trees for config and operational state. Note that this is
>>> discussed in sections 6, 7.3, and 7.4 of
>>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>>
>>>
>> A NETCONF  with a subtree filter  can retrieveg both config and
>> non-config subtrees
>> at the same time.  A new RPC can be added (or existing  RPC
>> extended) to
>> filter various conditions.  I don't see how the YANG data layout affects
>> the definition
>> of "rpc" statements in another module.
>>
>>
>> There is the requirement to be able to do the retrievals but there is
>> also this requirement:
>>
>>  C.  The mappings needs to be programmatically consumable
>>
>>
>> Now, if the derived-state nodes are locat

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> 
> 
> 
> 
> 
> 
> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" 
>  wrote:
> 
>> 
>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> 
 I hope that nobody disagrees that the operational state design and how 
 to structure the models are the two blocking factors to publish YANG 
 models. If you disagree or don't see this, let me know, I should 
 communicate better.
>>> 
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models. There seem to be
>>> ways to address the requirements without having to block all work or
>>> to redo what that we have published. But sure, if you make it a
>>> blocking factor, it will be one.
>> 
>> I agree with Juergen. It is not clear to me how the proposed split between 
>> intended and applied configuration is supposed to affect the data models we 
>> are working on.
> 
> 
> As I understand it, solution #1 affects the models themselves, whereas 
> solutions #2 and #3 are transparent to the models.

Then #1 looks like a non-starter to me.

Lada

> 
> Kent
> 
> 
> 
>> Lada
>> 
>>> 
 I hope that nobody really believes that because some people in IETF (or 
 in any other SDOs) thinks that what those operators want is a bad idea, 
 those operators will not get what they request/pay for from their 
 suppliers.
>>> 
>>> To be fair, those operators also tell us that they use protocols that
>>> are not IETF protocols and it remains somewhat unclear what those
>>> protocols are we are expected to optimize data model solutions for.
>>> 
>>> /js
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" 
 wrote:

>
>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder 
>>  wrote:
>> 
>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>> 
>>> I hope that nobody disagrees that the operational state design and how 
>>> to structure the models are the two blocking factors to publish YANG 
>>> models. If you disagree or don't see this, let me know, I should 
>>> communicate better.
>> 
>> Even if it may spoil your day, I disagree that there is a blocking
>> factor that should stop us from publishing models. There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published. But sure, if you make it a
>> blocking factor, it will be one.
>
>I agree with Juergen. It is not clear to me how the proposed split between 
>intended and applied configuration is supposed to affect the data models we 
>are working on.


As I understand it, solution #1 affects the models themselves, whereas 
solutions #2 and #3 are transparent to the models.

Kent



>Lada
>
>> 
>>> I hope that nobody really believes that because some people in IETF (or 
>>> in any other SDOs) thinks that what those operators want is a bad idea, 
>>> those operators will not get what they request/pay for from their suppliers.
>> 
>> To be fair, those operators also tell us that they use protocols that
>> are not IETF protocols and it remains somewhat unclear what those
>> protocols are we are expected to optimize data model solutions for.
>> 
>> /js
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Benoit Claise]

Jürgen,

On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:


I hope that nobody disagrees that the operational state design and how
to structure the models are the two blocking factors to publish YANG
models. If you disagree or don't see this, let me know, I should
communicate better.

Even if it may spoil your day, I disagree that there is a blocking
factor that should stop us from publishing models.
Interestingly, I received that feedback again recently, this time from 
the OSPF and ISIS YANG model authors.

There seem to be
ways to address the requirements without having to block all work or
to redo what that we have published.

That's my hope too.

But sure, if you make it a
blocking factor, it will be one.

I'll chose to ignore this last sentence.

Regards, Benoit



I hope that nobody really believes that because some people in IETF (or
in any other SDOs) thinks that what those operators want is a bad idea,
those operators will not get what they request/pay for from their suppliers.

To be fair, those operators also tell us that they use protocols that
are not IETF protocols and it remains somewhat unclear what those
protocols are we are expected to optimize data model solutions for.

/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Nadeau Thomas]

> On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise  wrote:
> 
> Jürgen,
>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>> 
>>> I hope that nobody disagrees that the operational state design and how
>>> to structure the models are the two blocking factors to publish YANG
>>> models. If you disagree or don't see this, let me know, I should
>>> communicate better.
>> Even if it may spoil your day, I disagree that there is a blocking
>> factor that should stop us from publishing models.
> Interestingly, I received that feedback again recently, this time from the 
> OSPF and ISIS YANG model authors.

This is a blocking factor that people are not considering: The RFC 
process the 
IETF has in place is not suitable for rapid/modern/canonical model development. 
 It will 
be difficult for the IESG review process to scale to even a couple models 
during any given 
telechat period given the state of the document review/approval process. How do 
we 
envision the IESG reviewing 250+ models (and growing)?  Besides the initial RFC 
version, 
rapid refresh/update of models has the same issues. 

—Tom

>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
> 
> Regards, Benoit
>> 
>>> I hope that nobody really believes that because some people in IETF (or
>>> in any other SDOs) thinks that what those operators want is a bad idea,
>>> those operators will not get what they request/pay for from their suppliers.
>> To be fair, those operators also tell us that they use protocols that
>> are not IETF protocols and it remains somewhat unclear what those
>> protocols are we are expected to optimize data model solutions for.
>> 
>> /js
>> 
> 
> ___
> 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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Tue, Dec 22, 2015 at 5:07 AM, Acee Lindem (acee)  wrote:

> Hi Lada,
>
> On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:
>
> >Hi Acee,
> >
> >> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
> >>
> >> Jurgen, Lada,
> >>
> >> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
> >>  wrote:
> >>
> >>>
>  On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
> 
>  Jürgen,
> > On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >
> >> I hope that nobody disagrees that the operational state design and
> >>how
> >> to structure the models are the two blocking factors to publish YANG
> >> models. If you disagree or don't see this, let me know, I should
> >> communicate better.
> > Even if it may spoil your day, I disagree that there is a blocking
> > factor that should stop us from publishing models.
>  Interestingly, I received that feedback again recently, this time from
>  the OSPF and ISIS YANG model authors.
> >>>
> >>> Did they mention any reason *why* it is a blocking factor for their
> >>> modules?
> >>
> >> This should be obvious - the OSPF and IS-IS WG are not going to publish
> >> YANG models that don’t meet the ops-state requirements. Why would we
> >
> >Can you please explain what specific ops-state requirements aren't met in
> >those modules? I am interested because the same problem may possibly be
> >present in our ietf-routing module.
>
> That’s easy - the requirements as stated in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
> We could go back and reorganize the IGP models and add separate leaves for
> intended and applied config and meet these requirements. However, if we
> conclude on a more elegant solution, it would be great to avail ourselves
> to that solution.
>
>

At the last IETF, the consensus in the room was to use an RPC-based
solution.
Has that changed? What aspect of the RPC-based solution is blocking data
model development?



> Thanks,
> Acee
>


Andy


>
>
>
> >
> >Thanks, Lada
> >
> >> publish standards that don’t meet the requirements and are,
> >>consequently,
> >> irrelevant? Failure to recognize this is a real blocking issue.
> >>
> >> Acee
> >>
> >>
> >>
> >>
> >>>
> >>> Thanks, Lada
> >>>
> > There seem to be
> > ways to address the requirements without having to block all work or
> > to redo what that we have published.
>  That's my hope too.
> > But sure, if you make it a
> > blocking factor, it will be one.
>  I'll chose to ignore this last sentence.
> 
>  Regards, Benoit
> >
> >> I hope that nobody really believes that because some people in IETF
> >> (or
> >> in any other SDOs) thinks that what those operators want is a bad
> >> idea,
> >> those operators will not get what they request/pay for from their
> >> suppliers.
> > To be fair, those operators also tell us that they use protocols that
> > are not IETF protocols and it remains somewhat unclear what those
> > protocols are we are expected to optimize data model solutions for.
> >
> > /js
> >
> 
>  ___
>  netmod mailing list
>  netmod@ietf.org
>  https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >
> >--
> >Ladislav Lhotka, CZ.NIC Labs
> >PGP Key ID: E74E8C0C
> >
> >
> >
> >
>
> ___
> 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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> 
>> I hope that nobody disagrees that the operational state design and how 
>> to structure the models are the two blocking factors to publish YANG 
>> models. If you disagree or don't see this, let me know, I should 
>> communicate better.
> 
> Even if it may spoil your day, I disagree that there is a blocking
> factor that should stop us from publishing models. There seem to be
> ways to address the requirements without having to block all work or
> to redo what that we have published. But sure, if you make it a
> blocking factor, it will be one.

I agree with Juergen. It is not clear to me how the proposed split between 
intended and applied configuration is supposed to affect the data models we are 
working on.

Lada

> 
>> I hope that nobody really believes that because some people in IETF (or 
>> in any other SDOs) thinks that what those operators want is a bad idea, 
>> those operators will not get what they request/pay for from their suppliers.
> 
> To be fair, those operators also tell us that they use protocols that
> are not IETF protocols and it remains somewhat unclear what those
> protocols are we are expected to optimize data model solutions for.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 21 Dec 2015, at 17:42, Robert Wilton  wrote:
> 
> Hi Lada,
> 
> On 21/12/2015 16:05, Ladislav Lhotka wrote:
>>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
>>> 
>>> Hi Lada,
>>> 
>>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
 Juergen Schoenwaelder  writes:
 
> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  
>>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> I’m struggling a bit to understand what is motivating you to ask 
>> this question.That is, as a tool vendor, I wouldn’t think that 
>> any decision made here would affect you immediately.   My 
>> expectations are that any impact to YANG/NETCONF/RESTCONF would be 
>> backwards compatible, such that implementations would only opt-in 
>> when needed - a pay as you grow strategy.   But herein perhaps lies 
>> an unstated requirement, that the impact to YANG/NETCONF/RESTCONF 
>> needs to be backwards compatible with respect to existing 
>> deployments.  Did we miss it or is it too obvious?
>> 
> It may be obvious for many of us but for the sake of completeness I
> prefer to have this backwards compatibility assumption explicitely
> stated.
 +1
>>> [as a chair]
>>> 
>>> As last call comment, there seems to be support for adding a 
>>> requirement to the opstate-reqs draft to state that solutions 
>>> supporting said requirements MUST be backwards compatible with respect 
>>> to existing deployments.  Do we have WG consensus to add this as a 
>>> requirement to this draft?  Are there any objections? Please voice your 
>>> opinion before the last call cutoff date (Dec 30).
>>> 
>>> 
>>> [as a contributor]
>>> 
>>> 
>>> I’m unsure if it makes sense to call it out in this draft, in that it 
>>> seems universally applicable, but I don’t see any harm in it either and 
>>> thus do not object.
>>> 
>>> 
>>> Kent
>>  [As Co-chair]
>> 
>>  Given the tall hill we climbed to get to this point on the 
>> requirements, I
>> want to be clear that there needs to be very significant support to 
>> change the requirements
>> in any significant way. We went round and round the drain on settling on 
>> these requirements, and
>> people had a whole host of reasonable opportunities to add this during 
>> those times. I want to point out that while this statement may seem 
>> subtle, slipping this in at the last minute could have a profound impact 
>> on solutions built from these requirements, so I want to be sure 
>> everyone involved has through through this kind of change.
>> 
>>  —Tom
> Tom,
> 
> I think Andy is talking about applicability - to which kind of servers
> do these requirements apply. For example, if it takes more time on a
> certain class of devices to retrieve the difference between applied
> and intended config than it takes to turn intended config into applied
> config, then these requirements may not be applicable (since by the
> time you have finished retrieving the difference it has vanished).
 I think it is not only matter of synchronisation delays between intended
 and applied configuration. I have serious troubles understanding how
 these concepts map to the class of devices I am mainly interested in.
 
 Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
 server that supports intended and applied config. Assume the server
 implements modules of the acl-model family so that firewall rules can be
 configured through NETCONF/RESTCONF. Great.
 
 Now an admin runs "iptables" to manipulate netfilter rules in the
 kernel. How does it affect the applied and intended configurations?
 
 A. The change isn't reflected in applied configuration. Then applied
configuration is no more "…, the configuration state which is
currently being used by server components (e.g., control plane
daemons, operating system kernels, line cards)."
 
 B. The change is reflected in applied but not in intended
configuration. This violates requirement 1 sub D, and also it may be
impossible to map the kernel changes back to the configuration.
 
 For sure, these problems exist also with the good old "running", but I
 think the migration to intended-applied would just make things worse.
>>> If I understand your example correctly, then the complexity in your 
>>> scenario is that what is actually written in the hardware is controlled by 
>>> two independent management entities.  Is that right?
>> Right, and this is quite typical for systems where users have access to a 
>> 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Christian Hopps]

Ladislav Lhotka  writes:
>> Tom,
>>
>> I think Andy is talking about applicability - to which kind of servers
>> do these requirements apply. For example, if it takes more time on a
>> certain class of devices to retrieve the difference between applied
>> and intended config than it takes to turn intended config into applied
>> config, then these requirements may not be applicable (since by the
>> time you have finished retrieving the difference it has vanished).
>
> I think it is not only matter of synchronisation delays between intended
> and applied configuration. I have serious troubles understanding how
> these concepts map to the class of devices I am mainly interested in.
>
> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
> server that supports intended and applied config. Assume the server
> implements modules of the acl-model family so that firewall rules can be
> configured through NETCONF/RESTCONF. Great.
>
> Now an admin runs "iptables" to manipulate netfilter rules in the
> kernel. How does it affect the applied and intended configurations?
>
> A. The change isn't reflected in applied configuration. Then applied
>configuration is no more "…, the configuration state which is
>currently being used by server components (e.g., control plane
>daemons, operating system kernels, line cards)."
>
> B. The change is reflected in applied but not in intended
>configuration. This violates requirement 1 sub D, and also it may be
>impossible to map the kernel changes back to the configuration.
>
> For sure, these problems exist also with the good old "running", but I
> think the migration to intended-applied would just make things worse.

Perhaps I'm misunderstanding the example, but it seems you have a setup
where your netconf/restconf server isn't in sync with actual
configuration of the device, regardless of whether is implements these
requirements or not.

Why isn't this a non-starter? I mean it seems to me that you don't need
to worry about new operational state requirements until the most basic
functionality is working.

Thanks,
Chris.


>
> Lada
>
>
>>
>> Andy, did I get this right?
>>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
> 
> Hi Lada,
> 
> On 21/12/2015 13:55, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>> 
>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  
> wrote:
> 
> 
> 
> 
> 
> 
 I’m struggling a bit to understand what is motivating you to ask this 
 question.That is, as a tool vendor, I wouldn’t think that any 
 decision made here would affect you immediately.   My expectations are 
 that any impact to YANG/NETCONF/RESTCONF would be backwards 
 compatible, such that implementations would only opt-in when needed - 
 a pay as you grow strategy.   But herein perhaps lies an unstated 
 requirement, that the impact to YANG/NETCONF/RESTCONF needs to be 
 backwards compatible with respect to existing deployments.  Did we 
 miss it or is it too obvious?
 
>>> It may be obvious for many of us but for the sake of completeness I
>>> prefer to have this backwards compatibility assumption explicitely
>>> stated.
>> +1
> 
> [as a chair]
> 
> As last call comment, there seems to be support for adding a requirement 
> to the opstate-reqs draft to state that solutions supporting said 
> requirements MUST be backwards compatible with respect to existing 
> deployments.  Do we have WG consensus to add this as a requirement to 
> this draft?  Are there any objections? Please voice your opinion before 
> the last call cutoff date (Dec 30).
> 
> 
> [as a contributor]
> 
> 
> I’m unsure if it makes sense to call it out in this draft, in that it 
> seems universally applicable, but I don’t see any harm in it either and 
> thus do not object.
> 
> 
> Kent
[As Co-chair]
 
Given the tall hill we climbed to get to this point on the 
 requirements, I
 want to be clear that there needs to be very significant support to change 
 the requirements
 in any significant way. We went round and round the drain on settling on 
 these requirements, and
 people had a whole host of reasonable opportunities to add this during 
 those times. I want to point out that while this statement may seem 
 subtle, slipping this in at the last minute could have a profound impact 
 on solutions built from these requirements, so I want to be sure everyone 
 involved has through through this kind of change.
 
—Tom
>>> Tom,
>>> 
>>> I think Andy is talking about applicability - to which kind of servers
>>> do these requirements apply. For example, if it takes more time on a
>>> certain class of devices to retrieve the difference between applied
>>> and intended config than it takes to turn intended config into applied
>>> config, then these requirements may not be applicable (since by the
>>> time you have finished retrieving the difference it has vanished).
>> I think it is not only matter of synchronisation delays between intended
>> and applied configuration. I have serious troubles understanding how
>> these concepts map to the class of devices I am mainly interested in.
>> 
>> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
>> server that supports intended and applied config. Assume the server
>> implements modules of the acl-model family so that firewall rules can be
>> configured through NETCONF/RESTCONF. Great.
>> 
>> Now an admin runs "iptables" to manipulate netfilter rules in the
>> kernel. How does it affect the applied and intended configurations?
>> 
>> A. The change isn't reflected in applied configuration. Then applied
>>configuration is no more "…, the configuration state which is
>>currently being used by server components (e.g., control plane
>>daemons, operating system kernels, line cards)."
>> 
>> B. The change is reflected in applied but not in intended
>>configuration. This violates requirement 1 sub D, and also it may be
>>impossible to map the kernel changes back to the configuration.
>> 
>> For sure, these problems exist also with the good old "running", but I
>> think the migration to intended-applied would just make things worse.
> If I understand your example correctly, then the complexity in your scenario 
> is that what is actually written in the hardware is controlled by two 
> independent management entities.  Is that right?

Right, and this is quite typical for systems where users have access to a 
standard Unix shell and/or can install software on their own.

> 
> If so I think that your scenario is outside what could be reasonably expected 
> to be defined by a standards specification.

Why? Such systems could also benefit from NETCONF/RESTCONF and standard data 
models.

> 
> Ideally, all of the related 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Benoit Claise]

Andy,



On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <kwat...@juniper.net 
<mailto:kwat...@juniper.net>> wrote:



Hi Robert,

I agree that -01 doesn’t add much on top of -00.  This is expected
as we’re in the fit and finish phase.  If you want to help finish
the draft, then please consider responding to one of these threads:

http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html
(re: rollback-on-error)
http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html
(re: model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility
requirement, please note that what was written here is still in
effect:
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.
Note that no objections have been raised yet, so this will likely
happen.

2. Regarding adding an applicability statement, there is currently
only one voice asking for it, which isn’t enough to warrant a change.


I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a 
document.
I hope that nobody disagrees that the operational state design and how 
to structure the models are the two blocking factors to publish YANG 
models. If you disagree or don't see this, let me know, I should 
communicate better.
I hope that nobody disagrees that there is a problem to be solved (a 
problem statement extracted from 
https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/). We 
havea bunch of operators <http://www.openconfig.net/participants>, 
coming to the IETF, telling us they have a problem. So there is a problem.
I hope that nobody really believes that because some people in IETF (or 
in any other SDOs) thinks that what those operators want is a bad idea, 
those operators will not get what they request/pay for from their suppliers.


Regards, Benoit (OPS AD)



Thanks,
Kent


Andy




On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
<netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org> on
behalf of rwil...@cisco.com <mailto:rwil...@cisco.com>> wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
    >>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
>>> Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any
clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate
aware, and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the
very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support
opstate aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good*
thing to me.
>>
>>>   - Having a server side configuration knob to control the
behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to
prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some
(perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios,
and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements
can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use.  This really doesn't appear to be
>u

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi,

On 17/12/2015 23:45, Randy Presuhn wrote:

Hi -


From: Robert Wilton
Sent: Dec 17, 2015 1:12 PM
To: Andy Bierman
Cc: "netmod@ietf.org"
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

...

 Your requirement is a bit too strong for my liking.

 To paraphrase your requirement text, it is forcing that all
 compliant NETCONF/RESTCONF servers MUST support any clients that do
 not want to differentiate between intended config and applied
 config.

Do do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.


 However, this requires all opstate aware servers:

  - To handle a mix of clients, some of which are opstate aware, and
  some that are not.

This seems perfectly reasonable.  To do otherwise torpedoes the very
notion of interoperability.


  - To potentially handle a mix of requests, some of which are
  opstate aware requests, and some are not.

Ditto.


 It also prevents:

  - Having a server that is implemented to only support opstate aware
  clients.

Avoiding the creation of such servers sounds like a *good* thing to me.


  - Having a server side configuration knob to control the behaviour
  (since it would affect the semantics for all clients).

This also sounds like something which it would be desireable to prevent.

I think I'm squarely with Andy on this one.


Taking a step back ...

I am probably way off the mark, but my perception is that some (perhaps 
many) of the folks in the WG still perceive that the opstate 
requirements are niche requirements for some unusual scenarios, and that 
everyone else is happy with the status quo and don't want/need them.


Alas, I don't share that view.  For me, the opstate requirements can be 
summarized as saying that the operators just want to know what 
configuration the device is actually running in a format that is 
convenient for them to use.  This really doesn't appear to be 
unreasonable request to me, and if I was writing to a network 
manageability API then I would choose to use opstate because I perceive 
that it is a more robust and easier to use API.  The counter arguments 
appear to be that it is too hard for devices to provide this 
information, and that the operators have historically managed without it.


However, I think that several things have changed, and hence negate 
these counter arguments: (i) the operators want to have much more 
automation and management over their devices, (ii) they have found a way 
to group together and have a more vocal voice about what they need and 
want, (iii) the operators have realized that they don't need to wait for 
the SDOs and can create defacto standard models on their own if they 
have to.


Personally, I would like us to stop spending time churning on the 
requirements and actually get on to discussing the solutions.  To be 
honest, there has been relatively little change in my understanding of 
the requirements from reading draft-openconfig-netmod-opstate-01 back in 
July, and I was expecting to discuss the solution drafts back in 
September.  Here we are in December, and I'm not convinced that we have 
truly made significant progress.


The only reason that I submitted a solution draft to this problem was 
because I thought it unlikely that OpenConfig would support a multiple 
datastore solution, and I could see strong resistance amongst the IETF 
engineers to the proposed OpenConfig solution.  I was hoping that my 
proposed solution might be seen for the compromise that it is between 
the two opposing positions.  But I care less on what the solution is, 
and more whether we can agree on one and move forward.


As someone that is quite new to SDO processes, my main concern is that 
IETF (and other standards bodies) are moving too slowly here, and that 
by the time that IETF have produced a sufficiently complete set of YANG 
models to manage network devices it will be too late because the 
industry will already have converged on the OpenConfig models, which 
although not perfect, are close to being usable now, and are being 
evolved at a much quicker pace ...


So my hope for the early new year is that we can reach common ground 
with OpenConfig and converge on a single set of YANG modules for 
managing network devices, and that includes having a solution to the 
Opstate problem.


Finally, if my acquiescing to Andy's requirement is helpful to move this 
process forward then that is fine with me.  As I have previously 
indicated, I don't really think that it helps with framing or discussing 
the solutions, but equally I can live with it since I suspect that the 
solutions are likely to comply with it anyway.


Apologies for the long email, and given I may not be actively reading 
the WG emails over the next couple of weeks, I'll wish you all happy 
holidays!


Thanks,
Rob



Randy

___
netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 18 Dec 2015, at 15:08, Andy Bierman <a...@yumaworks.com> wrote:
> 
> 
> 
> On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton <rwil...@cisco.com> wrote:
> Hi,
> 
> On 17/12/2015 23:45, Randy Presuhn wrote:
> Hi -
> 
> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>  Your requirement is a bit too strong for my liking.
> 
>  To paraphrase your requirement text, it is forcing that all
>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>  not want to differentiate between intended config and applied
>  config.
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
> 
>  However, this requires all opstate aware servers:
> 
>   - To handle a mix of clients, some of which are opstate aware, and
>   some that are not.
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
> 
>   - To potentially handle a mix of requests, some of which are
>   opstate aware requests, and some are not.
> Ditto.
> 
>  It also prevents:
> 
>   - Having a server that is implemented to only support opstate aware
>   clients.
> Avoiding the creation of such servers sounds like a *good* thing to me.
> 
>   - Having a server side configuration knob to control the behaviour
>   (since it would affect the semantics for all clients).
> This also sounds like something which it would be desireable to prevent.
> 
> I think I'm squarely with Andy on this one.
> 
> Taking a step back ...
> 
> I am probably way off the mark, but my perception is that some (perhaps many) 
> of the folks in the WG still perceive that the opstate requirements are niche 
> requirements for some unusual scenarios, and that everyone else is happy with 
> the status quo and don't want/need them.
> 
> Alas, I don't share that view.  For me, the opstate requirements can be 
> summarized as saying that the operators just want to know what configuration 
> the device is actually running in a format that is convenient for them to 
> use.  This really doesn't appear to be unreasonable request to me, and if I 
> was writing to a network manageability API then I would choose to use opstate 
> because I perceive that it is a more robust and easier to use API.  The 
> counter arguments appear to be that it is too hard for devices to provide 
> this information, and that the operators have historically managed without it.
> 
> However, I think that several things have changed, and hence negate these 
> counter arguments: (i) the operators want to have much more automation and 
> management over their devices, (ii) they have found a way to group together 
> and have a more vocal voice about what they need and want, (iii) the 
> operators have realized that they don't need to wait for the SDOs and can 
> create defacto standard models on their own if they have to.
> 
> Personally, I would like us to stop spending time churning on the 
> requirements and actually get on to discussing the solutions.  To be honest, 
> there has been relatively little change in my understanding of the 
> requirements from reading draft-openconfig-netmod-opstate-01 back in July, 
> and I was expecting to discuss the solution drafts back in September.  Here 
> we are in December, and I'm not convinced that we have truly made significant 
> progress.
> 
> The only reason that I submitted a solution draft to this problem was because 
> I thought it unlikely that OpenConfig would support a multiple datastore 
> solution, and I could see strong resistance amongst the IETF engineers to the 
> proposed OpenConfig solution.  I was hoping that my proposed solution might 
> be seen for the compromise that it is between the two opposing positions.  
> But I care less on what the solution is, and more whether we can agree on one 
> and move forward.
> 
> As someone that is quite new to SDO processes, my main concern is that IETF 
> (and other standards bodies) are moving too slowly here, and that by the time 
> that IETF have produced a sufficiently complete set of YANG models to manage 
> network devices it will be too late because the industry will already have 
> converged on the OpenConfig models, which although not perfect, are close to 
> being usable now, and are being evolved at a much quicker pace ...
> 
> So my hope for the early new year is that we can reach common ground with 
> OpenConfig and converge on a single set of YANG modules for managing network 
> devices, and that incl

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Fri, Dec 18, 2015 at 04:16:04PM +0100, Ladislav Lhotka wrote:
> 
> > On 18 Dec 2015, at 15:49, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> >> 
> >> Is it not? I would say it severely restricts the workflow for the data 
> >> model development. The ultra-conservative update rules essentially permit 
> >> only incremental changes to published modules. This would be fine if the 
> >> data model landscape already was reasonably stable. We are not that far 
> >> though, and everything is in flux. So I believe we would be much better 
> >> off with "release early - release often" strategy, which is made 
> >> impossible by the existing update rules.
> >> 
> > 
> > There is a "release early - release often cycle" in the IETF process -
> > it is called the Internet Drafts stage. Unfortunately, often people
> > wait for things to stabilize (becoming an RFC) before implementing. I
> 
> There are other disadvantages to I-Ds, for example that they have to be 
> updated every six months. It is actually funny: RFC used to mean "request for 
> comments", then later I-D acquired this role, so now we probably need a 
> "drafty draft" category.
> 
> > assume we would have fewer but more solid data models if they would
> > all come along with running code behind them (and ideally > 1
> > independent implementations). The problem might be "us" and not the
> > update rules.
> 
> The update rules mean that it is risky to publish a data model in an RFC. And 
> indeed, if there is a need, for one reason or another, to restructure, for 
> example, ietf-interfaces, it will have to become a new module 
> (ietf-interfaces-dash?) and the revision history will be broken. Doing this 
> more than once would turn the data model ecosystem into a mess.

No, it does not.
 
> Backward compatibility is nice, but making it an absolute requirement, which 
> is even ingrained in the data modelling language specification, is IMO absurd.
>

I can grab interface statistics from pretty much all devices on my
network using a single data model and SNMP. This is a feature, not a
bug. You may find this not worth the effort or you might even find
this absurd in todays world. I do not have to share this view.

Can we stop here and get back to the I-D discussed in this thread? If
you want to complain about absurd YANG update rules, please do so
using a separate thread.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Rob, 
Thanks for authoring the comprehensive response. I’m in complete agreement
and support publication of the document.
Thanks,
Acee 

On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)" <netmod-boun...@ietf.org on behalf of
rwil...@cisco.com> wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that
>>>do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware,
>>>and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate
>>>aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the
>>>behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios, and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use.  This really doesn't appear to be
>unreasonable request to me, and if I was writing to a network
>manageability API then I would choose to use opstate because I perceive
>that it is a more robust and easier to use API.  The counter arguments
>appear to be that it is too hard for devices to provide this
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate
>these counter arguments: (i) the operators want to have much more
>automation and management over their devices, (ii) they have found a way
>to group together and have a more vocal voice about what they need and
>want, (iii) the operators have realized that they don't need to wait for
>the SDOs and can create defacto standard models on their own if they
>have to.
>
>Personally, I would like us to stop spending time churning on the
>requirements and actually get on to discussing the solutions.  To be
>honest, there has been relatively little change in my understanding of
>the requirements from reading draft-openconfig-netmod-opstate-01 back in
>July, and I was expecting to discuss the solution drafts back in
>September.  Here we are in December, and I'm not convinced that we have
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was
>because I thought it unlikely that OpenConfig would support a multiple
>datastore solution, and I could see strong resistance amongst the IETF
>engineers to the proposed OpenConfig solution.  I was hoping that my
>proposed solution might be seen for the compromise that it is between
>the two opposing positions.  But I care less on what the solution is,
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is that
>IETF (and other standards bodies) are moving too slowly here, and that
>by the time that IETF have produced a sufficiently complete set of YANG
>models to manage network devices it will be too late because the
>industry will a

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> 
> Is it not? I would say it severely restricts the workflow for the data model 
> development. The ultra-conservative update rules essentially permit only 
> incremental changes to published modules. This would be fine if the data 
> model landscape already was reasonably stable. We are not that far though, 
> and everything is in flux. So I believe we would be much better off with 
> "release early - release often" strategy, which is made impossible by the 
> existing update rules.
>

There is a "release early - release often cycle" in the IETF process -
it is called the Internet Drafts stage. Unfortunately, often people
wait for things to stabilize (becoming an RFC) before implementing. I
assume we would have fewer but more solid data models if they would
all come along with running code behind them (and ideally > 1
independent implementations). The problem might be "us" and not the
update rules.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

Hi Robert,

I agree that -01 doesn’t add much on top of -00.  This is expected as we’re in 
the fit and finish phase.  If you want to help finish the draft, then please 
consider responding to one of these threads:

  http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re: 
rollback-on-error)
  http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: 
model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility requirement, please 
note that what was written here is still in effect: 
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note that 
no objections have been raised yet, so this will likely happen.

2. Regarding adding an applicability statement, there is currently only one 
voice asking for it, which isn’t enough to warrant a change.

Thanks,
Kent



On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" 
<netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware, and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps 
>many) of the folks in the WG still perceive that the opstate 
>requirements are niche requirements for some unusual scenarios, and that 
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be 
>summarized as saying that the operators just want to know what 
>configuration the device is actually running in a format that is 
>convenient for them to use.  This really doesn't appear to be 
>unreasonable request to me, and if I was writing to a network 
>manageability API then I would choose to use opstate because I perceive 
>that it is a more robust and easier to use API.  The counter arguments 
>appear to be that it is too hard for devices to provide this 
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate 
>these counter arguments: (i) the operators want to have much more 
>automation and management over their devices, (ii) they have found a way 
>to group together and have a more vocal voice about what they need and 
>want, (iii) the operators have realized that they don't need to wait for 
>the SDOs and can create defacto standard models on their own if they 
>have to.
>
>Personally, I would like us to stop spending time churning on the 
>requirements and actually get on to discussing the solutions.  To be 
>honest, there has been relatively little change in my understanding of 
>the requirements from reading draft-openconfig-netmod-opstate-01 back in 
>July, and I was expecting to discuss the solution drafts back in 
>September.  Here we are in December, and I'm not convinced that we have 
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was 
>because I thought it unlikely that OpenConfig would support a multiple 
>datastore solution, 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 18 Dec 2015, at 15:49, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
>> 
>> Is it not? I would say it severely restricts the workflow for the data model 
>> development. The ultra-conservative update rules essentially permit only 
>> incremental changes to published modules. This would be fine if the data 
>> model landscape already was reasonably stable. We are not that far though, 
>> and everything is in flux. So I believe we would be much better off with 
>> "release early - release often" strategy, which is made impossible by the 
>> existing update rules.
>> 
> 
> There is a "release early - release often cycle" in the IETF process -
> it is called the Internet Drafts stage. Unfortunately, often people
> wait for things to stabilize (becoming an RFC) before implementing. I

There are other disadvantages to I-Ds, for example that they have to be updated 
every six months. It is actually funny: RFC used to mean "request for 
comments", then later I-D acquired this role, so now we probably need a "drafty 
draft" category.

> assume we would have fewer but more solid data models if they would
> all come along with running code behind them (and ideally > 1
> independent implementations). The problem might be "us" and not the
> update rules.

The update rules mean that it is risky to publish a data model in an RFC. And 
indeed, if there is a need, for one reason or another, to restructure, for 
example, ietf-interfaces, it will have to become a new module 
(ietf-interfaces-dash?) and the revision history will be broken. Doing this 
more than once would turn the data model ecosystem into a mess.

Backward compatibility is nice, but making it an absolute requirement, which is 
even ingrained in the data modelling language specification, is IMO absurd.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

>>>I’m struggling a bit to understand what is motivating you to ask this 
>>>question.That is, as a tool vendor, I wouldn’t think that any decision 
>>>made here would affect you immediately.   My expectations are that any 
>>>impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that 
>>>implementations would only opt-in when needed - a pay as you grow strategy.  
>>> But herein perhaps lies an unstated requirement, that the impact to 
>>>YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to 
>>>existing deployments.  Did we miss it or is it too obvious?
>>> 
>> 
>> It may be obvious for many of us but for the sake of completeness I
>> prefer to have this backwards compatibility assumption explicitely
>> stated.
>
>+1


[as a chair]

As last call comment, there seems to be support for adding a requirement to the 
opstate-reqs draft to state that solutions supporting said requirements MUST be 
backwards compatible with respect to existing deployments.  Do we have WG 
consensus to add this as a requirement to this draft?  Are there any 
objections? Please voice your opinion before the last call cutoff date (Dec 30).


[as a contributor]


I’m unsure if it makes sense to call it out in this draft, in that it seems 
universally applicable, but I don’t see any harm in it either and thus do not 
object.


Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.


Andy


On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen  wrote:

>
>
>
>
>
> >>>I’m struggling a bit to understand what is motivating you to ask this
> question.That is, as a tool vendor, I wouldn’t think that any decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> >>>
> >>
> >> It may be obvious for many of us but for the sake of completeness I
> >> prefer to have this backwards compatibility assumption explicitely
> >> stated.
> >
> >+1
>
>
> [as a chair]
>
> As last call comment, there seems to be support for adding a requirement
> to the opstate-reqs draft to state that solutions supporting said
> requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to this
> draft?  Are there any objections? Please voice your opinion before the last
> call cutoff date (Dec 30).
>
>
> [as a contributor]
>
>
> I’m unsure if it makes sense to call it out in this draft, in that it
> seems universally applicable, but I don’t see any harm in it either and
> thus do not object.
>
>
> Kent
>
> ___
> 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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Nadeau Thomas]

> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  wrote:
> 
> 
> 
> 
> 
> 
 I’m struggling a bit to understand what is motivating you to ask this 
 question.That is, as a tool vendor, I wouldn’t think that any decision 
 made here would affect you immediately.   My expectations are that any 
 impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that 
 implementations would only opt-in when needed - a pay as you grow 
 strategy.   But herein perhaps lies an unstated requirement, that the 
 impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with 
 respect to existing deployments.  Did we miss it or is it too obvious?
 
>>> 
>>> It may be obvious for many of us but for the sake of completeness I
>>> prefer to have this backwards compatibility assumption explicitely
>>> stated.
>> 
>> +1
> 
> 
> [as a chair]
> 
> As last call comment, there seems to be support for adding a requirement to 
> the opstate-reqs draft to state that solutions supporting said requirements 
> MUST be backwards compatible with respect to existing deployments.  Do we 
> have WG consensus to add this as a requirement to this draft?  Are there any 
> objections? Please voice your opinion before the last call cutoff date (Dec 
> 30).
> 
> 
> [as a contributor]
> 
> 
> I’m unsure if it makes sense to call it out in this draft, in that it seems 
> universally applicable, but I don’t see any harm in it either and thus do not 
> object.
> 
> 
> Kent

[As Co-chair]

Given the tall hill we climbed to get to this point on the 
requirements, I
want to be clear that there needs to be very significant support to change the 
requirements
in any significant way. We went round and round the drain on settling on these 
requirements, and 
people had a whole host of reasonable opportunities to add this during those 
times. I want to point out that while this statement may seem subtle, slipping 
this in at the last minute could have a profound impact on solutions built from 
these requirements, so I want to be sure everyone involved has through through 
this kind of change.

—Tom



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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Martin Bjorklund]

Nadeau Thomas  wrote:
> 
> > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen 
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > 
>  I’m struggling a bit to understand what is motivating you to ask this
>  question.  That is, as a tool vendor, I wouldn’t think that any
>  decision made here would affect you immediately.  My expectations are
>  that any impact to YANG/NETCONF/RESTCONF would be backwards
>  compatible, such that implementations would only opt-in when needed -
>  a pay as you grow strategy.  But herein perhaps lies an unstated
>  requirement, that the impact to YANG/NETCONF/RESTCONF needs to be
>  backwards compatible with respect to existing deployments.  Did we
>  miss it or is it too obvious?
>  
> >>> 
> >>> It may be obvious for many of us but for the sake of completeness I
> >>> prefer to have this backwards compatibility assumption explicitely
> >>> stated.
> >> 
> >> +1
> > 
> > 
> > [as a chair]
> > 
> > As last call comment, there seems to be support for adding a
> > requirement to the opstate-reqs draft to state that solutions
> > supporting said requirements MUST be backwards compatible with respect
> > to existing deployments.  Do we have WG consensus to add this as a
> > requirement to this draft?  Are there any objections? Please voice
> > your opinion before the last call cutoff date (Dec 30).
> > 
> > 
> > [as a contributor]
> > 
> > 
> > I’m unsure if it makes sense to call it out in this draft, in that it
> > seems universally applicable, but I don’t see any harm in it either
> > and thus do not object.
> > 
> > 
> > Kent
> 
>   [As Co-chair]
> 
>   Given the tall hill we climbed to get to this point on the
>   requirements, I
> want to be clear that there needs to be very significant support to
> change the requirements
> in any significant way. We went round and round the drain on settling
> on these requirements, and
> people had a whole host of reasonable opportunities to add this during
> those times. I want to point out that while this statement may seem
> subtle, slipping this in at the last minute could have a profound
> impact on solutions built from these requirements, so I want to be
> sure everyone involved has through through this kind of change.

I think this has been taken for granted.  As such, it is not really a
completely new, last minute, requirement, and I think it makes sense
to explicitly state it.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi Andy,

Please can you let me know whether you think that any of the three 
proposed solutions wouldn't meet this backwards compatibility requirement?


draft-kwatsen-netmod-opstate-00 has some features that might be 
generally useful to NETCONF, like adding  support as defined 
in section 5.1, that I would expect could just be added to a future 
version of NETCONF.  Would a requirement that the solution is backwards 
compatible with existing implementations require that support for 
 must always be optional? Or could a new version of the 
NETCONF protocol require that support for  is required?


Thanks,
Rob


On 17/12/2015 16:06, Andy Bierman wrote:

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.


Andy


On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen > wrote:







>>>I’m struggling a bit to understand what is motivating you to
ask this question.That is, as a tool vendor, I wouldn’t think
that any decision made here would affect you immediately.   My
expectations are that any impact to YANG/NETCONF/RESTCONF would be
backwards compatible, such that implementations would only opt-in
when needed - a pay as you grow strategy.  But herein perhaps lies
an unstated requirement, that the impact to YANG/NETCONF/RESTCONF
needs to be backwards compatible with respect to existing
deployments.  Did we miss it or is it too obvious?
>>>
>>
>> It may be obvious for many of us but for the sake of completeness I
>> prefer to have this backwards compatibility assumption explicitely
>> stated.
>
>+1


[as a chair]

As last call comment, there seems to be support for adding a
requirement to the opstate-reqs draft to state that solutions
supporting said requirements MUST be backwards compatible with
respect to existing deployments.  Do we have WG consensus to add
this as a requirement to this draft?  Are there any objections?
Please voice your opinion before the last call cutoff date (Dec 30).


[as a contributor]


I’m unsure if it makes sense to call it out in this draft, in that
it seems universally applicable, but I don’t see any harm in it
either and thus do not object.


Kent

___
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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> 
> > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > 
>  I’m struggling a bit to understand what is motivating you to ask this 
>  question.That is, as a tool vendor, I wouldn’t think that any 
>  decision made here would affect you immediately.   My expectations are 
>  that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, 
>  such that implementations would only opt-in when needed - a pay as you 
>  grow strategy.   But herein perhaps lies an unstated requirement, that 
>  the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible 
>  with respect to existing deployments.  Did we miss it or is it too 
>  obvious?
>  
> >>> 
> >>> It may be obvious for many of us but for the sake of completeness I
> >>> prefer to have this backwards compatibility assumption explicitely
> >>> stated.
> >> 
> >> +1
> > 
> > 
> > [as a chair]
> > 
> > As last call comment, there seems to be support for adding a requirement to 
> > the opstate-reqs draft to state that solutions supporting said requirements 
> > MUST be backwards compatible with respect to existing deployments.  Do we 
> > have WG consensus to add this as a requirement to this draft?  Are there 
> > any objections? Please voice your opinion before the last call cutoff date 
> > (Dec 30).
> > 
> > 
> > [as a contributor]
> > 
> > 
> > I’m unsure if it makes sense to call it out in this draft, in that it seems 
> > universally applicable, but I don’t see any harm in it either and thus do 
> > not object.
> > 
> > 
> > Kent
> 
>   [As Co-chair]
> 
>   Given the tall hill we climbed to get to this point on the 
> requirements, I
> want to be clear that there needs to be very significant support to change 
> the requirements
> in any significant way. We went round and round the drain on settling on 
> these requirements, and 
> people had a whole host of reasonable opportunities to add this during those 
> times. I want to point out that while this statement may seem subtle, 
> slipping this in at the last minute could have a profound impact on solutions 
> built from these requirements, so I want to be sure everyone involved has 
> through through this kind of change.
> 
>   —Tom

Tom,

I think Andy is talking about applicability - to which kind of servers
do these requirements apply. For example, if it takes more time on a
certain class of devices to retrieve the difference between applied
and intended config than it takes to turn intended config into applied
config, then these requirements may not be applicable (since by the
time you have finished retrieving the difference it has vanished).

Andy, did I get this right?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

Hi,

I already did that:

 All existing protocol
> functionality for NETCONF and RESTCONF MUST continue to work
> for clients which do not choose to examine the differences between
> intended config and applied config.
>
>
Another way to put it:

  The client MUST choose to participate (opt-in).

An example of a solution that meets this requirement

  - The client adds a  flag to an edit-config request
which causes the server to wait until the edit is applied before returning
.
This requires the server to opt-in for the wait, and it is not forced on
the client.


Andy



On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you state the specific text that is being proposed to be added
> as a new requirement?
>
> Thanks,
> Rob
>
>
> On 17/12/2015 17:33, Andy Bierman wrote:
>
> Hi,
>
> I am not commenting on the solution proposals.
> The document being discussed is the requirements document.
> I agree with Juergen that backward compatibility needs to be an
> explicit requirement.  Are you objecting to such a requirement?
>
>
> Andy
>
>
>
>
> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Please can you let me know whether you think that any of the three
>> proposed solutions wouldn't meet this backwards compatibility requirement?
>>
>> draft-kwatsen-netmod-opstate-00 has some features that might be generally
>> useful to NETCONF, like adding  support as defined in section
>> 5.1, that I would expect could just be added to a future version of
>> NETCONF.  Would a requirement that the solution is backwards compatible
>> with existing implementations require that support for  must
>> always be optional?  Or could a new version of the NETCONF protocol require
>> that support for  is required?
>>
>> Thanks,
>> Rob
>>
>>
>> On 17/12/2015 16:06, Andy Bierman wrote:
>>
>> Hi,
>>
>> I agree with Juergen that this should be clear.
>> It was discussed several times.  All existing protocol
>> functionality for NETCONF and RESTCONF MUST continue to work
>> for clients which do not choose to examine the differences between
>> intended config and applied config.
>>
>>
>> Andy
>>
>>
>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < 
>> kwat...@juniper.net> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>> >>>I’m struggling a bit to understand what is motivating you to ask this
>>> question.That is, as a tool vendor, I wouldn’t think that any decision
>>> made here would affect you immediately.   My expectations are that any
>>> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
>>> implementations would only opt-in when needed - a pay as you grow
>>> strategy.   But herein perhaps lies an unstated requirement, that the
>>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>>> respect to existing deployments.  Did we miss it or is it too obvious?
>>> >>>
>>> >>
>>> >> It may be obvious for many of us but for the sake of completeness I
>>> >> prefer to have this backwards compatibility assumption explicitely
>>> >> stated.
>>> >
>>> >+1
>>>
>>>
>>> [as a chair]
>>>
>>> As last call comment, there seems to be support for adding a requirement
>>> to the opstate-reqs draft to state that solutions supporting said
>>> requirements MUST be backwards compatible with respect to existing
>>> deployments.  Do we have WG consensus to add this as a requirement to this
>>> draft?  Are there any objections? Please voice your opinion before the last
>>> call cutoff date (Dec 30).
>>>
>>>
>>> [as a contributor]
>>>
>>>
>>> I’m unsure if it makes sense to call it out in this draft, in that it
>>> seems universally applicable, but I don’t see any harm in it either and
>>> thus do not object.
>>>
>>>
>>> Kent
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
>> ___
>> netmod mailing 
>> listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Thu, Dec 17, 2015 at 9:29 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> >
> > > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen 
> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> >  I’m struggling a bit to understand what is motivating you to ask
> this question.That is, as a tool vendor, I wouldn’t think that any
> decision made here would affect you immediately.   My expectations are that
> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such
> that implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> > 
> > >>>
> > >>> It may be obvious for many of us but for the sake of completeness I
> > >>> prefer to have this backwards compatibility assumption explicitely
> > >>> stated.
> > >>
> > >> +1
> > >
> > >
> > > [as a chair]
> > >
> > > As last call comment, there seems to be support for adding a
> requirement to the opstate-reqs draft to state that solutions supporting
> said requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to this
> draft?  Are there any objections? Please voice your opinion before the last
> call cutoff date (Dec 30).
> > >
> > >
> > > [as a contributor]
> > >
> > >
> > > I’m unsure if it makes sense to call it out in this draft, in that it
> seems universally applicable, but I don’t see any harm in it either and
> thus do not object.
> > >
> > >
> > > Kent
> >
> >   [As Co-chair]
> >
> >   Given the tall hill we climbed to get to this point on the
> requirements, I
> > want to be clear that there needs to be very significant support to
> change the requirements
> > in any significant way. We went round and round the drain on settling on
> these requirements, and
> > people had a whole host of reasonable opportunities to add this during
> those times. I want to point out that while this statement may seem subtle,
> slipping this in at the last minute could have a profound impact on
> solutions built from these requirements, so I want to be sure everyone
> involved has through through this kind of change.
> >
> >   —Tom
>
> Tom,
>
> I think Andy is talking about applicability - to which kind of servers
> do these requirements apply. For example, if it takes more time on a
> certain class of devices to retrieve the difference between applied
> and intended config than it takes to turn intended config into applied
> config, then these requirements may not be applicable (since by the
> time you have finished retrieving the difference it has vanished).
>
> Andy, did I get this right?
>

pretty much.

I can see how the time delay is subjective and depends on the use-case
and the operator preferences.  In 1 deployment a delay of 5 seconds
is not a concern, and in another it is a concern.

The solution does not have to polling.
The server can send 1 indication when intended == applied for the entire
datastore,
or it can answer a million individual "are you done yet?" queries from the
client.
Both could be considered solutions to the same problem.


> /js
>

Andy


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> 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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi Andy,

Please can you state the specific text that is being proposed to be 
added as a new requirement?


Thanks,
Rob


On 17/12/2015 17:33, Andy Bierman wrote:

Hi,

I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement.  Are you objecting to such a requirement?


Andy




On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton > wrote:


Hi Andy,

Please can you let me know whether you think that any of the three
proposed solutions wouldn't meet this backwards compatibility
requirement?

draft-kwatsen-netmod-opstate-00 has some features that might be
generally useful to NETCONF, like adding  support as
defined in section 5.1, that I would expect could just be added to
a future version of NETCONF.  Would a requirement that the
solution is backwards compatible with existing implementations
require that support for  must always be optional?  Or
could a new version of the NETCONF protocol require that support
for  is required?

Thanks,
Rob


On 17/12/2015 16:06, Andy Bierman wrote:

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.


Andy


On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen > wrote:






>>>I’m struggling a bit to understand what is motivating you
to ask this question.   That is, as a tool vendor, I wouldn’t
think that any decision made here would affect you
immediately.   My expectations are that any impact to
YANG/NETCONF/RESTCONF would be backwards compatible, such
that implementations would only opt-in when needed - a pay as
you grow strategy.   But herein perhaps lies an unstated
requirement, that the impact to YANG/NETCONF/RESTCONF needs
to be backwards compatible with respect to existing
deployments.  Did we miss it or is it too obvious?
>>>
>>
>> It may be obvious for many of us but for the sake of
completeness I
>> prefer to have this backwards compatibility assumption
explicitely
>> stated.
>
>+1


[as a chair]

As last call comment, there seems to be support for adding a
requirement to the opstate-reqs draft to state that solutions
supporting said requirements MUST be backwards compatible
with respect to existing deployments.  Do we have WG
consensus to add this as a requirement to this draft?  Are
there any objections? Please voice your opinion before the
last call cutoff date (Dec 30).


[as a contributor]


I’m unsure if it makes sense to call it out in this draft, in
that it seems universally applicable, but I don’t see any
harm in it either and thus do not object.


Kent

___
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





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

Hi,

I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement.  Are you objecting to such a requirement?


Andy




On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you let me know whether you think that any of the three
> proposed solutions wouldn't meet this backwards compatibility requirement?
>
> draft-kwatsen-netmod-opstate-00 has some features that might be generally
> useful to NETCONF, like adding  support as defined in section
> 5.1, that I would expect could just be added to a future version of
> NETCONF.  Would a requirement that the solution is backwards compatible
> with existing implementations require that support for  must
> always be optional?  Or could a new version of the NETCONF protocol require
> that support for  is required?
>
> Thanks,
> Rob
>
>
> On 17/12/2015 16:06, Andy Bierman wrote:
>
> Hi,
>
> I agree with Juergen that this should be clear.
> It was discussed several times.  All existing protocol
> functionality for NETCONF and RESTCONF MUST continue to work
> for clients which do not choose to examine the differences between
> intended config and applied config.
>
>
> Andy
>
>
> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen  wrote:
>
>>
>>
>>
>>
>>
>> >>>I’m struggling a bit to understand what is motivating you to ask this
>> question.That is, as a tool vendor, I wouldn’t think that any decision
>> made here would affect you immediately.   My expectations are that any
>> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
>> implementations would only opt-in when needed - a pay as you grow
>> strategy.   But herein perhaps lies an unstated requirement, that the
>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>> respect to existing deployments.  Did we miss it or is it too obvious?
>> >>>
>> >>
>> >> It may be obvious for many of us but for the sake of completeness I
>> >> prefer to have this backwards compatibility assumption explicitely
>> >> stated.
>> >
>> >+1
>>
>>
>> [as a chair]
>>
>> As last call comment, there seems to be support for adding a requirement
>> to the opstate-reqs draft to state that solutions supporting said
>> requirements MUST be backwards compatible with respect to existing
>> deployments.  Do we have WG consensus to add this as a requirement to this
>> draft?  Are there any objections? Please voice your opinion before the last
>> call cutoff date (Dec 30).
>>
>>
>> [as a contributor]
>>
>>
>> I’m unsure if it makes sense to call it out in this draft, in that it
>> seems universally applicable, but I don’t see any harm in it either and
>> thus do not object.
>>
>>
>> Kent
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi Andy,

Thanks for resending and apologies for missing it earlier.

Your requirement is a bit too strong for my liking.

To paraphrase your requirement text, it is forcing that all compliant 
NETCONF/RESTCONF servers MUST support any clients that do not want to 
differentiate between intended config and applied config.


However, this requires all opstate aware servers:
 - To handle a mix of clients, some of which are opstate aware, and 
some that are not.
 - To potentially handle a mix of requests, some of which are opstate 
aware requests, and some are not.


It also prevents:
 - Having a server that is implemented to only support opstate aware 
clients.
 - Having a server side configuration knob to control the behaviour 
(since it would affect the semantics for all clients).



Personally, I think that the best solutions will likely meet your 
proposed requirement below, but I don't agree that it should be 
mandated, even though I agree that it is something that the solution 
should aim for.


Changing the MUST to SHOULD would make the requirement fine with me ...

Finally, regarding your example below, I didn't think that the existing 
NETCONF protocol semantics specify exactly when the server is required 
to respond to the client, and hence blocking the client until the 
configuration has been applied would be a valid edit-config 
implementation under the existing NETCONF specification.


Thanks,
Rob


On 17/12/2015 18:26, Andy Bierman wrote:

Hi,

I already did that:


 All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.




Another way to put it:

  The client MUST choose to participate (opt-in).

An example of a solution that meets this requirement

  - The client adds a  flag to an edit-config 
request
which causes the server to wait until the edit is applied before 
returning .
This requires the server to opt-in for the wait, and it is not forced 
on the client.



Andy


On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton > wrote:


Hi Andy,

Please can you state the specific text that is being proposed to
be added as a new requirement?

Thanks,
Rob


On 17/12/2015 17:33, Andy Bierman wrote:

Hi,

I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement.  Are you objecting to such a requirement?


Andy




On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton > wrote:

Hi Andy,

Please can you let me know whether you think that any of the
three proposed solutions wouldn't meet this backwards
compatibility requirement?

draft-kwatsen-netmod-opstate-00 has some features that might
be generally useful to NETCONF, like adding 
support as defined in section 5.1, that I would expect could
just be added to a future version of NETCONF.  Would a
requirement that the solution is backwards compatible with
existing implementations require that support for 
must always be optional?  Or could a new version of the
NETCONF protocol require that support for  is
required?

Thanks,
Rob


On 17/12/2015 16:06, Andy Bierman wrote:

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences
between
intended config and applied config.


Andy


On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen
> wrote:






>>>I’m struggling a bit to understand what is motivating
you to ask this question.That is, as a tool vendor,
I wouldn’t think that any decision made here would
affect you immediately.   My expectations are that any
impact to YANG/NETCONF/RESTCONF would be backwards
compatible, such that implementations would only opt-in
when needed - a pay as you grow strategy.   But herein
perhaps lies an unstated requirement, that the impact to
YANG/NETCONF/RESTCONF needs to be backwards compatible
with respect to existing deployments.  Did we miss it or
is it too obvious?
>>>
>>
>> It may be obvious for many of us but for the sake of
completeness I
>> prefer to have this backwards compatibility
assumption explicitely
>> stated.
>
>+1


[as a chair]

 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

Hi,

I think the current operations need to continue to work.
With the current  or  the client does
not know if the server applied the config or just accepted the request.

With the new solution, I expect that a client that does not explicitly ask
for "wait until applied" will get the old (unspecified) behavior.


Andy



On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton  wrote:

> Hi Andy,
>
> Thanks for resending and apologies for missing it earlier.
>
> Your requirement is a bit too strong for my liking.
>
> To paraphrase your requirement text, it is forcing that all compliant
> NETCONF/RESTCONF servers MUST support any clients that do not want to
> differentiate between intended config and applied config.
>
> However, this requires all opstate aware servers:
>  - To handle a mix of clients, some of which are opstate aware, and some
> that are not.
>  - To potentially handle a mix of requests, some of which are opstate
> aware requests, and some are not.
>
> It also prevents:
>  - Having a server that is implemented to only support opstate aware
> clients.
>  - Having a server side configuration knob to control the behaviour (since
> it would affect the semantics for all clients).
>
>
> Personally, I think that the best solutions will likely meet your proposed
> requirement below, but I don't agree that it should be mandated, even
> though I agree that it is something that the solution should aim for.
>
> Changing the MUST to SHOULD would make the requirement fine with me ...
>
> Finally, regarding your example below, I didn't think that the existing
> NETCONF protocol semantics specify exactly when the server is required to
> respond to the client, and hence blocking the client until the
> configuration has been applied would be a valid edit-config implementation
> under the existing NETCONF specification.
>
> Thanks,
> Rob
>
>
> On 17/12/2015 18:26, Andy Bierman wrote:
>
> Hi,
>
> I already did that:
>
>  All existing protocol
>> functionality for NETCONF and RESTCONF MUST continue to work
>> for clients which do not choose to examine the differences between
>> intended config and applied config.
>>
>>
> Another way to put it:
>
>   The client MUST choose to participate (opt-in).
>
> An example of a solution that meets this requirement
>
>   - The client adds a  flag to an edit-config request
> which causes the server to wait until the edit is applied before returning
> .
> This requires the server to opt-in for the wait, and it is not forced on
> the client.
>
>
> Andy
>
>
>
> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Please can you state the specific text that is being proposed to be added
>> as a new requirement?
>>
>> Thanks,
>> Rob
>>
>>
>> On 17/12/2015 17:33, Andy Bierman wrote:
>>
>> Hi,
>>
>> I am not commenting on the solution proposals.
>> The document being discussed is the requirements document.
>> I agree with Juergen that backward compatibility needs to be an
>> explicit requirement.  Are you objecting to such a requirement?
>>
>>
>> Andy
>>
>>
>>
>>
>> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton < 
>> rwil...@cisco.com> wrote:
>>
>>> Hi Andy,
>>>
>>> Please can you let me know whether you think that any of the three
>>> proposed solutions wouldn't meet this backwards compatibility requirement?
>>>
>>> draft-kwatsen-netmod-opstate-00 has some features that might be
>>> generally useful to NETCONF, like adding  support as defined in
>>> section 5.1, that I would expect could just be added to a future version of
>>> NETCONF.  Would a requirement that the solution is backwards compatible
>>> with existing implementations require that support for  must
>>> always be optional?  Or could a new version of the NETCONF protocol require
>>> that support for  is required?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 17/12/2015 16:06, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I agree with Juergen that this should be clear.
>>> It was discussed several times.  All existing protocol
>>> functionality for NETCONF and RESTCONF MUST continue to work
>>> for clients which do not choose to examine the differences between
>>> intended config and applied config.
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < 
>>> kwat...@juniper.net> wrote:
>>>





 >>>I’m struggling a bit to understand what is motivating you to ask
 this question.That is, as a tool vendor, I wouldn’t think that any
 decision made here would affect you immediately.   My expectations are that
 any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such
 that implementations would only opt-in when needed - a pay as you grow
 strategy.   But herein perhaps lies an unstated requirement, that the
 impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
 respect to existing deployments.  Did we miss it or is it too obvious?
 >>>

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman  wrote:

> Hi,
>
> I think the current operations need to continue to work.
> With the current  or  the client does
> not know if the server applied the config or just accepted the request.
>
> With the new solution, I expect that a client that does not explicitly ask
> for "wait until applied" will get the old (unspecified) behavior.
>
>
> Andy
>
>
>
> On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Thanks for resending and apologies for missing it earlier.
>>
>> Your requirement is a bit too strong for my liking.
>>
>> To paraphrase your requirement text, it is forcing that all compliant
>> NETCONF/RESTCONF servers MUST support any clients that do not want to
>> differentiate between intended config and applied config.
>>
>> However, this requires all opstate aware servers:
>>  - To handle a mix of clients, some of which are opstate aware, and some
>> that are not.
>>  - To potentially handle a mix of requests, some of which are opstate
>> aware requests, and some are not.
>>
>>

This is simple to achieve by adding optional parameters that a new client
will set
and an old client will not know about.



> It also prevents:
>>  - Having a server that is implemented to only support opstate aware
>> clients.
>>  - Having a server side configuration knob to control the behaviour
>> (since it would affect the semantics for all clients).
>>
>>


Not true, since the current RFC behavior is undefined.
A server vendor can choose right now to only return  after
all intended is applied.

The new feature will be that a client can explicitly request this behavior
and a compliant server will support it.  If the client does not request it,
then
there is a chance that operations will time out that did not use to time
out.
This will be very visible and disruptive to operators, and perceived as a
bug.





>
>> Personally, I think that the best solutions will likely meet your
>> proposed requirement below, but I don't agree that it should be mandated,
>> even though I agree that it is something that the solution should aim for.
>>
>> Changing the MUST to SHOULD would make the requirement fine with me ...
>>
>> Finally, regarding your example below, I didn't think that the existing
>> NETCONF protocol semantics specify exactly when the server is required to
>> respond to the client, and hence blocking the client until the
>> configuration has been applied would be a valid edit-config implementation
>> under the existing NETCONF specification.
>>
>

Yes it would be valid, but it might generate unhappy customers with broken
client applications just the same.



>
>> Thanks,
>> Rob
>>
>

Andy


>
>>
>> On 17/12/2015 18:26, Andy Bierman wrote:
>>
>> Hi,
>>
>> I already did that:
>>
>>  All existing protocol
>>> functionality for NETCONF and RESTCONF MUST continue to work
>>> for clients which do not choose to examine the differences between
>>> intended config and applied config.
>>>
>>>
>> Another way to put it:
>>
>>   The client MUST choose to participate (opt-in).
>>
>> An example of a solution that meets this requirement
>>
>>   - The client adds a  flag to an edit-config
>> request
>> which causes the server to wait until the edit is applied before
>> returning .
>> This requires the server to opt-in for the wait, and it is not forced on
>> the client.
>>
>>
>> Andy
>>
>>
>>
>> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton 
>> wrote:
>>
>>> Hi Andy,
>>>
>>> Please can you state the specific text that is being proposed to be
>>> added as a new requirement?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 17/12/2015 17:33, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I am not commenting on the solution proposals.
>>> The document being discussed is the requirements document.
>>> I agree with Juergen that backward compatibility needs to be an
>>> explicit requirement.  Are you objecting to such a requirement?
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton < 
>>> rwil...@cisco.com> wrote:
>>>
 Hi Andy,

 Please can you let me know whether you think that any of the three
 proposed solutions wouldn't meet this backwards compatibility requirement?

 draft-kwatsen-netmod-opstate-00 has some features that might be
 generally useful to NETCONF, like adding  support as defined in
 section 5.1, that I would expect could just be added to a future version of
 NETCONF.  Would a requirement that the solution is backwards compatible
 with existing implementations require that support for  must
 always be optional?  Or could a new version of the NETCONF protocol require
 that support for  is required?

 Thanks,
 Rob


 On 17/12/2015 16:06, Andy Bierman wrote:

 Hi,

 I agree with Juergen that this should be clear.
 It was discussed several times.  All existing protocol
 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi Andy,

On 17/12/2015 22:14, Andy Bierman wrote:



On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman > wrote:


Hi,

I think the current operations need to continue to work.
With the current  or  the client does
not know if the server applied the config or just accepted the
request.

With the new solution, I expect that a client that does not
explicitly ask
for "wait until applied" will get the old (unspecified) behavior.


Andy



On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton > wrote:

Hi Andy,

Thanks for resending and apologies for missing it earlier.

Your requirement is a bit too strong for my liking.

To paraphrase your requirement text, it is forcing that all
compliant NETCONF/RESTCONF servers MUST support any clients
that do not want to differentiate between intended config and
applied config.

However, this requires all opstate aware servers:
 - To handle a mix of clients, some of which are opstate
aware, and some that are not.
 - To potentially handle a mix of requests, some of which are
opstate aware requests, and some are not.



This is simple to achieve by adding optional parameters that a new 
client will set

and an old client will not know about.


My point is really that it may be harder for servers to support clients 
using a mix of semantics.


It still feels to me that at this stage of just considering/comparing 
solutions we shouldn't rule out a server potentially being able to 
declare that it only supports/implements opstate-aware semantics, which 
I think that your requirement would. For some devices, if all customers 
are only asking for opstate-aware semantics, then do we really also have 
to support the non opstate-aware semantics as well?





It also prevents:
 - Having a server that is implemented to only support opstate
aware clients.
 - Having a server side configuration knob to control the
behaviour (since it would affect the semantics for all clients).



Not true, since the current RFC behavior is undefined.
A server vendor can choose right now to only return  after
all intended is applied.

The new feature will be that a client can explicitly request this behavior
and a compliant server will support it.  If the client does not 
request it, then
there is a chance that operations will time out that did not use to 
time out.
This will be very visible and disruptive to operators, and perceived 
as a bug.


Technically the bug would be in the client rather than the server here, 
but I don't deny that the client operator would necessarily perceive it 
the same way.  But shouldn't this be up to the implementer to weight up 
the benefits of a potentially simpler server solution vs the impacts to 
existing clients?







Personally, I think that the best solutions will likely meet
your proposed requirement below, but I don't agree that it
should be mandated, even though I agree that it is something
that the solution should aim for.

Changing the MUST to SHOULD would make the requirement fine
with me ...

Finally, regarding your example below, I didn't think that the
existing NETCONF protocol semantics specify exactly when the
server is required to respond to the client, and hence
blocking the client until the configuration has been applied
would be a valid edit-config implementation under the existing
NETCONF specification.



Yes it would be valid, but it might generate unhappy customers with broken
client applications just the same.
It still doesn't feel like a good requirement that states that an 
opstate-aware server must preserve support for some existing, but 
unspecified, behaviour.  If the new more tightly defined behaviour is 
compliant with the existing unspecified behaviour then it feels like 
that should be a valid implementation choice to treat both of them the 
same way.


Thanks,
Rob





Thanks,
Rob



Andy



On 17/12/2015 18:26, Andy Bierman wrote:

Hi,

I already did that:


 All existing protocol
functionality for NETCONF and RESTCONF MUST continue to
work
for clients which do not choose to examine the
differences between
intended config and applied config.




Another way to put it:

  The client MUST choose to participate (opt-in).

An example of a solution that meets this requirement

  - The client adds a  flag to an
edit-config request
which causes the server to wait until the edit is applied
before returning .
This requires the server to opt-in for the wait, and it is
not forced on the client.


Andy

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Randy Presuhn]

Hi -

> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
...
> Your requirement is a bit too strong for my liking.
>
> To paraphrase your requirement text, it is forcing that all
> compliant NETCONF/RESTCONF servers MUST support any clients that do
> not want to differentiate between intended config and applied
> config.

Do do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.

> However, this requires all opstate aware servers:
>
>  - To handle a mix of clients, some of which are opstate aware, and
>  some that are not.

This seems perfectly reasonable.  To do otherwise torpedoes the very
notion of interoperability.

>  - To potentially handle a mix of requests, some of which are
>  opstate aware requests, and some are not.

Ditto. 

> It also prevents:
>
>  - Having a server that is implemented to only support opstate aware
>  clients.

Avoiding the creation of such servers sounds like a *good* thing to me.

>  - Having a server side configuration knob to control the behaviour
>  (since it would affect the semantics for all clients).

This also sounds like something which it would be desireable to prevent.

I think I'm squarely with Andy on this one.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

[as a contributor]

Hi Andy,

I’m struggling a bit to understand what is motivating you to ask this question. 
   That is, as a tool vendor, I wouldn’t think that any decision made here 
would affect you immediately.   My expectations are that any impact to 
YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations 
would only opt-in when needed - a pay as you grow strategy.   But herein 
perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF 
needs to be backwards compatible with respect to existing deployments.  Did we 
miss it or is it too obvious?

I agree that supporting these requirements will be unnecessary for many 
platforms.  After all, we’ve gone decades without needing such visibility, and 
that’s not going to change for many platforms for some time, if ever.

You ask for objective metrics for determining solution applicability.  My 
thinking is to just let the market decide - is it not good enough?   If I tried 
to quantify it, I might say that its only useful for networking devices (as 
their operational state somehow matters more?) and that it’s only useful when 
there is no guarantee that the intended config will become operational (i.e. 
applied) in some bounded amount of time.   Just throwing out ideas here, but I 
like best letting the market decide.

Kent


From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, December 16, 2015 at 7:21 PM
To: Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>
Cc: "netmod-cha...@tools.ietf.org<mailto:netmod-cha...@tools.ietf.org>" 
<netmod-cha...@tools.ietf.org<mailto:netmod-cha...@tools.ietf.org>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such that 
retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.


Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
<tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>> wrote:

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Thu, Dec 17, 2015 at 02:18:42AM +, Kent Watsen wrote:
> 
> [as a contributor]
> 
> Hi Andy,
> 
> I’m struggling a bit to understand what is motivating you to ask this 
> question.That is, as a tool vendor, I wouldn’t think that any decision 
> made here would affect you immediately.   My expectations are that any impact 
> to YANG/NETCONF/RESTCONF would be backwards compatible, such that 
> implementations would only opt-in when needed - a pay as you grow strategy.   
> But herein perhaps lies an unstated requirement, that the impact to 
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to 
> existing deployments.  Did we miss it or is it too obvious?
>

It may be obvious for many of us but for the sake of completeness I
prefer to have this backwards compatibility assumption explicitely
stated.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Nadeau Thomas]

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such
that retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.


Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
wrote:

>
> This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
> Please post comments on this draft by Wednesday, December 30, 2015
> at 9AM EST.
>
> Tom/Kent
>
>
> ___
> 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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Wed, Dec 16, 2015 at 6:18 PM, Kent Watsen <kwat...@juniper.net> wrote:

>
> [as a contributor]
>
> Hi Andy,
>
> I’m struggling a bit to understand what is motivating you to ask this
> question.That is, as a tool vendor, I wouldn’t think that any decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow strategy.
>   But herein perhaps lies an unstated requirement, that the impact to
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to
> existing deployments.  Did we miss it or is it too obvious?
>
> I agree that supporting these requirements will be unnecessary for many
> platforms.  After all, we’ve gone decades without needing such visibility,
> and that’s not going to change for many platforms for some time, if ever.
>
> You ask for objective metrics for determining solution applicability.  My
> thinking is to just let the market decide - is it not good enough?   If I
> tried to quantify it, I might say that its only useful for networking
> devices (as their operational state somehow matters more?) and that it’s
> only useful when there is no guarantee that the intended config will become
> operational (i.e. applied) in some bounded amount of time.   Just throwing
> out ideas here, but I like best letting the market decide.
>
>

There seemed to be agreement that most devices will apply intended config
within 5 seconds (not counting the 'waiting for line card' corner-case).
We usually see exec. times way under 1 sec., but if others are having
a problem with delays, I guess they will find this work useful.



> Kent
>


Andy


>
>
> From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <
> a...@yumaworks.com>
> Date: Wednesday, December 16, 2015 at 7:21 PM
> To: Thomas Nadeau <tnad...@lucidvision.com>
> Cc: "netmod-cha...@tools.ietf.org" <netmod-cha...@tools.ietf.org>, "
> netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
> Hi,
>
> I have asked repeatedly for some indication of scope in these requirements.
> There is an assumption all possible YANG-based platforms have intended
> and applied state that can be different for a long enough interval such
> that retrieving
> the differences is operationally useful.
>
> For devices that converge in milli-seconds or even as long as 5 seconds,
> I do not see the point of implementing solutions for these requirements.
> I would prefer that this draft specify some sort of objective
> metric for determining the solution applicability.
>
>
> Andy
>
>
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <tnad...@lucidvision.com>
> wrote:
>
>>
>> This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
>> Please post comments on this draft by Wednesday, December 30, 2015
>> at 9AM EST.
>>
>> Tom/Kent
>>
>>
>> ___
>> 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

[netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Nadeau Thomas]

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod