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

Rob, Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied. What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be

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

>Will there ever be a server that operates in synchronous mode, given >that applied will not match intended if hardware is missing? > >Will a client ever use "block" mode if it means that it might hang >forever (or at least until some hw is plugged in)? I think the key is in the phrase "The

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

Kent Watsen writes: >If a line card is missing, then (as I understand it), the server would not >wait for the line-card to show up. That said, if the client requested >transactional/atomic update, a missing line-card would cause an immediate >failure/rollback. We have to avoid the scenario when

[netmod] I-D Action: draft-ietf-netmod-syslog-model-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : SYSLOG YANG model Author : Clyde Wildes Filename:

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-06.txt

Hi, Ladislav Lhotka wrote: > Hi, > > since the WGLC is over, I posted a new revision of this > document. Compared to -05, there are no technical changes, just minor > text modifications and one or two new examples, mainly based on > Martin's review. This version addresses all of

[netmod] IPR Poll for draft-ietf-netmod-yang-json-06

This mail starts the IPR poll on draft-ietf-netmod-yang-json-06. Are you aware of any IPR that applies to draft-ietf-netmod-yang-json-06? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document

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

Kent Watsen wrote: > > > >>Wait, I think we're talking about different things. Martin, I'm sure > >>that > >> internal to a NC/RC server, parts of the intended configuration is > >> actually applied synchronously (e.g., a hostname) whereas other parts > >>are > >> not

Re: [netmod] Order of evaluation for when?

On Fri, Oct 16, 2015 at 12:49 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I find all this fretting over when-stmt corner-cases to be a waste of > time. > > I certainly have no intention of spending 100s of hours coding for > >

Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (section 9. built-in types)

Ladislav Lhotka wrote: > Ladislav Lhotka writes: > > > Juergen Schoenwaelder writes: > > > >> Hi, > >> > >> here is the review of section 9 or draft-ietf-netmod-rfc6020bis-07; I > >> have finish now a complete review of the

Re: [netmod] 6020bis extensions

Andy Bierman wrote: > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > > > Conformance to YANG for the extension: NONE This includes syntax and >

Re: [netmod] 6020bis extensions

On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote: > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote: > > > > > > Conformance to YANG for the extension: NONE This

Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types)

Juergen Schoenwaelder wrote: > On Thu, Oct 15, 2015 at 10:37:49PM +0200, Martin Bjorklund wrote: > > > * p67 > > > > > > Similar to the comment for p63. Perhaps the right way is to phrase > > > this in such a way that is simply says leaf nodes

Re: [netmod] Order of evaluation for when?

> On 15 Oct 2015, at 18:03, Martin Bjorklund wrote: > > Andy Bierman wrote: >> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund wrote: >> >>> Andy Bierman wrote: Hi, You are incorrect.

Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types)

Martin Bjorklund writes: ... > >> I am also wondering why we use device and server. It seems we use >> these terms interchangeably. If so, for clarity, I would suggest to >> use a single term, that is s/device/server > > Ok, fixed. > >> / and perhaps explicitly >>

Re: [netmod] 6020bis extensions

Juergen Schoenwaelder wrote: > On Thu, Oct 15, 2015 at 07:19:14PM -0700, Andy Bierman wrote: > > On Thu, Oct 15, 2015 at 3:34 PM, Juergen Schoenwaelder < > > j.schoenwael...@jacobs-university.de> wrote: > > > > > On Tue, Oct 13, 2015 at 09:19:45AM -0700,

Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types)

> On 16 Oct 2015, at 13:17, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >> ... >> >>> I am also wondering why we use device and server. It seems we use these terms interchangeably. If so, for

Re: [netmod] Order of evaluation for when?

Hi, Balazs Lengyel wrote: > Hello Andy, Martin, > If that is what is meant by 8.2.1 then I have a few comments Sorry for the confusion on this topic. I have now done some digging in the archives and I think that section 8.2 is really intended to apply only to

Re: [netmod] Order of evaluation for when?

Hello, AFAIK the document order in edit-config was not seen as important till today, with the single exception : - user-ordered list/leaf-list Making it significant now would be a new concept. I don't want that. It makes it more difficult to make a correct edit-config. So Scenario B(2) and C

Re: [netmod] Order of evaluation for when?

Ladislav Lhotka wrote: > > > On 16 Oct 2015, at 12:27, Balazs Lengyel > > wrote: > > > > IMHO YANG should define the behavoir, and I would want it to be the > > same on Netconf/Restconf/CLI etc. > > I agree that " 1) you get an error back" would be

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

Robert Wilton wrote: > Hi Kent, > > Here is my attempt at word smithing section 3: > > The old D and E have been merged together (now labelled as C). A new > D has been added to try and define transactional error handling > semantics without introducing the term

Re: [netmod] Order of evaluation for when?

> On 16 Oct 2015, at 12:27, Balazs Lengyel wrote: > > IMHO YANG should define the behavoir, and I would want it to be the same on > Netconf/Restconf/CLI etc. > I agree that " 1) you get an error back" would be the best: because it is the > easiest to understand

Re: [netmod] review of draft-ietf-netmod-rfc6020bis-07 (except 9. built-in types)

Ladislav Lhotka wrote: > Martin Bjorklund writes: > > ... > > > > >> I am also wondering why we use device and server. It seems we use > >> these terms interchangeably. If so, for clarity, I would suggest to > >> use a single term, that is s/device/server

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Hi Kent, Gert, Balazs pointed out, and I agree, that the text about transaction/not transactional can equally apply to both synchronous and asynchronous configuration operations. So rather than reproducing this text twice, once for each configuration definition, I propose keeping the

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

Hi Kent, Here is my attempt at word smithing section 3: The old D and E have been merged together (now labelled as C). A new D has been added to try and define transactional error handling semantics without introducing the term transactional. 3. Support for both synchronous and

Re: [netmod] not a non-presence container

I like that approach. Thanks, W. On 15 October 2015 at 16:50, Jonathan Hansford wrote: > How about “closest ancestor node in the schema tree (excluding > non-presence containers)”? > > > > Jonathan > > > > > > > *From: *Martin Bjorklund > *Sent: *15 October 2015 13:39 >

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

Hi Martin, On 16/10/2015 13:23, Martin Bjorklund wrote: Robert Wilton wrote: Hi Kent, Here is my attempt at word smithing section 3: The old D and E have been merged together (now labelled as C). A new D has been added to try and define transactional error handling

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

>>> These terms were edited on today's call, resulting in the following >>>text: >>> >>> Synchronous configuration operation - A configuration request to >>>update >>> the running configuration of a server that is applied >>>synchronously with >>> respect to the client request.

Re: [netmod] Order of evaluation for when?

Hi, I find all this fretting over when-stmt corner-cases to be a waste of time. I certainly have no intention of spending 100s of hours coding for corner-cases that have no operational value whatsoever. When-stmt has always been full of problems that exist on paper but not in real servers.

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

> Why is there a need to update the intended config? Because that is what happens via requests like and PATCH. The intended (running) config gets updated first and then config is distributed to internal components, ultimately updated the applied config. Kent // as a contributor From:

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Kent, The new one looks much better. However the last sentence is confusing with respect to intended config. Why is there a need to update the intended config? Proposal: The server MUST fully attempt to apply the configuration change to all impacted components in the server, updating

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Juergen, Rob summarized the discussion well. Since I also have some strange feelings about transactions here, my proposal in the other thread was to define the state of the config at the time the client is notified. Gert Sent from my Apple ][ > On 16 Oct 2015, at 14:19, Robert Wilton

Re: [netmod] About correlation between snmp alarms and yang structures

Hi, if you implement the ietf-interfaces YANG module including the if-mib feature, then /interfaces-state/interface/if-index provides you the ifIndex value that MIB modules usually use to identify an interface. /js On Fri, Oct 16, 2015 at 02:04:38PM +, De Noia Giuseppe wrote: > Hi guys, > I

Re: [netmod] Order of evaluation for when?

Hello, We already have embedded choice and when in choice in the OSPF module https://tools.ietf.org/html/draft-ietf-ospf-yang-02. So unless we do something fast the nasty complications will be happenning. regards Balazs On 2015-10-16 17:37, Ladislav Lhotka wrote: On 16 Oct 2015, at 17:03,

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

On Fri, Oct 16, 2015 at 5:23 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > Hi Kent, > > > > Here is my attempt at word smithing section 3: > > > > The old D and E have been merged together (now labelled as C). A new > > D has been added to try and

Re: [netmod] Order of evaluation for when?

On 10/16/2015 2:49 PM, Martin Bjorklund wrote: Andy Bierman wrote: Hi, I find all this fretting over when-stmt corner-cases to be a waste of time. I certainly have no intention of spending 100s of hours coding for corner-cases that have no operational value whatsoever.

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

Hi - > From: Robert Wilton > Sent: Oct 16, 2015 5:12 AM > To: Kent Watsen , Nadeau Thomas > Cc: "netmod@ietf.org" > Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for > asynchronous systems to provide a blocking config update? ... >Here is my attempt at word smithing section