Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On Tue, Feb 09, 2016 at 11:17:13AM +, Robert Wilton wrote: > > > On 08/02/2016 16:20, Juergen Schoenwaelder wrote: > >On Mon, Feb 08, 2016 at 01:21:52PM +, Robert Wilton wrote: > >>So, IIRC, your concern is specifically that a generic YANG client > >>library cannot validate that the RPC

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[chair hat on] >But I wonder whether the OpenConfig operators might also ask the WG the >same question of whether a datastore solution is orders of magnitude >better than the OpenConfig solution? > >My best guess is that at the moment they would regard a datastore >solution as being

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On 08/02/2016 16:20, Juergen Schoenwaelder wrote: On Mon, Feb 08, 2016 at 01:21:52PM +, Robert Wilton wrote: So, IIRC, your concern is specifically that a generic YANG client library cannot validate that the RPC reply is well formed against the schema without knowledge about the request.

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On 08/02/2016 21:37, Martin Bjorklund wrote: Robert Wilton wrote: On 08/02/2016 19:41, Martin Bjorklund wrote: Hi, Robert Wilton wrote: Hi Martin, On 08/02/2016 13:45, Martin Bjorklund wrote: Robert Wilton wrote: On 06/02/2016

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

>Can you please suggest an approach of how to return a single tree that >contains the data from two separate datastores (where the leaf paths may >overlap)? I think that the approach would need to work both for get >requests and also notification data. I know that this is a difference

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi Lou, >>>I know that this is a difference between the solutions, but I don’t see it >>>listed as a requirement. There is a requirement to return the diff, but >>>that’s all. Is there actually a need to return both sets of data? - or is >>>this just a desire for the diff to be able

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Kent, On 2/9/2016 10:42 AM, Kent Watsen wrote: > > > >> Can you please suggest an approach of how to return a single tree that >> contains the data from two separate datastores (where the leaf paths may >> overlap)? I think that the approach would need to work both for get >> requests and

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On Mon, Feb 08, 2016 at 05:26:13PM +0100, Eliot Lear wrote: > Juergen, > > On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote: > > > None of the existing tools that assume YANG defined data is XML > > encoded according to RFC 6020 will not be able to process data in a > > new encoding. > >

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Juergen, On 2/8/16 5:20 PM, Juergen Schoenwaelder wrote: > None of the existing tools that assume YANG defined data is XML > encoded according to RFC 6020 will not be able to process data in a > new encoding. Reversing you're negatives you are asserting that all existing tools that assume that

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi, The XML namespace matches the YANG namespace-stmt. The JSON module name prefix matches the YANG module name. All YANG tools use these instance document mechanisms to find the correct YANG schema to apply. All YANG tools will correctly decide the opstate reporting does not match the YANG

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On Mon, Feb 08, 2016 at 01:21:52PM +, Robert Wilton wrote: > > So, IIRC, your concern is specifically that a generic YANG client > library cannot validate that the RPC reply is well formed against the > schema without knowledge about the request. Is that correct? > None of the existing

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On 06/02/2016 00:41, Andy Bierman wrote: On Fri, Feb 5, 2016 at 4:23 AM, Juergen Schoenwaelder > wrote: On Fri, Feb 05, 2016 at 10:09:37AM +, Robert Wilton wrote: > Hi Juergen, > > I

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi Martin, On 08/02/2016 13:45, Martin Bjorklund wrote: Robert Wilton wrote: On 06/02/2016 00:41, Andy Bierman wrote: [...] IMO, this solution is a non-starter. OK, and yet my understanding is that the folks requesting a solution to the opstate problem are saying that

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Robert Wilton wrote: > > > On 06/02/2016 00:41, Andy Bierman wrote: [...] > > IMO, this solution is a non-starter. > OK, and yet my understanding is that the folks requesting a solution > to the opstate problem are saying that the applied datastore approach > is also a

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Robert Wilton wrote: > > > On 08/02/2016 19:41, Martin Bjorklund wrote: > > Hi, > > > > Robert Wilton wrote: > >> Hi Martin, > >> > >> On 08/02/2016 13:45, Martin Bjorklund wrote: > >>> Robert Wilton wrote: > On 06/02/2016 00:41,

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

On 08/02/2016 19:41, Martin Bjorklund wrote: Hi, Robert Wilton wrote: Hi Martin, On 08/02/2016 13:45, Martin Bjorklund wrote: Robert Wilton wrote: On 06/02/2016 00:41, Andy Bierman wrote: [...] IMO, this solution is a non-starter. OK, and yet my

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi, Robert Wilton wrote: > Hi Martin, > > On 08/02/2016 13:45, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 06/02/2016 00:41, Andy Bierman wrote: > > [...] > > > >>> IMO, this solution is a non-starter. > >> OK, and yet my understanding is

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

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

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

This I-D seems to break core design assumptions of YANG data encoding works and hence it seems to break all existing implementations. If you define leaf mtu { type uint32; } then this is encoded as 9000 and there is not room for mixed content. I am stictly against any solution that is not

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Juergen Schoenwaelder wrote: > This I-D seems to break core design assumptions of YANG data encoding > works and hence it seems to break all existing implementations. If you > define > > leaf mtu { type uint32; } > > then this is encoded as > > 9000 >

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Rob, Thanks for the response, see below. On February 5, 2016 6:36:47 AM Robert Wilton wrote: Hi Lou (& Chris), Thanks for the comments. On 04/02/2016 22:31, Lou Berger wrote: Hello, A few of us in the routing area architecture yang DT discussed this draft yesterday and

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi Lou (& Chris), Thanks for the comments. On 04/02/2016 22:31, Lou Berger wrote: Hello, A few of us in the routing area architecture yang DT discussed this draft yesterday and had a couple of comments, (note that the open config contributors who are members of the design team did not

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

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

[netmod] a few comments on draft-wilton-netmod-opstate-yang

Hello, A few of us in the routing area architecture yang DT discussed this draft yesterday and had a couple of comments, (note that the open config contributors who are members of the design team did not participate in this discussion): - that with tooling, it is possible for the models