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

[Gert Grammel]

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 "hybrid" which suggests something in between asynchronous and 
synchronous.

>From a client perspective an asynchronous server and a hybrid server look the 
>same. The difference is that the asynchronous one should convey a "finished" 
>information to the client, while the hybrid would remain in a "trust me babe" 
>mode forever.


Another way to look at hybrids is to consider them "cheating synchronous". 
Given that the new config may not have been applied at the time of the response 
to the client. This is worse than the situation before where a missing verify 
lets the client know that something may still go on. Clients can't tell if 
servers are cheating :-)

Gert



Sent from my Apple ][

> On 16 Oct 2015, at 18:44, Robert Wilton  wrote:
> 
> 
> 
>> On 16/10/2015 14:59, Kent Watsen wrote:
>> 
> 3.  Support for both synchronous and asynchronous configuration
> operations
> 
> A. A server may choose to support only synchronous
> configuration
>operations, or only asynchronous configuration operations,
> or
>both synchronous and asynchronous configuration operations
> in
>a client specified per-operation basis.
 I think the most common mode *today* is a mix of sync/async, on a
 per-object basis.
>>> Yes, I agree.
>> 
>> 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 (e.g., config for data plane).   But that nuance is not currently
>> exposed in any way today -right?
> I think that today, from what a client sees/experiences, many replies from 
> netconf servers fits neither the definition of "synchronous configuration 
> operation" nor "asynchronous configuration operation", but instead, the reply 
> is somewhere between the two extremes.
> 
> So the question I was trying to raise is whether servers that need to meet 
> the opstate requirements have to change to strictly comply with the defined 
> async or sync config operation semantics?  E.g. not just adding a 
> "done-applying" option, but perhaps also adding something along the lines of 
> a "done-verifying" option.
> 
> Thanks,
> Rob
> 
> 
>> 
>> What we're talking about here is an ability for a client to request a
>> protocol operation (PATCH) to block, or for the "done-applying"
>> notification to not be sent, until all that processing of the request is
>> complete.  This regardless if the request contains a mix of nodes that are
>> applied internally sync/async.  Makes sense? - or it is something else?
> 
> 
> 
>> 
>> 
>> 
> B. Support for synchronous operations as per the definition of
>"synchronous configuration operation".
 Doesn't this follow from A?
>>> Yes, possibly.  I don't mind if B is deleted.  If we do this then I
>>> would suggest that we also delete the analogous first sentence of C, and
>>> re-introduce the "(see terms)" text in the headline description.
>> +1
>> 
>> 
>> Kent  // as a contributor
>> 
>> 
>> .
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

>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 server MUST fully *attempt* to
apply..."

In my view, the server does not have to "fully apply", it merely has to
have attempted to do so.  Essentially, a request comes in resulting in a
flurry of activity, that ultimately stabilizes, at which point the
response can be sent.

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.

Makes sense?

Kent  // as a contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Phil Shafer]

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 a box boots with a missing FRU.
In past model has always been that missing hardware does not cause
a configuration to fail validity checks.  This is enforced by the
inability of config=true constraints from referring to config=false
nodes.

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[internet-drafts]

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: draft-ietf-netmod-syslog-model-05.txt
Pages   : 21
Date: 2015-10-16

Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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 my concerns.  I think it is ready for
publication.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 author or contributor please respond to this
email explicitly regardless of whether or not you are aware of any relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR 
that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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 (e.g., config for data plane).   But that nuance is not currently
> >> exposed in any way today -right?
> >I think that today, from what a client sees/experiences, many replies
> >from netconf servers fits neither the definition of "synchronous
> >configuration operation" nor "asynchronous configuration operation", but
> >instead, the reply is somewhere between the two extremes.
> 
> I don't think it matters if the server is anywhere between the two
> extremes.

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)?


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

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
> > 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.
> >
> > There is no need for the YANG spec to point out that the constraints
> > only apply to YANG. That is self-evident.
> >
> > Why doesn't when-stmt apply to a plain rpc?
> >
> >
> >rpc plot-point {
> >  input {
> > leaf 3d {
> >   type boolean;
> >default false;
> > }
> > leaf X { type uint32; }
> > leaf Y { type uint32; }
> > leaf Z {
> >   when "../3d";
> >   type uint32;
> >}
> >  }
> >}
> >
> >
> > Are you saying that the when-stmt for Z is not allowed?
>
> No.
>
> > Or that it gets ignored and not enforced?
>
> No.
>
> > IMO this section was rather clear -- it applies to when-stmt
> > in the RPC input.
>
> No - and that's the problem which we need to fix.  It might be that we
> all agree on the expected server behavior ,and if that's the case, we
> just need to fix the text to align with what we meant.  In order to
> resolve this, it would be very helpful if you could provide your
> opinion on the questions in the three scenarios below:
>
> > > Suppose we have:
> > >
> > >  leaf a {
> > >when "../b = 42";
> > >type int32;
> > >  }
> > >  leaf b {
> > >type int32;
> > >  }
> > >
> > >
> > > Scenario A
> > > --
> > > The DB contains b=10
> > >
> > > The server gets an edit-config with:
> > >
> > >2
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok; the request to set a to 2 is silently dropped
> > >
>


We implement (2)



> > >
> > > Scenario B
> > > --
> > > The DB contains b=10.
> > >
> > > The server gets an edit-config with:
> > >
> > >2
> > >42
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok, db now has b=42; the request to set a to 2 is silently
> > >  dropped
> > >  3)  ok, db now has a=2 and b=42
> > >
>


We implement (3)



> > >
> > > Scenario C  (same as 2, but different order in edit-config)
> > > --
> > > The DB contains b=10.
> > >
> > > The server gets an edit-config with:
> > >
> > >42
> > >2
> > >
> > > What is the result?
> > >
> > >  1)  an error is returned
> > >  2)  ok, db now has b=42; the request to set a to 2 is silently
> > >  dropped
> > >  3)  ok, db now has a=2 and b=42
>
>
>
We implement (3)

Order of edits never matters.
We apply all the edits in a non-destructive manner and then
run all the when-stmt tests that are needed.

The order of when-stmt evaluation can change the answer but we
have not seen any YANG modules where that really happens.




> /martin
>


Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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 document. The most important
> >> bug I spotted is likely that section 9.4.6 is empty.
> >
> > Yes, and the "modifier" statement should also be listed in Table 1 of
> > sec. 13.1.
> 
> I just noticed this table contains a copy-and-paste error:
> 
> +--+---+-+
> | keyword  | argument name | yin-element |
> +--+---+-+
> | action   | name  | false   |
> | anydata  | 7.10  | 0..n|
>  

fixed!


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6020bis extensions

[Martin Bjorklund]

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
> > > semantics.  It makes no sense at all (Lada is right) to say the
> > > extension semantics apply.  They only apply if the tool supports the
> > > extension.  Conformance to the extension is a different matter.
> >
> > I would hope that a server supporting NACM implements the behaviour of
> > nacm:default-deny-write when nodes are tagged with this extension.
> > Sure, a YANG parser is allowed to skip over nacm:default-deny-write
> > but if nacm:default-deny-write is used for a certain node, I think we
> > want the server to implement the semantics implied by
> > nacm:default-deny-write regardless which tool the developer used.
> >
> >
> I do not agree.
> The semantics for this YANG extension only apply to NACM.
> Of course an implementation of NACM cannot ignore this extension.

+1

So the question is if we need to add/change any text in 6020bis?


/martin

> 
> The extensions says what to do in NACM if the tag is found.
> (As it should).  It does not define any behavior outside of NACM.
> No other tool except a NETCONF server implementation
> of NACM has any conformance requirement to implement this extension.
> 
> 
> /js
> >
> 
> 
> Andy
> 
> 
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> >

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6020bis extensions

[Juergen Schoenwaelder]

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 includes syntax and
> > > semantics.  It makes no sense at all (Lada is right) to say the
> > > extension semantics apply.  They only apply if the tool supports the
> > > extension.  Conformance to the extension is a different matter.
> >
> > I would hope that a server supporting NACM implements the behaviour of
> > nacm:default-deny-write when nodes are tagged with this extension.
> > Sure, a YANG parser is allowed to skip over nacm:default-deny-write
> > but if nacm:default-deny-write is used for a certain node, I think we
> > want the server to implement the semantics implied by
> > nacm:default-deny-write regardless which tool the developer used.
> >
> >
> I do not agree.
> The semantics for this YANG extension only apply to NACM.
> Of course an implementation of NACM cannot ignore this extension.
> 
> The extensions says what to do in NACM if the tag is found.
> (As it should).  It does not define any behavior outside of NACM.
> No other tool except a NETCONF server implementation
> of NACM has any conformance requirement to implement this extension.

I am confused, perhaps we talk past each other. If a server implements
NACM and some data model X contains

leaf foo {
 type string;
 nacm:default-deny-write;
}

does this not mean that the nacm:default-deny-write semantics must be
implemented for the foo leaf regardless whether the developer's tool
is able to parse nacm:default-deny-write or skips over it?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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 containing a
> > >   default value may not be present in the XML encoding. Simply remove
> > >   NETCONF  or  specifics.
> > 
> > Or maybe we should simply remove the last paragraph completely?  For
> > NETCONF, RFC 6243 details how leafs with defaults are handled.
> 
> Well, yes, but then readers may not know about RFC 6243. Perhaps state
> that leaf nodes containing a default value may not be present in the
> XML encoding and point to RFC 6243 for further details how NETCONF
> handles leafs with defaults (and I think the reference to RFC 6243
> would be informative).

In some sense I think it is weird to talk about default values here.
This text describes how leafs and their values are encoded.

The default value is defined as the value being used if the leaf
doesn't exist in the data tree, so why should we mention defaults
here?

> > > * p100
> > > 
> > >   The XML encoding text starts with detailing NETCONF specifics.
> > >   Would it make sense to separate the XML encoding of the rpc and its
> > >   input/output from the specifics how the RPCs fit into NETCONF's
> > >system?
> > 
> > 
> > Hmm.  NETCONF and RESTCONF use quite different encodings of rpcs and
> > their output.
> > 
> > NETCONF:
> > 
> >>xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > http://example.net/rock;>
> >   27606-0100
> > 
> >   
> > 
> >>  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > 
> >   
> > 
> > RESTCONF:
> > 
> >POST to  .../rock-the-house
> > 
> >http://example.net/rock;>
> > 27606-0100
> >
> > 
> >result: 204 no content
> > 
> > 
> > Maybe it would have been better to have a common encoding, like:
> > 
> > http://example.net/rock;>
> >   ...
> >   
> > 
> >and
> > 
> > http://example.net/rock;>
> >   ...
> >   
> > 
> > but this cannot be done now.
> > 
> > So, maybe the simplest solution would be to rename the section to
> > "NETCONF XML Encoding"?
> 
> You mean section 7.14.4? Well, OK...

Yes.

> Too bad these RPC encodings are
> actually different. Out of curiosity, was there a specific reason not
> to use
> 
> http://example.net/rock;>
>   27606-0100
> 
> 
> in the RESTCONF POST or did this "just happen"?

The reason is that we can't do output in the same way as NETCONF, and
the current RESTCONF encoding of input is consistent with how we do
output.

But it is not too late to change this.  This should be discussed in
netconf though.

> > > * p105
> > > 
> > >   Again, the proposal is to separate the XML encoding of notifications
> > >   from the details how notifications work with RFC 5277.
> > 
> > Also notifications are encoded differently in RESTCONF and NETCONF.
> 
> Hm.
>  
> > > * p120
> > > 
> > >   The text in section 7.21.1 talks about NETCONF specific operations.
> > >   Is this actually necessary? Can the purpose of the config statement
> > >   not be described by referring to general concepts such as
> > >   configuration datastores instead of using protocol specific
> > >   operations?
> > 
> > Yes, maybe we can just say:
> > 
> >   Data nodes representing configuration are part of configuration
> >   datastores.
> 
> Yes.
>  
> > > * p123
> > > 
> > >   "All leaf data values MUST match the type constraints..." may be
> > >   read as 'all data nodes that contain values' or 'all instantiations
> > >   of nodes defined by the leaf statement'.
> > 
> > I don't really see what you mean.  Can you suggest new text?
> 
> See above, I think 'leaf' sometimes means an instance of a leaf schema
> node and sometimes it means all leaf instances of the data tree. Or I
> am confused. I think here you mean 'all leaf instances of the data
> tree' and not the subset of all 'instances of a leaf schema nodes'.

Right; this is what the current text says:

   The following properties are true in all data trees:

   o  All leaf data values MUST match the type constraints for the leaf,
  including those defined in the type's "range", "length", and
  "pattern" properties.

Note the sentence before the bullet where it says that this is for the
data tree.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Ladislav Lhotka]

> 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.
 
 Within the PAYLOAD (as this section describes), there is no when-stmt
 for data nodes within the datastore.  Look at the YANG for edit-config.
 There are no when-stmts for "interface" in "edit-config".
>>> 
>>> Andy, there is some confusion here.  The section talks about:
>>> 
>>>  For configuration data, there are three windows when constraints
>>>  MUST be enforced:
>>> 
>>>  - during parsing of RPC payloads
>>>  - during processing of NETCONF operations
>>>  - during validation
>>> 
>>> So the entire section talks about constraints *on configuration data*.
>>> 
>>> 
>> 
>> http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421
>> 
>> 
>> Here is the YANG for edit-config?
>> Please point out the when-stmts in this rpc-stmt
>> specific to the "interface" node.
>> I just see an "anyxml" that has no when-stmts at all.
>> 
>> So enforcing the when constraint on the RPC PAYLOAD
>> clearly has nothing to do with "interface" -- just the parameters
>> specified in the rpc-stmt.
> 
> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> rephrase the intro text in 8.2) But I think Balazs is also right.
> Suppose you have:
> 
>  leaf a {
>when "../b = 42";
>type int32;
>  }
>  leaf b {
>type int32;
>  }
> 
> and the db contains b=10.
> 
> Suppose I send an edit-config with a=2.  What is the result?
> 
>  1)  you get an error back
>  2)  you get ok; the request to set a to 2 is silently dropped
>  3)  something else

IMO YANG spec shouldn't deal with this kind of things in the first place. It 
should be sufficient to define two validation levels, e.g. syntactic (schema) 
and semantic validity. Stating what a protocol does if either of these validity 
types is violated would then be up to the protocol spec, and different 
protocols may use different approaches.

That said, I like #1 best.

Lada

> 
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

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
>>   state that unless stated otherwise server means a server providing
>>   access to a YANG defined data tree.
>
> Yes this makes sense.  But then I guess we shouldn't import client and
> server from 6241.  (And most other documents (restconf etc) should
> probably import these terms from ths document).  See also below.
>
>> * p12/p13
>> 
>>   We import 7 terms from RFC 6241. Would it make sense to copy the
>>   necessary text in order to avoid a too strict binding to RFC 6241?
>>   In particular, 'client' and 'server' means NETCONF client and server
>>   if we import from RFC 6241 but this may be a bit narrow given that
>>   we have RESTCONF as well. In an ideal world, we would factor out
>>   core architectural concepts but the best we can do is likely to
>>   define core concepts inline, pointing out where they are the same.
>>   The idea is to loosen the coupling to RFC 6241. Example:
>> 
>>   OLD
>> 
>>o  datastore: an instantiated data tree
>> 
>>   NEW
>> 
>>o  datastore: A conceptual place to store and access information.
>>   A datastore might be implemented, for example, using files, a
>>   database, flash memory locations, or combinations thereof.
>>   [Matches the definition in RFC 6241.]
>
> To start with, I think we should define client and server more
> generically than just NETCONF:
>
>   server: An entity that provides access to YANG-defined data to a
>   client, over some network management protocol.

But then perhaps "device" is a broader term in the sense that the server is just
a software component running in a device.

For example, it is the device that is required to operationally use
default values of parameters that are not present in the
configuration. Replacing "device" with "server" here IMO means something
different.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6020bis extensions

[Martin Bjorklund]

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, Andy Bierman wrote:
> > > >
> > > > Conformance to YANG for the extension: NONE This includes syntax and
> > > > semantics.  It makes no sense at all (Lada is right) to say the
> > > > extension semantics apply.  They only apply if the tool supports the
> > > > extension.  Conformance to the extension is a different matter.
> > >
> > > I would hope that a server supporting NACM implements the behaviour of
> > > nacm:default-deny-write when nodes are tagged with this extension.
> > > Sure, a YANG parser is allowed to skip over nacm:default-deny-write
> > > but if nacm:default-deny-write is used for a certain node, I think we
> > > want the server to implement the semantics implied by
> > > nacm:default-deny-write regardless which tool the developer used.
> > >
> > >
> > I do not agree.
> > The semantics for this YANG extension only apply to NACM.
> > Of course an implementation of NACM cannot ignore this extension.
> > 
> > The extensions says what to do in NACM if the tag is found.
> > (As it should).  It does not define any behavior outside of NACM.
> > No other tool except a NETCONF server implementation
> > of NACM has any conformance requirement to implement this extension.
> 
> I am confused, perhaps we talk past each other. If a server implements
> NACM and some data model X contains
> 
>   leaf foo {
>type string;
>nacm:default-deny-write;
>   }
> 
> does this not mean that the nacm:default-deny-write semantics must be
> implemented for the foo leaf regardless whether the developer's tool
> is able to parse nacm:default-deny-write or skips over it?

Sure.  Andy wrote:

   Of course an implementation of NACM cannot ignore this extension.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

> 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 clarity, I would suggest to
  use a single term, that is s/device/server
>>> 
>>> Ok, fixed.
>>> 
 / and perhaps explicitly
  state that unless stated otherwise server means a server providing
  access to a YANG defined data tree.
>>> 
>>> Yes this makes sense.  But then I guess we shouldn't import client and
>>> server from 6241.  (And most other documents (restconf etc) should
>>> probably import these terms from ths document).  See also below.
>>> 
 * p12/p13
 
  We import 7 terms from RFC 6241. Would it make sense to copy the
  necessary text in order to avoid a too strict binding to RFC 6241?
  In particular, 'client' and 'server' means NETCONF client and server
  if we import from RFC 6241 but this may be a bit narrow given that
  we have RESTCONF as well. In an ideal world, we would factor out
  core architectural concepts but the best we can do is likely to
  define core concepts inline, pointing out where they are the same.
  The idea is to loosen the coupling to RFC 6241. Example:
 
  OLD
 
   o  datastore: an instantiated data tree
 
  NEW
 
   o  datastore: A conceptual place to store and access information.
  A datastore might be implemented, for example, using files, a
  database, flash memory locations, or combinations thereof.
  [Matches the definition in RFC 6241.]
>>> 
>>> To start with, I think we should define client and server more
>>> generically than just NETCONF:
>>> 
>>>  server: An entity that provides access to YANG-defined data to a
>>>  client, over some network management protocol.
>> 
>> But then perhaps "device" is a broader term in the sense that the
>> server is just
>> a software component running in a device.
> 
> So how do you define "device"?

An entity that's being managed and runs the server.

> 
>> For example, it is the device that is required to operationally use
>> default values of parameters that are not present in the
>> configuration. Replacing "device" with "server" here IMO means something
> 
> The text was actually already in RFC 6020:
> 
>   When the default value is in use, the server MUST operationally
>   behave as if the leaf was present in the data tree with the default
>   value as its value.

Right, but with your definition of "server" there is no guarantee that, say, if 
"mtu" on an interface has a default value and no value is configured, then the 
default value is really used - MTU has nothing to do with server operation.

Lada

> 
> 
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Martin Bjorklund]

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 *configuration data* (which it actually says upfront).
The text in 8.2.1 is not intended to be for generic rpcs; it is
intended for rpcs that modify configuration datastores (edit-config).

The whole idea is that there are really three points in time where
"checks" are done - (1) simple type checks and structural checks when
the edit-config is parsed (2) check that the requested _operations_
are valid and (3) check that the _resulting datastore_ is valid.

This said, note that section 8.1 applies to *all* valid data trees,
including rpc/action input/output.

So, in summary, 8.1 defines the generic rules for valid data trees,
and 8.2 defines the NETCONF-specific behavior for edit-config
processing.

In order to resolve Balazs' original issue, we need to agree what
should happen in these cases *for NETCONF*.

Suppose we have:

 leaf a {
   when "../b = 42";
   type int32;
 }
 leaf b {
   type int32;
 }


Scenario A
--
The DB contains b=10

The server gets an edit-config with:

   2

What is the result?

 1)  an error is returned
 2)  ok; the request to set a to 2 is silently dropped


Scenario B
--
The DB contains b=10.

The server gets an edit-config with:

   2
   42

What is the result?

 1)  an error is returned
 2)  ok, db now has b=42; the request to set a to 2 is silently
 dropped
 3)  ok, db now has a=2 and b=42


Scenario C  (same as 2, but different order in edit-config)
--
The DB contains b=10.

The server gets an edit-config with:

   42
   2

What is the result?

 1)  an error is returned
 2)  ok, db now has b=42; the request to set a to 2 is silently
 dropped
 3)  ok, db now has a=2 and b=42



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Balazs Lengyel]

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 should have the same result.
regards Balazs


On 2015-10-16 14:01, Martin Bjorklund wrote:

Scenario C  (same as 2, but different order in edit-config)


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Martin Bjorklund]

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 the best: because it
> > is the easiest to understand for the operator, with the fewest corner
> > cases.
> > Also we must define if in the same transaction we set b=42 and
> > a=2. which of the 3 options are taken?
> > 
> > 
> > We should not leave such complex cases undefined, or alternatively
> > state that they are implementation dependant.
> 
> I might be difficult to say what is a complex case, unless we abandon
> XPath in "when" statements and use something else - and considerably
> simpler.
> 
> Here is another interesting corner case - does it qualify as being
> complex?
> 
> leaf-list bar {
>type uint8;
>when "count(../*) > 1";
> }
> leaf foo {
>type uint8;
> }
> 
> Assuming no instances exist, is this edit allowed? (This was
> essentially your question.)
> 
> 1
> 2

Yes.

> But what about this?
> 
> 1
> 2

No.

(Note the new text that specifies that 'bar' is tentatively replaced
with a dummy node during when processing)


> 
> Lada
> 
> > regards Balazs
> > 
> > On 2015-10-16 09:43, Ladislav Lhotka wrote:
> >>> 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.
> >> 
> >> Within the PAYLOAD (as this section describes), there is no when-stmt
> >> for data nodes within the datastore.  Look at the YANG for
> >> edit-config.
> >> There are no when-stmts for "interface" in "edit-config".
> >> 
> > Andy, there is some confusion here.  The section talks about:
> > 
> > For configuration data, there are three windows when constraints
> > MUST be enforced:
> > 
> > - during parsing of RPC payloads
> > - during processing of NETCONF operations
> > - during validation
> > 
> > So the entire section talks about constraints *on configuration data*.
> > 
> > 
> > 
>  http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421
>  
>  
>  
>  Here is the YANG for edit-config?
>  Please point out the when-stmts in this rpc-stmt
>  specific to the "interface" node.
>  I just see an "anyxml" that has no when-stmts at all.
>  
>  So enforcing the when constraint on the RPC PAYLOAD
>  clearly has nothing to do with "interface" -- just the parameters
>  specified in the rpc-stmt.
>  
> >>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
> >>> rephrase the intro text in 8.2) But I think Balazs is also right.
> >>> Suppose you have:
> >>> 
> >>> leaf a {
> >>>   when "../b = 42";
> >>>   type int32;
> >>> }
> >>> leaf b {
> >>>   type int32;
> >>> }
> >>> 
> >>> and the db contains b=10.
> >>> 
> >>> Suppose I send an edit-config with a=2.  What is the result?
> >>> 
> >>> 1)  you get an error back
> >>> 2)  you get ok; the request to set a to 2 is silently dropped
> >>> 3)  something else
> >>> 
> >> IMO YANG spec shouldn't deal with this kind of things in the first
> >> place. It should be sufficient to define two validation levels,
> >> e.g. syntactic (schema) and semantic validity. Stating what a protocol
> >> does if either of these validity types is violated would then be up to
> >> the protocol spec, and different protocols may use different
> >> approaches.
> >> 
> >> That said, I like #1 best.
> >> 
> >> Lada
> >> 
> >> 
> >>> 
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>> ___
> >>> netmod mailing list
> >>> 
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> netmod mailing list
> >> 
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> 
> >> 
> >> 
> > 
> > -- 
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909  email: 
> > balazs.leng...@ericsson.com
> > 
> > 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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 transactional.
> 
> 
>3.  Support for both synchronous and asynchronous configuration
>operations
> 
>A. A server may choose to support only synchronous configuration
>   operations, or only asynchronous configuration operations, or
>   both synchronous and asynchronous configuration operations in
>   a client specified per-operation basis.

I think the most common mode *today* is a mix of sync/async, on a
per-object basis.  Is this mode no longer valid?

>B. Support for synchronous operations as per the definition of
>   "synchronous configuration operation".

Doesn't this follow from A?

>C. Support for asynchronous operations as per the definition of
>   "asynchronous configuration operation".  Servers that support
>   asynchronous configuration operations MAY also provide a
>   verify operation that a client can request from the server to
>   return information regarding the difference between the
>   intended and applied configurations.
> 
>D. Support for best effort and rollback-on-error error handling
>   semantics.  The configuration protocol, or default server
>   behavior, MUST specify whether the configuration is applied
>   in a best effort fashion, or using "rollback on error"
>   semantics - where all configuration changes in the request are
>   undone if processing of any part of the configuration update
>   failed.  A configuration protocol, or server, SHOULD provide
>   support for rollback-on-error behavior and MAY choose to
>   provide support for best effort semantics as well.


/martin


> 
> Any comments?
> 
> Thanks,
> Rob
> 
> 
> On 15/10/2015 18:32, Kent Watsen wrote:
> > Again, with better formatting for the list:
> >
> > 3.  Support for both synchronous and asynchronous configuration
> > operations (see terms)
> >
> > A. A server may only support synchronous configuration
> >operations, or may only support asynchronous configuration
> >operations, or may support synchronicity to be client
> >specified on a per-operation basis.
> >
> >
> > C. Support for synchronous configuration operations
> >requires the server to block sending a response to
> >the client until it is able to able to determine whether
> >there are any errors in the request or errors from
> >applying the configuration change.
> >  D. Support for asynchronous configuration operations
> >requires the server to send a response to the client
> >immediately indicated that the request was accepted
> >and send a notification to the client when the intended
> >config is fully effective or there are any errors from
> >applying the configuration change.
> >
> > E. Support for asynchronous configuration operations MAY
> >also provide a verify operation which a client can request
> >from the server to obtain information regarding the
> >difference between the intended and applied configurations.
> >
> >
> > Kent
> >
> >
> >
> > On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:
> >
> >> Requirement #3 was discussed on today's call.  We agreed to remove the
> >> words "distributed" and "transactional" and to reword it in terms of
> >> "configuration operations".  The resulting text follows:
> >>
> >>
> >>3.  Support for both synchronous and asynchronous configuration
> >> operations (see terms)
> >>
> >>A. A server may only support synchronous configuration operations,
> >> or may only support
> >>   asynchronous configuration operations, or may support
> >> synchronicity to be client
> >>   specified on a per-operation basis.
> >>
> >>
> >>C. Support for synchronous configuration operations requires the
> >> server to block
> >>   sending a response to the client until it is able to able to
> >> determine whether
> >>   there are any errors in the request or errors from applying the
> >> configuration
> >>   change.
> >>D. Support for asynchronous configuration operations requires
> >>the
> >> server to send
> >>   a response to the client immediately indicated that the request
> >> was accepted
> >>   and send a notification to the client when the intended config
> >> is fully
> >>   effective or there are any errors from applying the
> >> configuration change.
> >>
> >>E. Support for asynchronous configuration 

Re: [netmod] Order of evaluation for when?

[Ladislav Lhotka]

> 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 for the operator, with the fewest corner cases.
> Also we must define if in the same transaction we set b=42 and a=2. which of 
> the 3 options are taken?
> 
> 
> We should not leave such complex cases undefined, or alternatively state that 
> they are implementation dependant.

I might be difficult to say what is a complex case, unless we abandon XPath in 
"when" statements and use something else - and considerably simpler.

Here is another interesting corner case - does it qualify as being complex?

leaf-list bar {
   type uint8;
   when "count(../*) > 1";
}
leaf foo {
   type uint8;
}

Assuming no instances exist, is this edit allowed? (This was essentially your 
question.)

1
2

But what about this?

1
2

Lada

> regards Balazs
> 
> On 2015-10-16 09:43, Ladislav Lhotka wrote:
>>> 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.
>> 
>> Within the PAYLOAD (as this section describes), there is no when-stmt
>> for data nodes within the datastore.  Look at the YANG for edit-config.
>> There are no when-stmts for "interface" in "edit-config".
>> 
> Andy, there is some confusion here.  The section talks about:
> 
> For configuration data, there are three windows when constraints
> MUST be enforced:
> 
> - during parsing of RPC payloads
> - during processing of NETCONF operations
> - during validation
> 
> So the entire section talks about constraints *on configuration data*.
> 
> 
> 
 http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#edit-config.421
 
 
 
 Here is the YANG for edit-config?
 Please point out the when-stmts in this rpc-stmt
 specific to the "interface" node.
 I just see an "anyxml" that has no when-stmts at all.
 
 So enforcing the when constraint on the RPC PAYLOAD
 clearly has nothing to do with "interface" -- just the parameters
 specified in the rpc-stmt.
 
>>> Ok, you're right.  8.2.1 should be kept as it is.  (we may need to
>>> rephrase the intro text in 8.2) But I think Balazs is also right.
>>> Suppose you have:
>>> 
>>> leaf a {
>>>   when "../b = 42";
>>>   type int32;
>>> }
>>> leaf b {
>>>   type int32;
>>> }
>>> 
>>> and the db contains b=10.
>>> 
>>> Suppose I send an edit-config with a=2.  What is the result?
>>> 
>>> 1)  you get an error back
>>> 2)  you get ok; the request to set a to 2 is silently dropped
>>> 3)  something else
>>> 
>> IMO YANG spec shouldn't deal with this kind of things in the first place. It 
>> should be sufficient to define two validation levels, e.g. syntactic 
>> (schema) and semantic validity. Stating what a protocol does if either of 
>> these validity types is violated would then be up to the protocol spec, and 
>> different protocols may use different approaches.
>> 
>> That said, I like #1 best.
>> 
>> Lada
>> 
>> 
>>> 
>>> 
>>> 
>>> /martin
>>> 
>>> ___
>>> netmod mailing list
>>> 
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> 
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> 
>> 
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909  email: 
> balazs.leng...@ericsson.com
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

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
> >
> > Ok, fixed.
> >
> >>  / and perhaps explicitly
> >>   state that unless stated otherwise server means a server providing
> >>   access to a YANG defined data tree.
> >
> > Yes this makes sense.  But then I guess we shouldn't import client and
> > server from 6241.  (And most other documents (restconf etc) should
> > probably import these terms from ths document).  See also below.
> >
> >> * p12/p13
> >> 
> >>   We import 7 terms from RFC 6241. Would it make sense to copy the
> >>   necessary text in order to avoid a too strict binding to RFC 6241?
> >>   In particular, 'client' and 'server' means NETCONF client and server
> >>   if we import from RFC 6241 but this may be a bit narrow given that
> >>   we have RESTCONF as well. In an ideal world, we would factor out
> >>   core architectural concepts but the best we can do is likely to
> >>   define core concepts inline, pointing out where they are the same.
> >>   The idea is to loosen the coupling to RFC 6241. Example:
> >> 
> >>   OLD
> >> 
> >>o  datastore: an instantiated data tree
> >> 
> >>   NEW
> >> 
> >>o  datastore: A conceptual place to store and access information.
> >>   A datastore might be implemented, for example, using files, a
> >>   database, flash memory locations, or combinations thereof.
> >>   [Matches the definition in RFC 6241.]
> >
> > To start with, I think we should define client and server more
> > generically than just NETCONF:
> >
> >   server: An entity that provides access to YANG-defined data to a
> >   client, over some network management protocol.
> 
> But then perhaps "device" is a broader term in the sense that the
> server is just
> a software component running in a device.

So how do you define "device"?

> For example, it is the device that is required to operationally use
> default values of parameters that are not present in the
> configuration. Replacing "device" with "server" here IMO means something

The text was actually already in RFC 6020:

   When the default value is in use, the server MUST operationally
   behave as if the leaf was present in the data tree with the default
   value as its value.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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 transactional text out of the 
definition for synchronous/asynchronous configuration operations and 
instead include it as a sub-bullet for the section 3 requirements.  I'll 
send my proposed text for the section 3 requirements on that separate 
email thread.


Hence, I propose that we revert to this text for synchronous 
configuration operation:


Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously 
with

respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see 
terms),
before replying to the client.  The reply to the client indicates 
whether there

are any errors in the request or errors from applying the configuration
change.

I agree with the existing proposed text for asynchronous configuration 
operation and also support the proposal to drop the definition of 
synchronous/asynchronous configuration servers if they are not being used.


Thanks,
Rob


On 15/10/2015 18:03, Kent Watsen wrote:

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.  The server MUST fully attempt to 
apply

the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see 
terms),

before replying to the client.  This may be transactional or non-
transactional (need terms!).  The transactionality of the operation
may be a server property or specified on as a property.
The reply to the client indicates whether there
are any errors in the request or errors from applying the 
configuration

change.
Asynchronous configuration operation - A configuration request to 
update

the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its 
intended

configuration (see term) before replying to the client indicating
whether the request will be processed.  This reply to the client only
indicates whether there are any errors in the  original request.  The
server's applied configuration state (see term) is updated after the
configuration change has been fully effected to all impacted 
components
in the server.  Once applied, there MUST be a mechanism for the 
client to

determine when the request has completed processing and whether the
intended config is now fully effective or there are any errors from
applying the configuration change, which could be from an asynchronous
notification or via a client operation.

Synchronous configuration server - a configuration server that 
processes

all configuration operations as synchronous configuration operations.
Asynchronous configuration server - a configuration server that 
processes

all configuration operations as asynchronous configuration operations.


We have consensus on the above, but are hoping for some word-smithing 
before committing it to the draft.  Anybody want to take a crack at it?


BTW, do we still need to define the last two terms anymore?  - they're 
not used elsewhere in the draft...


Kent



From: Gert Grammel >
Date: Thursday, October 15, 2015 at 10:35 AM
To: Robert Wilton >, Kent 
Watsen >, 
"netmod@ietf.org " >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous 
vs asynchronous (esp. wrt intended and applied)


Rob,

From a client perspective a server has three states:

 1. intended != applied
 2. Funny-state
 3. Intended == applied

Irrespective of synchronous or asynchronous processing in the server, 
the third state MUST be reported to the client. Else (from a client 
perspective) the server stays in funny-state forever.



Gert


From: Robert Wilton >
Date: Thursday 15 October 2015 15:59
To: Gert Grammel >, 
Kent Watsen >, 
"netmod@ietf.org " >
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous 
vs asynchronous (esp. wrt 

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

[Robert Wilton]

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 asynchronous configuration
   operations

   A. A server may choose to support only synchronous configuration
  operations, or only asynchronous configuration operations, or
  both synchronous and asynchronous configuration operations in
  a client specified per-operation basis.

   B. Support for synchronous operations as per the definition of
  "synchronous configuration operation".

   C. Support for asynchronous operations as per the definition of
  "asynchronous configuration operation".  Servers that support
  asynchronous configuration operations MAY also provide a
  verify operation that a client can request from the server to
  return information regarding the difference between the
  intended and applied configurations.

   D. Support for best effort and rollback-on-error error handling
  semantics.  The configuration protocol, or default server
  behavior, MUST specify whether the configuration is applied
  in a best effort fashion, or using "rollback on error"
  semantics - where all configuration changes in the request are
  undone if processing of any part of the configuration update
  failed.  A configuration protocol, or server, SHOULD provide
  support for rollback-on-error behavior and MAY choose to
  provide support for best effort semantics as well.

Any comments?

Thanks,
Rob


On 15/10/2015 18:32, Kent Watsen wrote:

Again, with better formatting for the list:

3.  Support for both synchronous and asynchronous configuration
operations (see terms)

A. A server may only support synchronous configuration
   operations, or may only support asynchronous configuration
   operations, or may support synchronicity to be client
   specified on a per-operation basis.


C. Support for synchronous configuration operations
   requires the server to block sending a response to
   the client until it is able to able to determine whether
   there are any errors in the request or errors from
   applying the configuration change.
 
D. Support for asynchronous configuration operations

   requires the server to send a response to the client
   immediately indicated that the request was accepted
   and send a notification to the client when the intended
   config is fully effective or there are any errors from
   applying the configuration change.

E. Support for asynchronous configuration operations MAY
   also provide a verify operation which a client can request
   from the server to obtain information regarding the
   difference between the intended and applied configurations.


Kent



On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:


Requirement #3 was discussed on today's call.   We agreed to remove the
words "distributed" and "transactional" and to reword it in terms of
"configuration operations".  The resulting text follows:


   3.  Support for both synchronous and asynchronous configuration
operations (see terms)

   A. A server may only support synchronous configuration operations,
or may only support
  asynchronous configuration operations, or may support
synchronicity to be client
  specified on a per-operation basis.


   C. Support for synchronous configuration operations requires the
server to block
  sending a response to the client until it is able to able to
determine whether
  there are any errors in the request or errors from applying the
configuration
  change.

   D. Support for asynchronous configuration operations requires the

server to send
  a response to the client immediately indicated that the request
was accepted
  and send a notification to the client when the intended config
is fully
  effective or there are any errors from applying the
configuration change.

   E. Support for asynchronous configuration operations MAY also
provide a verify
  operation which a client can request from the server to obtain
information
  regarding the difference between the intended and applied
configurations.



We have consensus on the above, but wanted to rewrite it relying more on
the terms from the Terminology section, and also potentially merge E into
D.

Anybody want to take a stab at it?

Thanks,
Kent



On 10/14/15, 8:00 PM, "Nadeau Thomas"  wrote:


On Oct 14, 2015:7:51 PM, at 7:51 PM, Kent Watsen 
wrote:



On 

Re: [netmod] not a non-presence container

[William Lupton]

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
> *To: *jonat...@hansfords.net
> *Cc: *w...@cantab.net;netmod@ietf.org
>
> *Subject: *Re: [netmod] not a non-presence container
>
>
>
>
>
> Jonathan Hansford  wrote:
>
> > If that misinterpretation has already happened for (at least) one
>
> > individual, would it be worth adding the clarification and remove the
>
> > ambiguity?
>
>
>
> Sure.  The words "not a non-presence container" occurs a couple of
>
> times throughout the document.
>
>
>
> Would it be correct to write "not a non-presence-container"?
>
>
>
>
>
> /martin
>
>
>
>
>
>
>
> >
>
> > Jonathan
>
> >
>
> >
>
> >
>
> > From: William Lupton
>
> > Sent: 14 October 2015 23:28
>
> > To: Martin Bjorklund
>
> > Cc: netmod@ietf.org
>
> > Subject: Re: [netmod] not a non-presence container
>
> >
>
> >
>
> > Thanks. I see now. As you will have realised, I parsed "not a
>
> > non-presence container" as "(not a non-presence) container" (WRONG)
>
> > rather than "not a (non-presence container)" (RIGHT). Cheers, W.
>
> >
>
> > On 14 October 2015 at 20:41, Martin Bjorklund  wrote:
>
> > William Lupton  wrote:
>
> > > All,
>
> > >
>
> > > Both RFC 6020 and the bis draft use the term "not a non-presence
>
> > > container", sometimes with a reference to section 7.5.1.
>
> > >
>
> > > Does this term mean the same as "presence container"?
>
> >
>
> > No.  A list (for example) is not a non-presence container.
>
> >
>
> > > If so, I think it
>
> > > would be easier (on the reader!) to say that instead. If not, I think
>
> > > that
>
> > > the term warrants a mention in section 7.5.1.
>
> >
>
> > The term is "non-presence container", and it is explained in 7.5.1.
>
> >
>
> >
>
> > /martin
>
> >
>
> >
>
> >
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Robert Wilton]

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
semantics without introducing the term transactional.


3.  Support for both synchronous and asynchronous configuration
operations

A. A server may choose to support only synchronous configuration
   operations, or only asynchronous configuration operations, or
   both synchronous and asynchronous configuration operations in
   a client specified per-operation basis.

I think the most common mode *today* is a mix of sync/async, on a
per-object basis.

Yes, I agree.

It might also be useful to have some text somewhere in the draft that 
makes this point clear (i.e. that existing NC/RC implementations are 
neither sync or async).



   Is this mode no longer valid?
I don't think that we can or should invalidate existing netconf server 
implementations.


However, to sensibly support the opstate requirements, I think that the 
client has to know whether a particular request is, or all requests are, 
being handled by the server in a sync or async fashion.


There has been a suggestion that existing NC implementations could be 
regarded as being async, but that isn't going to work if there ends up 
needing to be a separate "async config apply has completed" notification 
since no existing NC/RC implementations are going to generate such a 
notification.


So, I think that ultimately operations need to be regarded as one of:
 (i) netconf current behavior
 (ii) explicit sync
 (iii) explicit async

It isn't clear to me whether only servers that support (ii) or (iii) can 
meet the opstate requirements, or whether servers supporting (i) can 
also be supported.  What do you think?





B. Support for synchronous operations as per the definition of
   "synchronous configuration operation".

Doesn't this follow from A?
Yes, possibly.  I don't mind if B is deleted.  If we do this then I 
would suggest that we also delete the analogous first sentence of C, and 
re-introduce the "(see terms)" text in the headline description.


Thanks,
Rob





C. Support for asynchronous operations as per the definition of
   "asynchronous configuration operation".  Servers that support
   asynchronous configuration operations MAY also provide a
   verify operation that a client can request from the server to
   return information regarding the difference between the
   intended and applied configurations.

D. Support for best effort and rollback-on-error error handling
   semantics.  The configuration protocol, or default server
   behavior, MUST specify whether the configuration is applied
   in a best effort fashion, or using "rollback on error"
   semantics - where all configuration changes in the request are
   undone if processing of any part of the configuration update
   failed.  A configuration protocol, or server, SHOULD provide
   support for rollback-on-error behavior and MAY choose to
   provide support for best effort semantics as well.


/martin



Any comments?

Thanks,
Rob


On 15/10/2015 18:32, Kent Watsen wrote:

Again, with better formatting for the list:

 3.  Support for both synchronous and asynchronous configuration
 operations (see terms)

 A. A server may only support synchronous configuration
operations, or may only support asynchronous configuration
operations, or may support synchronicity to be client
specified on a per-operation basis.


 C. Support for synchronous configuration operations
requires the server to block sending a response to
the client until it is able to able to determine whether
there are any errors in the request or errors from
applying the configuration change.
  D. Support for asynchronous configuration operations
requires the server to send a response to the client
immediately indicated that the request was accepted
and send a notification to the client when the intended
config is fully effective or there are any errors from
applying the configuration change.

 E. Support for asynchronous configuration operations MAY
also provide a verify operation which a client can request
from the server to obtain information regarding the
difference between the intended and applied configurations.


Kent



On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:


Requirement #3 was discussed on today's call.  We agreed to remove the
words "distributed" and "transactional" and to reword it in terms of

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

[Kent Watsen]

>>> 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.  The server MUST fully attempt to
>>>apply
>>>  the configuration change to all impacted components in the server,
>>>  updating both the server's intended and applied configuration
>>>(see terms),
>>>  before replying to the client.  This may be transactional or non-
>>>  transactional (need terms!).  The transactionality of the
>>>operation
>>>  may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
>
>It was added in the meeting because some interpretations of the text
>assumed that the text implied that the server would always
>rollback-on-error, so the proposed text was intended to clarify that.
>
>However, I think that this clarification applies equally to both sync
>and async operations and hence I have proposed (on a separate thread)
>that it be documented as part of the requirement 3 "Support for both
>synchronous and asynchronous configuration operations" instead.


So the proposal is to remove the last two sentences? - I'm OK with that.

I think that the new word "attempt" in the previous sentence fixed it to
be (IMO) a very good definition for what is meant by a "synchronous
configuration operation" without it getting mired in details.

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Andy Bierman]

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.

There is no need for the YANG spec to point out that the constraints
only apply to YANG. That is self-evident.

Why doesn't when-stmt apply to a plain rpc?


   rpc plot-point {
 input {
leaf 3d {
  type boolean;
   default false;
}
leaf X { type uint32; }
leaf Y { type uint32; }
leaf Z {
  when "../3d";
  type uint32;
   }
 }
   }


Are you saying that the when-stmt for Z is not allowed?
Or that it gets ignored and not enforced?
IMO this section was rather clear -- it applies to when-stmt
in the RPC input.


Andy


On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund  wrote:

> 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 *configuration data* (which it actually says upfront).
> The text in 8.2.1 is not intended to be for generic rpcs; it is
> intended for rpcs that modify configuration datastores (edit-config).
>
> The whole idea is that there are really three points in time where
> "checks" are done - (1) simple type checks and structural checks when
> the edit-config is parsed (2) check that the requested _operations_
> are valid and (3) check that the _resulting datastore_ is valid.
>
> This said, note that section 8.1 applies to *all* valid data trees,
> including rpc/action input/output.
>
> So, in summary, 8.1 defines the generic rules for valid data trees,
> and 8.2 defines the NETCONF-specific behavior for edit-config
> processing.
>
> In order to resolve Balazs' original issue, we need to agree what
> should happen in these cases *for NETCONF*.
>
> Suppose we have:
>
>  leaf a {
>when "../b = 42";
>type int32;
>  }
>  leaf b {
>type int32;
>  }
>
>
> Scenario A
> --
> The DB contains b=10
>
> The server gets an edit-config with:
>
>2
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok; the request to set a to 2 is silently dropped
>
>
> Scenario B
> --
> The DB contains b=10.
>
> The server gets an edit-config with:
>
>2
>42
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok, db now has b=42; the request to set a to 2 is silently
>  dropped
>  3)  ok, db now has a=2 and b=42
>
>
> Scenario C  (same as 2, but different order in edit-config)
> --
> The DB contains b=10.
>
> The server gets an edit-config with:
>
>42
>2
>
> What is the result?
>
>  1)  an error is returned
>  2)  ok, db now has b=42; the request to set a to 2 is silently
>  dropped
>  3)  ok, db now has a=2 and b=42
>
>
>
> /martin
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

> 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: Gert Grammel >
Date: Friday, October 16, 2015 at 10:16 AM
To: Kent Watsen >
Cc: Robert Wilton >, 
"netmod@ietf.org" 
>
Subject: 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 the server's applied configuration (see terms),
before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen 
> wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers.

Thank you (and Juergen) for the confirmation.   Again, if no objections, these 
two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as being 
discussed elsewhere on this thread]

OLD:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.

NEW

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request (i.e. a blocking call).  The server MUST 
fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.


What do you think?

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

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 the server's applied configuration (see terms),
before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen 
> wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers.

Thank you (and Juergen) for the confirmation.   Again, if no objections, these 
two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as being 
discussed elsewhere on this thread]

OLD:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.

NEW

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request (i.e. a blocking call).  The server MUST 
fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.


What do you think?

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

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  wrote:
> 
> Hi Juergen,
> 
>> On 15/10/2015 22:59, Juergen Schoenwaelder wrote:
>>> On Thu, Oct 15, 2015 at 05:03:33PM +, Kent Watsen wrote:
>>> 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.  The server MUST fully attempt to apply
>>> the configuration change to all impacted components in the server,
>>> updating both the server's intended and applied configuration (see 
>>> terms),
>>> before replying to the client.  This may be transactional or non-
>>> transactional (need terms!).  The transactionality of the operation
>>> may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
> 
> It was added in the meeting because some interpretations of the text assumed 
> that the text implied that the server would always rollback-on-error, so the 
> proposed text was intended to clarify that.
> 
> However, I think that this clarification applies equally to both sync and 
> async operations and hence I have proposed (on a separate thread) that it be 
> documented as part of the requirement 3 "Support for both synchronous and 
> asynchronous configuration operations" instead.
> 
> Thanks,
> Rob
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

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 have a question about Yang language support for snmp alarm correlation.
> It could be nice if a device supplier, specifying the Yang model of his 
> network element, could also specify the correspondence between snmp alarms 
> produced and affected part of the yang model of its device. This will allow 
> for correlation between snmp traps (or other events) affecting a given object 
>  and the service instance created (through Netconf/yang) on that object.
> 
> As for example, let's say a device send the following trap
> 
> xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/2015 
> 14:13:27
>   Time stamp: 0 days 00h:00m:40s.15th
>   Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: 
> SNMPv2c Notification
>   Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
>   Community: public
>   Enterprise: enterprises.8072.3.2.10
>   Bindings (8)
> Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
> Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
> Binding #3: ifIndex.6 *** (int32) 6
> Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
> Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
> Binding #6: ifAdminStatus.6 *** (int32) down(2)
> Binding #7: ifOperStatus.6 *** (int32) down(2)
> Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10
> 
> On the same device I created a service instance, which consists on an 
> interface configuration . The interface, described through the YANG model is 
> the following
> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']
> 
> Actually the SNMP trap impacts on the same interface where I configured my 
> service instance, but I have no means to understand it.
> 
> How can I enrich my YANG model to support the information that a trap with 
> oid= snmpTraps.3 and ifDescr = dp0s3 affect the same interface described in 
> Yang by the xpath expression 
> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']?
> 
> Do I need to define a new YANG extension statement to carry on such a 
> correspondence, or can I rely on existing structures?
> 
> Regards,
> Giuseppe De Noia
> 
> 
> 
> 
> --
> Telecom Italia
> Giuseppe De Noia
> T.TG.NM.OSI,
> Via Reiss Romoli, 274  10148 Torino
> 011 227
> 331 6001197
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
> darne immediata comunicazione al mittente e di provvedere alla sua 
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged 
> information intended for the addressee(s) only. Dissemination, copying, 
> printing or use by anybody else is unauthorised. If you are not the intended 
> recipient, please delete this message and any attachments and advise the 
> sender by return e-mail, Thanks.
> 
> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? 
> necessario.
> 


> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Order of evaluation for when?

[Balazs Lengyel]

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, 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.  When-stmt has always been full
of problems that exist on paper but not in real servers.

This may well be because YANG module authors so far have been aware of the pitfalls of 
"when". Now that YANG is mushrooming all around, it may change very soon.

Lada


There is no need for the YANG spec to point out that the constraints
only apply to YANG. That is self-evident.

Why doesn't when-stmt apply to a plain rpc?


rpc plot-point {
  input {
 leaf 3d {
   type boolean;
default false;
 }
 leaf X { type uint32; }
 leaf Y { type uint32; }
 leaf Z {
   when "../3d";
   type uint32;
}
  }
}


Are you saying that the when-stmt for Z is not allowed?
Or that it gets ignored and not enforced?
IMO this section was rather clear -- it applies to when-stmt
in the RPC input.


Andy


On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund  wrote:
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 *configuration data* (which it actually says upfront).
The text in 8.2.1 is not intended to be for generic rpcs; it is
intended for rpcs that modify configuration datastores (edit-config).

The whole idea is that there are really three points in time where
"checks" are done - (1) simple type checks and structural checks when
the edit-config is parsed (2) check that the requested _operations_
are valid and (3) check that the _resulting datastore_ is valid.

This said, note that section 8.1 applies to *all* valid data trees,
including rpc/action input/output.

So, in summary, 8.1 defines the generic rules for valid data trees,
and 8.2 defines the NETCONF-specific behavior for edit-config
processing.

In order to resolve Balazs' original issue, we need to agree what
should happen in these cases *for NETCONF*.

Suppose we have:

  leaf a {
when "../b = 42";
type int32;
  }
  leaf b {
type int32;
  }


Scenario A
--
The DB contains b=10

The server gets an edit-config with:

2

What is the result?

  1)  an error is returned
  2)  ok; the request to set a to 2 is silently dropped


Scenario B
--
The DB contains b=10.

The server gets an edit-config with:

2
42

What is the result?

  1)  an error is returned
  2)  ok, db now has b=42; the request to set a to 2 is silently
  dropped
  3)  ok, db now has a=2 and b=42


Scenario C  (same as 2, but different order in edit-config)
--
The DB contains b=10.

The server gets an edit-config with:

42
2

What is the result?

  1)  an error is returned
  2)  ok, db now has b=42; the request to set a to 2 is silently
  dropped
  3)  ok, db now has a=2 and b=42



/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

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 define transactional error handling
> > semantics without introducing the term transactional.
> >
> >
> >3.  Support for both synchronous and asynchronous configuration
> >operations
> >
> >A. A server may choose to support only synchronous configuration
> >   operations, or only asynchronous configuration operations, or
> >   both synchronous and asynchronous configuration operations in
> >   a client specified per-operation basis.
>
> I think the most common mode *today* is a mix of sync/async, on a
> per-object basis.  Is this mode no longer valid?
>

good question.
I am curious how this synchronous return will be deployed.
Is the intent to rewrite NETCONF and RESTCONF so they have
some mechanism like "don't return until intended == applied".


Andy


>
> >B. Support for synchronous operations as per the definition of
> >   "synchronous configuration operation".
>
> Doesn't this follow from A?
>
> >C. Support for asynchronous operations as per the definition of
> >   "asynchronous configuration operation".  Servers that support
> >   asynchronous configuration operations MAY also provide a
> >   verify operation that a client can request from the server to
> >   return information regarding the difference between the
> >   intended and applied configurations.
> >
> >D. Support for best effort and rollback-on-error error handling
> >   semantics.  The configuration protocol, or default server
> >   behavior, MUST specify whether the configuration is applied
> >   in a best effort fashion, or using "rollback on error"
> >   semantics - where all configuration changes in the request are
> >   undone if processing of any part of the configuration update
> >   failed.  A configuration protocol, or server, SHOULD provide
> >   support for rollback-on-error behavior and MAY choose to
> >   provide support for best effort semantics as well.
>
>
> /martin
>
>
> >
> > Any comments?
> >
> > Thanks,
> > Rob
> >
> >
> > On 15/10/2015 18:32, Kent Watsen wrote:
> > > Again, with better formatting for the list:
> > >
> > > 3.  Support for both synchronous and asynchronous configuration
> > > operations (see terms)
> > >
> > > A. A server may only support synchronous configuration
> > >operations, or may only support asynchronous configuration
> > >operations, or may support synchronicity to be client
> > >specified on a per-operation basis.
> > >
> > >
> > > C. Support for synchronous configuration operations
> > >requires the server to block sending a response to
> > >the client until it is able to able to determine whether
> > >there are any errors in the request or errors from
> > >applying the configuration change.
> > >  D. Support for asynchronous configuration operations
> > >requires the server to send a response to the client
> > >immediately indicated that the request was accepted
> > >and send a notification to the client when the intended
> > >config is fully effective or there are any errors from
> > >applying the configuration change.
> > >
> > > E. Support for asynchronous configuration operations MAY
> > >also provide a verify operation which a client can request
> > >from the server to obtain information regarding the
> > >difference between the intended and applied configurations.
> > >
> > >
> > > Kent
> > >
> > >
> > >
> > > On 10/15/15, 1:22 PM, "Kent Watsen"  wrote:
> > >
> > >> Requirement #3 was discussed on today's call.  We agreed to remove the
> > >> words "distributed" and "transactional" and to reword it in terms of
> > >> "configuration operations".  The resulting text follows:
> > >>
> > >>
> > >>3.  Support for both synchronous and asynchronous configuration
> > >> operations (see terms)
> > >>
> > >>A. A server may only support synchronous configuration
> operations,
> > >> or may only support
> > >>   asynchronous configuration operations, or may support
> > >> synchronicity to be client
> > >>   specified on a per-operation basis.
> > >>
> > >>
> > >>C. Support for synchronous configuration operations requires
> the
> > >> server to block
> > >>   sending a response to the client until it is able to able to
> > >> determine whether
> > >>   there are any errors in the request or errors from applying
> the
> > >> 

Re: [netmod] Order of evaluation for when?

[Xiang Li]

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.  When-stmt has always been full
of problems that exist on paper but not in real servers.

There is no need for the YANG spec to point out that the constraints
only apply to YANG. That is self-evident.

Why doesn't when-stmt apply to a plain rpc?


rpc plot-point {
  input {
 leaf 3d {
   type boolean;
default false;
 }
 leaf X { type uint32; }
 leaf Y { type uint32; }
 leaf Z {
   when "../3d";
   type uint32;
}
  }
}


Are you saying that the when-stmt for Z is not allowed?

No.


Or that it gets ignored and not enforced?

No.


IMO this section was rather clear -- it applies to when-stmt
in the RPC input.

No - and that's the problem which we need to fix.  It might be that we
all agree on the expected server behavior ,and if that's the case, we
just need to fix the text to align with what we meant.  In order to
resolve this, it would be very helpful if you could provide your
opinion on the questions in the three scenarios below:


Suppose we have:

  leaf a {
when "../b = 42";
type int32;
  }
  leaf b {
type int32;
  }


Scenario A
--
The DB contains b=10

The server gets an edit-config with:

2

What is the result?

  1)  an error is returned
  2)  ok; the request to set a to 2 is silently dropped


I would expect 1).




Scenario B
--
The DB contains b=10.

The server gets an edit-config with:

2
42

What is the result?

  1)  an error is returned
  2)  ok, db now has b=42; the request to set a to 2 is silently
  dropped
  3)  ok, db now has a=2 and b=42


I would expect 3)


Scenario C  (same as 2, but different order in edit-config)
--
The DB contains b=10.

The server gets an edit-config with:

42
2

What is the result?

  1)  an error is returned
  2)  ok, db now has b=42; the request to set a to 2 is silently
  dropped
  3)  ok, db now has a=2 and b=42

I would expect 3)


In SNMP, when a set operation contains multiple variable bindings, the 
rule is:


"Each variable assignment specified by the SetRequest-PDU should be 
effected as if

simultaneously set with respect to all other assignments specified in
the same message."

I would expect the same rule applies for edit-config. That is , the 
order is not

significant.

-Xiang Li

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Randy Presuhn]

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 3:
...
> A. A server may choose to support only synchronous configuration
>operations, or only asynchronous configuration operations, or
>both synchronous and asynchronous configuration operations in
>a client specified per-operation basis.

Editorial comments:
  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
a semantically inappropriate use of the keyword.
  - please avoid unnecessary anthropomorphisms; the server doesn't
"choose" anything here.
  - s/ in/ on/
  - s/client specified/client-specified/

...
>  failed.  A configuration protocol, or server, SHOULD provide
>  support for rollback-on-error behavior and MAY choose to
>  provide support for best effort semantics as well.

Editorial comments:

  - The implications of the RFC 2119 SHOULD and MAY are quite different
depending on which of the two subjects ("protocol" or "server") one
chooses to think about.  The server's observable behaviour is presumably
circumscribed by the protocol, so I suggest removing ", or server,".

  - Please suppress anthropomorphisms.

  - s/best effort/best-effort/

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod