[netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-yang)

[Lou Berger]

Hi Juergen, (All)

I've change the subject line as I'm really commenting on all three
documented options in this message.

On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
 wrote:

> Lou,
>
> there are things I find fundamentally flawed and things I find
> somewhat flawed. I do not understand why we need to mess around with
> data encodings at all. I do not see what gets simpler by messing
> around with the data encodings. Engineering decisions are usually
> cost/benefit tradeoffs.

I completely agree with this statement, as a general statement. the
motivation in this case is that users are saying that the current
solution is inadequate. I think it behooves us to listen and see if a
better tool can be provided that addresses the limitations raised.

> I see the costs, I am unsure about the
> benefits.
>

I think this is a question of perspective. I get that from a protocol
standpoint, and possibly even language standpoint, why this  discussion
can  be considered unneeded complexity. I wouldn't even be surprised if
the open config folks agreed with you, as the core of  their solution
really doesn't need changes to the underlying protocol or language.

As I see it, there are three options on the table to address the core
issue of OpState:

1. Do nothing in Netconf / restconf or yang, and leave it to  model
conventions = openconfig draft

2. Extend Netconf / restconf , but not yang or models = Kent's draft

3. Use a language / tools based approach to augment models and
automatically produce a form of option 1  style convention changes,
without model definition restrictions. ~= Rob's draft (I'll assume
changes previously discussed on list)

WRT 1: We've heard from the model development community, i.e. model
writers, that 1 is doable but painful and easily done incorrectly. It
also impacts other SDOs, i.e. non ietf model writers.

WRT 2: We heard from the user community, at least a small number of
representatives, that 2 alone doesn't address their needs.  But it's
also clear that some in the WG would prefer Option 2 (and most/all of
these are its coauthors.)

WRT 3: There's some discussion on how/if Option 3 might best meet the
user requirements.  I think focusing on this approach on the list could
be helpful.

One question I have for you, Juergen, and the other authors of 2 is if
there are changes/improvements to 3 that you/the can see that would make
acceptable? Note I am NOT asking which the authors prefer as this is clear.

For the authors of 1, I think it would be worth hearing if a
language/tools based approach to populating the Applied Configuration
information is workable for them.

Lou

> /js
>
> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
>> Juergen,
>>
>> How do you feel about the proposed modification on the table? (Leaving the
>> model defined config leaves untouched and adding a -CFG or -metadata
>> sibling node which would contain the additional automatically generated
>> leaves.)
>>
>> Lou
>>
>>
>> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
>>  wrote:
>>
>> >On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
>> >>Hi Juergen,
>> >>
>> >>I don't really follow your point.
>> >>
>> >>The solution is fully backward compatible - in that only clients that
>> >>make use of the protocol extension would see the new encoding. Existing
>> >>clients would continue to see the encoding as directly defined in the
>> >>YANG schema, and a server would be able to support old and new clients
>> >>concurrently.
>> >>
>> >
>> >The YANG RFC details how data is encoded in XML. People have written
>> >and deployed code against based on this RFC. I do not accept an
>> >approach where an RPC option can simply request that the encoding
>> >defined in the YANG RFC is ignored and replaced with a very different
>> >encoding.
>> >
>> >/js (stating a clear opinion as a technical contributor)
>> >
>> >--
>> >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
>> >
>>
>>
>
> --
> 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] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-yang)

[Lou Berger]

Thanks Andy -- It seems to me that there are aspects of your comments
that apply to each...

Lou

On 2/8/2016 3:29 PM, Andy Bierman wrote:
> Hi,
>
>
> I was commenting on solution 1.
>
>
> Andy
>
> On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger  > wrote:
>
> Hi Andy,
>
> Thanks for the very good comments.
>
> Which solutions(s) were you commenting on -- you say "this" so is
> ambiguous.
>
> Lou
>
> On 2/8/2016 2:17 PM, Andy Bierman wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger  
> > >> wrote:
> >
> > Hi Juergen, (All)
> >
> > I've change the subject line as I'm really commenting on all
> three
> > documented options in this message.
> >
> > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
> >  
> >  >> wrote:
> >
> > > Lou,
> > >
> > > there are things I find fundamentally flawed and things I find
> > > somewhat flawed. I do not understand why we need to mess
> around with
> > > data encodings at all. I do not see what gets simpler by
> messing
> > > around with the data encodings. Engineering decisions are
> usually
> > > cost/benefit tradeoffs.
> >
> > I completely agree with this statement, as a general
> statement. the
> > motivation in this case is that users are saying that the
> current
> > solution is inadequate. I think it behooves us to listen and
> see if a
> > better tool can be provided that addresses the limitations
> raised.
> >
> > > I see the costs, I am unsure about the
> > > benefits.
> > >
> >
> > I think this is a question of perspective. I get that from a
> protocol
> > standpoint, and possibly even language standpoint, why this
> > discussion
> > can  be considered unneeded complexity. I wouldn't even be
> > surprised if
> > the open config folks agreed with you, as the core of  their
> solution
> > really doesn't need changes to the underlying protocol or
> language.
> >
> > As I see it, there are three options on the table to address
> the core
> > issue of OpState:
> >
> > 1. Do nothing in Netconf / restconf or yang, and leave it
> to  model
> > conventions = openconfig draft
> >
> > 2. Extend Netconf / restconf , but not yang or models =
> Kent's draft
> >
> > 3. Use a language / tools based approach to augment models and
> > automatically produce a form of option 1  style convention
> changes,
> > without model definition restrictions. ~= Rob's draft (I'll
> assume
> > changes previously discussed on list)
> >
> > WRT 1: We've heard from the model development community,
> i.e. model
> > writers, that 1 is doable but painful and easily done
> incorrectly. It
> > also impacts other SDOs, i.e. non ietf model writers.
> >
> >
> >
> > This solution assumes that the overhead of retrieving data
> (while the
> > server
> > is applying config) does not impact performance.  IMO retrieving 2
> > separate
> > data trees and comparing them on the client uses a lot of
> bandwidth and
> > it makes the server even more busy, so applying the config will take
> > even longer.
>
> >
> > The only solution possible by replicating the YANG objects would
> be to
> > retrieve both trees and compare them on the client.
> >
> > I prefer a solution that does not involve any polling by the client,
> > such as a notification based solution.
> >
> > Since operations are data-driven in YANG, implementing a new RPC
> > is the same cost as implementing new YANG data nodes.
> >
> >
> > Andy
> >
> >
> > WRT 2: We heard from the user community, at least a small
> number of
> > representatives, that 2 alone doesn't address their needs. 
> But it's
> > also clear that some in the WG would prefer Option 2 (and
> most/all of
> > these are its coauthors.)
> >
> > WRT 3: There's some discussion on how/if Option 3 might best
> meet the
> > user requirements.  I think focusing on this approach on the
> list
> > could
> > be helpful.
> >
> > One question I have for you, Juergen, and the other authors
> of 2 is if
> > there are changes/improvements to 3 that you/the can see that
> > would make
> 

Re: [netmod] OpState Solution Options

[Lou Berger]

Martin,
Thanks for the response.  See below.

On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
> Hi,
>
> Lou Berger  wrote:
>> Hi Juergen, (All)
>>
>> I've change the subject line as I'm really commenting on all three
>> documented options in this message.
>>
>> On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
>>  wrote:
>>
>>> Lou,
>>>
>>> there are things I find fundamentally flawed and things I find
>>> somewhat flawed. I do not understand why we need to mess around with
>>> data encodings at all. I do not see what gets simpler by messing
>>> around with the data encodings. Engineering decisions are usually
>>> cost/benefit tradeoffs.
>> I completely agree with this statement, as a general statement.
> I agree with Juergen - I read his statement to be about Robert's
> proposed solution.  
>
>> the
>> motivation in this case is that users are saying that the current
>> solution is inadequate.
> Which solution is the current solution?

anything in an rfc or soon to be an rfc. IMO.

>
>> I think it behooves us to listen and see if a
>> better tool can be provided that addresses the limitations raised.
>>
>>> I see the costs, I am unsure about the
>>> benefits.
>>>
>> I think this is a question of perspective. I get that from a protocol
>> standpoint, and possibly even language standpoint, why this  discussion
>> can  be considered unneeded complexity. I wouldn't even be surprised if
>> the open config folks agreed with you, as the core of  their solution
>> really doesn't need changes to the underlying protocol or language.
>>
>> As I see it, there are three options on the table to address the core
>> issue of OpState:
>>
>> 1. Do nothing in Netconf / restconf or yang, and leave it to  model
>> conventions = openconfig draft
>>
>> 2. Extend Netconf / restconf , but not yang or models = Kent's draft
>>
>> 3. Use a language / tools based approach to augment models and
>> automatically produce a form of option 1  style convention changes,
>> without model definition restrictions. ~= Rob's draft (I'll assume
>> changes previously discussed on list)
>>
>> WRT 1: We've heard from the model development community, i.e. model
>> writers, that 1 is doable but painful and easily done incorrectly. It
>> also impacts other SDOs, i.e. non ietf model writers.
>>
>> WRT 2: We heard from the user community, at least a small number of
>> representatives, that 2 alone doesn't address their needs.
> We have heard from the open config people that their proprietary
> protocol does not support datastores, but no more details.

I think I've heard users say what they believe is true from their
perspective and context.  I've heard others say we disagree (or stronger
statements.)

>> But it's
>> also clear that some in the WG would prefer Option 2 (and most/all of
>> these are its coauthors.)
> This was the preferred solution of the room in Yokohama.  2 of the 4
> authors were present.
sure.  And we know that the IETF consensus is not judged by who is in
the room.  It is of course useful information to the WG and the chairs.

>> WRT 3: There's some discussion on how/if Option 3 might best meet the
>> user requirements.  I think focusing on this approach on the list could
>> be helpful.
>>
>> One question I have for you, Juergen, and the other authors of 2 is if
>> there are changes/improvements to 3 that you/the can see that would make
>> acceptable? Note I am NOT asking which the authors prefer as this is clear.
> I think this solution is pretty messy.  Also, it is unclear to me how
> it affects things like filtering and access control for example.  Can
> instance-identifiers all refer to these auto-generated nodes; are
> these nodes really part of the model or not?  How is partial locking
> affected?  There are lots of details to work out.

This is useful comments and would like to see what the options
are/should be WRT Option 3.  Do you have any opinions on this?

Thanks,
Lou
>
>
> /martin
>
>
>
>> For the authors of 1, I think it would be worth hearing if a
>> language/tools based approach to populating the Applied Configuration
>> information is workable for them.
>>
>> Lou
>>
>>> /js
>>>
>>> On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
 Juergen,

 How do you feel about the proposed modification on the table? (Leaving the
 model defined config leaves untouched and adding a -CFG or -metadata
 sibling node which would contain the additional automatically generated
 leaves.)

 Lou


 On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
  wrote:

> On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
>> Hi Juergen,
>>
>> I don't really follow your point.
>>
>> The solution is fully backward compatible - in that only clients that
>> make use of the protocol extension would see the new encoding. Existing
>> clients would 

Re: [netmod] OpState Solution Options

[Lou Berger]

[retry]

Martin,


On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>> Thanks for the response.  See below.
>>
>> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Lou Berger  wrote:
> [...]
>
 But it's
 also clear that some in the WG would prefer Option 2 (and most/all of
 these are its coauthors.)
>>> This was the preferred solution of the room in Yokohama.  2 of the 4
>>> authors were present.
>> sure.  And we know that the IETF consensus is not judged by who is in
>> the room.  It is of course useful information to the WG and the chairs.
> You wrote "most/all of [those who prefer option 2] are its coauthors".
I was referring to the on-list discussion, but fair point.  But keep in
mind that an in-person meeting isn't an authoritative source of WG
consensus from the IETF process standpoint.

> My observation was that just 2 of the coauthors were in the room, and
> still this was the preferred solution; thus I think that your
> statement that I quoted is incorrect.
>
okay, let me modify my comment:
OLD
and most/all of these are its coauthors
NEW
at very least its coauthors

Lou

> /martin
>


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

Re: [netmod] OpState Solution Options

[Martin Bjorklund]

Lou Berger  wrote:
> Martin,
> Thanks for the response.  See below.
> 
> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
> > Hi,
> >
> > Lou Berger  wrote:

[...]

> >> I think this is a question of perspective. I get that from a protocol
> >> standpoint, and possibly even language standpoint, why this  discussion
> >> can  be considered unneeded complexity. I wouldn't even be surprised if
> >> the open config folks agreed with you, as the core of  their solution
> >> really doesn't need changes to the underlying protocol or language.
> >>
> >> As I see it, there are three options on the table to address the core
> >> issue of OpState:
> >>
> >> 1. Do nothing in Netconf / restconf or yang, and leave it to  model
> >> conventions = openconfig draft
> >>
> >> 2. Extend Netconf / restconf , but not yang or models = Kent's draft
> >>
> >> 3. Use a language / tools based approach to augment models and
> >> automatically produce a form of option 1  style convention changes,
> >> without model definition restrictions. ~= Rob's draft (I'll assume
> >> changes previously discussed on list)
> >>
> >> WRT 1: We've heard from the model development community, i.e. model
> >> writers, that 1 is doable but painful and easily done incorrectly. It
> >> also impacts other SDOs, i.e. non ietf model writers.
> >>
> >> WRT 2: We heard from the user community, at least a small number of
> >> representatives, that 2 alone doesn't address their needs.
> > We have heard from the open config people that their proprietary
> > protocol does not support datastores, but no more details.
> 
> I think I've heard users say what they believe is true from their
> perspective and context.  I've heard others say we disagree (or stronger
> statements.)
> 
> >> But it's
> >> also clear that some in the WG would prefer Option 2 (and most/all of
> >> these are its coauthors.)
> > This was the preferred solution of the room in Yokohama.  2 of the 4
> > authors were present.
>
> sure.  And we know that the IETF consensus is not judged by who is in
> the room.  It is of course useful information to the WG and the chairs.

You wrote "most/all of [those who prefer option 2] are its coauthors".

My observation was that just 2 of the coauthors were in the room, and
still this was the preferred solution; thus I think that your
statement that I quoted is incorrect.


/martin

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

Re: [netmod] OpState Solution Options

[Martin Bjorklund]

Hi,

Lou Berger  wrote:
> Hi Juergen, (All)
> 
> I've change the subject line as I'm really commenting on all three
> documented options in this message.
> 
> On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
>  wrote:
> 
> > Lou,
> >
> > there are things I find fundamentally flawed and things I find
> > somewhat flawed. I do not understand why we need to mess around with
> > data encodings at all. I do not see what gets simpler by messing
> > around with the data encodings. Engineering decisions are usually
> > cost/benefit tradeoffs.
> 
> I completely agree with this statement, as a general statement.

I agree with Juergen - I read his statement to be about Robert's
proposed solution.  

> the
> motivation in this case is that users are saying that the current
> solution is inadequate.

Which solution is the current solution?

> I think it behooves us to listen and see if a
> better tool can be provided that addresses the limitations raised.
> 
> > I see the costs, I am unsure about the
> > benefits.
> >
> 
> I think this is a question of perspective. I get that from a protocol
> standpoint, and possibly even language standpoint, why this  discussion
> can  be considered unneeded complexity. I wouldn't even be surprised if
> the open config folks agreed with you, as the core of  their solution
> really doesn't need changes to the underlying protocol or language.
> 
> As I see it, there are three options on the table to address the core
> issue of OpState:
> 
> 1. Do nothing in Netconf / restconf or yang, and leave it to  model
> conventions = openconfig draft
> 
> 2. Extend Netconf / restconf , but not yang or models = Kent's draft
> 
> 3. Use a language / tools based approach to augment models and
> automatically produce a form of option 1  style convention changes,
> without model definition restrictions. ~= Rob's draft (I'll assume
> changes previously discussed on list)
> 
> WRT 1: We've heard from the model development community, i.e. model
> writers, that 1 is doable but painful and easily done incorrectly. It
> also impacts other SDOs, i.e. non ietf model writers.
> 
> WRT 2: We heard from the user community, at least a small number of
> representatives, that 2 alone doesn't address their needs.

We have heard from the open config people that their proprietary
protocol does not support datastores, but no more details.

> But it's
> also clear that some in the WG would prefer Option 2 (and most/all of
> these are its coauthors.)

This was the preferred solution of the room in Yokohama.  2 of the 4
authors were present.

> WRT 3: There's some discussion on how/if Option 3 might best meet the
> user requirements.  I think focusing on this approach on the list could
> be helpful.
> 
> One question I have for you, Juergen, and the other authors of 2 is if
> there are changes/improvements to 3 that you/the can see that would make
> acceptable? Note I am NOT asking which the authors prefer as this is clear.

I think this solution is pretty messy.  Also, it is unclear to me how
it affects things like filtering and access control for example.  Can
instance-identifiers all refer to these auto-generated nodes; are
these nodes really part of the model or not?  How is partial locking
affected?  There are lots of details to work out.


/martin



> For the authors of 1, I think it would be worth hearing if a
> language/tools based approach to populating the Applied Configuration
> information is workable for them.
> 
> Lou
> 
> > /js
> >
> > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
> >> Juergen,
> >>
> >> How do you feel about the proposed modification on the table? (Leaving the
> >> model defined config leaves untouched and adding a -CFG or -metadata
> >> sibling node which would contain the additional automatically generated
> >> leaves.)
> >>
> >> Lou
> >>
> >>
> >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
> >>  wrote:
> >>
> >> >On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
> >> >>Hi Juergen,
> >> >>
> >> >>I don't really follow your point.
> >> >>
> >> >>The solution is fully backward compatible - in that only clients that
> >> >>make use of the protocol extension would see the new encoding. Existing
> >> >>clients would continue to see the encoding as directly defined in the
> >> >>YANG schema, and a server would be able to support old and new clients
> >> >>concurrently.
> >> >>
> >> >
> >> >The YANG RFC details how data is encoded in XML. People have written
> >> >and deployed code against based on this RFC. I do not accept an
> >> >approach where an RPC option can simply request that the encoding
> >> >defined in the YANG RFC is ignored and replaced with a very different
> >> >encoding.
> >> >
> >> >/js (stating a clear opinion as a technical contributor)
> >> >
> >> >--
> >> >Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> >Phone: +49 

Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-yang)

[Lou Berger]

Hi Andy,

Thanks for the very good comments. 

Which solutions(s) were you commenting on -- you say "this" so is ambiguous.

Lou

On 2/8/2016 2:17 PM, Andy Bierman wrote:
>
>
> On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger  > wrote:
>
> Hi Juergen, (All)
>
> I've change the subject line as I'm really commenting on all three
> documented options in this message.
>
> On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
>  > wrote:
>
> > Lou,
> >
> > there are things I find fundamentally flawed and things I find
> > somewhat flawed. I do not understand why we need to mess around with
> > data encodings at all. I do not see what gets simpler by messing
> > around with the data encodings. Engineering decisions are usually
> > cost/benefit tradeoffs.
>
> I completely agree with this statement, as a general statement. the
> motivation in this case is that users are saying that the current
> solution is inadequate. I think it behooves us to listen and see if a
> better tool can be provided that addresses the limitations raised.
>
> > I see the costs, I am unsure about the
> > benefits.
> >
>
> I think this is a question of perspective. I get that from a protocol
> standpoint, and possibly even language standpoint, why this 
> discussion
> can  be considered unneeded complexity. I wouldn't even be
> surprised if
> the open config folks agreed with you, as the core of  their solution
> really doesn't need changes to the underlying protocol or language.
>
> As I see it, there are three options on the table to address the core
> issue of OpState:
>
> 1. Do nothing in Netconf / restconf or yang, and leave it to  model
> conventions = openconfig draft
>
> 2. Extend Netconf / restconf , but not yang or models = Kent's draft
>
> 3. Use a language / tools based approach to augment models and
> automatically produce a form of option 1  style convention changes,
> without model definition restrictions. ~= Rob's draft (I'll assume
> changes previously discussed on list)
>
> WRT 1: We've heard from the model development community, i.e. model
> writers, that 1 is doable but painful and easily done incorrectly. It
> also impacts other SDOs, i.e. non ietf model writers.
>
>
>
> This solution assumes that the overhead of retrieving data (while the
> server
> is applying config) does not impact performance.  IMO retrieving 2
> separate
> data trees and comparing them on the client uses a lot of bandwidth and
> it makes the server even more busy, so applying the config will take
> even longer.

>
> The only solution possible by replicating the YANG objects would be to
> retrieve both trees and compare them on the client.
>
> I prefer a solution that does not involve any polling by the client,
> such as a notification based solution.
>
> Since operations are data-driven in YANG, implementing a new RPC
> is the same cost as implementing new YANG data nodes.
>
>
> Andy
>  
>
> WRT 2: We heard from the user community, at least a small number of
> representatives, that 2 alone doesn't address their needs.  But it's
> also clear that some in the WG would prefer Option 2 (and most/all of
> these are its coauthors.)
>
> WRT 3: There's some discussion on how/if Option 3 might best meet the
> user requirements.  I think focusing on this approach on the list
> could
> be helpful.
>
> One question I have for you, Juergen, and the other authors of 2 is if
> there are changes/improvements to 3 that you/the can see that
> would make
> acceptable? Note I am NOT asking which the authors prefer as this
> is clear.
>
> For the authors of 1, I think it would be worth hearing if a
> language/tools based approach to populating the Applied Configuration
> information is workable for them.
>
> Lou
>
> > /js
> >
> > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
> >> Juergen,
> >>
> >> How do you feel about the proposed modification on the table?
> (Leaving the
> >> model defined config leaves untouched and adding a -CFG or
> -metadata
> >> sibling node which would contain the additional automatically
> generated
> >> leaves.)
> >>
> >> Lou
> >>
> >>
> >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
> >>  > wrote:
> >>
> >> >On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote:
> >> >>Hi Juergen,
> >> >>
> >> >>I don't really follow your point.
> >> >>
> >> >>The solution is fully backward compatible - in that only
> clients that
> >> >>make use of the protocol extension would see the new
>  

Re: [netmod] OpState Solution Options (Was: Re: a few comments on draft-wilton-netmod-opstate-yang)

[Andy Bierman]

Hi,


I was commenting on solution 1.


Andy

On Mon, Feb 8, 2016 at 11:57 AM, Lou Berger  wrote:

> Hi Andy,
>
> Thanks for the very good comments.
>
> Which solutions(s) were you commenting on -- you say "this" so is
> ambiguous.
>
> Lou
>
> On 2/8/2016 2:17 PM, Andy Bierman wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:56 AM, Lou Berger  > > wrote:
> >
> > Hi Juergen, (All)
> >
> > I've change the subject line as I'm really commenting on all three
> > documented options in this message.
> >
> > On February 5, 2016 12:41:17 PM Juergen Schoenwaelder
> >  > > wrote:
> >
> > > Lou,
> > >
> > > there are things I find fundamentally flawed and things I find
> > > somewhat flawed. I do not understand why we need to mess around
> with
> > > data encodings at all. I do not see what gets simpler by messing
> > > around with the data encodings. Engineering decisions are usually
> > > cost/benefit tradeoffs.
> >
> > I completely agree with this statement, as a general statement. the
> > motivation in this case is that users are saying that the current
> > solution is inadequate. I think it behooves us to listen and see if a
> > better tool can be provided that addresses the limitations raised.
> >
> > > I see the costs, I am unsure about the
> > > benefits.
> > >
> >
> > I think this is a question of perspective. I get that from a protocol
> > standpoint, and possibly even language standpoint, why this
> > discussion
> > can  be considered unneeded complexity. I wouldn't even be
> > surprised if
> > the open config folks agreed with you, as the core of  their solution
> > really doesn't need changes to the underlying protocol or language.
> >
> > As I see it, there are three options on the table to address the core
> > issue of OpState:
> >
> > 1. Do nothing in Netconf / restconf or yang, and leave it to  model
> > conventions = openconfig draft
> >
> > 2. Extend Netconf / restconf , but not yang or models = Kent's draft
> >
> > 3. Use a language / tools based approach to augment models and
> > automatically produce a form of option 1  style convention changes,
> > without model definition restrictions. ~= Rob's draft (I'll assume
> > changes previously discussed on list)
> >
> > WRT 1: We've heard from the model development community, i.e. model
> > writers, that 1 is doable but painful and easily done incorrectly. It
> > also impacts other SDOs, i.e. non ietf model writers.
> >
> >
> >
> > This solution assumes that the overhead of retrieving data (while the
> > server
> > is applying config) does not impact performance.  IMO retrieving 2
> > separate
> > data trees and comparing them on the client uses a lot of bandwidth and
> > it makes the server even more busy, so applying the config will take
> > even longer.
>
> >
> > The only solution possible by replicating the YANG objects would be to
> > retrieve both trees and compare them on the client.
> >
> > I prefer a solution that does not involve any polling by the client,
> > such as a notification based solution.
> >
> > Since operations are data-driven in YANG, implementing a new RPC
> > is the same cost as implementing new YANG data nodes.
> >
> >
> > Andy
> >
> >
> > WRT 2: We heard from the user community, at least a small number of
> > representatives, that 2 alone doesn't address their needs.  But it's
> > also clear that some in the WG would prefer Option 2 (and most/all of
> > these are its coauthors.)
> >
> > WRT 3: There's some discussion on how/if Option 3 might best meet the
> > user requirements.  I think focusing on this approach on the list
> > could
> > be helpful.
> >
> > One question I have for you, Juergen, and the other authors of 2 is
> if
> > there are changes/improvements to 3 that you/the can see that
> > would make
> > acceptable? Note I am NOT asking which the authors prefer as this
> > is clear.
> >
> > For the authors of 1, I think it would be worth hearing if a
> > language/tools based approach to populating the Applied Configuration
> > information is workable for them.
> >
> > Lou
> >
> > > /js
> > >
> > > On Fri, Feb 05, 2016 at 07:52:33AM -0500, Lou Berger wrote:
> > >> Juergen,
> > >>
> > >> How do you feel about the proposed modification on the table?
> > (Leaving the
> > >> model defined config leaves untouched and adding a -CFG or
> > -metadata
> > >> sibling node which would contain the additional automatically
> > generated
> > >> leaves.)
> > >>
> > >> Lou
> > >>
> > >>
> > >> On February 5, 2016 7:24:29 AM Juergen Schoenwaelder
> > >>  > 

Re: [netmod] OpState Solution Options

[Kent Watsen]

[As co-chair]

Andy et al.,

Please keep in mind this message from Benoit:

https://www.ietf.org/mail-archive/web/netmod/current/msg14585.html

And note that Lou is trying to perform the analysis now.

Thanks,
Kent


From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Monday, February 8, 2016 at 3:58 PM
To: Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>
Cc: Martin Bjorklund <m...@tail-f.com<mailto:m...@tail-f.com>>, Juergen 
Schoenwaelder 
<j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>,
 
"draft-openconfig-netmod-opst...@ietf.org<mailto:draft-openconfig-netmod-opst...@ietf.org>"
 
<draft-openconfig-netmod-opst...@ietf.org<mailto:draft-openconfig-netmod-opst...@ietf.org>>,
 
"draft-kwatsen-netmod-opst...@ietf.org<mailto:draft-kwatsen-netmod-opst...@ietf.org>"
 
<draft-kwatsen-netmod-opst...@ietf.org<mailto:draft-kwatsen-netmod-opst...@ietf.org>>,
 "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpState Solution Options

Hi,

It should be up to the co-chairs to make consensus calls.
The IETF 94 minutes indicate that "solution 2" (RPC-based)
had consensus in the room.

https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

I have not seen any evidence that room consensus has changed on the mailing 
list.


Andy



On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger 
<lber...@labn.net<mailto:lber...@labn.net>> wrote:
[retry]

Martin,


On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
> Lou Berger <lber...@labn.net<mailto:lber...@labn.net>> wrote:
>> Martin,
>> Thanks for the response.  See below.
>>
>> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Lou Berger <lber...@labn.net<mailto:lber...@labn.net>> wrote:
> [...]
>
>>>> But it's
>>>> also clear that some in the WG would prefer Option 2 (and most/all of
>>>> these are its coauthors.)
>>> This was the preferred solution of the room in Yokohama.  2 of the 4
>>> authors were present.
>> sure.  And we know that the IETF consensus is not judged by who is in
>> the room.  It is of course useful information to the WG and the chairs.
> You wrote "most/all of [those who prefer option 2] are its coauthors".
I was referring to the on-list discussion, but fair point.  But keep in
mind that an in-person meeting isn't an authoritative source of WG
consensus from the IETF process standpoint.

> My observation was that just 2 of the coauthors were in the room, and
> still this was the preferred solution; thus I think that your
> statement that I quoted is incorrect.
>
okay, let me modify my comment:
OLD
and most/all of these are its coauthors
NEW
at very least its coauthors

Lou

> /martin
>



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