Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

Hi Kent, Yes, fine with me. BTW, please can I check that I correctly understand B and C. Am I right in understanding that B means that multiple top level trees would be acceptable, and C means that having the structure defined in multiple modules would be acceptable? Thanks, Rob On 21/09/

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

Hi Andy, Please can you clarify. Is your concern specifically with requirement 7? Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00? Thanks, Rob On 21/09/2015 20:28, Andy Bierman wrote: Hi, I do not

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

>Yes, fine with me. Excellent! >BTW, please can I check that I correctly understand B and C. > >Am I right in understanding that B means that multiple top level trees >would be acceptable, and C means that having the structure defined in >multiple modules would be acceptable? Yes, this is wha

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

On 22/09/2015 13:45, Kent Watsen wrote: Yes, fine with me. Excellent! BTW, please can I check that I correctly understand B and C. Am I right in understanding that B means that multiple top level trees would be acceptable, and C means that having the structure defined in multiple modules

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton wrote: > Hi Andy, > > Please can you clarify. Is your concern specifically with requirement 7? > Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00 > ? > > My co

[netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

OK, how about another (hopefully) easy one. Robert Wilton writes: "It wasn't clear to me where the requirement 3 (A) came from. I'm not necessarily opposed to it, only that it doesn't appear to be obviously specified in the openconfig-netmod-opstate draft." For convenience, Requirement 3 is rep

[netmod] Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-01.txt

FYI we've updated the DT draft based on the following: 1) No single /device root This has been a topic of major discussion both publicly and within the DT. It's our hope that by making this change (okay, compromise), discussion can now move on to the rest of the proposed structure. 2) The add

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On Tue, Sep 22, 2015 at 02:04:16PM +, Kent Watsen wrote: > > Given that we only have asynchronous systems today with NETCONF and > RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF > synchronous with a blocking call. This may have been a bad assumption on > my part, as Anees

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On 22/09/2015 15:22, Juergen Schoenwaelder wrote: On Tue, Sep 22, 2015 at 02:04:16PM +, Kent Watsen wrote: Given that we only have asynchronous systems today with NETCONF and RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF synchronous with a blocking call. This may hav

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On 22/09/2015 17:20, Andy Bierman wrote: On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen > wrote: > Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous. > Did you messes up the terms throughout this paragraph? If I swap all > of t

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous. > Did you messes up the terms throughout this paragraph? If I swap all > of them, the text starts to make sense to me. Nope, but I grant you there are terminology issues here. What I mean, and have said before, is that NE

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen wrote: > > > > > Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous. > > Did you messes up the terms throughout this paragraph? If I swap all > > of them, the text starts to make sense to me. > > Nope, but I grant you there are termin

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote: > > NETCONF and RESTCONF are asynchronous, meaning the client and server > run in separate processes and communication between client and server can > occur at any time. > I thought the openconfig discussion was centered around the ser

Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

Hi Lada, Thanks for your feedback. I do think that there is value in an integrated technology solution. OpenDaylight combines (1) and (2) usefully. For example there are examples on the page: http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf such as: http://l

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote: > On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote: > > > > NETCONF and RESTCONF are asynchronous, meaning the client and server > > run in separate processes and communication betwee

Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

Hi Eric, Lada, I agree with Eric that the mount requirements should include both use cases. We have been discussing this mechanism as potentially providing support for meta model components that may or not be present in a network device. Thanks, Acee On 9/22/15, 1:59 PM, "netmod on behalf of E

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic wrote: > Andy, > > Mobile operators are sharing infrastructure more and more. They are even > now considering sharing spectrum. Today there are already use cases where > Radio Access Network (RAN) is shared between multiple operators and they > ar

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

On Tue, Sep 22, 2015 at 11:53 AM, Dean Bogdanovic wrote: > > On Sep 22, 2015, at 2:46 PM, Andy Bierman wrote: > > > > On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic > wrote: > >> Andy, >> >> Mobile operators are sharing infrastructure more and more. They are even >> now considering sharing s