[netmod] YANG 1.1 conformance announcement

[Andy Bierman]

Hi,

Buried in the many NETCONF-specific sections is a requirement to
announce the YANG library info.  However this info is incomplete
and sec. 5.6.5 needs to be changed because it assumes there is only
1 revision of the ietf-yang-library module possible.   The client cannot
read the read the library to find out which revision of the library template
to use.




5.6.5.  Announcing Conformance Information in NETCONF

   This document defines the following mechanism for announcing
   conformance information.  Other mechanisms may be defined by future
   specifications.

   A NETCONF server announces the modules it implements by implementing
   the YANG module "ietf-yang-library" defined in
   [I-D.ietf-netconf-yang-library], and listing all implemented modules
   in the "/modules-state/module" list.


OLD:

   The server also advertises the following capability in the 
   message (line-breaks and whitespaces are used for formatting reasons
   only):

 urn:ietf:params:netconf:capability:yang-library:1.0?
   module-set-id=

   The parameter "module-set-id" has the same value as the leaf
   "/modules-state/module-set-id" from "ietf-yang-library".  This
   parameter MUST be present.

NEW:

   The server also advertises the following capability in the 
   message (line-breaks and whitespaces are used for formatting reasons
   only):

 urn:ietf:params:netconf:capability:yang-library:1.0?
   revision==

   The parameter "revision" has the same value as the revision
   date of the "ietf-yang-library" implemented by the server. This
 parameter MUST be present.


The parameter "module-set-id" has the same value as the leaf
"/modules-state/module-set-id" from "ietf-yang-library". This parameter
MUST be present.



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

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Kent Watsen]

The chairs were just reviewing notes and realized that this thread never closed 
properly.

Juergen has some concerns regarding realistic milestones, that were never 
addressed.  Robert, can you please try to address Juergen’s concerns now?

Also, there were only a two responses before indicating willingness to review 
the draft as it progresses (thanks Dan and Martin).  Can others that support 
this draft and willing to review this draft say so?

Thanks,
Netmod Chairs


From: netmod > on 
behalf of Kent Watsen >
Date: Tuesday, December 15, 2015 at 11:48 AM
To: "netmod@ietf.org" 
>
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang 
as NETMOD WG draft


The minutes for IETF 94 show that there was in-room support for adopting 
draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
this decision would be confirmed on the mailing list, which I am doing now.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and 
correspondingly add this to the WG charter as a milestone?  Please comment by 
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
whether or not there is consensus to move forward with the document.

Thanks,
Kent


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

[netmod] WG Last Call: draft-ietf-netmod-syslog-model-06

[Lou Berger]

All,
This starts a two-week working group last call on
draft-ietf-netmod-syslog-model-06.

The working group last call ends on March 14. Please send your comments
to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs

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

[netmod] Moving the WG discussion on mount forward

[Lou Berger]

All,

At last week's interim, Martin committed to update his document based
on the meeting and then work with the other mount document authors
(i.e., Lada and Alex) on a future version.  Martin has now
published this version:
https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02

Lada also said that he was okay with using Martin's document
as a starting point for the working group document on this
topic.  (Keep in mind a -00 WG document is a starting point, not
and end point.)

We'd now like to ask for additional feedback from other WG
contributors on their opinions on what they would like see added
to base document in order for it to be accepted as a WG document.
So please review the document and send comments to the list --
again on what areas need to be covered for the document to be
accepted as a -00 WG draft.  We're hoping for comments within the
next week or so.

Thank you,
Netmod chairs

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

Re: [netmod] proposed change to ietf-routing

[Xufeng Liu]

It'd be better to have a consistent design pattern. There are at least three
more options as following.

Thanks,

- Xufeng

Option 1:

   +--rw networking-instances
   |  +--rw networking-instance* [name]
   | +--rw name  string
   | +--rw type? identityref
   | +--rw enabled?  boolean
   | +--rw description?  string
   | +--rw networking-instance-policy
   | +--rw root? structural-mount
   |+--rw routing
   ||  +--rw router-id?   yang:dotted-quad
   ||  +--rw description? string
   ||  +--rw routing-protocols
   ||  |  +--rw routing-protocol* [type name]
   ||  | ...
   ||  +--rw ribs
   || +--rw rib* [name]
   ||...
   |
   +--ro networking-instances-state
  +--ro networking-instance* [name]
 +--ro name  string
 +--ro type? identityref
 +--ro enabled?  boolean
 +--ro description?  string
 +--ro networking-instance-policy
 +--ro root? structural-mount
+--ro routing
|  +--ro router-id?   yang:dotted-quad
|  +--ro interfaces
|  |  +--ro interface*   if:interface-state-ref
|  +--ro routing-protocols
|  |  +--ro routing-protocol* [type name]
|  | ...
|  +--ro ribs
| +--ro rib* [name]
|...

Option 2:

   +--rw networking-instances
  +--rw networking-instance* [name]
 +--rw name  string
 +--rw type? identityref
 +--rw enabled?  boolean
 +--rw description?  string
 +--rw networking-instance-policy
 +--rw root? structural-mount
+--ro routing-state
|  +--ro router-id?   yang:dotted-quad
|  +--ro interfaces
|  |  +--ro interface*   if:interface-state-ref
+--rw routing
   +--rw router-id?   yang:dotted-quad
   +--rw description? string
   +--rw routing-protocols
   |  +--rw routing-protocol* [type name]
   | ...
   +--ro routing-protocols-state
   |  +--ro routing-protocol* [type name]
   | ...
   +--rw ribs
   |  +--rw rib* [name]
   | ...
   +--ro ribs-state
  +--rw rib* [name]
 ...

Option 3:

   +--rw networking-instances
  +--rw networking-instance* [name]
 +--rw config
 |  +--rw name  string
 |  +--rw type? identityref
 |  +--rw enabled?  boolean
 |  +--rw description?  string
 |  +--rw networking-instance-policy
 |  +--rw root? structural-mount
 | +--rw routing
 |+--rw config
 ||  +--rw router-id?   yang:dotted-quad
 ||  +--rw description? string
 ||  +--rw routing-protocols
 ||  |  +--rw routing-protocol* [type name]
 ||  | +--rw config
 ||  | | ...
 ||  | +--ro state
 ||  | | ...
 ||  +--rw ribs
 || +--rw config
 || |  +--rw rib* [name]
 || | ...
 || +--ro state
 ||+--ro rib* [name]
 ||   ...
 |+--ro state
 |   +--ro router-id?   yang:dotted-quad
 |   +--ro interfaces
 |   |  +--ro interface*   if:interface-state-ref
 | 
 +--ro state
   ...


> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Friday, February 26, 2016 10:41 AM
> To: Xufeng Liu 
> Cc: NETMOD WG 
> Subject: Re: [netmod] proposed change to ietf-routing
> 
> 
> > On 26 Feb 2016, at 15:33, Xufeng Liu  wrote:
> >
> > Hi Acee and Lada,
> >
> > Have a question: the schema hierarchy will be different after the
changes.
> > Is the following expected? We will have ro branch and rw branch split
> > in the middle of the tree after mounting?
> 
> Yes, unless and until we agree on a better data organization. Note that it
is
> exactly the same as with ietf-interfaces.
> 
> Lada
> 
> >
> > Before:
> >
> > module: ietf-routing
> >   +--ro routing-state
> >   |  +--ro 

Re: [netmod] Augment issue

[Robert Wilton]

Hi Peter,

I agree with you, i.e. I think that this is a bug in the OpenDaylight 
YANG parser.


My interpretation is that augmentations with mandatory nodes within a 
module, or a sub-module on nodes in its parent module are allowed.


This augmentation from the jukebox-cd module onto an external module is 
allowed because it is not augmenting with a mandatory node:


augment "/jbox:jukebox" {
   container cdcapable {
 presence
 "If present, indicates that the jukebox can play CDs";
   }
}

This augmentation is allowed because it is from a sub-module to its 
parent module:


augment "/jbox:jukebox/jboxcd:cdcapable" {
  description
  "Extra jukebox CD data";

  leaf number-of-cds {
type uint16;
mandatory true;
description
"The number of CDs in the jukebox";
  }
}

Interestingly, this second augmentation wouldn't/shouldn't be allowed if 
the cdcapable container didn't have presence.  Which I think means that 
when a sub-module augmentation is being considered, it needs to 
determine what the combined augmentation on the external module is to 
determine whether the augmentation adds any unconditional mandatory 
nodes on the external module - which is not allowed.


Thanks,
Rob


On 29/02/2016 09:09, Peter Verthez wrote:

Hi all,

A few weeks ago I reported a bug on the OpenDaylight YANG parser, 
regarding a error that was generated on a particular augment 
construction.   The bug report is the following:

https://bugs.opendaylight.org/show_bug.cgi?id=5335

We are disagreeing on the interpretation of the YANG RFC regarding to 
this bug, so could we get the opinion of the people on this mailing 
list on it?


The problem originated from a proposed Broadband Forum model, but 
there's a dummy model that reproduces the problem attached to that bug 
report.


Thanks,
Peter.

___
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] Query regarding "list" subelement XML Mapping rule

[Rohit pobbathi]

Hi,

I have a query regarding "list" subelement XML Mapping rules - RFC 6020 Section 
7.8.5.

For clarity, I am using the "example-jukebox" YANG model (from RESTCONF draft).
   +--rw jukebox!
  +--rw library
  |  +--rw artist* [name]
  |  |  +--rw name string
  |  |  +--rw album* [name]
  |  | +--rw name string
  |  | +--rw genre?   identityref
  |  | +--rw year?uint16
  |  | +--rw admin
  |  | |  +--rw label?  string
  |  | |  +--rw catalogue-number?   string
  |  | +--rw song* [name]
  |  |+--rw namestring
  |  |+--rw locationstring
  |  |+--rw format? string
  |  |+--rw length? uint32
  |  +--ro artist-count?   uint32
  |  +--ro album-count?uint32
  |  +--ro song-count? uint32

Request from Client to Server:
 
   
 
   http://example.com/ns/example-jukebox;>
 
   
 Foo Fighters
 
   Wasting Light
  ==> Request selection node order
   
   
 
   
 
   
 
   
 

The selection nodes in above request are not in the same order as defined in 
the YANG model for "jukebox" module's "album" list.

I assume this is allowed as per the RFC 6020 section 7.8.5's below paragraph:
   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC input or
   output parameters, the subelements are encoded in the same order as
   they are defined within the "list" statement.  Otherwise, the
   subelements are encoded in any order.

Please confirm if the above  request's selection nodes order is valid ?

Response from Server to Client:
 
   
 http://example.com/ns/example-jukebox;>
   
 
   Foo Fighters
   
 Wasting Light
 example-jukebox:alternative
 2011
 
   Wasting Light
   MP3
   286
 
 
   Rope
   MP3
   259
 
   
 
   
 
   
 

For the above request, is it fine for the Server to encode the response with 
list subelement order as per the defined YANG model ?
OR
Should the response follow the REQUEST's list subelement order ?

Regards,
Rohit P
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Augment issue

[Peter Verthez]

Hi all,

A few weeks ago I reported a bug on the OpenDaylight YANG parser, 
regarding a error that was generated on a particular augment 
construction.   The bug report is the following:

https://bugs.opendaylight.org/show_bug.cgi?id=5335

We are disagreeing on the interpretation of the YANG RFC regarding to 
this bug, so could we get the opinion of the people on this mailing list 
on it?


The problem originated from a proposed Broadband Forum model, but 
there's a dummy model that reproduces the problem attached to that bug 
report.


Thanks,
Peter.

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