date:20151015

Hi Acee,

I made the necessary changes in ietf-routing, please see the GitHub
repo:

https://github.com/netmod-wg/routing-cfg

A new leaf "rt:routing-instance" was augmented into interface
configuration, and "rt:interfaces" container in configuration is gone.

Below is the complete new tree.

Will this work?

Lada

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw name   string
   | +--rw description?   string
   | +--rw type   identityref
   | +--rw enabled?   boolean
   | +--rw ip:ipv4!
   | |  +--rw ip:enabled?  boolean
   | |  +--rw ip:forwarding?   boolean
   | |  +--rw ip:mtu?  uint16
   | |  +--rw ip:address* [ip]
   | |  |  +--rw ip:ip   inet:ipv4-address-no-zone
   | |  |  +--rw (subnet)
   | |  | +--:(prefix-length)
   | |  |+--rw ip:prefix-length?   uint8
   | |  +--rw ip:neighbor* [ip]
   | | +--rw ip:ipinet:ipv4-address-no-zone
   | | +--rw ip:link-layer-addressyang:phys-address
   | +--rw ip:ipv6!
   | |  +--rw ip:enabled?boolean
   | |  +--rw ip:forwarding? boolean
   | |  +--rw ip:mtu?uint32
   | |  +--rw ip:address* [ip]
   | |  |  +--rw ip:ip   inet:ipv6-address-no-zone
   | |  |  +--rw ip:prefix-lengthuint8
   | |  +--rw ip:neighbor* [ip]
   | |  |  +--rw ip:ipinet:ipv6-address-no-zone
   | |  |  +--rw ip:link-layer-addressyang:phys-address
   | |  +--rw ip:dup-addr-detect-transmits?  uint32
   | |  +--rw ip:autoconf
   | |  |  +--rw ip:create-global-addresses?   boolean
   | |  +--rw v6ur:ipv6-router-advertisements
   | | +--rw v6ur:send-advertisements?boolean
   | | +--rw v6ur:max-rtr-adv-interval?   uint16
   | | +--rw v6ur:min-rtr-adv-interval?   uint16
   | | +--rw v6ur:managed-flag?   boolean
   | | +--rw v6ur:other-config-flag?  boolean
   | | +--rw v6ur:link-mtu?   uint32
   | | +--rw v6ur:reachable-time? uint32
   | | +--rw v6ur:retrans-timer?  uint32
   | | +--rw v6ur:cur-hop-limit?  uint8
   | | +--rw v6ur:default-lifetime?   uint16
   | | +--rw v6ur:prefix-list
   | |+--rw v6ur:prefix* [prefix-spec]
   | |   +--rw v6ur:prefix-spec   inet:ipv6-prefix
   | |   +--rw (control-adv-prefixes)?
   | |  +--:(no-advertise)
   | |  |  +--rw v6ur:no-advertise? empty
   | |  +--:(advertise)
   | | +--rw v6ur:valid-lifetime?   uint32
   | | +--rw v6ur:on-link-flag? boolean
   | | +--rw v6ur:preferred-lifetime?   uint32
   | | +--rw v6ur:autonomous-flag?  boolean
   | +--rw rt:routing-instance?   routing-instance-ref
   +--ro interfaces-state
  +--ro interface* [name]
 +--ro name   string
 +--ro type   identityref
 +--ro oper-statusenumeration
 +--ro last-change?   yang:date-and-time
 +--ro phys-address?  yang:phys-address
 +--ro higher-layer-if*   interface-state-ref
 +--ro lower-layer-if*interface-state-ref
 +--ro speed? yang:gauge64
 +--ro statistics
 |  +--ro discontinuity-timeyang:date-and-time
 |  +--ro in-octets?yang:counter64
 |  +--ro in-unicast-pkts?  yang:counter64
 |  +--ro in-broadcast-pkts?yang:counter64
 |  +--ro in-multicast-pkts?yang:counter64
 |  +--ro in-discards?  yang:counter32
 |  +--ro in-errors?yang:counter32
 |  +--ro in-unknown-protos?yang:counter32
 |  +--ro out-octets?   yang:counter64
 |  +--ro out-unicast-pkts? yang:counter64
 |  +--ro out-broadcast-pkts?   yang:counter64
 |  +--ro out-multicast-pkts?   yang:counter64
 |  +--ro out-discards? yang:counter32
 |  +--ro out-errors?   yang:counter32
 +--ro ip:ipv4!
 |  +--ro ip:forwarding?   boolean
 |  +--ro ip:mtu?  uint16
 |  +--ro ip:address* [ip]
 |  |  +--ro ip:ip   inet:ipv4-address-no-zone
 |  |  +--ro (subnet)?
 |  |  |  +--:(prefix-length)
 |  |  | +--ro ip:prefix-length?   uint8
 |  |  +--ro ip:origin?  ip-address-origin
 |  +--ro ip:neighbor* [ip]
 | +--ro ip:ipinet:ipv4-address-no-zone
 | +--ro ip:link-layer-address?   yang:phys-address
 | +--ro ip:origin?

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] Order of evaluation for when?

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*.

If you interpret this section to talk about the nodes in the
definition of edit-config, nothing in the section makes any sense at
all.   For example:

  If all keys of a list entry are not present, the server MUST reply
  with a "missing-element" error-tag in the rpc-error.

you might say that there are no lists in the definition of
edit-config, so this bullet doesn't apply.



/martin



> 
> So explain which constraint in the payload is being violated?
> 
> 
> Andy
> 
> 
> On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel  > wrote:
> 
> > See below, Balazs
> >
> > On 2015-10-14 23:06, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < 
> > m...@tail-f.com> wrote:
> >
> >> Andy Bierman  wrote:
> >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund 
> >> wrote:
> >> >
> >> > > Andy Bierman  wrote:
> >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
> >> > > wrote:
> >> > > >
> >> > > > > Balazs Lengyel < 
> >> balazs.leng...@ericsson.com> wrote:
> >> > > > > > Hello Martin,
> >> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> >> IMHO you
> >> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
> >> > > error.
> >> > > > >
> >> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
> >> > > > >
> >> > > > >o  If data for a node tagged with "when" is present, and the
> >> "when"
> >> > > > >   condition evaluates to "false", the server MUST reply with
> >> an
> >> > > > >   "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > > and add to 8.2.2:
> >> > > > >
> >> > > > >   o  Modification requests for nodes tagged with "when", and the
> >> "when"
> >> > > > >  condition evaluates to "false".  In this case the server MUST
> >> > > reply
> >> > > > >  with an "unknown-element" error-tag in the rpc-error.
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > This seems like a BIG protocol change to  behavior.
> >> > > > IMO this not an error at all.  In our server the false-when data is
> >> just
> >> > > > pruned, and no error is ever sent for a pruned when=false data node.
> >> > >
> >> > > So you are not following the current RFC 6020 spec?
> >> > >
> >> >
> >> >
> >> > Yes we are following it.
> >>
> >> Ok.
> >>
> >> > The schema for the edit-config RPC operation contains
> >> > an 'anyxml' for  node.  It does not contain any
> >> > when-stmts for the data nodes that get passed in the  node.
> >> > The correct behavior is to just enforce the error on the when-stmts
> >> > that appear in the rpc-stmt.
> >>
> >> I don't understand what you are trying to say.
> >>
> >
> >
> > I know about the text that says a false-when in an RPC is an error.
> > Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.
> >
> >
> >
> >
> >>
> >> Here's an example:
> >>
> >>   augment /if:interfaces/if:interface {
> >> when "if:type = 'ianaift:ethernetCsmacd'";
> >>
> >> container ethernet {
> >>   leaf duplex {
> >> type enumeration {
> >>   enum "half";
> >>   enum "full";
> >> }
> >>   }
> >> }
> >>   }
> >>
> >> Suppose the db is empty.
> >>
> >> What if the edit-confif contains
> >>
> >>   
> >> 
> >>   eth0
> >>   full
> >>   ianaift:ethernetCsmacd
> >> 
> >>   
> >>
> >> will that work or not?  I.e., will the eth0 interface be created with
> >> duplex full?
> >>
> >
> > Yes -- because these are data nodes and the rules for when-stmt
> > on data nodes are different than for rpc-stmt.  Then the when-stmt
> > is a test on whether the node should exist in the candidate or running
> > datastore.
> >
> > Our server applies all the edits first, when checks all the when-stmts
> > that might have changed value.  Nodes that have already existed in the
> > datastore may get pruned, not just the new nodes.
> >
> >
> >
> >
> >
> >>
> >> /martin
> >>
> >>
> >>
> >
> > Andy
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > > I don't think this is a BIG protocol change, since the spec already
> >> > > says that requests for nodes w/ false when expressions MUST send
> >> > > error.  The change is to say that this behavior is true regardless of
> >> > > evaluation order.
> >> > >
>

Re: [netmod] Order of evaluation for when?

2015-10-15 Thread Andy Bierman

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".

So explain which constraint in the payload is being violated?


Andy


On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel  wrote:

> See below, Balazs
>
> On 2015-10-14 23:06, Andy Bierman wrote:
>
>
>
> On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < 
> m...@tail-f.com> wrote:
>
>> Andy Bierman  wrote:
>> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund 
>> wrote:
>> >
>> > > Andy Bierman  wrote:
>> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund 
>> > > wrote:
>> > > >
>> > > > > Balazs Lengyel < 
>> balazs.leng...@ericsson.com> wrote:
>> > > > > > Hello Martin,
>> > > > > > I agree that A1 is what follows the spirit of YANG, but then
>> IMHO you
>> > > > > > should change/correct 8.2.1 in YANG because that implies A2 and
>> > > error.
>> > > > >
>> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
>> > > > >
>> > > > >o  If data for a node tagged with "when" is present, and the
>> "when"
>> > > > >   condition evaluates to "false", the server MUST reply with
>> an
>> > > > >   "unknown-element" error-tag in the rpc-error.
>> > > > >
>> > > > > and add to 8.2.2:
>> > > > >
>> > > > >   o  Modification requests for nodes tagged with "when", and the
>> "when"
>> > > > >  condition evaluates to "false".  In this case the server MUST
>> > > reply
>> > > > >  with an "unknown-element" error-tag in the rpc-error.
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > > This seems like a BIG protocol change to  behavior.
>> > > > IMO this not an error at all.  In our server the false-when data is
>> just
>> > > > pruned, and no error is ever sent for a pruned when=false data node.
>> > >
>> > > So you are not following the current RFC 6020 spec?
>> > >
>> >
>> >
>> > Yes we are following it.
>>
>> Ok.
>>
>> > The schema for the edit-config RPC operation contains
>> > an 'anyxml' for  node.  It does not contain any
>> > when-stmts for the data nodes that get passed in the  node.
>> > The correct behavior is to just enforce the error on the when-stmts
>> > that appear in the rpc-stmt.
>>
>> I don't understand what you are trying to say.
>>
>
>
> I know about the text that says a false-when in an RPC is an error.
> Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.
>
>
>
>
>>
>> Here's an example:
>>
>>   augment /if:interfaces/if:interface {
>> when "if:type = 'ianaift:ethernetCsmacd'";
>>
>> container ethernet {
>>   leaf duplex {
>> type enumeration {
>>   enum "half";
>>   enum "full";
>> }
>>   }
>> }
>>   }
>>
>> Suppose the db is empty.
>>
>> What if the edit-confif contains
>>
>>   
>> 
>>   eth0
>>   full
>>   ianaift:ethernetCsmacd
>> 
>>   
>>
>> will that work or not?  I.e., will the eth0 interface be created with
>> duplex full?
>>
>
> Yes -- because these are data nodes and the rules for when-stmt
> on data nodes are different than for rpc-stmt.  Then the when-stmt
> is a test on whether the node should exist in the candidate or running
> datastore.
>
> Our server applies all the edits first, when checks all the when-stmts
> that might have changed value.  Nodes that have already existed in the
> datastore may get pruned, not just the new nodes.
>
>
>
>
>
>>
>> /martin
>>
>>
>>
>
> Andy
>
>
>>
>> >
>> >
>> >
>> >
>> > > I don't think this is a BIG protocol change, since the spec already
>> > > says that requests for nodes w/ false when expressions MUST send
>> > > error.  The change is to say that this behavior is true regardless of
>> > > evaluation order.
>> > >
>> > > > It may be a client programming error for the client to provide
>> > > > false when nodes or not.  What if the client is reusing some
>> > > > code that sends 5 parameters, it it's OK if 1 of them gets
>> > > > pruned sometimes because of a false when (e.g, product
>> > > > feature-specific knob and that feature is not installed)
>> > >
>> > > Well, it might be simpler to send if-featured nodes that the specific
>> > > server doesn't support - this is also an error in 6020.
>> > >
>> > > > BTW, this is a really good example of what not to do, if one
>> > > > wants to make the YANG specification protocol independent.
>> > >
>> > > That statement is true for the entire section 8.2, it is not
>> > > specifically true for this change.
>> > >
>> > >
>> > > /martin
>> > >
>> >
>> >
>> > Andy
>>
>
> And this contradicts the current rfc6020bis-07#section-8.2.1 which states
> that already during parsing you must check
>
> If data for a node tagged with "when" is present, and the "when"
>   condition evaluates to "false", the server MUST reply with an

Re: [netmod] The when-choice loop

Balazs Lengyel  wrote:
> Hello,
> In RFC6020bis we write:
> "There MUST NOT be any circular dependencies in these "when"
> expressions."
> How about a circular when-choice loop?

Good catch.  choice/case can (more or less) be seen as a syntactic
sugar for a special form a when expressions; or rather, choice/case
can be rewritten with when:

  choice a {
case c1 {
  node n11;
  ...
  node n1N;
}
case c2 {
  node n21;
  ...
  node n2N;
}
...  
case cM {
  node nM1;
  ...
  node nMN;
}
 }

can (sort of) be rewritten as:

  node n11 {
when not(n21 or .. n2N or ..  nM1 or nMN);
  }
  node n1N {
when not(n21 or .. n2N or ..  nM1 or nMN);
  }
  node n21 {
when not(n11 or .. n1N or n31 or n3N ...);
  }
  node n22 {
when not(n11 or .. n1N or n31 or n3N ...);
  }
  ...

So, if you expand your example, there is actually a loop in the when
expressions.


/martin


> 
> leaf a1 {
> type boolean;
> when not(../a2);
> }
> choice c2 {
> default case2;
> case case1 {
> when not(a1);
> leaf b1 {type int8;}
> }
> case case2 {
> leaf a2 {
> type boolean;
> default true;
> }
> }
> }
> 
> Initial state: a1=false, b1=5;
> - Set a1=true
> - case1 and b1 disapears
> - case2 and a2=false are set as default
> - a1 disappears
> - if there is no a1 why did we delete case1/b1?
> Did I miss something, is this really what happens?
> 
> Even if someone can come up with the correct solution, operators will
> be 100% sure to mess this up. Usability=0 !!!
> 
> I want some of this multistep when/when, choice/choice, when/choice
> scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the
> order of evaluation is implementation dependent: that would make it
> unusable, so practically prohibiting then while maintaining backward
> compatibility :-)
> 
> I attached an even more complicated example, so go ahead have fun
> understand it!
> regards Balazs
> 
> PS: Why did we make YANG so complicated?
> 
> -- 
> 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] 6020bis - sec. 5.6.4 comments


> On 14 Oct 2015, at 19:28, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Hi,
>> 
>> regarding $subj:
>> 
>> - What about extensions? Do modules defining them have to be
>>  implemented? That is, is "default-revision" true or false for such
>>  modules?
> 
> The "default-revision" leaf doesn't exist in ietf-yang-libary.  I will
> remove the note about aligning with ietf-yang-libary, and do:
> 
> OLD:
> 
>   If a server implements a module A that imports a module C without
>   specifying the revision date of module C, and the server does not
>   implement C (e.g., if C only defines some typedefs), the server
>   MUST list module C in the "/modules/module" list from
>   "ietf-yang-library", and it MUST set the leaf "default-revision" to
>   "true" for this module.
> 
> NEW:
> 
>   If a server implements a module A that imports a module C without
>   specifying the revision date of module C, and the server does not
>   implement C (e.g., if C only defines some typedefs), the server
>   MUST list module C in the "/modules/module" list from
>   "ietf-yang-library", and it MUST set the leaf "conformance" to
>   "import" for this module.

OK, and what about extensions? If a server supports an extension and it is 
defined in module X, what's the "conformance" value for X in yang-library: 
"import" or "implement"? Extensions aren't mentioned in the first paragraph of 
5.6.4.

> 
> 
>> - Third paragraph:
>> 
>> OLD
>> 
>>   This is regardless of if module B is imported by revision or not.
>> 
>> NEW
>> 
>>   If module B is imported by revision, the corresponding "revision-date"
>>   statement is ignored.
> 
> I think your proposed text can be misunderstood.  The "revision-date"
> statement is not ignored; typedefs etc. will be taken from the
> specified revision.

OK.

It seems this paragraph doesn't cover this case:

augment "/B:foo" {
when "B:bar = 1";
...
}

What if module B implements "foo" but not "bar"? One option is to add "when" to 
"augment" and "path", and another is to consider the "when" expression to be 
false so that the augment doesn't apply in this case.

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] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)


> On 15 Oct 2015, at 09:03, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Oct 14, 2015 at 04:01:13PM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>> 
>>> On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
 
> On 13 Oct 2015, at 13:01, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Oct 07, 2015 at 05:37:36PM +, Kent Watsen wrote:
>> 
>> This is a notice to start a NETMOD WG last call for the document:
>> 
>> Defining and Using Metadata with YANG
>> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
>> 
>> Please indicate your support by Thursday October 22, 2015 at 9PM EDT.
>> We are not only interested in receiving defect reports, we are equally
>> interested in statements of the form:
>> 
> 
> I am concerned about this text:
> 
>  Annotations modify the schema of datastores and/or management
>  protocol messages, and may also change their semantics.  Therefore,
>  due care has to be exercised when introducing annotations in
>  network management systems in order to avoid interoperability
>  problems and software failures.
> 
> I think we should actually very clearly discourage annotations that
> modify the schema of datastores and/or management protocol messages
> instead of assuming all annotations are free to do so.
 
 Annotations modify the schemas by definition because otherwise XML 
 attributes, and objects in JSON encoding whose names start with "@", are 
 not allowed.
 
>>> 
>>> For me, the schema of a datastore is the YANG data model. I do not
>>> want annotations that change the YANG data model of a datastore.
>>> Perhaps you mean something different but then the text allows multiple
>>> interpretations and hence it is problematic.
>> 
>> It depends on the definition of "schema". In any case, annotations add
>> some extra information that possibly might be persistent. FWIW, a RELAX
>> NG schema generated for datastore + annotation is different from the one
>> that's for datastore only.
> 
> Then this usage of "schema" needs to be clarified. The text in
> question does not say it is specific to RELAX NG schema. It can be
> read as "annotations modify the YANG data models and/or
> NETCONF/RESTCONF protocol messages". I do not want to legalize
> annotations that turn data model properties upside down.

Annotations may not turn data model properties upside down but in any case they 
add stuff that the peer may not be prepared to handle. If the NETCONF client 
doesn't expect XML attributes in the data part of a  reply, then it 
might break if the server uses them. That's what I meant by "schema changes" 
and this problem is relevant for all uses of annotations, regardless of their 
semantics.

> 
>>> Annotations should add metadata but I think metadata must not change
>>> the semantics of the data model itself. I am also concerned if
>>> metadata changes the semantics of protocol messages. I am not
>> 
>> Some annotations that are of this sort, such as "inactive", have already
>> been discussed. The text you cited tries to explain possible pitfalls of
>> such annotations, but my understanding of the consensus so far has been
>> that it is not desirable to limit annotations to "benign" ones.
> 
> I am fine with the bullets, my concern is about the paragraph above
> it. For me, there are different classes of annotations
> 
> - easy annotations that only add metadata (like the 'last-modified'
>  example) and which are harmless (since they can be simply ignored)
> 
> - risky annotations that impact the interpretation of data (such as an
>  'inactive' annotation) and which require that systems agree that
>  they understand the semantics of the annotations before they can be
>  used safely
> 
> - evil annotations that are trying to overwrite essential data model
>  properties (e.g. a 'key' annotation that redefines the key property
>  of a list or a 'type' annotation that overwrites the type of leafs
>  or a 'config' annotation that redefines the config true/false
>  property on the fly)
> 
> Yes, the boundary between these classes is fuzzy. I am concerned that

Yes, and the boundary may also depend on the presence of external information 
such as protocol specification.

> a statement like
> 
>   Annotations modify the schema of datastores and/or management
>   protocol messages, and may also change their semantics.


The "schema" part addresses syntactic changes in protocol messages, which are 
inevitable, and the second part is about risky annotations. I agree evil 
annotations should be banned but I am not sure we can find a satisfactory 
formulation. Do you have any suggestion?

> 
> paves the way to encourage not only risky but also evil annotations.
> People might point to this statement and say that evil

Re: [netmod] nested choices


> On 14 Oct 2015, at 20:43, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> Hi,
>> 
>> my action item from yesterday's interim was to check whether some updates to 
>> 6020bis are needed in order to address the corner cases presented by Balazs:
>> 
>> - https://mailarchive.ietf.org/arch/msg/netmod/i73sR0_d9UkshMuhxiCDOSZWhqk
>> - https://mailarchive.ietf.org/arch/msg/netmod/gBum0NdkixozakgncYXPKPpLQDk
>> 
>> I would propose this minor change to sec. 7.9.3:
>> 
>> OLD
>> 
>>   The default case is only important when considering the default
>>   values of nodes under the cases.
>> 
>> NEW
>> 
>>   The default case is only important when considering the default
>>   contents of nodes under the cases (default values of leafs and
>>   leaf-lists, or default cases of nested choices).
> 
> Maybe a slight variation, and taking the entire paragraph into
> account:
> 
> OLD:
> 
>  The default case is only important when considering the default
>  values of nodes under the cases.  The default values for nodes under
>  the default case are used if none of the nodes under any of the
>  cases are present.
> 
> NEW:
> 
>  The default case is only important when considering the default
>  statements of node under the cases (i.e., default values of leafs and
>  leaf-lists, and default cases of nested choices).  The default
>  values and nested default cases under the default case are used
>  if none of the nodes under any of the cases are present.


OK, just s/node/nodes/ in the second line.

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] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

2015-10-15 Thread Juergen Schoenwaelder

On Wed, Oct 14, 2015 at 04:01:13PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder 
> >> >  wrote:
> >> > 
> >> > On Wed, Oct 07, 2015 at 05:37:36PM +, Kent Watsen wrote:
> >> >> 
> >> >> This is a notice to start a NETMOD WG last call for the document:
> >> >> 
> >> >> Defining and Using Metadata with YANG
> >> >> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02
> >> >> 
> >> >> Please indicate your support by Thursday October 22, 2015 at 9PM EDT.
> >> >> We are not only interested in receiving defect reports, we are equally
> >> >> interested in statements of the form:
> >> >> 
> >> > 
> >> > I am concerned about this text:
> >> > 
> >> >   Annotations modify the schema of datastores and/or management
> >> >   protocol messages, and may also change their semantics.  Therefore,
> >> >   due care has to be exercised when introducing annotations in
> >> >   network management systems in order to avoid interoperability
> >> >   problems and software failures.
> >> > 
> >> > I think we should actually very clearly discourage annotations that
> >> > modify the schema of datastores and/or management protocol messages
> >> > instead of assuming all annotations are free to do so.
> >> 
> >> Annotations modify the schemas by definition because otherwise XML 
> >> attributes, and objects in JSON encoding whose names start with "@", are 
> >> not allowed.
> >>
> >
> > For me, the schema of a datastore is the YANG data model. I do not
> > want annotations that change the YANG data model of a datastore.
> > Perhaps you mean something different but then the text allows multiple
> > interpretations and hence it is problematic.
> 
> It depends on the definition of "schema". In any case, annotations add
> some extra information that possibly might be persistent. FWIW, a RELAX
> NG schema generated for datastore + annotation is different from the one
> that's for datastore only.

Then this usage of "schema" needs to be clarified. The text in
question does not say it is specific to RELAX NG schema. It can be
read as "annotations modify the YANG data models and/or
NETCONF/RESTCONF protocol messages". I do not want to legalize
annotations that turn data model properties upside down.

> > Annotations should add metadata but I think metadata must not change
> > the semantics of the data model itself. I am also concerned if
> > metadata changes the semantics of protocol messages. I am not
> 
> Some annotations that are of this sort, such as "inactive", have already
> been discussed. The text you cited tries to explain possible pitfalls of
> such annotations, but my understanding of the consensus so far has been
> that it is not desirable to limit annotations to "benign" ones.

I am fine with the bullets, my concern is about the paragraph above
it. For me, there are different classes of annotations

- easy annotations that only add metadata (like the 'last-modified'
  example) and which are harmless (since they can be simply ignored)

- risky annotations that impact the interpretation of data (such as an
  'inactive' annotation) and which require that systems agree that
  they understand the semantics of the annotations before they can be
  used safely

- evil annotations that are trying to overwrite essential data model
  properties (e.g. a 'key' annotation that redefines the key property
  of a list or a 'type' annotation that overwrites the type of leafs
  or a 'config' annotation that redefines the config true/false
  property on the fly)

Yes, the boundary between these classes is fuzzy. I am concerned that
a statement like

   Annotations modify the schema of datastores and/or management
   protocol messages, and may also change their semantics.

paves the way to encourage not only risky but also evil annotations.
People might point to this statement and say that evil annotations
are just fine.

> I guess the considerations are similar to extensions in general:
> certain annotations may be a mandatory part of a protocol but is has
> to be said in the protocol spec. This is essentially what was done for
> NETCONF, and a special extension was used for defining the annotations
> (XML attributes).

NETCONF is a special case since NETCONF was designed before we had
YANG and the WG retrofitted a YANG data model to describe 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] Order of evaluation for when?


  
  
See below, Balazs

On 2015-10-14 23:06, Andy Bierman
  wrote:


  
  

  On Wed, Oct 14, 2015 at 1:26 PM,
Martin Bjorklund  wrote:
Andy
  Bierman 
  wrote:
  > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund
  
  wrote:
  >
  > > Andy Bierman 
  wrote:
  > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin
  Bjorklund 
  > > wrote:
  > > >
  > > > > Balazs Lengyel 
  wrote:
  > > > > > Hello Martin,
  > > > > > I agree that A1 is what follows
  the spirit of YANG, but then IMHO you
  > > > > > should change/correct 8.2.1 in
  YANG because that implies A2 and
  > > error.
  > > > >
  > > > > Ok, I agree.  I suggest we remove from
  8.2.1:
  > > > >
  > > > >    o  If data for a node tagged with
  "when" is present, and the "when"
  > > > >       condition evaluates to "false",
  the server MUST reply with an
  > > > >       "unknown-element" error-tag in
  the rpc-error.
  > > > >
  > > > > and add to 8.2.2:
  > > > >
  > > > >   o  Modification requests for nodes
  tagged with "when", and the "when"
  > > > >      condition evaluates to "false". 
  In this case the server MUST
  > > reply
  > > > >      with an "unknown-element"
  error-tag in the rpc-error.
  > > > >
  > > > >
  > > > >
  > > >
  > > > This seems like a BIG protocol change to
   behavior.
  > > > IMO this not an error at all.  In our
  server the false-when data is just
  > > > pruned, and no error is ever sent for a
  pruned when=false data node.
  > >
  > > So you are not following the current RFC 6020
  spec?
  > >
  >
  >
  > Yes we are following it.
  
  Ok.
  
  > The schema for the edit-config RPC operation contains
  > an 'anyxml' for  node.  It does not
  contain any
  > when-stmts for the data nodes that get passed in the
   node.
  > The correct behavior is to just enforce the error on
  the when-stmts
  > that appear in the rpc-stmt.
  
  I don't understand what you are trying to say.





I know about the text that says a false-when in an RPC
  is an error.
Show me the when-stmts  "interface" in the
  "edit-config" rpc-stmt.




 

  
  Here's an example:
  
    augment /if:interfaces/if:interface {
      when "if:type = 'ianaift:ethernetCsmacd'";
  
      container ethernet {
        leaf duplex {
          type enumeration {
            enum "half";
            enum "full";
          }
        }
      }
    }
  
  Suppose the db is empty.
  
  What if the edit-confif contains
  
    
      
        eth0
        full
        ianaift:ethernetCsmacd
      
    
  
  will that work or not?  I.e., will the eth0 interface be
  created with
  duplex full?



Yes -- because these are data nodes and the rules for
  when-stmt
on data nodes are different than for rpc-stmt.  Then
  the when-stmt
is a test on whether the node should exist in the
  candidate or running
datastore.


Our server applies all the edits first, when checks all
  the when-stmts
that might have changed value.  Nodes that have already
  existed in the
datastore may get pruned, not just the new nodes.









  
  
  /martin

Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

2015-10-15 Thread Jonathan Hansford

The NMS only knows the intended config if it is the only NMS capable of 
changing that device’s config. That may not always be the case.

Jonathan

From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"

On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing constantly.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions for 
solutions to provide something like a yang-patch to describe just the diffs.  
Makes sense to me!

The NMS already knows the intended config since it sent it to the device in the 
first place, so in normal circumstances I would expect the NMS to only query 
the applied config (and possibly derived state at the same time) and then 
compare it to the NMS's view of the intended cfg for that device.  If the NMS 
is smart then it might be able to restrict most of the queries to only the 
device's applied config sub-trees that could possibly be out of sync, perhaps 
with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be 
useful (the draft that I put forward also proposes a diff-cfg-only option).  
However, it is also worth noting that the original requirements don't 
explicitly ask for this, so perhaps more of a nice to have than a formal 
requirement?

Thanks,
Rob

K.

From: Andy Bierman 
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen 
Cc: Robert Wilton , "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied 
configuration"

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen  wrote:

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
>    - does it include support for templating (as per 
> openconfig-netmod-opstate-01 section 7.3.)?
>    - is it allowed to represent system created objects that have no 
> corresponding configuration?
>
> Requirement 1.D states

 D.  For asynchronous systems, when fully synchronized, the data
   in the applied configuration is the same as the data in the
   intended configuration.
>
> So, if this requirement statement stands as being valid (which I think it 
> should) then that would imply that the answer for both the two issues above 
> must be "no".  The only question would be whether these need to be explicitly 
> listed out?
[KENT] so I think I have to (begrudgingly) agree with your logic.    I have 
heard the operators state that they want the intended/applied comparison to be 
drop-dead simple.  To that end, it would not be possible to flatten templates 
or apply defaults, or make any other change – it needs to be as close as 
possible to a carbon-copy of the original intended configuration (where 
deviations are allowed only for cases like a missing line-card).  To this end, 
yes, I think that we could tack on a statement like the following:

That is, the intended configuration is a subset of the applied 
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?

I am wondering why operators would want to compare 2 massive subtrees
in the first place, where 1 is static and the other is changing constantly.

Do they really want this complex task or do they just want to
determine if the intended config has been applied yet?

Andy

>>  - how does it relate to the state of the system after a equivalent 
>> synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the proposed 
> definition of synchronous configuration operation vs asynchronous 
> configuration operation, will provide a sufficient answer to this question.  
> I.e. that the state of the system after an asynchronous config operation 
> must, when fully synchronized, be the same as the state of the system after 
> an equivalent synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 
- right?

Thanks,
Kent

___
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] not a non-presence container

2015-10-15 Thread Jonathan Hansford

If that misinterpretation has already happened for (at least) one individual, 
would it be worth adding the clarification and remove the ambiguity?

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 #4: Provide a tighter definition of"applied configuration"

2015-10-15 Thread Robert Wilton

Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multiple NMS
 - responsibility for parts of the configuration is split between 
multiple NMS and they are each independently responsible for ensuring 
that their part of the configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive 
configuration for a device to be known and held (perhaps in a 
distributed fashion) somewhere in the operators management network, not 
on the device itself.

Thanks,
Rob

On 15/10/2015 09:55, Jonathan Hansford wrote:

The NMS only knows the intended config if it is the only NMS capable 
of changing that device’s config. That may not always be the case.

Jonathan

*From: *Robert Wilton
*Sent: *14 October 2015 22:28
*To: *Kent Watsen;Andy Bierman
*Cc: *netmod@ietf.org
*Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter definition 
of"applied configuration"

On 14/10/2015 20:15, Kent Watsen wrote:

Andy writes:

> I am wondering why operators would want to compare 2 massive subtrees

> in the first place, where 1 is static and the other is changing
constantly.

>

> Do they really want this complex task or do they just want to

> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been
suggestions for solutions to provide something like a yang-patch
to describe just the diffs.  Makes sense to me!

The NMS already knows the intended config since it sent it to the 
device in the first place, so in normal circumstances I would expect 
the NMS to only query the applied config (and possibly derived state 
at the same time) and then compare it to the NMS's view of the 
intended cfg for that device.  If the NMS is smart then it might be 
able to restrict most of the queries to only the device's applied 
config sub-trees that could possibly be out of sync, perhaps with 
periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also 
be useful (the draft that I put forward also proposes a diff-cfg-only 
option).  However, it is also worth noting that the original 
requirements don't explicitly ask for this, so perhaps more of a nice 
to have than a formal requirement?

Thanks,
Rob

K.

*From: *Andy Bierman >
*Date: *Wednesday, October 14, 2015 at 2:56 PM
*To: *Kent Watsen >
*Cc: *Robert Wilton >, "netmod@ietf.org
" >
*Subject: *Re: [netmod] opstate-reqs #4: Provide a tighter
definition of "applied configuration"

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen > wrote:

Thank you Robert for bringing the discussion back to the
github issues.

Robert writes:

> In particular:

>- does it include support for templating (as per
openconfig-netmod-opstate-01 section 7.3.)?

>- is it allowed to represent system created objects that have no
corresponding configuration?

>
> Requirement 1.D states

 D.  For asynchronous systems, when fully synchronized,
the data

   in the applied configuration is the same as the
data in the

   intended configuration.

>
> So, if this requirement statement stands as being valid
(which I think it should) then that would imply that the
answer for both the two issues above must be "no".  The only
question would be whether these need to be explicitly listed out?

[KENT] so I think I have to (begrudgingly) agree with your
logic.I have heard the operators state that they want the
intended/applied comparison to be drop-dead simple.  To that
end, it would not be possible to flatten templates or apply
defaults, or make any other change – it needs to be as close
as possible to a carbon-copy of the original intended
configuration (where deviations are allowed only for cases
like a missing line-card).  To this end, yes, I think that we
could tack on a statement like the following:

That is, the intended configuration is a subset of the applied

configuration where omissions are only due to when the

configuration cannot be applied (e.g., a missing line-card).

What do you think?

I am wondering why operators would want to compare 2 massive subtrees

in the first place, where 1 is static and the other is changing
constantly.

Do they really want this complex task

Re: [netmod] interim meeting NEW webex

2015-10-15 Thread Romascanu, Dan (Dan)

I joined one where I am the only person in the call ☺

Can someone re-send?

Thanks and Regards,

Dan

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Thursday, October 15, 2015 5:16 PM
To: Nadeau Thomas
Cc: netmod WG
Subject: Re: [netmod] interim meeting NEW webex

This one says the meeting is locked and one cannot join.

On Oct 15, 2015, at 7:12 AM, Nadeau Thomas 
> wrote:


  Apologies but the WebEx unexpectedly terminated.

  I’ve started a new one here:  
https://ietf.webex.com/meet/netmod

  Please join there if you were on the call or want to join the interim 
meeting.

  —Tom

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

Mahesh Jethanandani
mjethanand...@gmail.com




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

Re: [netmod] interim meeting NEW webex


Webex hung up on us again.  Please rejoin using the same URL.

—Tom

> On Oct 15, 2015:10:20 AM, at 10:20 AM, Nadeau Thomas 
>  wrote:
> 
>   Some (including me) were having issues with “computer audio”. If you 
> are, call into meeting using the dial info.
> 
> 
>> On Oct 15, 2015:10:18 AM, at 10:18 AM, Nadeau Thomas 
>> > wrote:
>> 
>> https://ietf.webex.com/meet/netmod 
>> 
>> 
>> 
>>> On Oct 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) 
>>> > wrote:
>>> 
>>> I joined one where I am the only person in the call J
>>>  
>>> Can someone re-send?
>>>  
>>> Thanks and Regards,
>>>  
>>> Dan
>>>  
>>> From: netmod [mailto:netmod-boun...@ietf.org 
>>> ] On Behalf Of Mahesh Jethanandani
>>> Sent: Thursday, October 15, 2015 5:16 PM
>>> To: Nadeau Thomas
>>> Cc: netmod WG
>>> Subject: Re: [netmod] interim meeting NEW webex
>>>  
>>> This one says the meeting is locked and one cannot join.
>>>  
>>> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas >> > wrote:
>>>  
>>> 
>>>   Apologies but the WebEx unexpectedly terminated. 
>>> 
>>>   I’ve started a new one here:  https://ietf.webex.com/meet/netmod 
>>> 
>>> 
>>>   Please join there if you were on the call or want to join the 
>>> interim meeting.
>>> 
>>>   —Tom
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> 
>>>  
>>> Mahesh Jethanandani
>>> mjethanand...@gmail.com 
>> ___
>> 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

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

Re: [netmod] Order of evaluation for when?


  
  
Hello,
I had the same interpretation as Martin. The when could be on the
config database model. Not just on the when defined in a definition
of an rpc or action.
regards Balazs

On 2015-10-15 17:02, 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.




 
If
  you interpret this section to talk about the nodes in the
  definition of edit-config, nothing in the section makes
  any sense at
  all.   For example:
  
    If all keys of a list entry are not present, the server
  MUST reply
    with a "missing-element" error-tag in the rpc-error.
  
  you might say that there are no lists in the definition of
  edit-config, so this bullet doesn't apply.
  
  





edit-config is the next section  -- 8.2.2





  /martin
  





Andy
 

  
  >
  > So explain which constraint in the payload is being
  violated?
  >
  >
  > Andy
  >
  >
  > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel  > wrote:
  >
  > > See below, Balazs
  > >
  > > On 2015-10-14 23:06, Andy Bierman wrote:
  > >
  > >
  > >
  > > On Wed, Oct 14, 2015 at 1:26 PM, Martin
  Bjorklund < 
  > > m...@tail-f.com>
  wrote:
  > >
  > >> Andy Bierman 
  wrote:
  > >> > On Wed, Oct 14, 2015 at 12:48 PM,
  Martin Bjorklund 
  > >> wrote:
  > >> >
  > >> > > Andy Bierman 
  wrote:
  > >> > > > On Wed, Oct 14, 2015 at 12:25
  PM, Martin Bjorklund 
  > >> > > wrote:
  > >> > > >
  > >> > > > > Balazs Lengyel < 
  > >> balazs.leng...@ericsson.com>
  wrote:
  > >> > > > > > Hello Martin,
  > >> > > > > > I agree that A1 is
  what follows the spirit of YANG, but then
  > >> IMHO you
  > >> > > > > > should
  change/correct 8.2.1 in YANG because that implies A2 and
  > >> > > error.
  > >> > > > >
  > >> > > > > Ok, I agree.  I suggest
  we remove from 8.2.1:
  > >> > > > >
  > >> > > > >    o  If data for a node
  tagged with "when" is present, and the
  > >> "when"
  > >> > > > >       condition
  evaluates to "false", the server MUST reply with

Re: [netmod] not a non-presence container

2015-10-15 Thread Jonathan Hansford

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] The when-choice loop

Limiting when to augment doesn't really solve the issues, as you can
augment in all the strange constructs instead of defining them locally.
My ideas would be:

- when MUST NOT be dependent on a data node controlled by another when
or choice statement
- choice SHOULD NOT be contained under a choice as the aggregate
construct is hard to understand for a human user

Anything more complicated is too hard to understand. As we know 50% of
all downtime in a network is caused by operator erroros. So DO NOT ake
it complicated

regards Balazs

On 2015-10-15 16:08, Ladislav Lhotka wrote:

On 15 Oct 2015, at 15:17, Balazs Lengyel wrote:

Hello Lada,
So can we start gathering support for limiting when/choice to the simple cases
by one of the 3 methods:
1) prohibit them (backward incompatible)

I would personally restrict the use of "when" only as a substatement of "augment". This would solve most
issues, including Y18 (missing context node). I other cases, "must" can be often used instead of "when" with
the same effect - at least for validation purposes. I am not sure that benefits of "when" outweigh the complexity -
both in YANG spec and server implementation.

I also think servers should not automatically delete nodes whose "when"
expression becomes false.

Lada

2) create a guideline not to use them in 6087, (easy to do, better then
nothing, but does not protect the application)
3) declaring them as implementation dependent, thus making them backward
compatible, but unusable

Complicated: In my view anytime a when or choice depends on another when or
choice it is complicated. So use the simple cases only.
regards Balazs

On 2015-10-15 14:53, Ladislav Lhotka wrote:

Hi Balazs,

one lesson taken from early XML schema languages (DTD) was that modifying the
validated document during validation easily leads to nasty race conditions.
That's why RELAX NG avoids changing the XML infoset like plague.

I've already got tired reiterating (and providing examples) that "when" statement is
inherently broken - the schema should not depend on evaluating arbitrary expressions in the context
of an instance document that is supposed to be validated with the schema. The standard disclaimer
is that it works for simple cases, and more complicated corner cases are "garbage in - garbage
out".

Lada

P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its
content is "false". So you'd need expressions like "not(../a2 = 'true')".

On 15 Oct 2015, at 13:59, Balazs Lengyel wrote:

Hello,
In RFC6020bis we write:
"There MUST NOT be any circular dependencies in these "when" expressions."
How about a circular when-choice loop?

leaf a1 {
type boolean;
when not(../a2);
}
choice c2 {
default case2;
case case1 {
when not(a1);
leaf b1 {type int8;}
}
case case2 {
leaf a2 {
type boolean;
default true;
}
}
}

Initial state: a1=false, b1=5;
- Set a1=true
- case1 and b1 disapears
- case2 and a2=false are set as default
- a1 disappears
- if there is no a1 why did we delete case1/b1?
Did I miss something, is this really what happens?

Even if someone can come up with the correct solution, operators will be 100%
sure to mess this up. Usability=0 !!!

I want some of this multistep when/when, choice/choice, when/choice scenarios
prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation
is implementation dependent: that would make it unusable, so practically
prohibiting then while maintaining backward compatibility :-)

I attached an even more complicated example, so go ahead have fun understand it!
regards Balazs

PS: Why did we make YANG so complicated?

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

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

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

--
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 #5: Support for situations when structure of intended configuration is not the same as applied

2015-10-15 Thread Robert Wilton


Hi Carl,

On 15/10/2015 14:05, Carl Moberg (camoberg) wrote:

  Maybe we’re coming down to a definition of “requirement” here. But the issue 
I raised can be summarized as follows:

“””
The assumption of a 1:1 mapping ignores situations where a change to an 
intended configuration leaf value may result in several instances of applied 
configuration leaf values (operational state) to be updated in the backend 
framework across several subsystems.
“”"

  My issue is that the requirement seems to ignore the situations and my 
suggestion is to relax the requirement.
I think that the operator requirement is stating that the multiple 
actual applied configuration leaves across multiple subsystems need to 
be mapped back to a single logical leaf for the purposes of the applied 
config leaf that is exposed to the operators.


If no such mapping is possible then this would imply that there is no 
way that the operator can determine whether a particular item of 
configuration is actually in effect on a system.  Is this reasonable 
behaviour for a system?


If such a mapping is possible, then I can see benefit in performing such 
a mapping on the device itself rather than requiring each and every 
operator to know and program the mapping.  Is the main concern here that 
the cost of implementing this mapping in the system may be prohibitively 
expensive?


Thanks,
Rob



  I don’t believe 1.C addresses the actual concern with the requirement.


On Oct 14, 2015, at 8:14 PM, Kent Watsen  wrote:


I believe that you are correct, it seems that we've doubled-down on 1C and so 
#5 should now be marked as DEAD.

This action will be taken if no objection is made before tomorrow's interim.

Thanks,
Kent


From: Robert Wilton 
Date: Tuesday, October 13, 2015 at 9:29 AM
To: Kent Watsen , "netmod@ietf.org" 
Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of 
intended configuration is not the same as applied

 From the interim meeting two weeks ago, it was clarified that the schema of 
the intended configuration nodes are expected to be the same as the schema of 
the applied configuration nodes so that clients can easily relate between the 
two.

I think that the requirement text for 1.C and the proposed updated text for 1.D 
makes this reasonable clear.

Hence, is issue 5 now at the state where is can be closed as not being a 
requirement?  Or is there something further that needs to be discussed first?

Thanks,
Rob


On 30/09/2015 16:44, Kent Watsen wrote:

It's time to tackle another issue, just before tomorrow's meeting, and this 
time I'm picking a hard one:

https://github.com/netmod-wg/opstate-reqs/issues/5

Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the GitHub 
issue tracker.Please first read the comments posted there and then continue 
the discussion here on the mailing list (not on the GitHub issue tracker).

Note that this issue is closely tied to the definition of "applied 
configuration", which is exactly what issue #4 regards 
(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh and Einar have 
posted comments on already.   As these two issues (#4 and #5) are so highly related, I'm 
going to simultaneously open the other issue for discussion now as well.

Thanks,
Kent



___
netmod mailing list

netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod

___
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 #5: Support for situations when structure of intended configuration is not the same as applied


Hi Carl,

I understand your concern, but isn't it up to the server to decide the
response it provides in that case?  Already I think the server needs to
scatter/gather responses from the operational components in the system and
stitch together a result.  In this case, the stitching may fail and hence
it reports an error of some sort (e.g., not-completely-applied) - what do
you think?

Kent



On 10/15/15, 9:05 AM, "Carl Moberg (camoberg)"  wrote:

>
> Maybe we¹re coming down to a definition of ³requirement² here. But the
>issue I raised can be summarized as follows:
>
>³²²
>The assumption of a 1:1 mapping ignores situations where a change to an
>intended configuration leaf value may result in several instances of
>applied configuration leaf values (operational state) to be updated in
>the backend framework across several subsystems.
>³²"
>
> My issue is that the requirement seems to ignore the situations and my
>suggestion is to relax the requirement.
>
> I don¹t believe 1.C addresses the actual concern with the requirement.
>
>> On Oct 14, 2015, at 8:14 PM, Kent Watsen  wrote:
>> 
>> 
>> I believe that you are correct, it seems that we've doubled-down on 1C
>>and so #5 should now be marked as DEAD.
>> 
>> This action will be taken if no objection is made before tomorrow's
>>interim.
>> 
>> Thanks,
>> Kent
>> 
>> 
>> From: Robert Wilton 
>> Date: Tuesday, October 13, 2015 at 9:29 AM
>> To: Kent Watsen , "netmod@ietf.org"
>>
>> Subject: Re: [netmod] opstate-reqs #5: Support for situations when
>>structure of intended configuration is not the same as applied
>> 
>> From the interim meeting two weeks ago, it was clarified that the
>>schema of the intended configuration nodes are expected to be the same
>>as the schema of the applied configuration nodes so that clients can
>>easily relate between the two.
>> 
>> I think that the requirement text for 1.C and the proposed updated text
>>for 1.D makes this reasonable clear.
>> 
>> Hence, is issue 5 now at the state where is can be closed as not being
>>a requirement?  Or is there something further that needs to be discussed
>>first?
>> 
>> Thanks,
>> Rob
>> 
>> 
>> On 30/09/2015 16:44, Kent Watsen wrote:
>>> 
>>> It's time to tackle another issue, just before tomorrow's meeting, and
>>>this time I'm picking a hard one:
>>> 
>>> https://github.com/netmod-wg/opstate-reqs/issues/5
>>> 
>>> Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the
>>>GitHub issue tracker.Please first read the comments posted there
>>>and then continue the discussion here on the mailing list (not on the
>>>GitHub issue tracker).
>>> 
>>> Note that this issue is closely tied to the definition of "applied
>>>configuration", which is exactly what issue #4 regards
>>>(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh
>>>and Einar have posted comments on already.   As these two issues (#4
>>>and #5) are so highly related, I'm going to simultaneously open the
>>>other issue for discussion now as well.
>>> 
>>> Thanks,
>>> Kent
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> 
>>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>> 
>> ___
>> 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] The when-choice loop


> On 15 Oct 2015, at 15:17, Balazs Lengyel  wrote:
> 
> Hello Lada,
> So can we start gathering support for limiting when/choice to the simple 
> cases by one of the 3 methods:
> 1) prohibit them (backward incompatible)

I would personally restrict the use of "when" only as a substatement of 
"augment". This would solve most issues, including Y18 (missing context node). 
I other cases, "must" can be often used instead of "when" with the same effect 
- at least for validation purposes. I am not sure that benefits of "when" 
outweigh the complexity - both in YANG spec and server implementation.

I also think servers should not automatically delete nodes whose "when" 
expression becomes false.

Lada

> 2) create a guideline not to use them in 6087, (easy to do, better then 
> nothing, but does not protect the application)
> 3) declaring them as implementation dependent, thus making them backward 
> compatible, but unusable
> 
> Complicated: In my view anytime a when or choice depends on another when or 
> choice it is complicated. So use the simple cases only.
> regards Balazs
> 
> On 2015-10-15 14:53, Ladislav Lhotka wrote:
>> Hi Balazs,
>> 
>> one lesson taken from early XML schema languages (DTD) was that modifying 
>> the validated document during validation easily leads to nasty race 
>> conditions. That's why RELAX NG avoids changing the XML infoset like plague.
>> 
>> I've already got tired reiterating (and providing examples) that "when" 
>> statement is inherently broken - the schema should not depend on evaluating 
>> arbitrary expressions in the context of an instance document that is 
>> supposed to be validated with the schema. The standard disclaimer is that it 
>> works for simple cases, and more complicated corner cases are "garbage in - 
>> garbage out".
>> 
>> Lada
>> 
>> P.S. Note that XPath expressions like "not(../a2)" evaluate to false if 
>> ../a2 exists, even if its content is "false". So you'd need expressions like 
>> "not(../a2 = 'true')".
>> 
>>> On 15 Oct 2015, at 13:59, Balazs Lengyel  
>>> wrote:
>>> 
>>> Hello,
>>> In RFC6020bis we write:
>>> "There MUST NOT be any circular dependencies in these "when" expressions."
>>> How about a circular when-choice loop?
>>> 
>>>leaf a1 {
>>>type boolean;
>>>when not(../a2);
>>>}
>>>choice c2 {
>>>default case2;
>>>case case1 {
>>>when not(a1);
>>>leaf b1 {type int8;}
>>>}
>>>case case2 {
>>>leaf a2 {
>>>type boolean;
>>>default true;
>>>}
>>>}
>>>}
>>> 
>>> Initial state: a1=false, b1=5;
>>> - Set a1=true
>>> - case1 and b1 disapears
>>> - case2 and a2=false are set as default
>>> - a1 disappears
>>> - if there is no a1 why did we delete case1/b1?
>>> Did I miss something, is this really what happens?
>>> 
>>> Even if someone can come up with the correct solution, operators will be 
>>> 100% sure to mess this up. Usability=0 !!!
>>> 
>>> I want some of this multistep when/when, choice/choice, when/choice 
>>> scenarios prohibited in RFC 6020 or 6087. Or state in 6020 that the order 
>>> of evaluation is implementation dependent: that would make it unusable, so 
>>> practically prohibiting then while maintaining backward compatibility :-)
>>> 
>>> I attached an even more complicated example, so go ahead have fun 
>>> understand it!
>>> regards Balazs
>>> 
>>> PS: Why did we make YANG so complicated?
>>> 
>>> -- 
>>> 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
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> 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] The when-choice loop


Hello Lada,
So can we start gathering support for limiting when/choice to the simple 
cases by one of the 3 methods:

1) prohibit them (backward incompatible)
2) create a guideline not to use them in 6087, (easy to do, better then 
nothing, but does not protect the application)
3) declaring them as implementation dependent, thus making them backward 
compatible, but unusable


Complicated: In my view anytime a when or choice depends on another when 
or choice it is complicated. So use the simple cases only.

regards Balazs

On 2015-10-15 14:53, Ladislav Lhotka wrote:

Hi Balazs,

one lesson taken from early XML schema languages (DTD) was that modifying the 
validated document during validation easily leads to nasty race conditions. 
That's why RELAX NG avoids changing the XML infoset like plague.

I've already got tired reiterating (and providing examples) that "when" statement is 
inherently broken - the schema should not depend on evaluating arbitrary expressions in the context 
of an instance document that is supposed to be validated with the schema. The standard disclaimer 
is that it works for simple cases, and more complicated corner cases are "garbage in - garbage 
out".

Lada

P.S. Note that XPath expressions like "not(../a2)" evaluate to false if ../a2 exists, even if its 
content is "false". So you'd need expressions like "not(../a2 = 'true')".


On 15 Oct 2015, at 13:59, Balazs Lengyel  wrote:

Hello,
In RFC6020bis we write:
"There MUST NOT be any circular dependencies in these "when" expressions."
How about a circular when-choice loop?

leaf a1 {
type boolean;
when not(../a2);
}
choice c2 {
default case2;
case case1 {
when not(a1);
leaf b1 {type int8;}
}
case case2 {
leaf a2 {
type boolean;
default true;
}
}
}

Initial state: a1=false, b1=5;
- Set a1=true
- case1 and b1 disapears
- case2 and a2=false are set as default
- a1 disappears
- if there is no a1 why did we delete case1/b1?
Did I miss something, is this really what happens?

Even if someone can come up with the correct solution, operators will be 100% 
sure to mess this up. Usability=0 !!!

I want some of this multistep when/when, choice/choice, when/choice scenarios 
prohibited in RFC 6020 or 6087. Or state in 6020 that the order of evaluation 
is implementation dependent: that would make it unusable, so practically 
prohibiting then while maintaining backward compatibility :-)

I attached an even more complicated example, so go ahead have fun understand it!
regards Balazs

PS: Why did we make YANG so complicated?

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

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







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

[netmod] interim meeting NEW webex


Apologies but the WebEx unexpectedly terminated. 

I’ve started a new one here:  https://ietf.webex.com/meet/netmod

Please join there if you were on the call or want to join the interim 
meeting.

—Tom

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

Re: [netmod] interim meeting NEW webex


I just unlocked it. Audio should work now.

> On Oct 15, 2015:10:16 AM, at 10:16 AM, Mahesh Jethanandani 
>  wrote:
> 
> This one says the meeting is locked and one cannot join.
> 
>> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas > > wrote:
>> 
>> 
>>  Apologies but the WebEx unexpectedly terminated. 
>> 
>>  I’ve started a new one here:  https://ietf.webex.com/meet/netmod 
>> 
>> 
>>  Please join there if you were on the call or want to join the interim 
>> meeting.
>> 
>>  —Tom
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com 
> 
> 
> 
> 
> 

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

Re: [netmod] Order of evaluation for when?

2015-10-15 Thread Andy Bierman

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.




> If you interpret this section to talk about the nodes in the
> definition of edit-config, nothing in the section makes any sense at
> all.   For example:
>
>   If all keys of a list entry are not present, the server MUST reply
>   with a "missing-element" error-tag in the rpc-error.
>
> you might say that there are no lists in the definition of
> edit-config, so this bullet doesn't apply.
>
>
>

edit-config is the next section  -- 8.2.2



> /martin
>
>

Andy


>
>
> >
> > So explain which constraint in the payload is being violated?
> >
> >
> > Andy
> >
> >
> > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <
> balazs.leng...@ericsson.com
> > > wrote:
> >
> > > See below, Balazs
> > >
> > > On 2015-10-14 23:06, Andy Bierman wrote:
> > >
> > >
> > >
> > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < 
> > > m...@tail-f.com> wrote:
> > >
> > >> Andy Bierman  wrote:
> > >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund 
> > >> wrote:
> > >> >
> > >> > > Andy Bierman  wrote:
> > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <
> m...@tail-f.com>
> > >> > > wrote:
> > >> > > >
> > >> > > > > Balazs Lengyel < 
> > >> balazs.leng...@ericsson.com> wrote:
> > >> > > > > > Hello Martin,
> > >> > > > > > I agree that A1 is what follows the spirit of YANG, but then
> > >> IMHO you
> > >> > > > > > should change/correct 8.2.1 in YANG because that implies A2
> and
> > >> > > error.
> > >> > > > >
> > >> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
> > >> > > > >
> > >> > > > >o  If data for a node tagged with "when" is present, and
> the
> > >> "when"
> > >> > > > >   condition evaluates to "false", the server MUST reply
> with
> > >> an
> > >> > > > >   "unknown-element" error-tag in the rpc-error.
> > >> > > > >
> > >> > > > > and add to 8.2.2:
> > >> > > > >
> > >> > > > >   o  Modification requests for nodes tagged with "when", and
> the
> > >> "when"
> > >> > > > >  condition evaluates to "false".  In this case the server
> MUST
> > >> > > reply
> > >> > > > >  with an "unknown-element" error-tag in the rpc-error.
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > > This seems like a BIG protocol change to  behavior.
> > >> > > > IMO this not an error at all.  In our server the false-when
> data is
> > >> just
> > >> > > > pruned, and no error is ever sent for a pruned when=false data
> node.
> > >> > >
> > >> > > So you are not following the current RFC 6020 spec?
> > >> > >
> > >> >
> > >> >
> > >> > Yes we are following it.
> > >>
> > >> Ok.
> > >>
> > >> > The schema for the edit-config RPC operation contains
> > >> > an 'anyxml' for  node.  It does not contain any
> > >> > when-stmts for the data nodes that get passed in the  node.
> > >> > The correct behavior is to just enforce the error on the when-stmts
> > >> > that appear in the rpc-stmt.
> > >>
> > >> I don't understand what you are trying to say.
> > >>
> > >
> > >
> > > I know about the text that says a false-when in an RPC is an error.
> > > Show me the when-stmts  "interface" in the "edit-config" rpc-stmt.
> > >
> > >
> > >
> > >
> > >>
> > >> Here's an example:
> > >>
> > >>   augment /if:interfaces/if:interface {
> > >> when "if:type = 'ianaift:ethernetCsmacd'";
> > >>
> > >> container ethernet {
> > >>   leaf duplex {
> > >> type enumeration {
> > >>   enum "half";
> > >>   enum "full";
> > >> }
> > >>   }
> > >> }
> > >>   }
> > >>
> > >> Suppose the db is empty.
> > >>
> > >> What if the edit-confif contains
> > >>
> > >>   
> > >> 
> > >>   eth0
> > >>   full
> > >>   ianaift:ethernetCsmacd
> > >> 
> > >>   
> > >>
> > >> will that work or not?  I.e., will the eth0 interface be created with
> > >>

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

Thanks Gert.  I've incorporated these suggestions into my notes for today's 
interim meeting.

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

Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn’t look 
complete. The way it stands for the synchronous operation, the client knows 
that it's intended config was good AND it has been effected to the server. In 
the Asynchronous case, the client only knows that the intended config was good 
– and that’s not enough.

So the proposal is to refine the asynchronous case definition as follows:

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.  The 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 applied to all impacted components in the server. 
 Once applied, the client MUST be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a client can 
request from the server to obtain above information on an on-demand basis. 
Would that somehow go in the opstate-reqs #3 then?

Best

Gert

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

Hi Robert,

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor

On 10/14/15, 10:59 AM, "Robert Wilton" 
> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

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 effect 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.

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.  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.  The
reply to the client only indicates whether there are any errors in the
original request.

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.

Thanks,
Rob

On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

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 SHOULD ensure that the
request is valid, and MUST fully effect the configuration change to
all
impacted components in the server,

Re: [netmod] interim meeting NEW webex

https://ietf.webex.com/meet/netmod 



> On Oct 15, 2015:10:18 AM, at 10:18 AM, Romascanu, Dan (Dan) 
>  wrote:
> 
> I joined one where I am the only person in the call J
>  
> Can someone re-send?
>  
> Thanks and Regards,
>  
> Dan
>  
> From: netmod [mailto:netmod-boun...@ietf.org 
> ] On Behalf Of Mahesh Jethanandani
> Sent: Thursday, October 15, 2015 5:16 PM
> To: Nadeau Thomas
> Cc: netmod WG
> Subject: Re: [netmod] interim meeting NEW webex
>  
> This one says the meeting is locked and one cannot join.
>  
> On Oct 15, 2015, at 7:12 AM, Nadeau Thomas  > wrote:
>  
> 
>   Apologies but the WebEx unexpectedly terminated. 
> 
>   I’ve started a new one here:  https://ietf.webex.com/meet/netmod 
> 
> 
>   Please join there if you were on the call or want to join the 
> interim meeting.
> 
>   —Tom
> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
>  
> Mahesh Jethanandani
> mjethanand...@gmail.com 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] webex accidentally cancelled meeting - looking to restart webex now...


webex accidentally cancelled meeting - looking to restart webex now...

Kent

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

2015-10-15 Thread Juergen Schoenwaelder

On Thu, Oct 15, 2015 at 10:37:49PM +0200, Martin Bjorklund wrote:
> 
> > * 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.
> 
>   client: An entity that can access YANG-defined data on a server,
>   over some network management protocol.
> 

Yes, we should definately open things up so that RESTCONF clients and
servers are covered.

> > * p13
> > 
> >   Would it make sense to add a sentence right at the beginning of
> >   section 4 stating that section 4 is intended to provide orientation
> >   for the first time reader but that section 4 is not normative?
> 
> How about:
> 
>   This non-normative section is intended to give a high-level
>   overview of YANG to first-time readers.

OK

> > * p16
> > 
> >   Perhaps simplify:
> > 
> >   OLD
> > 
> > A leaf instance contains simple data like an integer or a string.  It
> > has exactly one value of a particular type and no child nodes.
> > 
> >   NEW
> > 
> > A leaf data node has exactly one value of a particular type and no
> > child nodes.
> 
> We changed this to "leaf instance" after discussion with Lada.  I
> think it makes sense to mention that it is supposed to contain data
> like an integer or string, so I think I prefer to keep this text as
> is.

I think the document uses 'leaf' in different meanings; sometimes a
leaf is a 'leaf schema node instance' and sometimes a leaf is 'any leaf
of the tree'. This is what got me started here but perhaps the context
is clear enough (hence the 'perhaps simplify').

> > * p28
> > 
> >   Start section 5 by saying that this section defined language
> >   concepts and that it is normative, e.g.
> > 
> > This normative section defines core language concepts.
> 
> But aren't all sections normative unless we say so?  Otherwise it
> seems we should start every section by saying that it is either
> normative or not.

OK

> > * p49
> > 
> >   Is the text in section 7.1.3 correct when it says all identifiers
> >   defined by the module? I mean, schema node identifiers are
> >   namespaced by module names and their prefixes. And data node
> >   identifiers are using the namespace in the XML encoding. Here is
> >   an attempt of a rewrite:
> > 
> >  The "namespace" statement defines the XML namespace that all data
> >  node identifiers defined by the module are qualified by in the
> >  XML encoding. Data node identifiers defined inside a grouping are
> >  an exception q(see Section 7.13 for details).  The argument to
> >  the "namespace" statement is the URI of the namespace.
> 
> It's actually not only data nodes, it is also rpc, actions,
> notifications, identities.  How about:
> 
>   The "namespace" statement defines the XML namespace that all
>   identifiers defined by the module are qualified by in the XML
>   encoding, with the exception of identifiers for data nodes, action
>   nodes, and notification nodes defined inside a grouping (see ^uses^
>   for details).  The argument to the "namespace" statement is the URI
>   of the namespace.

OK

> > * p61
> > 
> >   Should the text in 7.5.4.1 and 7.5.4.2 say explicitly that we talk
> >   about NETCONF when we refer to ? Or should the text try
> >   to be more generic, saying that the respective fields will be
> >   carried in error message in protocols that use YANG? It is actually
> >   somewhat opaque what an error-app-tag is or how it should be used.
> 
> I think we can say "If the constraint evaluates to false, the string is
> passed as  in the  in NETCONF."  Other
> protocols have to define how these fields are used.

OK

> > * p63
> > 
> >   Should the last paragraph in 7.5.7 be factored out into its own
> >   subsection titled "NETCONF  and  Operations"?  The
> >   text is not really anymore about XML encoding (which may be used
> >   with RESTCONF). Or the text is actually about the encoding but
> >   should be written to

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

2015-10-15 Thread Gert Grammel

Kent,

I don't see the need for defining synchronous/asynchronous config servers.

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,

Nevertheless the proposed wording works for me.

Gert

Sent from my Apple ][

On 15 Oct 2015, at 19: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 intended and applied)

Hi Gert, Kent,

I think that notifying the client is one possible way that an asynchronous 
request could be completed, but not necessarily the only way.  E.g. if the 
information as to whether a particular intended leave had been successfully 
applied was available (e.g. as per github issue #2).

So, I wonder whether we shouldn't weaken the last sentence, changing MUST to 
COULD, or perhaps reword it.:

E.g. replacing:

Once applied, the client MUST be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

Perhaps with:

Once applied, the client COULD be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

Or:

Once applied, there MUST be a mechanism available for the client to be able to 
determine whether the intended config is now fully effective or whether there 
are any errors from applying the

Re: [netmod] Order of evaluation for when?

2015-10-15 Thread Andy Bierman

Hi,

Show me the text that says an anyxml passes the constraints of
the hidden data models through to the RPC processing.
The error for false-when only applies to parameters specified
in the RPC.

The processing of the rpc-stmt does not have any when-stmts that
need to be checked.

The config data is validated as part of a datastore, not as part
of the RPC payload.


Andy



On Thu, Oct 15, 2015 at 8:33 AM, Balazs Lengyel  wrote:

> Hello,
> I had the same interpretation as Martin. The when could be on the config
> database model. Not just on the when defined in a definition of an rpc or
> action.
> regards Balazs
>
> On 2015-10-15 17:02, Andy Bierman wrote:
>
>
>
> On Thu, Oct 15, 2015 at 4:53 AM, Martin Bjorklund < 
> m...@tail-f.com> 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.
>
>
>
>
>> If you interpret this section to talk about the nodes in the
>> definition of edit-config, nothing in the section makes any sense at
>> all.   For example:
>>
>>   If all keys of a list entry are not present, the server MUST reply
>>   with a "missing-element" error-tag in the rpc-error.
>>
>> you might say that there are no lists in the definition of
>> edit-config, so this bullet doesn't apply.
>>
>>
>>
>
> edit-config is the next section  -- 8.2.2
>
>
>
>> /martin
>>
>>
>
> Andy
>
>
>>
>>
>> >
>> > So explain which constraint in the payload is being violated?
>> >
>> >
>> > Andy
>> >
>> >
>> > On Thu, Oct 15, 2015 at 1:00 AM, Balazs Lengyel <
>> balazs.leng...@ericsson.com
>> > > wrote:
>> >
>> > > See below, Balazs
>> > >
>> > > On 2015-10-14 23:06, Andy Bierman wrote:
>> > >
>> > >
>> > >
>> > > On Wed, Oct 14, 2015 at 1:26 PM, Martin Bjorklund < 
>> > > m...@tail-f.com> wrote:
>> > >
>> > >> Andy Bierman  wrote:
>> > >> > On Wed, Oct 14, 2015 at 12:48 PM, Martin Bjorklund > >
>> > >> wrote:
>> > >> >
>> > >> > > Andy Bierman < a...@yumaworks.com> wrote:
>> > >> > > > On Wed, Oct 14, 2015 at 12:25 PM, Martin Bjorklund <
>> m...@tail-f.com>
>> > >> > > wrote:
>> > >> > > >
>> > >> > > > > Balazs Lengyel < < 
>> balazs.leng...@ericsson.com>
>> > >> balazs.leng...@ericsson.com> wrote:
>> > >> > > > > > Hello Martin,
>> > >> > > > > > I agree that A1 is what follows the spirit of YANG, but
>> then
>> > >> IMHO you
>> > >> > > > > > should change/correct 8.2.1 in YANG because that implies
>> A2 and
>> > >> > > error.
>> > >> > > > >
>> > >> > > > > Ok, I agree.  I suggest we remove from 8.2.1:
>> > >> > > > >
>> > >> > > > >o  If data for a node tagged with "when" is present, and
>> the
>> > >> "when"
>> > >> > > > >   condition evaluates to "false", the server MUST reply
>> with
>> > >> an
>> > >> > > > >   "unknown-element" error-tag in the rpc-error.
>> > >> > > > >
>> > >> > > > > and add to 8.2.2:
>> > >> > > > >
>> > >> > > > >   o  Modification requests for nodes tagged with "when", and
>> the
>> > >> "when"
>> > >> > > > >  condition evaluates to "false".  In this case the
>> server MUST
>> > >> > > reply
>> > >> > > > >  with an "unknown-element" error-tag in the rpc-error.
>> > >> > > > >
>> > >> > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > > > This seems like a BIG protocol change to 
>> behavior.
>> > >> > > > IMO this not an error at all.  In our server the false-when
>> data is
>> > >> just
>> > >> > > > pruned, and no error is ever sent for a pruned when=false data
>> node.
>> > >> > >
>> > >> > > So you are not following the current RFC 6020 spec?
>> > >> > >
>> > >> >
>> > >> >
>> > >> > Yes we are following it.
>> > >>
>> > >> Ok.
>> > >>
>> > >> > The schema for the edit-config RPC operation contains
>> > >> > an 'anyxml' for  node.  It does not contain any
>> > >> > when-stmts for the data nodes that get passed in the  node.
>> > >> > The correct behavior is to just enforce

Re: [netmod] rib-data-model and routing-cfg

2015-10-15 Thread Acee Lindem (acee)

Hi Lada, 
I looked at this and I like this simple association. I think we should go
with this - there is one point for discussion.

All,

In routing design team discussions we had augmented
“if:interfaces/if:interface/ip:ipv4” and
“if:interface/if:interface/ip:ipv6” so an interface could be mapped to
different routing-instances for IPv4 and IPv6.

Do we really see associating the same interface with different
routing-instances for IPv4 and IPv6? I can seem to remember the use case
and it does add complexity forever.

Thanks,
Acee 



On 10/15/15, 7:25 AM, "Ladislav Lhotka"  wrote:

>Hi Acee,
>
>I made the necessary changes in ietf-routing, please see the GitHub
>repo:
>
>https://github.com/netmod-wg/routing-cfg
>
>A new leaf "rt:routing-instance" was augmented into interface
>configuration, and "rt:interfaces" container in configuration is gone.
>
>Below is the complete new tree.
>
>Will this work?
>
>Lada
>
>module: ietf-interfaces
>   +--rw interfaces
>   |  +--rw interface* [name]
>   | +--rw name   string
>   | +--rw description?   string
>   | +--rw type   identityref
>   | +--rw enabled?   boolean
>   | +--rw ip:ipv4!
>   | |  +--rw ip:enabled?  boolean
>   | |  +--rw ip:forwarding?   boolean
>   | |  +--rw ip:mtu?  uint16
>   | |  +--rw ip:address* [ip]
>   | |  |  +--rw ip:ip   inet:ipv4-address-no-zone
>   | |  |  +--rw (subnet)
>   | |  | +--:(prefix-length)
>   | |  |+--rw ip:prefix-length?   uint8
>   | |  +--rw ip:neighbor* [ip]
>   | | +--rw ip:ipinet:ipv4-address-no-zone
>   | | +--rw ip:link-layer-addressyang:phys-address
>   | +--rw ip:ipv6!
>   | |  +--rw ip:enabled?boolean
>   | |  +--rw ip:forwarding? boolean
>   | |  +--rw ip:mtu?uint32
>   | |  +--rw ip:address* [ip]
>   | |  |  +--rw ip:ip   inet:ipv6-address-no-zone
>   | |  |  +--rw ip:prefix-lengthuint8
>   | |  +--rw ip:neighbor* [ip]
>   | |  |  +--rw ip:ipinet:ipv6-address-no-zone
>   | |  |  +--rw ip:link-layer-addressyang:phys-address
>   | |  +--rw ip:dup-addr-detect-transmits?  uint32
>   | |  +--rw ip:autoconf
>   | |  |  +--rw ip:create-global-addresses?   boolean
>   | |  +--rw v6ur:ipv6-router-advertisements
>   | | +--rw v6ur:send-advertisements?boolean
>   | | +--rw v6ur:max-rtr-adv-interval?   uint16
>   | | +--rw v6ur:min-rtr-adv-interval?   uint16
>   | | +--rw v6ur:managed-flag?   boolean
>   | | +--rw v6ur:other-config-flag?  boolean
>   | | +--rw v6ur:link-mtu?   uint32
>   | | +--rw v6ur:reachable-time? uint32
>   | | +--rw v6ur:retrans-timer?  uint32
>   | | +--rw v6ur:cur-hop-limit?  uint8
>   | | +--rw v6ur:default-lifetime?   uint16
>   | | +--rw v6ur:prefix-list
>   | |+--rw v6ur:prefix* [prefix-spec]
>   | |   +--rw v6ur:prefix-spec   inet:ipv6-prefix
>   | |   +--rw (control-adv-prefixes)?
>   | |  +--:(no-advertise)
>   | |  |  +--rw v6ur:no-advertise? empty
>   | |  +--:(advertise)
>   | | +--rw v6ur:valid-lifetime?   uint32
>   | | +--rw v6ur:on-link-flag? boolean
>   | | +--rw v6ur:preferred-lifetime?   uint32
>   | | +--rw v6ur:autonomous-flag?  boolean
>   | +--rw rt:routing-instance?   routing-instance-ref
>   +--ro interfaces-state
>  +--ro interface* [name]
> +--ro name   string
> +--ro type   identityref
> +--ro oper-statusenumeration
> +--ro last-change?   yang:date-and-time
> +--ro phys-address?  yang:phys-address
> +--ro higher-layer-if*   interface-state-ref
> +--ro lower-layer-if*interface-state-ref
> +--ro speed? yang:gauge64
> +--ro statistics
> |  +--ro discontinuity-timeyang:date-and-time
> |  +--ro in-octets?yang:counter64
> |  +--ro in-unicast-pkts?  yang:counter64
> |  +--ro in-broadcast-pkts?yang:counter64
> |  +--ro in-multicast-pkts?yang:counter64
> |  +--ro in-discards?  yang:counter32
> |  +--ro in-errors?yang:counter32
> |  +--ro in-unknown-protos?yang:counter32
> |  +--ro out-octets?   yang:counter64
> |  +--ro out-unicast-pkts? yang:counter64
> |  +--ro out-broadcast-pkts?   yang:counter64
> |  +--ro out-multicast-pkts?   yang:counter64
> |  +--ro

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

Hi,

Thanks for this detailed review, it is much appreciated!  Comments
inline.

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I have read through draft-ietf-netmod-rfc6020bis-07 (except section 9.
> Built-In Types). Overall, the document is in a good shape. I spotted a
> number of editorial issues or a number of issues where we could try to
> seek a clearer separation of NETCONF specifics. (I plan to read
> section 9 as well but I assume this is less important since there
> likely are not many changes from RFC 6020 in this part.)
> 
> I am indicating the paper number below for each comment/suggestion.
> 
> * p8:
> 
>   s/XML has been/XML have been/
> 
>   s/how the data model/how a data model/
> 
>   s/represented in/encoded in/

Fixed.

> * p9:
> 
>   s/names means/names mean/

Fixed.

> * p11:
> 
>   s/the module faithfully/a module faithfully/

Fixed.

>   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.

  client: An entity that can access YANG-defined data on a server,
  over some network management protocol.

?


> * p13
> 
>   Does the term 'mandatory node' really deserve its own subsection?  I
>   understand that there are references to section 3.1 but would
>   reference to section 3 not work as well?

Sure.  The thing is that I have toolchain problems with nested
lists...  [hacking away] ... Fixed.

> * p13
> 
>   s/used for other/used with other/

Fixed.

> * p14
> 
>   s/encoded in NETCONF operations/encoded on-the-wire/

Fixed.

> * p14
> 
>   s/of NETCONF data models/of data models for network management
>   protocols such as NETCONF,/

Fixed.

>   And I suggest to remove the following sentence since it is not
>   really needed.
> 
>   The data models described by YANG are designed to be easily
>   operated upon by NETCONF operations.

Fixed.

> * p15
> 
>   s/read-only access/read-only access [RFC6643]/

Fixed.

> * p15
> 
>   I am not sure why the last paragraph in section 4.1 is needed. In
>   the first setence, I would remove 'Like NETCONF' and in the second
>   sentence I am not sure what we are saying given that there is NACM.
>   I would definitely remove the second sentence and if the first
>   should be kept, I would likely move it up since it is a fairly
>   general statement. But I think removing the whole paragraph is the
>   simplest solution since it is not essential.

Agree, removed.

> * p13
> 
>   Would it make sense to add a sentence right at the beginning of
>   section 4 stating that section 4 is intended to provide orientation
>   for the first time reader but that section 4 is not normative?

How about:

  This non-normative section is intended to give a high-level
  overview of YANG to first-time readers.

> * p15
> 
>   With the previous in mind, I suggest to remove "This progressive
>   approach handles the inter-related nature of YANG concepts and
>   statements.  A detailed description of YANG statements and syntax
>   begins in Section 7." from the text right below 4.2. Note that
>   Section 7 is actually Section 6 (but Section 5 has also important
>   normative content).

I agree; removed.

> * p16
> 
>   s/four types of nodes/four types of data nodes/

Fixed.

> * p16
> 
>   Perhaps simplify:
> 
>   OLD
> 
> A leaf instance contains simple data like an integer or a string.  It
> has exactly one value of a particular type and no

[netmod] FW: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

2015-10-15 Thread Alexander Clemm (alex)

Forwarding to NETMOD as people there might be interested as well
(for those subscribed to both mailers, apologies for the spam...)

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Alexander Clemm 
(alex)
Sent: Thursday, October 15, 2015 1:57 PM
To: netc...@ietf.org
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

Hello all,

below we noted that "draft-clemm-netconf-yang-push" would become 
"draft-ietf-netconf-yang-push-00" this week.   Just as an FYI, the WG draft is 
now posted:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/

Kind regards
--- Alex

From: Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 8:37 PM
To: netc...@ietf.org
Cc: Alexander Clemm (alex) >; Alberto 
Gonzalez Prieto (albertgo) >; 
Ambika Prasad Tripathy (ambtripa) 
>; Einar Nilsen-Nygaard (einarnn) 
>
Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

There are a couple new drafts posted in NETCONF:

(1)  Subscribing to YANG datastore push updates
http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt
As per earlier NETCONF 
discussions 
we are expecting this draft to become draft-ietf-netconf-yang-push in the 
coming days (once the NETCONF charter is approved).  Look for an OpenDaylight 
client in the Beryllium release (Feb).

(2) Restconf subscription and HTTP push for YANG datastores
http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt
Extends draft-clemm-netconf-yang-push in the following ways:

* proposes Restconf subscription and push mechanisms to continuously stream 
information from YANG datastores over HTTP

* provides a mechanism to support static subscriptions so that an operator 
can stream updates over HTTP without Restconf

* provides YANG model extensions to leverage HTTP/2 so that individual 
subscriptions can get custom treatment via their own HTTP streams.

Thanks for your interest, and we look forward to the discussions!

- Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripathy, 
& Einar Nilsen-Nygaard

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

Re: [netmod] 6020bis extensions

2015-10-15 Thread Juergen Schoenwaelder

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.

/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 (section 9. built-in types)

Juergen Schoenwaelder  wrote:
> 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.

Ha!  It seems to have been empty since -01...

> /js
> 
> * p126
> 
>   OLD
> 
>  Some types have a lexical representation that depends on the XML
>  context in which they occur.  These types do not have a canonical
>  form.
> 
>   NEW
> 
>  Some types have a lexical representation that depends on the
>  encoding, e.g., the XML context in which they occur.  These types
>  do not have a canonical form.

Fixed.

>   Well, it turns out that there are XML encoding specifics in several
>   of the following sections. Perhaps instead stated upfront that the
>   section 9 describes the types and they XML encoding and noting that
>   other encodings may use different rules. Perhaps also stating that
>   the canonical representation is also used for constraint evaluation
>   purposes.
> 
>   OLD
> 
> When a NETCONF server sends data, it MUST be in the canonical form.
> 
>   NEW
> 
> When a server sends data encoded in XML, it MUST use the canonical
> form defined in this section. Other encodings may introduce
> alternate representations. Note, however, that values in the data
> tree are conceptually stored in the canonical representation as
> defined in this section. In particular, any XPath expression
> evaluations are done using the canonical form.

Fixed.

> * p127
> 
>   s/XML instance documents/XML encoding/

Fixed.

> * p131
> 
>   s/XML instance documents/XML encoding/

Fixed.

> * p132
> 
>   The section 9.4.6 (modifier statement) is empty and needs to be
>   filled in.

Fixed.

> * p137
> 
>   Y25-02 says:
> 
>   Keep the auto-numbering procedure for enums and bits and add an
>   explicit warning that inserting enum or bits definitions or
>   reordering enum or bits definitions violates section 10 and causes
>   interoperability problems unless explicit value assignments are
>   used.
> 
>   Has this been implemented? I did not find such a statement.

Neither did I :(

I think it is best to add this warning to section 10:

OLD:

  o  An "enumeration" type may have new enums added, provided the old
 enums's values do not change.

NEW:

  o  An "enumeration" type may have new enums added, provided the old
 enums's values do not change.  Note that inserting a new enum before
 an existing enum or reordering existing enums will result in new
 values for the existing enums, unless they have explicit values
 assigned to them.

?

> * p139
> 
>   s/A binary can/A binary type can/

Fixed.

> * p139
> 
>   s/are encoded/are encoded in XML/

How about s/are encoded/are lexically represented/

since it is not just XML, but also defaults and the canonical form.

> * p141
> 
>   s/is encoded/is encoded in XML/

s/is encoded/is lexically represented/ ?

> * p146
> 
>   s/is encoded/is encoded in XML/

s/is encoded/is lexically represented/ ?

> * p148
> 
>   The text stating that a value is consecutively against each member
>   type does not seem to be 100% true for the JSON mapping since JSON
>   says the JSON type information is taken into account. So we either
>   change the JSON specification or we rewrite this text in RFC 6020 to
>   allow different member type selection styles by making this
>   statement specific to the XML encoding:
> 
>  In the XML encoding, the value representing a union data type...

I added this last sentence.


/martin

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

Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

These terms were edited on today's call, resulting in the following:

  * intended configuration - this data represents the configuration
state that the network operator intends the system to be in, and
that has been accepted by the system as valid configuration.

  * applied configuration - this data represents the configuration
state that the network element is actually in.  That is, the
configuration state which is currently being used by system
components (e.g., control plane daemons, operating system
kernels, line cards).

NOTE: The system's ability to report applied configuration accurately
may be limited in some cases, such as when the the configuration
goes through an intermediate layer without an ability to inspect the
lower layer.

If no objection is raise by tomorrow, this issue will be moved to the
EDIT state and I'll plan to make the change in the draft before Monday's
cutoff.

Kent

From: Robert Wilton >
Date: Thursday, October 15, 2015 at 5:50 AM
To: Jonathan Hansford >, 
Kent Watsen >, Andy Bierman 
>
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"

Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multiple NMS
 - responsibility for parts of the configuration is split between multiple NMS 
and they are each independently responsible for ensuring that their part of the 
configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive 
configuration for a device to be known and held (perhaps in a distributed 
fashion) somewhere in the operators management network, not on the device 
itself.

Thanks,
Rob

On 15/10/2015 09:55, Jonathan Hansford wrote:

The NMS only knows the intended config if it is the only NMS capable of 
changing that device’s config. That may not always be the case.

Jonathan

From: Robert Wilton
Sent: 14 October 2015 22:28
To: Kent Watsen;Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"

On 14/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing constantly.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions for 
solutions to provide something like a yang-patch to describe just the diffs.  
Makes sense to me!

The NMS already knows the intended config since it sent it to the device in the 
first place, so in normal circumstances I would expect the NMS to only query 
the applied config (and possibly derived state at the same time) and then 
compare it to the NMS's view of the intended cfg for that device.  If the NMS 
is smart then it might be able to restrict most of the queries to only the 
device's applied config sub-trees that could possibly be out of sync, perhaps 
with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be 
useful (the draft that I put forward also proposes a diff-cfg-only option).  
However, it is also worth noting that the original requirements don't 
explicitly ask for this, so perhaps more of a nice to have than a formal 
requirement?

Thanks,
Rob

K.

From: Andy Bierman 
<a...@yumaworks.com>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen >
Cc: Robert Wilton >, 
"netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied 
configuration"

On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen 
<kwat...@juniper.net> 
wrote:

Thank you Robert for bringing the discussion back to the github issues.

Robert writes:

> In particular:
>- does it include support for templating (as per 
> openconfig-netmod-opstate-01 section 7.3.)?
>- is it allowed to represent system created objects that have no 
> corresponding configuration?
>
> Requirement 1.D states

 D.  For asynchronous systems, when fully synchronized, the data

   in the applied configuration is the same as the data in the

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