Re: [netmod] augment and if-feature

On 17/03/2017 14:03, Dale R. Worley wrote: Robert Wilton writes: To quote Joey's example, I think that both of the following modules are valid (presuming that they are both implemented by a device) regardless of which features are enabled. Do you agree? module base-module { p

Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00

the {{param|SerialNumber}} parameter is unique. Thanks, Rob On 17 Mar 2017, at 12:55, Ladislav Lhotka wrote: Hi Rob, thank you for reading the draft. On 17 Mar 2017, at 13:30, Robert Wilton wrote: Hi Lada, I've had a quick scan of your YANG markup extension draft and I have a few com

Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00

On 17/03/2017 12:55, Ladislav Lhotka wrote: Hi Rob, thank you for reading the draft. On 17 Mar 2017, at 13:30, Robert Wilton wrote: Hi Lada, I've had a quick scan of your YANG markup extension draft and I have a few comments: Allowing description, and similar descriptive statement

Re: [netmod] draft netmod charter update proposal

Hi, Would 7950bis be allowed to have a normative reference to an Informational RFC that defined the YANG datastores? If we did a 7950bis document (and it isn't clear that one is actually required to support the revised datastores draft) then does that mean we would also need to have a new ve

[netmod] Comments on draft-lhotka-netmod-yang-markup-00

Hi Lada, I've had a quick scan of your YANG markup extension draft and I have a few comments: Allowing description, and similar descriptive statements, to use something other than text seems like it could be useful in some cases. I'm not sure that allowing the statements to use any text-lik

Re: [netmod] augment and if-feature

On 16/03/2017 17:26, Andy Bierman wrote: On Thu, Mar 16, 2017 at 10:18 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: Hi Andy, On 16/03/2017 16:17, Andy Bierman wrote: On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton mailto:rwil...@cisco.com>> wrote:

Re: [netmod] augment and if-feature

Hi Andy, On 16/03/2017 16:17, Andy Bierman wrote: On Thu, Mar 16, 2017 at 2:54 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: Hi Dale, On 15/03/2017 19:02, Dale R. Worley wrote: JOEY BOYD mailto:joey.b...@adtran.com>> writes: mod

[netmod] Combining if-feature statements

YANG nodes can have multiple if-feature statements. Its not entirely obvious to me how if-feature statements combine for a given node. I presume that a node is supported if all if-feature statements on the node are valid. Is this the correct interpretation? I.e. in the example below, "thing

Re: [netmod] augment and if-feature

Hi Dale, On 15/03/2017 19:02, Dale R. Worley wrote: JOEY BOYD writes: module base-module { prefix bmod; feature do-things; container things { if-feature do-things; ... } } module augment-module { prefix amod; augment "/bmod:do-things" { container other-thi

Re: [netmod] augment and if-feature

On 15/03/2017 10:20, Martin Bjorklund wrote: Robert Wilton wrote: Hi, On 15/03/2017 07:28, Martin Bjorklund wrote: Phil Shafer wrote: Martin Bjorklund writes: Phil Shafer wrote: Martin Bjorklund writes: What are your thoughts on this? Surely, an augment should not have to contain if

Re: [netmod] augment and if-feature

Hi, On 15/03/2017 07:28, Martin Bjorklund wrote: Phil Shafer wrote: Martin Bjorklund writes: Phil Shafer wrote: Martin Bjorklund writes: What are your thoughts on this? Surely, an augment should not have to contain if-feature statements of all parents of the augmented node. The spec says:

Re: [netmod] stable reference for tree diagram notation

e doc is fine. does this mean the contents of the tree diagram and the syntax for the tree diagram are subject to WG consensus? That would seem to make sense, given that they are used in all drafts describing YANG models. Rob Andy On 3/13/2017 2:20 PM, Robert Wilton wrote: > Hi And

Re: [netmod] stable reference for tree diagram notation

Hi Martin, It looks like it needs a further tweak to also wrap augments. I just tried (with the latest master off github) and hasn't wrapped the augment line. E.g. module: ietf-if-l3-vlan augment /if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type: +--:(vlan)

Re: [netmod] stable reference for tree diagram notation

Hi Andy, Would it make sense to update 6087bis section 4.4 to reference this new pyang option for generated tree diagrams? Thanks, Rob On 11/03/2017 21:49, Martin Bjorklund wrote: "Acee Lindem (acee)" wrote: Hi Juergen, On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder" wro

Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

Lada, Thanks for the comments, some further comments inline ... On 10/03/2017 14:09, Ladislav Lhotka wrote: Hi Rob, please see inline. Robert Wilton writes: Hi Lada, To pick up an old thread, I'm updating the interface model per your comments below, and I had a few questions tha

Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

Hi Lada, To pick up an old thread, I'm updating the interface model per your comments below, and I had a few questions that you might have an opinion on. On 22/12/2016 14:32, Robert Wilton wrote: Hi Lada, Thanks for the review and comments. On 21/12/2016 13:08, Ladislav Lhotka wrote

Re: [netmod] stable reference for tree diagram notation

On 08/03/2017 20:57, Kent Watsen wrote: This way, reader can focus more quickly on the diffs, but also this likely mimics what happened in reality (start with `pyang -f tree` and then manually edit from there). What do you think? Manually edited tree diagrams? I hope not. Perhaps we shoul

Re: [netmod] RFC 7950 - Import without revision

On 07/03/2017 17:03, Martin Bjorklund wrote: Robert Wilton wrote: in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by Revision" states: "If a module is not imported with a specific revision, it is undefined which revision is used." But I was wondering

Re: [netmod] RFC 7950 - Import without revision

en.* I think that section 5.6.5 does define which revision is used (as the text below). I.e. it is the most recent revision out of all the module revisions that are imported or implemented. Rob On 27/02/2017 11:15, Robert Wilton wrote: in RFC 7950, The last paragraph, section 5.1.1 "Import

Re: [netmod] yanglint and implemented versus imported YANG modules

Hi William, I think that what yanglint is doing here is sane, i.e. I think that its interpretation/split between imported vs implemented modules is supported by the YANG RFC. However, for validation purposes it seems that it would be useful if yanglint had an option to assume that all import

Re: [netmod] draft netmod charter update proposal

Hi Lada, On 01/03/2017 10:45, Ladislav Lhotka wrote: On 1 Mar 2017, at 10:46, Juergen Schoenwaelder wrote: On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote: So are we going through all NETMOD/NETCONF documents now to replace 'encoding' with 'representation', which also includ

Re: [netmod] draft netmod charter update proposal

On 27/02/2017 20:31, Kent Watsen wrote: Hi Rob, Hi Kent, Lou, I think that it might possibly be a good idea to please align the timelines for: draft-ietf-netmod-intf-ext-yang draft-ietf-netmod-sub-intf-vlan-yang because I think that it will be somewhat helpful to review both documen

Re: [netmod] draft netmod charter update proposal

On 27/02/2017 21:41, Lou Berger wrote: Hi Rob, On 2/27/2017 3:31 PM, Kent Watsen wrote: Hi Rob, Hi Kent, Lou, I think that it might possibly be a good idea to please align the timelines for: draft-ietf-netmod-intf-ext-yang draft-ietf-netmod-sub-intf-vlan-yang because I think that

Re: [netmod] draft netmod charter update proposal

Hi Kent, Lou, I think that it might possibly be a good idea to please align the timelines for: draft-ietf-netmod-intf-ext-yang draft-ietf-netmod-sub-intf-vlan-yang because I think that it will be somewhat helpful to review both documents together. Also, I just wanted to confirm that th

[netmod] RFC 7950 - Import without revision

in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by Revision" states: "If a module is not imported with a specific revision, it is undefined which revision is used." But I was wondering if the above text is misleading, since section 5.6.5: "Implementing a Module" has the fo

Re: [netmod] Module tags

On 14/02/2017 16:30, Christian Hopps wrote: Robert Wilton writes: On 14/02/2017 14:08, Christian Hopps wrote: Robert Wilton writes: Hi tags draft authors, On 09/02/2017 12:28, Lou Berger wrote: I'm personally more excited by the use of tags as additional module meta-data accessibl

Re: [netmod] Module tags

On 14/02/2017 14:08, Christian Hopps wrote: Robert Wilton writes: Hi tags draft authors, On 09/02/2017 12:28, Lou Berger wrote: I'm personally more excited by the use of tags as additional module meta-data accessible via yang library. But also see no reason to preclude this possible

Re: [netmod] Module tags

On 13/02/2017 18:19, Kent Watsen wrote: As for a concrete use-case, would something like this be helpful for a server to indicate which datastores a module is supported in? I'm not sure. I would probably prefer to see the two kept separate, but it may depend on what the scope of modules tags

Re: [netmod] Module tags

Hi tags draft authors, On 09/02/2017 12:28, Lou Berger wrote: I'm personally more excited by the use of tags as additional module meta-data accessible via yang library. But also see no reason to preclude this possible (even if unlikely) usage. When the idea of tags was presented as IETF, I

Re: [netmod] YANG 1.1 range-stmt

On 06/02/2017 07:55, Martin Bjorklund wrote: Andy Bierman wrote: Hi, I noticed a new difference between our YANG compiler and pyang. leaf X { type int8; range "1 .. 1"; } pyang says this is an error: error: range error: "1" is not larger than "1" yangdump-pro does no

Re: [netmod] proposal to add 2 new guidelines in 6087bis

On 30/01/2017 20:07, Ladislav Lhotka wrote: On 30 Jan 2017, at 19:09, Robert Wilton wrote: On 30/01/2017 17:52, Andy Bierman wrote: On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton wrote: Hi Andy, Lada, On 28/01/2017 16:23, Andy Bierman wrote: On Sat, Jan 28, 2017 at 2:54 AM, Ladislav

Re: [netmod] proposal to add 2 new guidelines in 6087bis

On 30/01/2017 17:52, Andy Bierman wrote: On Mon, Jan 30, 2017 at 3:38 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: Hi Andy, Lada, On 28/01/2017 16:23, Andy Bierman wrote: On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka mailto:lho...@nic.cz>> wrote:

Re: [netmod] Are multiple revisions with the same date allowed?

en in most organizations this is unlikely to happen (at least this is what we assumed). /js On Mon, Jan 30, 2017 at 11:50:20AM +0000, Robert Wilton wrote: RFC 7950 doesn't state that the date associated with revision statements in a YANG module must be unique. Hence, I presume that it i

[netmod] Are multiple revisions with the same date allowed?

RFC 7950 doesn't state that the date associated with revision statements in a YANG module must be unique. Hence, I presume that it is intentionally allowed to have multiple revision statements with the same date. E.g. the following module is allowed (and passes pyang --lint): module rev-exa

Re: [netmod] proposal to add 2 new guidelines in 6087bis

Hi Andy, Lada, On 28/01/2017 16:23, Andy Bierman wrote: On Sat, Jan 28, 2017 at 2:54 AM, Ladislav Lhotka > wrote: > On 27 Jan 2017, at 20:23, Andy Bierman mailto:a...@yumaworks.com>> wrote: > > Hi, > > The "pyang --ietf" validator checks the statem

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

I would suggest tweaking the order of the words slightly: Old: The interpretation of any *other character then* the ones listed above following a backslash is undefined. Authors are advised to avoid using such backslash sequences in double-quoted strings in their YANG modules. New: The interpr

Re: [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[Dropping netconf from the reply] Hi Phil, On 18/01/2017 21:26, Phil Shafer wrote: Robert Wilton writes: The server is buggy if it is sending data that violates YANG constraints. If any of these statements need to be different for config and oper then the old style YANG has to be used instead

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

Hi Phil, Wouldn't you just write this without the back reference to the deprecated/obsolete leaf. E.g. wouldn't the following be sufficient to enforce the desired constraint? leaf old-stuff { status deprecated; must not(../new-stuff); } leaf new-stuff { } Than

Re: [netmod] [Technical Errata Reported] RFC6020 (4911)

Hi Lada, I don't feel strongly, but basically agree with Martin. The YANG 1.0 spec is ambiguous, YANG 1.1 has fixed that. I guess that most pragmatic YANG 1.0 implementations would treat a backslash followed by something other than n,t,", or / as just a backslash character. This issue seems

[netmod] Combined config/state trees [was Re: Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits]

e life harder for implementors since they will need to hard code the relationship between the the config and state tree. Having a single tree avoids this problem because it automatically forces the config and state to be consistently co-located. Rob Andy On Fri, Jan 13, 2017 at 8:21 AM, R

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

[keeping netmod, bcc netconf] On 12/01/2017 22:05, Andy Bierman wrote: On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund > wrote: Ladislav Lhotka mailto:lho...@nic.cz>> wrote: > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > mailto:j.schoenwa

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 12/01/2017 17:38, Andy Bierman wrote: On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder > wrote: On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > YANG statements: >- It is not possible to define these

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 11/01/2017 20:32, Andy Bierman wrote: On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <mailto:lho...@nic.cz>> wrote: > On 11 Jan 2017, at 17:56, Andy Bierman mailto:a...@yumaworks.com>> wrote: > > Hi, > > > On Wed, Jan 1

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 11/01/2017 16:56, Andy Bierman wrote: Hi, On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: On 11/01/2017 09:22, Martin Bjorklund wrote: Andy Bierman mailto:a...@yumaworks.com>> wrote: On Tue, Jan 10,

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 11/01/2017 20:32, Andy Bierman wrote: On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <mailto:lho...@nic.cz>> wrote: > On 11 Jan 2017, at 17:56, Andy Bierman mailto:a...@yumaworks.com>> wrote: > > Hi, > > > On Wed, Jan 1

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 11/01/2017 09:22, Martin Bjorklund wrote: Andy Bierman wrote: On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen wrote: I think it is better to have a human decide what is in the module instead of relying on a pyang plugin to generate some additional module that follows some simplistic patter

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 11/01/2017 14:48, Ladislav Lhotka wrote: On 11 Jan 2017, at 15:18, Robert Wilton wrote: Hi, On 11/01/2017 13:05, Ladislav Lhotka wrote: On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: Ladislav Lhotka wrote: Show me a single YANG data node definition that's duplicate

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Hi, On 11/01/2017 13:05, Ladislav Lhotka wrote: On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: Ladislav Lhotka wrote: Show me a single YANG data node definition that's duplicate in my concept above. But then maybe I didn't explain it properly. The interface's "type" leaf. With the new

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 10/01/2017 17:25, Andy Bierman wrote: On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: On 10/01/2017 16:16, Juergen Schoenwaelder wrote: On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: On Mon, Jan 9, 2

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 10/01/2017 16:16, Juergen Schoenwaelder wrote: On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: I think itt is

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 10/01/2017 15:30, Andy Bierman wrote: On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder > wrote: On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > I think itt is not realistic to say that datastores are option

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

On 09/01/2017 12:38, Lou Berger wrote: On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: The current document involves quite a lot of hand-waving, and that's why I was also reluctant to accept it as a WG standard-track deliverable. IMO I think we should do and document the work and

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Hi, On 09/01/2017 21:17, Andy Bierman wrote: On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder > wrote: On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > I am more concerned about use cases that are not known

Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

Hi Lada, Thanks for the review and comments. On 21/12/2016 13:08, Ladislav Lhotka wrote: Hi, I think this is a very useful addition to ietf-interfaces. In general, the document is clearly written and YANG modules nicely designed. Here are my comments: *** Sec. 1 - "This document defines

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

Hi Alex, Thanks for the support and comments. Please see inline ... On 21/12/2016 00:08, Alex Campbell wrote: Yes/support The main issue I have with this draft, that I would like to be addressed at some point, is the way it uses heavily restricted lists to model sequences of VLAN tags. It

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

On 22/12/2016 10:49, Martin Bjorklund wrote: Robert Wilton wrote: On 22/12/2016 10:22, Martin Bjorklund wrote: Robert Wilton wrote: On 22/12/2016 10:00, Andy Bierman wrote: On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka mailto:lho...@nic.cz>> wrote: > On 22 Dec 2016,

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

On 22/12/2016 10:22, Martin Bjorklund wrote: Robert Wilton wrote: On 22/12/2016 10:00, Andy Bierman wrote: On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka mailto:lho...@nic.cz>> wrote: > On 22 Dec 2016, at 07:22, Randy Presuhn mailto:randy_pres...@alumni.stanford.ed

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

On 22/12/2016 10:00, Andy Bierman wrote: On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka > wrote: > On 22 Dec 2016, at 07:22, Randy Presuhn mailto:randy_pres...@alumni.stanford.edu>> wrote: > > Hi - > > On 12/21/2016 3:55 PM, Andy Bierman wro

Re: [netmod] Does the YANG "status" statement inherit from its parent node?

I think that it should be a error to have a current node under a deprecated node in the same module, and similarly for deprecated/obsolete. I.e. to be consistent with the following text from 7950 sec 7.21.2: 'If a definition is "current", it MUST NOT reference a "deprecated" or"obsolete" def

[netmod] Does the YANG "status" statement inherit from its parent node?

Hi, The definition of "status" in RFC 7950 in section 7.21.2 (full text below), states: If no status is specified, the default is "current". From my interpretation of the text in the draft, this implies that the status of the "new" child leaf in the following example is "current", and that

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

Hi Giles, Thanks for the support, and comments. On 19/12/2016 19:37, Giles Heron wrote: support a couple of quick Qs for the authors: 1) is there a reason why you have the “tags” container in the L3 interface but don’t have equivalents in the flexible encapsulation model? since the “tags”

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

Hi Jonathan, These are just my thoughts ... I'm not advocating getting rid of candidate/locking, but if I was designing a new network management solution, I would not plan on using candidate/locking. Candidate is great when you have got a human operator typing in some config on the CLI and

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

Hi Iftekhar, Thanks for the comments and support, please see inline ... On 15/12/2016 18:55, Iftekhar Hussain wrote: Yes/support. I have read this draft and believe it would be very useful for enabling many Layer 2 and Layer 3 services. However, I do have few comments and that I would like

Re: [netmod] Modelling different "levels" of data in YANG

lag, something like the below. Is this what you were envisioning? container thermostat { leaf configured-temperature { type int8; } leaf current-temperature { config false; type int8; } container diagnostics { config false; diagnostics true;<-- new flag here ...

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

Hi Andy, Thanks for you comments, please see inline. On 14/12/2016 15:41, Andy Bierman wrote: On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <mailto:rwil...@cisco.com>> wrote: On 14/12/2016 14:09, Andy Bierman wrote: On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund

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

On 14/12/2016 14:09, Andy Bierman wrote: On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund > wrote: Andy Bierman mailto:a...@yumaworks.com>> wrote: > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue mailto:mer...@gmail.com>> wrote: > > > Hi Andy, > >

Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent, On 10/12/2016 00:59, Kent Watsen wrote: > I prefer not to use specialized operations. Agreed, I was thinking something more along the lines of: <--- note this flag here http://example.com/schema/1.2/config";>

Re: [netmod] Modelling different "levels" of data in YANG

Hi Andy, On 09/12/2016 18:50, Andy Bierman wrote: Why can't you use a when-stmt? system ... // config false // when "/top/diag-mode = 'system'" A when statement has two problems: i) It affects all clients that are

Re: [netmod] Modelling different "levels" of data in YANG

On 09/12/2016 15:17, Martin Bjorklund wrote: Robert Wilton wrote: On 09/12/2016 12:06, Juergen Schoenwaelder wrote: On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote: Even if they don't break, debug and diagnostics information can be very verbose. If a client

Re: [netmod] Modelling different "levels" of data in YANG

On 09/12/2016 12:06, Juergen Schoenwaelder wrote: On Fri, Dec 09, 2016 at 11:25:35AM +, Robert Wilton wrote: Even if they don't break, debug and diagnostics information can be very verbose. If a client had 4 connections to a device for monitoring different things, then you don'

Re: [netmod] Modelling different "levels" of data in YANG

Hi Juergen, On 09/12/2016 11:19, Juergen Schoenwaelder wrote: On Fri, Dec 09, 2016 at 10:54:14AM +, Robert Wilton wrote: Assuming that diagnostics information was specified for each of N different protocols on a device. Then this would seem to mean that every device would have to install

Re: [netmod] Modelling different "levels" of data in YANG

On 09/12/2016 11:16, Juergen Schoenwaelder wrote: On Fri, Dec 09, 2016 at 11:05:47AM +, Robert Wilton wrote: OK, so this is closer, but still would mean that enabling the debug flag via RPC would potentially cause all clients to start to see the diagnostics information (which may break

Re: [netmod] Modelling different "levels" of data in YANG

On 09/12/2016 10:54, Ladislav Lhotka wrote: On 9 Dec 2016, at 11:48, Robert Wilton wrote: Hi Lada, On 09/12/2016 10:33, Ladislav Lhotka wrote: Hi Rob, I didn't follow the previous discussion closely but a natural solution seems to be to define a leaf like "debug" - i

Re: [netmod] Modelling different "levels" of data in YANG

On 08/12/2016 19:11, Juergen Schoenwaelder wrote: On Thu, Dec 08, 2016 at 05:49:11PM +, Robert Wilton wrote: On 07/12/2016 16:13, Juergen Schoenwaelder wrote: On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote: Alas, xpath filtering is optional, and I'm not sure how

Re: [netmod] Modelling different "levels" of data in YANG

ld be modeled in YANG and if so how that should be done. Perhaps, we should just concentrate on getting the basis config and operational state models sorted out initially and then figure out how diagnostics should be modeled at a later date? Rob Lada Robert Wilton writes: On 07/12/2016 16:

Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang

No, I'm not aware of any IPR that applies to this draft. Thanks, Rob On 08/12/2016 21:47, Lou Berger wrote: Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR

Re: [netmod] Modelling different "levels" of data in YANG

On 07/12/2016 16:13, Juergen Schoenwaelder wrote: On Wed, Dec 07, 2016 at 02:39:00PM +, Robert Wilton wrote: Alas, xpath filtering is optional, and I'm not sure how many devices have implemented support for it. Further, this still requires every client to be coded to avoid receivin

Re: [netmod] Modelling different "levels" of data in YANG

Hi, On 07/12/2016 13:30, Vladimir Vassilev wrote: On 12/06/2016 10:03 PM, Alex Campbell wrote: IMO using an action or rpc is an okay solution for now, certainly better than than not including the data at all. If I have to chose between RPC with 'output' containing the state data for select

Re: [netmod] Modelling different "levels" of data in YANG

Hi Vladimir, Thanks for your suggestion. Please see some comments inline ... On 06/12/2016 10:34, Vladimir Vassilev wrote: On 12/05/2016 07:10 PM, Robert Wilton wrote: Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue

[netmod] Modelling different "levels" of data in YANG

Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue that has come up is the scope of the operational state data that could be modeled: At the top level, an operator may just want to know whether an Ethernet interface is up

Re: [netmod] How to prevent a client from modifying the type of an interface?

Hi, On 29/11/2016 15:54, Juergen Schoenwaelder wrote: On Tue, Nov 29, 2016 at 03:37:29PM +, Bogaert, Bart (Nokia - BE) wrote: Hi, We’re trying to figure out how to prevent a NC client from changing the type of an interface. Assume that we have an interface stack defined and the lowest

Re: [netmod] Mandatory leafs via augment

ictly prohibited without the prior consent of its author. >> *From:*Andy Bierman [mailto:a...@yumaworks.com] *Sent:* 28 November 2016 18:39 *To:* Robert Wilton *Cc:* Bogaert, Bart (Nokia - BE) ; netmod@ietf.org *Subject:* Re: [netmod] Mandatory leafs via augment On Mon, Nov 28, 2016 at 7:4

Re: [netmod] Regarding IPR on draft-nmdsdt-netmod-revised-datastores

No, I'm not aware of any IPR that applies to this draft. Thanks, Rob On 28/11/2016 22:50, Lou Berger wrote: Authors, Contributors, WG, As part of the preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? [NOTE: Adoption poll will be on the first draft

Re: [netmod] Mandatory leafs via augment

for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author.

Re: [netmod] Mandatory leafs via augment

Hi Bart, In your idea, am I correct to assume that only the client loads (base-class, augment-base, and base-deviation), and the server only knows about (base-class and augment-base)? Further, am I right to assume that the server would still support clients configuring base even if they don'

Re: [netmod] Interplay between YANG network instances and schema mount

Hi Martin, Thanks for the comments, please see inline ... On 10/11/2016 15:30, Martin Bjorklund wrote: Robert Wilton wrote: Hi, The network-instances draft (draft-ietf-rtgwg-ni-model) uses YANG mount to allow relevant parts of the YANG schema to be made available under a particular network

[netmod] Interplay between YANG network instances and schema mount

Hi, The network-instances draft (draft-ietf-rtgwg-ni-model) uses YANG mount to allow relevant parts of the YANG schema to be made available under a particular network instance (e.g. as per the diagram on section 3.2), reproduced inline here: +--rw yanglib:modules-state [RFC78

Re: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-02.txt

ernet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj

Re: [netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang

Hi Kent, "No, I'm not aware of any IPR that applies to this draft" Thanks, Rob On 22/10/2016 14:31, Kent Watsen wrote: Authors, Contributors, WG, This IPR disclosure requests is being made as part of the preparation for WG adoption of this draft. Are you aware of any IPR that applies to d

Re: [netmod] OpsState and Schema-Mount

d objects (e.g., interfaces). It is not directly related to the how to report applied configuration problem. It is however indirectly related, in that a holistic solution can address both. Kent *From: *Andy Bierman mailto:a...@yumaworks.com>> *Date: *Monday, August 8,

Re: [netmod] OpsState and Schema-Mount

Hi Andy, I don't properly understand the points that you are making, please see clarifying comments/questions inline ... On 08/08/2016 22:51, Andy Bierman wrote: On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen > wrote: Acee writes: >Then I see no YANG l

Re: [netmod] OpsState and Schema-Mount

On 03/08/2016 19:37, Acee Lindem (acee) wrote: On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: On 03/08/2016 07:49, Ladislav Lhotka wrote: On 02 Aug 2016, at 18:35, Balazs Lengyel wrote: Hello, If we allow foo and foo

Re: [netmod] OpsState and Schema-Mount

On 03/08/2016 07:49, Ladislav Lhotka wrote: On 02 Aug 2016, at 18:35, Balazs Lengyel wrote: Hello, If we allow foo and foo-state for opstate, mounting models atop such a multi rooted yang module will be fun. mount modB-config-part onto modA-config-part mount modB-state-part onto modA-state-p

Re: [netmod] OpsState and Schema-Mount

Hi Balazs, Yes, it would be exactly as you describe: you end up having two parallel trees, with two parallel sets of mount points. It feels like this would be an extra wart, but not the end of the world. I also agree that avoiding the foo/foo-state split would help mitigate this. Thanks, Rob

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

ly this one has already been answered above. Thanks, Rob Andy On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka <mailto:lho...@nic.cz>> wrote: Robert Wilton mailto:rwil...@cisco.com>> writes: > On 28/07/2016 15:20, Ladislav Lhotka wrote: >>> On 28 J

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Hi Andy, I think that it would be fair to say that the authors of draft-openconfig-netmod-opstate-01 think that it broken (e.g. sections 6.1, 8.1.2), particularly given that they have decided that it is better to have their own OpenConfig version of interfaces rather than augment RFC 7223. I

Re: [netmod] Design-Time schema mount

On 28/07/2016 15:51, Juergen Schoenwaelder wrote: On Thu, Jul 28, 2016 at 04:14:42PM +0200, Ladislav Lhotka wrote: We could define it using built-in statements, and bump YANG version number. I don't get why this is worse that introducing "standard extensions", except at Layer 8 (Political) -

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

ls in routing area structure this way. Regards, - Xufeng *From:*netmod [mailto:netmod-boun...@ietf.org]*On Behalf Of*Robert Wilton *Sent:*Wednesday, July 27, 2016 1:05 PM *To:*Kent Watsen mailto:kwat...@juniper.net>>; netmod WG mailto:netmod@ietf.org>> *Subject:*

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 28/07/2016 15:48, Acee Lindem (acee) wrote: On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" wrote: On 28/07/2016 15:20, Ladislav Lhotka wrote: On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: Hi Lada, On 7/28/16, 9:52 AM, "netm

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On 28/07/2016 15:20, Ladislav Lhotka wrote: On 28 Jul 2016, at 15:57, Acee Lindem (acee) wrote: Hi Lada, On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka" wrote: Robert Wilton writes: On 26/07/2016 21:36, Kent Watsen wrote: So my thinking is that if we can&#x

<    1   2   3   4   5   6   7   8   >