Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

2015-07-26 Thread Juergen Schoenwaelder
On Sun, Jul 26, 2015 at 12:53:41PM +0200, Ladislav Lhotka wrote: What might be a new task for YANG is to define general syntax for identifying different trees and inter-tree references. This is not the time to add new features to YANG 1.1. /js -- Juergen Schoenwaelder Jacobs

Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific

2015-07-26 Thread Juergen Schoenwaelder
Any are concrete actionable proposals? /js On Sun, Jul 26, 2015 at 12:46:22PM +0200, Ladislav Lhotka wrote: On 26 Jul 2015, at 02:26, Andy Bierman a...@yumaworks.com wrote: Hi, The WG should decide what it means for YANG to not be NETCONF-specific. Why does YANG define

Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific

2015-07-26 Thread Juergen Schoenwaelder
Lada, there won't be any decision as long as there is not a concrete actionable proposal to be discussed. Such a proposal does not have to be 'complete rewrite' but it needs to be a detailed list of what would have to change so that it is possible to assess such a proposal. /js On Sun, Jul 26,

Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific

2015-07-26 Thread Juergen Schoenwaelder
On Sat, Jul 25, 2015 at 05:26:16PM -0700, Andy Bierman wrote: Hi, The WG should decide what it means for YANG to not be NETCONF-specific. Why does YANG define extensions to NETCONF operations (like insert)? IMO the normative text about NETCONF should not be in the YANG RFC. So what is

Re: [netmod] new YANG 1.1 Issue Y62: YANG should not be NETCONF-specific

2015-07-26 Thread Ladislav Lhotka
On 26 Jul 2015, at 12:55, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: Any are concrete actionable proposals? Start rewriting 6020bis, but only if we decide to go that way - it is a difficult decision. I will be slightly in favor of doing so. Lada /js On Sun,

Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

2015-07-26 Thread Juergen Schoenwaelder
On Sat, Jul 25, 2015 at 05:17:11PM -0700, Andy Bierman wrote: Hi, I would like to open another issue for YANG 1.1, because I don't want to have 1.1 and then 1.2 right away. The NETMOD WG should evaluate the different ways to support ephemeral state, based on Jeff's draft. The NETMOD WG

Re: [netmod] YANG 1.1 Y60 IETF 93 discussion summary and action items

2015-07-26 Thread Andy Bierman
On Sun, Jul 26, 2015 at 12:22 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Sat, Jul 25, 2015 at 03:15:45PM -0700, Andy Bierman wrote: On Sat, Jul 25, 2015 at 1:25 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: This is the summary of

Re: [netmod] Y34

2015-07-26 Thread Lou Berger
I completely agree. We definitely will make use if this in the new models being developed in the routing area. Lou On July 26, 2015 1:50:00 PM Acee Lindem (acee) a...@cisco.com wrote: I think being able to place a given model anywhere in the device tree would be useful and this would allow

Re: [netmod] Y34

2015-07-26 Thread Andy Bierman
Hi Acee, I agree that Relocatable YANG would be very useful, and have been thinking about the problem for awhile. I think the key is to precisely define a protocol-independent document root for each of the various YANG XPath contexts. In most cases the expression can be automatically relocated

Re: [netmod] Y34

2015-07-26 Thread Lou Berger
Andy, Have you thought through implications / possibilities for existing models, e.g., interfaces? Thanks, Lou On July 26, 2015 4:41:32 PM Andy Bierman a...@yumaworks.com wrote: Hi Acee, I agree that Relocatable YANG would be very useful, and have been thinking about the problem for

Re: [netmod] new YANG 1.1 Issue Y61: I2RS support

2015-07-26 Thread Andy Bierman
Hi, I agree it should be a WG (maybe IESG) decision whether YANG 1.1 should be published ASAP and a new version started right away to update it. The RFC publication process is not that hard to solve. The tool and user confusion caused by all these versions is another matter. more inline...