from:"Benoit Claise"

Re: [netmod] 3 RFCs in 1 day!

2016-09-01 Thread Benoit Claise


Indeed, great achievement.
Thanks to everybody involved.

Regards, Benoit.

With the publication of these three RFCs a major milestone has been
reached - a big thank you to Martin and Lada and everybody who
contributed to the development of these specifications over the last
two years. This work involved 1 interim meeting, 22 virtual interim
meetings and the resolution of 60 tracked issues, and countless
messages on the mailing list. Lets have a virtual celebration today!

/js

On Wed, Aug 31, 2016 at 07:57:16PM -0700, Andy Bierman wrote:

Hi,

I get to be the first to thank Martin and Lada for all the work
that went into these RFCs. YANG 1.1 is finally done!

Now I hope we start seeing lots of implementations of these RFCs.


Andy
___
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] Fwd: RE: Regarding IEEE/IETF coordination draft draft-wilton-netmod-intf-vlan-yang

2016-08-30 Thread Benoit Claise


Dear all,

As discussed with the IEEE, here is a way to progress 
draft-wilton-netmod-intf-vlan-yang

Rob, please update your draft with an Informational intended status.

Regards, Benoit

 Forwarded Message 
Subject: 	RE: Regarding IEEE/IETF coordination draft 
draft-wilton-netmod-intf-vlan-yang

Date:   Thu, 18 Aug 2016 19:51:14 +
From:   Glenn Parsons <glenn.pars...@ericsson.com>
To: 	Benoit Claise <bcla...@cisco.com>, Romascanu, Dan (Dan) 
<droma...@avaya.com>, ops-...@ietf.org <ops-...@ietf.org>
CC: 	netconf-cha...@ietf.org <netconf-cha...@ietf.org>, Robert Wilton -X 
(rwilton - Ensoft Ltd at Cisco) <rwil...@cisco.com>, Pat Thaler 
<ptha...@broadcom.com>, Eric Gray <eric.g...@ericsson.com>, John 
Messenger <jmessen...@advaoptical.com>, Paul Nikolich 
<paul.nikol...@att.net> (paul.nikol...@att.net) <paul.nikol...@att.net>




Subject: Regarding IEEE/IETF coordination draft 
draft-Wilton-netmod-intf-vlan-yang


To: Benoit Claise, Dan Romascanu

Date: July 28, 2016

Dear Benoit, Dan,

Thank you for your email (attached below) regarding IEEE/IETF

coordination draft draft-Wilton-netmod-intf-vlan-yang

In its July 2016 plenary meeting, IEEE 802.1  held detailed discussions

of YANG models for 802.1Q and 802.1X, the related interfaces, interface

stacks, and the service(s) offered to higher layer entities both in end

stations and attached to bridge ports. IEEE 802.1 will continue this

work in its September 2016 interim.

IEEE 802.1 agrees that progression of draft-Wilton-netmod-intf-vlan-yang

as an Informational RFC would be appropriate to meet immediate needs,

and values the details included in the document to ensure that the draft

does not deviate from 802.1 standards. IEEE 802.1 will continue its work

on standard YANG model, appreciates the contribution that other work can

make towards that standards goal, and would welcome participation by

IETF experts in its face-to-face discussions and teleconferences.

Regards,

Glenn.

--

Glenn Parsons - Chair, IEEE 802.1

glenn.pars...@ericsson.com <mailto:glenn.pars...@ericsson.com>

+1-613-963-8141

*From:*Benoit Claise [mailto:bcla...@cisco.com]
*Sent:* Thursday, July 21, 2016 2:19 PM
*To:* Romascanu, Dan (Dan); John Messenger; ops-...@ietf.org; Glenn Parsons
*Cc:* netconf-cha...@ietf.org; Robert Wilton -X (rwilton - Ensoft Ltd at 
Cisco); Pat Thaler; Eric Gray
*Subject:* Regarding IEEE/IETF coordination draft 
draft-wilton-netmod-intf-vlan-yang


Dear 802.1 WG,

In the IETF, we're considering how to 
progressdraft-wilton-netmod-intf-vlan-yang-03 
<https://datatracker.ietf.org/doc/draft-wilton-netmod-intf-vlan-yang/> , 
Sub-interface VLAN YANG Data Models, in order to allow IETF forwarding 
services to interact with 802.1Q VLAN tagged frames.
One option considered is to publish this draft as Informational RFC (as 
opposed to Proposed Standard), with the understanding that IEEE 802.1 
could develop an end station interface model that would considered as 
the reference standard.

Is this a viable solution from the viewpoint of 802.1Q?

The latest draft version contains YANG "must" statements to try to 
constrain the model such that only 802.1 compatible frames result.


Regards, Dan Romascanu (IETF Liaison Manager to IEEE-SA, Benoit Claise 
(IETF Operations and Management Area Director)




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

Re: [netmod] netmod - New Meeting Session Request for IETF 97

2016-08-28 Thread Benoit Claise


Hi,


A new meeting session request has just been submitted by Lou Berger, a Chair of 
the netmod working group.


-
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour
Number of Attendees: 100
The room was packed last time. I would increase the number of attendees, 
to get a bigger room.


Regards, B.

Conflicts to Avoid:
  First Priority: netconf rtgwg
  Second Priority: i2rs anima isis ospf
  Third Priority: saag


Special Requests:
   
-


.



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

[netmod] RFC087bis and intended/applied status guideline

2016-07-19 Thread Benoit Claise


Dear all,

Where do we capture this outcome, cut/pasted from the NETMOD chairs into 
slides:
"Models need not, and SHOULD NOT, be structured to include 
nodes/leaves to indicate applied configuration"


RFC6087 is about: "_Guidelines _for _Authors _and _Reviewers _of _YANG 
Data Model Documents_".
As OPS AD, I need to provide to both guidance to authors of YANG 
modules, and also guidance to the YANG doctors.

I can't think of a better place.

Once we have this RFC published, do you believe that YANG module authors 
will be looking in a WIKI?
Btw, keep in mind: YANG module authors from all SDOs and opensource 
projects.


Regards, Benoit


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

[netmod] draft-ietf-netmod-intf-ext-yang-01.txt: compilation error

2016-07-16 Thread Benoit Claise


Dear authors,

Part of the IETF hackathon today, I integrated confdc , as a second YANG 
module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. 
Reason? For example, confdc validates xpath while pyang doesn't.
And confdc found an issue with your draft, which is now flagged as 
failing the YANG compilation.

Please correct this issue.
Note: you're not alone, look at the green dip today on green graph 
!


During the hackathon today, Carl Moberg also integrated the confdc 
output in his www.yangalidtor.com.

This might help you.

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

[netmod] draft-ietf-netmod-entity-00.txt: compilation error

2016-07-16 Thread Benoit Claise


Dear authors,

Part of the IETF hackathon today, I integrated confdc , as a second YANG 
module compiler, in http://www.claise.be/IETFYANGPageCompilation.html. 
Reason? For example, confdc validates xpath while pyang doesn't.
And confdc found an issue with your draft, which is now flagged as 
failing the YANG compilation.

Please correct this issue.
Note: you're not alone, look at the green dip today on green graph 
!


During the hackathon today, Carl Moberg also integrated the confdc 
output in his www.yangalidtor.com.

This might help you.

Regards, Benoit

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

[netmod] In preparation of our NETMOD meeting in Berlin

2016-07-12 Thread Benoit Claise


Dear all,

$ wgstatus - sNETMOD
# Document Status Since 2016-04-08 00:00:00

## New WG-Docs
draft-ietf-netmod-entity-00[u'I-D Exists', u'WG Document']
draft-ietf-netmod-intf-ext-yang-01 [u'I-D Exists', u'WG Document']

## Updated WG-Docs
draft-ietf-netmod-rfc6020bis-14[u'RFC Ed Queue', u': 
EDIT', u'for 25 days', u'Submitted to IESG for Publication:', u'Proposed 
Standard', u'Jul 2014', u',', u'Jan 2016']
draft-ietf-netmod-yang-model-classification-02 [u'I-D Exists', u'WG 
Document']
draft-ietf-netmod-schema-mount-02  [u'I-D Exists', u'WG 
Document']
draft-ietf-netmod-routing-cfg-22   [u'AD is watching', 
u'Submitted to IESG for Publication:', u'Proposed Standard']
draft-ietf-netmod-rfc6087bis-07[u'I-D Exists', u'WG 
Document', u'Jun 2014', u',', u'Dec 2015']
draft-ietf-netmod-acl-model-08 [u'I-D Exists', u'WG 
Document', u'Apr 2014']
draft-ietf-netmod-syslog-model-09  [u'I-D Exists', u'WG 
Document']


## Existing WG-Docs
draft-ietf-netmod-opstate-reqs-04  [u'Waiting for AD Go-Ahead::Revised 
I-D Needed', u'for 132 days', u'Submitted to IESG for Publication:', 
u'Informational']
draft-ietf-netmod-yang-metadata-07 [u'RFC Ed Queue', u': EDIT', u'for 
112 days', u'Submitted to IESG for Publication:', u'Proposed Standard']
draft-ietf-netmod-yang-json-10 [u'RFC Ed Queue', u': EDIT', u'for 
104 days', u'Submitted to IESG for Publication:', u'Proposed Standard', 
u'Apr 2014']


## New IDs
draft-schoenw-netmod-revised-datastores-01 [u'I-D Exists']
draft-agv-netmod-yang-annotation-ds-and-derived-00 [u'I-D Exists']
draft-sharma-netmod-fault-model-00 [u'I-D Exists']
draft-wilton-netmod-refined-datastores-01  [u'I-D Exists']
draft-agv-netmod-yang-compiler-metadata-01 [u'I-D Exists']

## Updated IDs
draft-chen-netmod-enterprise-yang-namespace-01 [u'I-D Exists']
draft-lear-ietf-netmod-mud-02  [u'I-D Exists']
draft-openconfig-netmod-model-catalog-01   [u'I-D Exists']
draft-wilton-netmod-intf-vlan-yang-03  [u'I-D Exists']

## Existing IDs
draft-lear-ietf-netmod-acl-dnsname-00   [u'I-D Exists']
draft-kwatsen-netmod-opstate-02 [u'I-D Exists']
draft-bjorklund-netmod-structural-mount-02  [u'I-D Exists']
draft-betts-netmod-framework-data-schema-uml-03 [u'I-D Exists']
draft-liu-netmod-yang-schedule-00   [u'I-D Exists']
draft-mansfield-netmod-uml-to-yang-02   [u'I-D Exists']
draft-voit-netmod-yang-mount-requirements-00[u'I-D Exists']
draft-clemm-netmod-mount-04 [u'I-D Exists']
draft-asechoud-netmod-qos-model-00  [u'I-D Exists']


Agenda: https://datatracker.ietf.org/meeting/96/agenda/netmod/

Regards, Benoit

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

Re: [netmod] contact statement content

2016-07-06 Thread Benoit Claise

On 7/6/2016 3:26 AM, Andy Bierman wrote:

On Tue, Jul 5, 2016 at 6:16 PM, Dale R. Worley > wrote:

Kent Watsen > writes:
> 1) Remove the text "In addition, the Area Director and other contact
> information MAY be present", as there is no reason to hint that
> listing ADs makes sense.

My rationale for listing ADs and WG chairs is that they get no credit
whatsoever for the work they put into the RFC. Considering Benoit
has put more review time into these drafts than anybody in the WG,
this seems appropriate.
Thanks Andy. The draft acknowledgment section seems appropriate in such 
a case.
However, ADs come and go, as WG chairs btw. And their affiliations can 
change too.
So I'm not convinced of the value of listing the AD and WG chairs in the 
YANG module itself.
The more stable point of contact is always the WG list. A role email 
address for the relevant Area Director, that is likely to be more stable 
than the working group address, would anyway be constructed out of the 
WG list.

Regards, Benoit (as a contributor)

This thread started as a 6020bis request to move the contact info and
now it is a 6087bis request to remove guideline text about the contact 
info.

Can you restate the OLD and NEW so we can gauge WG consensus on the 
change?

If there's a role email address for the relevant Area Director,
that is
likely to be more stable than the working group address, since
areas are
expected to be semi-permanent, whereas WGs are assumed to have a
finite
lifetime.  Of course, a personal address for an AD will likely be less
stable.

Dale

Andy

___
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

[netmod] draft-ietf-netmod-yang-model-classification-02.txt posted

2016-06-27 Thread Benoit Claise


Dear all,

We have posted draft-ietf-netmod-yang-model-classification version 2

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

We believe that we have addressed all the open issues, and that this 
draft is ready for WGLC.


Regards, Carl, Dean, and Benoit

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

Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process

2016-06-10 Thread Benoit Claise


Thank you Jürgen and Martin.
The document really improved IMO.

Regards, Benoit

Hi,

Martin has posted revision -13 of the YANG 1.1 specification. This
revision incorporates all comments that we have received during the
IESG process. A big thanks in particular to our gen-art and ops-dir
reviewers and to Martin for following up on the issues. Please check
the edits do make sure that nothing broke. The diff can be found
here:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt

Note that this is _not_ the time to raise new issues or to suggest
alternate resolutions to issues discussed before. This is only a check
to verify that the edits were done correctly. Please check the edits
as soon as possible, any errors found must be raised by Thursday
2016-06-16.

/js



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

[netmod] Fwd: YANG Model Coordination Group directory closure

2016-06-09 Thread Benoit Claise

FYI.

 Forwarded Message 
Subject:YANG Model Coordination Group directory closure
Date:   Thu, 9 Jun 2016 17:35:07 +0200
From:   Benoit Claise <bcla...@cisco.com>
To: 	IETF-Discussion list <i...@ietf.org>, yang-co...@ietf.org 
<yang-co...@ietf.org>

Dear all,

The YANG Model Coordination Group 
<http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html> 
has been a success, and has served its purpose.

The plan and the time commitment (each person committed to spend 1/3 of 
his time) for this group were ambitious:

 * Phase 1: List of the YANG models (inventory)
 * Phase 2: Tooling
 * Phase 3: Help with compilation
 * Phase 4: Training & Education
 * Phase 5: Coordination across SDOs/Opensource
 * Phase 6: Model Coordination within the IETF
 * Phase 7: Standardization Priorities

Let's review the achievements. Quiet impressive for a couple of 
volunteers if you ask me.

Phase 1: List of the YANG models (inventory)
Extracted all YANG data models from IETF drafts and RFCs on 
http://www.claise.be/

Started to work on YANG data model catalog for the industry

Phase 2: Tooling
YANG data models extraction from drafts/RFCs
YANG data models dependency visualization
YANG data model grouping extraction and compilation
Created http://www.yangvalidator.org/
pyang integration in idnits/tracker
pyang plugin for the YANG data model catalog
Along the process we filed a couple of pyang bugs
Organized the YANG track at the IETF Hackathon
etc.

Phase 3: Help with compilation
Proactively contacted the IETF draft authors, discussing their 
compilation error messages 
<http://www.claise.be/IETFYANGPageCompilation.html>
Kept track of the situation here 
<https://trac.tools.ietf.org/area/ops/trac/wiki/YangCoordModelExtractionandCompilation>

Flagged the duplicate YANG module names, groupings, etc.

Phase 4: Training & Education
Created some training materials, presented at IETF94
NETCONF Slides 
<http://datatracker.ietf.org/doc/slides-edu-network-configuration-with-netconf/>, 
YANG Slides 
<http://datatracker.ietf.org/doc/slides-edu-network-configuration-with-yang/>, 
pyang Slides <https://datatracker.ietf.org/doc/slides-edu-pyang-tutorial/>

Phase 5: Coordination across SDOs/Opensource
Coordinated with the IEEE/MEF/BBF, amongst others
Worked on the YANG Data Model Classification, 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/> 
accepted as NETMOD WG document
Based on github, we're compiling the 
IEEE/BBF/Opendaylight/openconfig data models 
<http://www.claise.be/YANGPageMain.html>

Helped on URN for different SDOs
YANG Modeling Efforts in the Industry 
<https://trac.tools.ietf.org/area/ops/trac/wiki/YANGModelingEffortsinTheIndustry>

Phase 6: Model Coordination within the IETF
We helped with the coordination, even if the YANG routing design team
contributed significantly for the routing aspects.

Phase 7: Standardization Priorities
This is maybe where we haven't had enough time to dedicate,
even if we have identified the next steps.
See YANG Data Models in the Industry: Current State of Affairs 
<https://www.ietf.org/blog/2016/03/yang-data-models-in-the-industry-current-state-of-affairs/>

I probably missed some of the achievements. Sorry about that.

Let's analyze the current situation!
It's difficult, in a voluntary-based organization to dedicate so much 
time on this YANG effort. On the other hand, this group efforts helped 
with the heavy-lifting job to promote YANG in the industry. Thanks for 
that. These days, even if it doesn't translate yet in many RFC numbers, 
YANG became a mature technology, which can now rely on a bigger community.
I expect that the YANG doctors 
<https://www.ietf.org/iesg/directorate/yang-doctors.html> to take over 
some of the effort here, helping with the proactive review of YANG data 
models. More on this later.
Regarding the tooling aspects, the IETF hackathon will continue to play 
an important role: a couple of people signed up already

Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, 
and to many others who helped directly or indirectly.

I will now request to close this directorate.

Regards, Benoit (OPS AD)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: Multiple deviations with same target

2016-04-29 Thread Benoit Claise

On 4/29/2016 11:27 AM, Juergen Schoenwaelder wrote:

Right, I think it goes pretty much without saying, so this sentence is
>IMO unnecessary.
>

Apparently, this was not clear to every reader and hence the proposal
to add this sentence in order to make this explicit.

This is a always a good principle IMO.

Regards, Benoit

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

Re: [netmod] datastores Re: AD review draft-ietf-netmod-rfc6020bis-11 (part 1)

2016-04-27 Thread Benoit Claise


Tom,

I see that the definition of 'datastores' has cropped up in this AD
Review, as in the e-mail below.

Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
Call and redefines, or recreates, the term for us

A YANG datastore is a conceptual datastore that contains hierarchical
data defined in YANG data models.  It is what is referred in existing
RFCs as "NETCONF datastore".  However, as the same datastore is no
longer tied to NETCONF as a specific transport, the term "YANG
datastore" is deemed more appropriate.

I think that the concept of datastore has been troublesome to those
coming to YANG lately, such as openconfig and I2RS, and that this will
just muddy the waters more, especially as it is tucked away in an
Informational document.  If I2RS want to define such terminology, then
it should be in the I2RS Architecture or some such; but IMHO they should
not be defining YANG datastores at all.

Agreed.
Timely review as draft-ietf-i2rs-pub-sub-requirements is on the next 
IESG telechat.


Regards, Benoit


Tom Petch

- Original Message -
From: "Martin Bjorklund" <m...@tail-f.com>
To: <bcla...@cisco.com>
Cc: <netmod@ietf.org>
Sent: Thursday, April 21, 2016 2:58 PM
Subject: Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)



Benoit Claise <bcla...@cisco.com> wrote:

Hi Martin,

Thanks for engaging quickly.
[I removed the resolved entries]

Hi Benoit,

Benoit Claise <bcla...@cisco.com> wrote:

Dear all,

Here is part 1 of my AD review.

I found this useful:


http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/
rfc6020.txt=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.
txt

- Do we want to mention RESTCONF in the abstract? From the new

charter:

 The NETMOD working group has defined the data modeling

language

 YANG, which can be used to specify network management data

models

 that are transported over such protocols as NETCONF and

RESTCONF.

OLD:

 YANG is a data modeling language used to model configuration

data,

 state data, remote procedure calls, and notifications for

network

 management protocols like the Network Configuration Protocol
 (NETCONF).

NEW:

 YANG is a data modeling language used to model configuration

data,

 state data, remote procedure calls, and notifications for

network

 management protocols transported over such protocols as

Network

 Configuration Protocol (NETCONF) and RESTCONF. This document

specifies

 the YANG mappings to NETCONF.

The first paragraph in the introduction mentions other protocols;
RESCTONF and CoMI.  My personal opinion is that this is

sufficient,

but I'd like to hear what others think.

The current abstract doesn't even mention the mapping to NETCONF.

See Juergen's proposal, I think that one is better.


- Section 1.1
Since this document introduces the NETCONF mapping, the protocol
change must be included in section 1.1
Example: no NETCONF capability exchange in YANG 1.1, we use
exclusively the YANG library
Any other ones?

And this one?

NEW:

The following changes are done to the NETCONF mapping:

o  A server advertises support for YANG 1.1 modules by using ietf-
   yang-library [I-D.ietf-netconf-yang-library] instead of listing
   them as capabilities in the  message.


- Terminology:
   The following terms are defined in [RFC6241
   <https://tools.ietf.org/html/rfc6241>]:

 ...

 o  configuration datastore: a configuration datastore is an
instantiated data tree with configuration data

 o  datastore: an instantiated data tree

RFC6241 has different definition for "configuration datastore"

and

"datastore".
I would just provide the pointer to the RFC 6241 definitions.
If you intend to provide an adapted definition for the YANG

mappings,

then you should say so.

How about:

OLD:

 o  configuration datastore: a configuration datastore is an
instantiated data tree with configuration data

 o  datastore: an instantiated data tree

NEW:

 o  configuration datastore: When modelled with YANG, a

configuration

datastore is an instantiated data tree with configuration

data

 o  datastore: When modelled with YANG, an instantiated data

tree

This issue is with "The following terms are defined in [RFC6241]",

but

you re-define those terms.
So give a warning about the redefinition to the readers.

Yes, that's what my proposed text does.  It says that "datastore" is
defined in 6241, and when YANG is used, it means the instantiated data
tree.


- Section 4.1

 YANG models can describe constraints to be enforced on the

data,

 restricting the appearance or value of nodes based on the

presence or

 value of other nodes in the hierarchy.

I was looking for an example of appearance.
NEW?
 YANG models can describe constrai

Re: [netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)

2016-04-27 Thread Benoit Claise


On 4/27/2016 12:43 PM, Martin Bjorklund wrote:

Benoit Claise <bcla...@cisco.com> wrote:

Hi Martin,

Benoit Claise <bcla...@cisco.com> wrote:

Hi Martin,

Removed some extra ones on which we agree.
See in line.

- Terminology:
 The following terms are defined in [RFC6241
 <https://tools.ietf.org/html/rfc6241>]:

   ...

   o  configuration datastore: a configuration datastore is an
  instantiated data tree with configuration data

   o  datastore: an instantiated data tree

RFC6241 has different definition for "configuration datastore" and
"datastore".
I would just provide the pointer to the RFC 6241 definitions.
If you intend to provide an adapted definition for the YANG mappings,
then you should say so.

How about:

OLD:

   o  configuration datastore: a configuration datastore is an
  instantiated data tree with configuration data

   o  datastore: an instantiated data tree

NEW:

   o configuration datastore: When modelled with YANG, a configuration
  datastore is an instantiated data tree with configuration data

   o  datastore: When modelled with YANG, an instantiated data tree


This issue is with "The following terms are defined in [RFC6241]", but
you re-define those terms.

I don't think it is correct to say that we "re-define" these terms.
It sounds like we give the terms a different meaning.

Playing with words? :-)

   I agree that
the OLD text gave that impression, but I think the NEW proposed text
fixes this.

This does not work.

Reading the terminology ...

The following terms are defined in [RFC6241
<https://tools.ietf.org/html/rfc6241>]:

  o  configuration datastore: ...

  o  datastore: ...

... I will not even bother reading the definitions, because I know
them from 6241.
Doing this, I will not spot the subtle "different meaning" you
inserted in the definitions.

Ok, how about moving the specialized-meaning-text to its own paragraph:


   The following terms are defined in [RFC6241]:

o  configuration data

o  configuration datastore

o  datastore

o  running configuration datastore

o  state data

When modelled with YANG, a datastore is realized as an instantiated
data tree.

When modelled with YANG, a configuration datastore is realized as an
instantiated data tree with configuration data.

That works.

Regards, Benoit



/martin
.



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

[netmod] AD review draft-ietf-netmod-rfc6020bis-11 (part 1)

2016-04-19 Thread Benoit Claise

Dear all,

Here is part 1 of my AD review.

I found this useful:
http://tools.ietf.org/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc6020.txt=http://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt

- Do we want to mention RESTCONF in the abstract? From the new charter:

The NETMOD working group has defined the data modeling language
YANG, which can be used to specify network management data models
that are transported over such protocols as NETCONF and RESTCONF.

OLD:

YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network
management protocols like the Network Configuration Protocol
(NETCONF).

NEW:

YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network
management protocols transported over such protocols as Network
Configuration Protocol (NETCONF) and RESTCONF. This document specifies
the YANG mappings to NETCONF.

- Section 1.1
Can we want to stress the backwards incompatible changes from YANG version 1 in
a specific paragraph?
I see
o Changed the rules for the interpretation of escaped characters in
double quoted strings. This is an backwards incompatible change
from YANG version 1. A module that uses a character sequence that
is now illegal must change the string to match the new rules. See
Section 6.1.3
for details.

o An unquoted string cannot contain any single or double quote
characters. This is an backwards incompatible change from YANG
version 1.

There is section 12, but this is not exactly that.

Have we made an analysis of the 38 RFC-produced YANG modules? Any facing issues
with 1.1 compilation?

- Section 1.1
Since this document introduces the NETCONF mapping, the protocol change must be
included in section 1.1
Example: no NETCONF capability exchange in YANG 1.1, we use exclusively the
YANG library
Any other ones?

- Section 3

o anydata: A data node that can contain an unknown set of nodes that
can be modelled by YANG.

NEW

o anydata: A data node that can contain an unknown set of nodes that
can be modelled by YANG, except anyxml, but for which the data
model is not known at module design time.

- Terminology:
The following terms are defined in [RFC6241
]:

...

o configuration datastore: a configuration datastore is an
instantiated data tree with configuration data

o datastore: an instantiated data tree

RFC6241 has different definition for "configuration datastore" and "datastore".
I would just provide the pointer to the RFC 6241 definitions.
If you intend to provide an adapted definition for the YANG mappings, then you
should say so.

- Section 4.1

YANG models can describe constraints to be enforced on the data,
restricting the appearance or value of nodes based on the presence or
value of other nodes in the hierarchy.

I was looking for an example of appearance.
NEW?
YANG models can describe constraints to be enforced on the data,
restricting the appearance (for example, with the "when" statement)
or value of nodes based on the presence or value of other nodes in
the hierarchy.

- section 4.2.2.3, Container Nodes

A container is used to group related nodes in a subtree. A container
has only child nodes and no value. A container may contain any
number of child nodes of any type (leafs, lists, containers, leaf-
lists, and actions).

And notification, right? This should be added

container-stmt = container-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt]
*if-feature-stmt
*must-stmt
[presence-stmt
]

[config-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
*data-def-stmt
*action-stmt
*notification-stmt
"}") stmtsep

- Examples
I guess that no examples are supposed to compile, right?
Please add a sentence saying so.
When Andy's proposal will be ready (TAG: EXAMPLE-BEGINS => the YANG example
compiles, NO TAG: => no supposed to compile), this document will already be
compliant.

- Section 4.2.4

+-+-+
| Name|

Re: [netmod] Plans for draft-openconfig-netmod-model-catalog

2016-03-31 Thread Benoit Claise


On 3/30/2016 11:16 PM, Anees Shaikh wrote:
Lou, you may know but just FYI it sounds like Benoit and Carl were 
thinking about a hackathon project to populate a version of the 
catalog model with IETF modules 

yes, for the information we can extract from the YANG models.
Some other  info will need to be populated manually.

Regards, Benoit




On Wed, Mar 30, 2016 at 1:52 PM, Rob Shakir > wrote:


Hi Lou,

We’re currently working to rev the model that it describes - there
are some issues we’ve come across when trying to utilise it - and
define bundles of the models that it defines. I expect that once
this work has been done we’ll rev the draft.

None of the authors will be at the IETF mtg, so we did not request
any time to cover this — but this is an actively interesting, and
used model.

Cheers,
r.


On 30 March, 2016 at 10:48:05 AM, Lou Berger (lber...@labn.net
) wrote:


Authors,
Just wanted to check in with you on your plans for this document.
My understanding is that the WG expressed some interest in this work
when last presented. What are your plans for this work?

Thanks,
Lou (and 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

[netmod] Fwd: [RFC State] has been added to the RFC Editor database

2016-03-22 Thread Benoit Claise


Thank you all for this document.

Regards, B.


 Forwarded Message 
Subject: 	[RFC State]  has been 
added to the RFC Editor database

Date:   Tue, 22 Mar 2016 08:56:45 -0700
From:   rfc-edi...@rfc-editor.org
To: lho...@nic.cz
CC: 	netmod-...@ietf.org, netmod-cha...@ietf.org, 
rfc-edi...@rfc-editor.org, kwat...@juniper.net




Author(s),

We have received notice that your document draft-ietf-netmod-yang-metadata-07 
has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at


If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time.  Please
attach the file as draft-ietf-netmod-yang-metadata-07.xml, and specify
any differences between the approved I-D and the document that the XML
produces.  We recommend using xml2rfc v2  to create
your document.  See the RSE's message about the RFC Editor's transition to
xml2rfc v2 here
.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue.

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.



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

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

2016-03-22 Thread Benoit Claise


On 3/22/2016 9:47 AM, Ladislav Lhotka wrote:

On 22 Mar 2016, at 09:10, Juergen Schoenwaelder 
 wrote:

On Mon, Mar 21, 2016 at 06:10:57PM +0100, Eliot Lear wrote:

Hi Kent,

Thanks for the pointer.  The zeroconf draft is cool beans to be sure.
That describes an enrollment mechanism for devices that make use of
802.1AR.  Very ANIMAesque.  What I'm suggesting, and perhaps it's a bit
late for this draft, is just a statement in this draft along the lines
that "signing and verifying happens at the JSON level; see [ref] for how
to do it", and for extra credit an example would be exceedingly cool.
That way we as developers know what to do (again, I'm neither a JSON nor
netmod expert - just trying to make use of what's there for what I am
expert at (or so I think)).


This I-D is an object encoding specification. Why would this document
have to talk about possible object signatures?

+1

These issues are important but they should IMO be dealt with separately.

Ok. Where should it be described? RFC6087bis?

Regards, Benoit


Thanks, Lada


/js

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

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




.



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

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

2016-03-22 Thread Benoit Claise


Dear all,

Hi Stephen,

thanks for your comments, please see my responses inline.

Stephen Farrell  writes:


--
COMMENT:
--


- I would have thought that it'd be useful to point out any
issues with round-tripping, e.g. going from XML to JSON and
back to XML or vice-versa. But I didn't see any mention of
that. How come?

I believe fifth paragraph in sec. 3 is what you are asking for:

With the exception of anyxml and schema-less anydata nodes, it is
possible to map a JSON-encoded data tree to XML encoding as defined
in [I-D.ietf-netmod-rfc6020bis], and vice versa.  However, such
conversions require the YANG data model to be available.

Thanks.

- I'm not sure if anyone has considered XMLDSIG or use of JOSE
with YANG. If one did, then this kind of mapping would not
allow one to preserve digital signatures without a lot of
work. I assume that that's considered ok. (Which it can be,
depending on how one does object level security, if one does
object level security.)

I am not an expert on digital signatures and their representations, but
I'd say they could be modelled as YANG's "binary" type (and transferred
base64-encoded). This should work equally well in XML and JSON,
including round trips.

I skipped this point above for now as the thread goes on.



- It's not clear to me if the discussion of the secdir review
[1] concluded. It seemed to just stall. Is there more to be
said? (If so, be great if the shepherd would kick that
discussion.)

I don't have much more to say without seeing alternative proposals.
I re-reviewed the security directory review, and from my vantage point, 
I believe that Lada addressed the review.


Regards, Benoit


Lada


[1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html




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

[netmod] Fwd: Blog: YANG Data Models in the Industry: Current State of Affairs

2016-03-19 Thread Benoit Claise

Forwarded here, in case you don't look at the IETF-Discussion list

Regards, B.
 Forwarded Message 
Subject:Blog: YANG Data Models in the Industry: Current State of Affairs
Date:   Thu, 17 Mar 2016 07:49:32 -0700
From:   Benoit Claise <bcla...@cisco.com>
To: IETF-Discussion list <i...@ietf.org>

Dear all,

https://www.ietf.org/blog/2016/03/yang-data-models-in-the-industry-current-state-of-affairs/

Enjoy.

Regards, Benoit

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

[netmod] YANG check in idintis (was: New datatracker release: v6.16.0)

2016-03-05 Thread Benoit Claise


Dear all,

Now, idnits uses xym.py (to extract the YANG data models from the IETF 
drafts) and pyang (to validate them).

And there is also http://www.yangvalidator.com/
And also http://www.claise.be/IETFYANGPageCompilation.html

All this to help you with your YANG data models.

Regards, Benoit


 Forwarded Message 
Subject:New datatracker release: v6.16.0
Date:   Sat, 05 Mar 2016 07:02:15 -0800
From:   Henrik Levkowetz 
To: codespri...@ietf.org, i...@ietf.org, wgcha...@ietf.org



Hi,

This is an automatic notification about a new datatracker release,
v6.16.0, generated when running the mkrelease script.

Release notes:

ietfdb (6.16.0) ietf; urgency=medium

  **Yang validation of draft submissions**

  This release adds Yang validation of submitted drafts which contain
  Yang code, through a new plug-in architecture which makes it easy to
  addo other submission-time checkers and validators in the future.

  It also contains a few unrelated fixes and tweaks, as follows:

  * Fixed pyflakes complaints introduced with pyflakes 1.1.0

  * Refactored draft submission checks so that new checkers can be slotted
in through a configuration in settings.py.  Refactored the calling of
idnits to use the new API, and added a pyang validation check.

  * Added new entries to requirements.txt: pyang, xym, and jsonfield.  Sorted
the list.

  * Merged in [10880] from rjspa...@nostrum.com:
Only show the 'Upload new revision' button when the view will actually
let you upload a new revision.

  * Merged in [10862] from rjspa...@nostrum.com:
Group concluded working groups by area. Fixes #1670.

  * Merged in [10839] from hous...@vigilsec.com:
Added test for proper eneration of the approval message with and without
an RFC Editor Note.  Tweaked RFC Editor note display template.

 -- Henrik Levkowetz   05 Mar 2016 06:27:10 -0800

The new version is available for installation through SVN checkout, with
  'svn checkout https://svn.tools.ietf.org/svn/tools/ietfdb/tags/6.16.0'

For development, check out the new development version instead:
  'svn checkout 
https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.16.1.dev0'

Regards,

Henrik
(via the mkrelease script)

.



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

Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]

2016-03-02 Thread Benoit Claise


On 2/26/2016 1:13 PM, Acee Lindem (acee) wrote:

Hi Benoit, Lada,

On 2/26/16, 3:32 AM, "netmod on behalf of Benoit Claise (bclaise)"
<netmod-boun...@ietf.org on behalf of bcla...@cisco.com> wrote:


Hi Lada,


Hi Benoit,

this was discussed a while ago in this thread:

https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I

tl;dr: The WG decision then was to introduce a new type in
ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the
semantics of an IPv4 address - it is an uint32 number that's expressed
in the dotted quad format, which is what most router platforms accept as
routerID via CLI.

 From what I understand below, this is not an acceptable solution.
I'm sure the routing experts will confirm this.

At least for the OSPF Router ID (RFC 2328) and the BGP Identifier (RFC
4271), the dotted-quad type matches the semantics of the protocols. The
value is not necessarily a routable address and solely a unique 32-bit
identifier within the protocol routing domain that is commonly expressed
in dotted quad format. What is the problem with using this YANG type?

uint32 sure, but what is the conclusion regarding dotted-quad?
On one side, I hear: dotted-quad is suitable because it's uint32 and 
does NOT have the semantics of an IPv4 address.
On the other side, I hear: we should not even display the identifier as 
an IPv4 address.


The routing experts should tell us if the dotted-quad type is appropriate.

Regards, Benoit


Thanks,
Acee


Regards, Benoit

Lada


On 25 Feb 2016, at 13:41, Benoit Claise <bcla...@cisco.com> wrote:

Dear all,

Sorry for the delay (mix of vacation and business travel).

Let me try to summarize the situation as I see it:
- From the routing RFCs, BGP Identifier, OSPF router ID, TE
identifier, and LSR identifiers are all an unsigned integers.
- We need consistency for the router ID and identifier in YANG
leaf/typedef
- The OSPF MIB module has defined
RouterID ::= TEXTUAL-CONVENTION
 STATUS   current
 DESCRIPTION
"A OSPF Router Identifier.
 Note that the Router ID, in OSPF, has the same format
 as an IP address, but identifies the router independent
 of its IP address."
 SYNTAX   IpAddress


ospfRouterId OBJECT-TYPE
 SYNTAX   RouterID
 MAX-ACCESS   read-write
 STATUS   current
 DESCRIPTION
"A 32-bit integer uniquely identifying the
router in the Autonomous System.
By convention, to ensure uniqueness, this
should default to the value of one of the
router's IP interface addresses.

As Adrian mentioned: it is NOT an IP address but the MIB module uses
the notational formatting of n IP address for display purposes.
- An IPv4 address as OSPF router ID doesn't make sense in an IPv6
environment

Based on this, I believe that:
- We must not associate an IP address semantic with the router ID
- Based on Brian's feedback (which I agree with) "As long as the YANG
module does not specify a format that makes the routerID display like
an IPv4 address", it was probably a mistake to have defined RouterID as
IpAdress in OSPF MIB module.
- Interestingly,
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains:

   grouping router-id {
 description
   "This grouping provides router ID.";
 leaf router-id {
   type yang:dotted-quad;
   description
 "A 32-bit number in the form of a dotted quad that is used
by
  some routing protocols identifying a router.";
   reference
 "
RFC 2328
: OSPF Version 2.";
 }
   }

This should be an uint32 number.
- An union-based solution is a bad compromise
  From draft-raza-mpls-ldp-mldp-yang-02
   leaf lsr-id {
 type union {
   type yang:dotted-quad;
   type uint32;
 }
 description "LSR ID.";



Since the question was asked: as AD, I would support uint32 everywhere.

Now, practically, how to move forward?
- Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with
the uint32 modification),
- Or you create a "Common Routing YANG Data Types", similarly to RFC
6991 including the router IDs. I see already many typedef in
draft-raza-mpls-ldp-mldp-yang-02
- Or you define you own types in your own draft

But, if we have agreement on the uint32, let's document this now
somewhere/somehow, and let's not revisit this on regular basis (yes, I
see it coming...)
A few lines of explanation in the draft would already help for
example, in an operational section, explaining to people the mapping of
the MIB OSPF RouterID to the YANG object

Regards, Benoit

Hi Adrian,

On 2/16/16 7:53 AM, Adrian Farrel wrote:


Hi Brian,

I said I wasn't going to participa

Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]

2016-02-26 Thread Benoit Claise


Hi Lada,


Hi Benoit,

this was discussed a while ago in this thread:

https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I

tl;dr: The WG decision then was to introduce a new type in ietf-inet-types, namely 
"dotted-quad", that explicitly does NOT have the semantics of an IPv4 address - 
it is an uint32 number that's expressed in the dotted quad format, which is what most 
router platforms accept as routerID via CLI.


From what I understand below, this is not an acceptable solution.
I'm sure the routing experts will confirm this.

Regards, Benoit


Lada


On 25 Feb 2016, at 13:41, Benoit Claise <bcla...@cisco.com> wrote:

Dear all,

Sorry for the delay (mix of vacation and business travel).

Let me try to summarize the situation as I see it:
- From the routing RFCs, BGP Identifier, OSPF router ID, TE identifier, and LSR 
identifiers are all an unsigned integers.
- We need consistency for the router ID and identifier in YANG leaf/typedef
- The OSPF MIB module has defined
RouterID ::= TEXTUAL-CONVENTION
STATUS   current
DESCRIPTION
   "A OSPF Router Identifier.
Note that the Router ID, in OSPF, has the same format
as an IP address, but identifies the router independent
of its IP address."
SYNTAX   IpAddress


   ospfRouterId OBJECT-TYPE
SYNTAX   RouterID
MAX-ACCESS   read-write
STATUS   current
DESCRIPTION
   "A 32-bit integer uniquely identifying the
   router in the Autonomous System.
   By convention, to ensure uniqueness, this
   should default to the value of one of the
   router's IP interface addresses.

As Adrian mentioned: it is NOT an IP address but the MIB module uses the 
notational formatting of n IP address for display purposes.
- An IPv4 address as OSPF router ID doesn't make sense in an IPv6 environment

Based on this, I believe that:
- We must not associate an IP address semantic with the router ID
- Based on Brian's feedback (which I agree with) "As long as the YANG module does 
not specify a format that makes the routerID display like an IPv4 address", it was 
probably a mistake to have defined RouterID as IpAdress in OSPF MIB module.
- Interestingly, https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 
contains:

  grouping router-id {
description
  "This grouping provides router ID.";
leaf router-id {
  type yang:dotted-quad;
  description
"A 32-bit number in the form of a dotted quad that is used by
 some routing protocols identifying a router.";
  reference
"
RFC 2328
: OSPF Version 2.";
}
  }

This should be an uint32 number.
- An union-based solution is a bad compromise
 From draft-raza-mpls-ldp-mldp-yang-02
  leaf lsr-id {
type union {
  type yang:dotted-quad;
  type uint32;
}
description "LSR ID.";



Since the question was asked: as AD, I would support uint32 everywhere.

Now, practically, how to move forward?
- Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with the uint32 
modification),
- Or you create a "Common Routing YANG Data Types", similarly to RFC 6991 
including the router IDs. I see already many typedef in draft-raza-mpls-ldp-mldp-yang-02
- Or you define you own types in your own draft

But, if we have agreement on the uint32, let's document this now 
somewhere/somehow, and let's not revisit this on regular basis (yes, I see it 
coming...)
A few lines of explanation in the draft would already help for example, in an 
operational section, explaining to people the mapping of the MIB OSPF RouterID 
to the YANG object

Regards, Benoit

Hi Adrian,

On 2/16/16 7:53 AM, Adrian Farrel wrote:


Hi Brian,

I said I wasn't going to participate in this discussion :-)


Nice try. ;)



I should not respond to questions that I don't fully understand, but:

the BGP Identifier is an unsigned integer
the OSPF router ID is an unsigned integer


I assume the above is based on the YANG definition of OSPF routerID. RFC
4750 says the routerID is an IPv4 address. Is that an issue?


To quote from 4750...

RouterID ::= TEXTUAL-CONVENTION
STATUS   current
DESCRIPTION
   "A OSPF Router Identifier.
Note that the Router ID, in OSPF, has the same format
as an IP address, but identifies the router independent
of its IP address."
SYNTAX   IpAddress

So it explicitly says it is NOT an IP address but the MIB module uses the 
notational formatting of n IP address for display purposes.

I think this is done because the router ID is often chosen to be an IP address 
of the router, and because it is easier for humans to deal with a.b.c.d wher

[netmod] Both draft-ietf-netmod-yang-metadata and draft-ietf-netmod-yang-json are now moved IETF LC ...

2016-02-24 Thread Benoit Claise


Dear all,

... thanks to the new draft versions posted today.
I thought I would let you know.

Regards, Benoit

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

Re: [netmod] AD review draft-ietf-netmod-yang-metadata-03

2016-02-24 Thread Benoit Claise


On 2/24/2016 11:16 AM, Juergen Schoenwaelder wrote:

On Wed, Feb 24, 2016 at 10:34:36AM +0100, Benoit Claise wrote:

[...]


"The 'md:annotation' statement can appear only at the top level of a YANG
module."

I don't understand what the top is? You mean, after the import statements.
Should pyang check this? If yes, how?

I think the intention was to say at the 'top-level of the schema tree'.
It does not have to be right after the imports.

That would clarify. Thanks.

Regards, Benoit


/js



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

[netmod] Terminology => YANG module versus YANG data model versus YANG model : please don't use "YANG model" any longer

2016-02-24 Thread Benoit Claise


Dear all,

Reviewing some NETMOD documents these days, I realized that we're 
sometimes not consistent regarding terminology: YANG module, YANG data 
model, YANG model.


Example:
All three can be found in 
https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-11.txt and 
https://tools.ietf.org/html/rfc6244
YANG data model and YANG module can be found in 
https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-03 and 
https://www.ietf.org/id/draft-ietf-netmod-yang-json-07.txt


Asking advice from the YANG doctors, here are their conclusions:

   RFC 6020 defines:

   o  data model: A data model describes how data is represented and
  accessed.

   o  module: A YANG module defines a hierarchy of nodes that can be
  used for NETCONF-based operations.  With its definitions and the
  definitions it imports or includes from elsewhere, a module is
  self-contained and "compilable".

   Both terms 'YANG data model' and 'YANG module' mean slightly
   different things and both are valid. (I think a larger YANG data model
   can consist of multiple YANG modules and YANG submodules, RFC 7407
   would be an example.)

   The term 'YANG models' is likely simply an abbreviation of 'YANG data
   models' and we could get rid of this by not using an abbreviation.

Let's apply this rule from now: no more "YANG models".

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

[netmod] Welcome Lou Berger as NETMOD co-chair

2016-02-18 Thread Benoit Claise


Dear all,

I want to be the first one to thank Lou Berger who accepted to become 
the NETMOD co-chair, replacing Tom Nadeau.  Lou has been
working on YANG for some time now, including his work on the routing 
YANG design team.


Recently, I asked Lou and Acee to produce a comparison of the three 
operational state proposals (See 
https://www.ietf.org/mail-archive/web/netmod/current/msg14585.html). 
This work will be very helpful to the WG, and will be sent to the 
mailing list soon.


We will be working on the chair transition, which might last a couple of 
weeks, before installing Lou on the co-chair seat in Bueno-Aires.


Here is the summary of the situation:
Kent Watsen, co-chair, with a primary focus on the YANG language
Lou Berger, co-chair, with a primary focus on the YANG data models
Jürgen Schönwälder, co-chair till YANG 1.1 is complete

Regards, Benoit

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

Re: [netmod] Secdir review of draft-ietf-netmod-opstate-reqs-04

2016-02-18 Thread Benoit Claise


Tom, Kent, WG,

Can you please engage with Tero.
I would like to put this document on the telechat in 2 weeks from now.

Regards, Benoit

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is terminology and requirements document for handling operational
state. As such the security considerations section cannot have very
detailed problems, but it does properly point out that while
configuration is being applied the device might be in inconsistent
state, and that might cause security issues.

It does not say anything about how the configuration requests needs to
be secured, but I assume that is more in to the actual protocol RFC
issue, than this document.

It does not also comment anything about whether the different states
(intended configuration, applied configuration and derivative state)
should have different security policies to applied to them, i.e.
it does say that it should be possible to retrieve only applied
configuration or only derived state, but does not mention should there
also be different security policies to do those operations. In some
cases the derivative state might contain things like traffic keys
negotiated during the protocol runs, or traffic information aabout
flows passing the devices (privacy issues), so derivative state might
be more sensitive than the actual applied configuration.

Outside the security considerations section the requirement which
says:

A.  A server MUST support only synchronous configuration
operations, or only asynchronous configuration operations, or
both synchronous and asynchronous configuration operations on
a client-specified per-operation basis.

is bit funny, as it effectively says that either syncronous or
asyncronous MUST be supported and both may be supported, but I do not
understand what the "client-specified per-operation basis" is meaning
for the requirement for server.

Client cannot really require server to change its IMPLEMENTATION on
per-operation basis (i.e., client 1 requesting that server MUST
support only asyncronous operations, and client 2 requesting that
server MUST support only syncronous operations).

Client can use either syncronous or asyncronous if both are supported
by the server, and I assume this is trying to say that client can
select syncronous/asyncronous operation per-operation basis, but when
you are talking about that "A server MUST support ..." I do not think
it is ok to requiring that on a client-specified way.

I.e. proper way would be to say that if server supports both, it MUST
allow client to select which method is used on per-operation basis.


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

[netmod] Fwd: [OPS-DIR] OPS-DIR review of draft-ietf-netmod-opstate-reqs-04

2016-02-18 Thread Benoit Claise


Tom, Kent, WG,

Can you please engage with Al.
Here is his OPS DIR review.

Regards, Benoit


 Forwarded Message 
Subject:[OPS-DIR] OPS-DIR review of draft-ietf-netmod-opstate-reqs-04
Date:   Wed, 3 Feb 2016 16:18:28 -0500
From:   MORTON, ALFRED C (AL) 
To: 	draft-ietf-netmod-opstate-r...@ietf.org 
, ops-...@ietf.org 
, ops-...@tools.ietf.org 

CC: amcla...@cisco.com 



sorry, there was a stray character in 'draft-ietf-netmod-opstate-r...@ietf.org''
all of us are on OPS-DIR list (not trying to straighten this out again).

(resending because the HTML-ized version "Email to authors link"
still uses @tools.ietf.org = bounce)

'Hi Kent and Tom, and ops-dir,

It's time for your OPS-DIR review and I'm "it".
As Warren always says, "Be not afraid...".

I fully support the purpose of your draft. These are
important concepts to define unambiguously and
some useful requirements to see implemented.
I'll make a few suggestions for clarification below,
and I trust you'll develop acceptable wording
where I haven't fully understood your intentions.

I'm not aware of any IPR associated with the points
I seek to clarify.

regards,
Al
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Section 2

   Asynchronous Configuration Operation:  A configuration request to
   update the running configuration of a server that is applied
   asynchronously with respect to the client request.

"running configuration" is used in this definition, and again in
Synchronous Configuration Operation without being defined.
Is this a subset of the "Operational State" ?


Section 3  Requirements

"   1.  Ability to interact with both intended and applied configuration"

What entity is this requirement for?  Is it:
1. The Client MUST possess the ability to interact with both...
or BOTH Client and Server?


Later in Section 3

"   3.  Separation of the applied configuration and derived state aspects
   of operational state; ability to retrieve them independently and
   together

   A.  Be able to retrieve only the applied configuration aspects of
   operational state

   B.  Be able to retrieve only the derived state aspects of
   operational state

   C.  Be able to retrieve both the applied configuration and
   derived state aspects of operational state together"

This seems to be a set of requirements for BOTH the Client and the Server,
worded from the Point-of-view of the Client ("retrieve").
Can you add the Client and Server here, using RFC 2119 terms?

suggest:
 The Client MUST:
   A.  Be able to retrieve only the applied configuration aspects of...
 


Later in Section 3

"   4.  Ability to relate configuration with its corresponding
   operational state
  A. ... "

These are Server requirements? One or both the entities gets MUST or SHOULD...
(These requirements (4) were not completely clear to me.)

___
OPS-DIR mailing list
ops-...@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
.



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

[netmod] AD review: draft-ietf-netmod-yang-json-07

2016-02-03 Thread Benoit Claise


Dear all,

I understood from the chairs that draft-ietf-netmod-yang-json is now 
ready and that the write-up will be completed end of this week.

In order to speed up the publication, here is my AD review.

- Editorial:

   This document defines encoding rules for representing configuration,
   state data, RPC operation or action input and output parameters, and
   notifications defined using YANG as JavaScript Object Notation (JSON)
   text.

"RPC operation or action input and output parameters"
", or ... and, " it's always complicated.
Why not only "RPC operation or action"?

At the very minimum "input and output parameters" to "input/output 
parameters"


Same remark for section 1.1

   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.

If you want to extend, also fine.

   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation input and output parameters, action input and output
   parameters, and event notifications.

Btw, "RPC", "action" and "input and output parameters" are only 
mentioned in the abstract and this introduction, not anymore in the body 
of the document. There is nothing specific to these worth noting? Not 
even an example?


- Editorial

In the introduction, you might want to complete the last sentence

NEW:
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159 ].

NEW:
   The specification of YANG 1.1 data modelling language
   [I-D.ietf-netmod-rfc6020bis 
] defines only XML encoding for data

   instances, i.e., contents of configuration datastores, state data,
   RPC operation or action input and output parameters, and event
   notifications.  The aim of this document is to define rules for
   encoding the same data as JavaScript Object Notation (JSON)
   text [RFC7159 ], most precisely the 
Internet JSON (I-JSON) restricted
   profile [RFC7493 ].


-
section 2:

   The following terms are defined in [I-D.ietf-netmod-rfc6020bis 
]:

  ...

   o  identity,

There is no identity definition in the RFC 6020 terminology section.
Are you referring to the identity statement, 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.18 ?


- Editorial.

OLD:
An object member name MUST be in one of the following forms:
NEW:
A JSON object member name MUST be encoded in one of the following forms:


-
  module foomod {

 namespace"http://example.com/foomod;;

 prefix "foo";

 container top {
   leaf foo {
 type uint8;
   }
 }
   }

Use "example-" in the module name, as mentioned 
inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:

   Example modules are non-normative, and SHOULD be named with the
   prefix "example-".

Same remark for module barmod (and btw, pay attention to the "import 
foomod") and module exmod



- Editorial (Appendix A):

OLD:
   The "if-mib" feature defined in the "ietf-
   interfaces" module is considered to be active.

NEW:
   The "if-mib" feature defined in the "ietf-
   interfaces" module is supported.

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

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

2016-02-03 Thread Benoit Claise

Hi Lada,

Thanks for the quick reply.

Hi Benoit,

thank you for the review, please see my responses inline.

Benoit Claise <bcla...@cisco.com> writes:

Dear all,

I understood from the chairs that draft-ietf-netmod-yang-json is now
ready and that the write-up will be completed end of this week.
In order to speed up the publication, here is my AD review.

- Editorial:

This document defines encoding rules for representing configuration,
state data, RPC operation or action input and output parameters, and
notifications defined using YANG as JavaScript Object Notation (JSON)
text.

"RPC operation or action input and output parameters"
", or ... and, " it's always complicated.
Why not only "RPC operation or action"?

Because we aren't encoding operations, just their parameters.

Good point.

At the very minimum "input and output parameters" to "input/output
parameters"

OK, so how about using just "parameters of RPC operations or actions" in
the abstract, and "input/output parameters of RPC operations or actions"
elsewhere?

Sure.

Same remark for section 1.1

The specification of YANG 1.1 data modelling language
[I-D.ietf-netmod-rfc6020bis
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#ref-I-D.ietf-netmod-rfc6020bis>]
defines only XML encoding for data
instances, i.e., contents of configuration datastores, state data,
RPC operation or action input and output parameters, and event
notifications.

If you want to extend, also fine.

The specification of YANG 1.1 data modelling language
[I-D.ietf-netmod-rfc6020bis
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#ref-I-D.ietf-netmod-rfc6020bis>]
defines only XML encoding for data
instances, i.e., contents of configuration datastores, state data,
RPC operation input and output parameters, action input and output
parameters, and event notifications.

Btw, "RPC", "action" and "input and output parameters" are only
mentioned in the abstract and this introduction, not anymore in the body
of the document. There is nothing specific to these worth noting? Not
even an example?

This document is about encoding YANG data nodes, and the rules are the
same for any data tree.

Not worth mentioning something such as
" There is nothing specific to input and output parameters compared to
any other data tree..."?

Encoding of operations or notifications is a
subject for a protocol spec, and RESTCONF does provide examples.

- Editorial

In the introduction, you might want to complete the last sentence

NEW:
The specification of YANG 1.1 data modelling language
[I-D.ietf-netmod-rfc6020bis
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07#ref-I-D.ietf-netmod-rfc6020bis>]
defines only XML encoding for data
instances, i.e., contents of configuration datastores, state data,
RPC operation or action input and output parameters, and event
notifications. The aim of this document is to define rules for
encoding the same data as JavaScript Object Notation (JSON)
text [RFC7159 <https://tools.ietf.org/html/rfc7159>].

I would say that for the introduction the more general term (JSON) is
appropriate, the reasons for sticking to I-JSON are explained later. In
fact, this document specifies a profile that's even more restricted than
I-JSON.

Fair enough.

-
section 2:

The following terms are defined in [I-D.ietf-netmod-rfc6020bis
<https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07#ref-I-D.ietf-netmod-rfc6020bis>]:
...

o identity,

There is no identity definition in the RFC 6020 terminology section.

Maybe it is an omission in 6020bis?

Ok, let's fix it in 6020bis then.

-
module foomod {

namespace"http://example.com/foomod;;

prefix "foo";

container top {
leaf foo {
type uint8;
}
}
}

Use "example-" in the module name, as mentioned
inhttps://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-05:

Example modules are non-normative, and SHOULD be named with the
prefix "example-&

Re: [netmod] AD review: draft-ietf-netmod-yang-json-07

2016-02-03 Thread Benoit Claise


Hi Lada,



I agree with Juergen that 6087bis should distinguish between complete
example modules and short module snippets that are used for explaining a
certain YANG language or encoding issue. If you look at this particular
example, then changing the JSON document on p. 6 to

{
  "example-foomod:top": {
"foo": 54,
"example-barmod:bar": true
  }
}

would IMO just add noise and blur the message the example is supposed to
convey.

So please fix the text in 6087bis.
Until it's done, I'll stick to the current rule.

I don't want to be excessively bureaucratic but, strictly speaking, current 
rules are those of RFC 6087 that contains no such requirement, so we should be 
OK for now. And I think there is enough consensus

so Jürgen and you?

to change the corresponding 6087bis text - after all, 6020bis also has example modules 
whose names don't start with "example-".
I'll still have to review it and that will be one of my comments, for 
sure. Consistency first.


Regards ,Benoit

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

Re: [netmod] [yang-doctors] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt

2016-02-02 Thread Benoit Claise


Dear all,

I started the IETF last call process on draft-ietf-netmod-opstate-reqs-04.

Regards, Benoit

[Speaking as co-chair]

Benoit,

I believe the document is now ready for your AD review.

—Tom




On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen  wrote:


[As a contributor]

This update contains the following changes:


1) removed “(see term)” throughout

2) moved 2nd-half of the Asynchronous Configuration Operation term to new 
requirement 2-B

3) moved the Backwards Compatibility to new requirement 5

4) made some may/MAY/SHOULD/MUST changes (as discussed on list)

5) replaced map/mapping with relate/relationships


Please see the diff for details.

Thanks,
Kent





On 1/22/16, 8:29 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language Working Group 
of the IETF.

   Title   : Terminology and Requirements for Enhanced Handling of 
Operational State
   Authors : Kent Watsen
 Thomas Nadeau
Filename: draft-ietf-netmod-opstate-reqs-04.txt
Pages   : 6
Date: 2016-01-22

Abstract:
  This document primarily regards the difference between the intended
  configuration and the applied configuration of a device and how
  intended and applied configuration relate to the operational state of
  a device.  This document defines requirements for the applied
  configuration's data model and its values, as well as for enabling a
  client to know when a configuration has been fully applied or not,
  how to access operational state, and how to relate intended
  configuration nodes to applied configuration and derived state nodes.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04


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

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

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

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

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


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

Re: [netmod] [yang-doctors] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt

2016-01-26 Thread Benoit Claise


Thanks Tom,

I believe the draft is good to go to IETF LC.
Once I have the write-up, I will progress it.

Regards, Benoit

[Speaking as co-chair]

Benoit,

I believe the document is now ready for your AD review.

—Tom




On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen  wrote:


[As a contributor]

This update contains the following changes:


1) removed “(see term)” throughout

2) moved 2nd-half of the Asynchronous Configuration Operation term to new 
requirement 2-B

3) moved the Backwards Compatibility to new requirement 5

4) made some may/MAY/SHOULD/MUST changes (as discussed on list)

5) replaced map/mapping with relate/relationships


Please see the diff for details.

Thanks,
Kent





On 1/22/16, 8:29 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language Working Group 
of the IETF.

   Title   : Terminology and Requirements for Enhanced Handling of 
Operational State
   Authors : Kent Watsen
 Thomas Nadeau
Filename: draft-ietf-netmod-opstate-reqs-04.txt
Pages   : 6
Date: 2016-01-22

Abstract:
  This document primarily regards the difference between the intended
  configuration and the applied configuration of a device and how
  intended and applied configuration relate to the operational state of
  a device.  This document defines requirements for the applied
  configuration's data model and its values, as well as for enabling a
  client to know when a configuration has been fully applied or not,
  how to access operational state, and how to relate intended
  configuration nodes to applied configuration and derived state nodes.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04


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

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

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

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

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


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

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

2016-01-26 Thread Benoit Claise


I'm not aware of any IPR.

Regards, Benoit

This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.

Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to this
email explicitly regardless of whether or not you are aware of any relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from each
author and contributor.

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

Thank you,

Kent and Tom, NETMOD WG Chairs

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



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

[netmod] AD review: draft-ietf-netmod-opstate-reqs

2016-01-12 Thread Benoit Claise


Dear all,

I know that this draft is not yet on my table, but in order to speed up 
the process, I read v3.


- Editorial: I see many instances of (see term) or (see terms).
This doesn't add any value IMO.
If there are some chance for misinterpretation of those terms, 
capitalize the terms specified in the terminology section.


- Any reason why the "backwards compatibility" (section 3) is not 
numbered as a requirement in section 4?  I.e. a new requirement 5. Or is 
it because it's a special requirement?
Numbering all the requirements might ease the comparison of the 3 
different proposed solutions.


- There is a requirement in asynchronous configuration operations 
definition:

   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.

Why isn't it a numbered requirement in section 4?

Regards, Benoit

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

Re: [netmod] applied configuration and system-controlled entries

2016-01-12 Thread Benoit Claise


Lada,

On 08 Jan 2016, at 16:20, Robert Wilton  wrote:

Hi Lada,

On 08/01/2016 12:30, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada,

I think that requirement 1D is fairly key to what is being asked for
here to allow both the user and system to easily relate between what the
operator desires and what configuration the system is actually using,

In a way, system-controlled interfaces are default entries in the
interface list - and the system can certainly be using interfaces with
no configuration installed by NETCONF/RESTCONF clients.


so I wouldn't be particularly keen on loosening this requirement.

OK, but then IMO this intended-applied dualism is of limited
utility. For many systems or services, asynchronicity is not an option,
or isn't important.

I don't really agree.   I think that this is plausibly important to anyone who 
wants to manage network devices in an automated way.

I am currently working with my colleagues on two use cases:

1. RESTCONF interface to a DNS server that will cover the daemon configuration, 
policies for zone signing, and zone provisioning.

2. RESTCONF interface to an OpenWRT-based router.

For neither of them applied configuration seems to add any value.

Fair enough. However, it doesn't entail that the opstate has no value 
for anybody.

Some operators have spoken loud and clear.

Regards, Benoit

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

Re: [netmod] [yang-doctors] Resigning Chair Position

2016-01-11 Thread Benoit Claise


Thanks Tom for your years of service in this very important WG.

Joel and I are working on a replacement plan.

Regards, Benoit


I am writing to the NETMOD WG to inform you all that I will be 
resigning my position as co-chair.  I will remain on as co-chair and continue 
my duties until Benoit finds a suitable replacement, which he tells me will not 
be too long.  It has been a challenge and pleasure serving the community as 
co-chair over the past 2 years. I learned a lot in this role, and I hope I 
served the community well.  I hope to continue working with many of you in the 
capacity of an individual contributor in and around the area of Yang and model 
creation.

Cheers,

—Tom

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

2015-12-22 Thread Benoit Claise


Jürgen,

On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:


I hope that nobody disagrees that the operational state design and how
to structure the models are the two blocking factors to publish YANG
models. If you disagree or don't see this, let me know, I should
communicate better.

Even if it may spoil your day, I disagree that there is a blocking
factor that should stop us from publishing models.
Interestingly, I received that feedback again recently, this time from 
the OSPF and ISIS YANG model authors.

There seem to be
ways to address the requirements without having to block all work or
to redo what that we have published.

That's my hope too.

But sure, if you make it a
blocking factor, it will be one.

I'll chose to ignore this last sentence.

Regards, Benoit



I hope that nobody really believes that because some people in IETF (or
in any other SDOs) thinks that what those operators want is a bad idea,
those operators will not get what they request/pay for from their suppliers.

To be fair, those operators also tell us that they use protocols that
are not IETF protocols and it remains somewhat unclear what those
protocols are we are expected to optimize data model solutions for.

/js



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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

2015-12-21 Thread Benoit Claise

Andy,

On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen > wrote:

Hi Robert,

I agree that -01 doesn’t add much on top of -00.  This is expected
as we’re in the fit and finish phase.  If you want to help finish
the draft, then please consider responding to one of these threads:

http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html
(re: rollback-on-error)
http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html
(re: model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility
requirement, please note that what was written here is still in
effect:
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.
Note that no objections have been raised yet, so this will likely
happen.

2. Regarding adding an applicability statement, there is currently
only one voice asking for it, which isn’t enough to warrant a change.

I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a 
document.
I hope that nobody disagrees that the operational state design and how 
to structure the models are the two blocking factors to publish YANG 
models. If you disagree or don't see this, let me know, I should 
communicate better.
I hope that nobody disagrees that there is a problem to be solved (a 
problem statement extracted from 
https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/). We 
havea bunch of operators , 
coming to the IETF, telling us they have a problem. So there is a problem.
I hope that nobody really believes that because some people in IETF (or 
in any other SDOs) thinks that what those operators want is a bad idea, 
those operators will not get what they request/pay for from their suppliers.

Regards, Benoit (OPS AD)

Thanks,
Kent

Andy

On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
 on
behalf of rwil...@cisco.com > wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org "
>>> Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any
clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate
aware, and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the
very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support
opstate aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good*
thing to me.
>>
>>>   - Having a server side configuration knob to control the
behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to
prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some
(perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios,
and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements
can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use.  This really doesn't appear to be
>unreasonable request to me, and if I was writing to a network
>manageability API then I would choose to use opstate because I
perceive
>that it is a more robust and easier to use API.  The counter
arguments
>appear to be that it is too hard for devices to provide this
>information, and that the operators have historically managed
without it.
>
>However, I think that several things have

Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft

2015-12-16 Thread Benoit Claise


Hi Tom,

Good question. I should have made it clear. Sorry.
"While I understand the concern of work prioritization, one of the 
issues in NETMOD is that we need to grow the number of people involved 
in participating/editing/reviewing, and I'm happy to see Dan and Jimmy 
taking the lead here." This remark is done as OPS AD.


Also, I discussed, as OPS AD, with the chairs, having an identity YANG 
model design team in the past.

However, my "support" below is an individual.

Regards, Benoit

On Dec 16, 2015:3:55 AM, at 3:55 AM, Benoit Claise <bcla...@cisco.com> wrote:

Dear all,

On 15 Dec 2015, at 13:34, Nadeau Thomas <tnad...@lucidvision.com> wrote:


NETMOD:

The Broadband Forum and the members of the design team who worked on the
IETF Entity module have asked that the working group considerthe ietf-entity 
YANG module
(currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which 
is
still in individual draft status) as a working group item.

Should we move to adopt draft-entitydt-netmod-entity 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.

Support.

I would strongly prefer to finish the existing items first, or at least the 
critical ones on which other work depends. Adding more items would mean that 
both old and new items receive less attention on the average. We already have 
at most one or two reviews per WGLC, and this is IMO insufficient.

While I understand the concern of work prioritization, one of the issues in 
NETMOD is that we need to grow the number of people involved in 
participating/editing/reviewing, and I'm happy to see Dan and Jimmy taking the 
lead here.

Regards, Benoit

Are you speaking as AD or as an individual?

—Tom



Lada


—Tom

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

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




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

.



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

Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft

2015-12-16 Thread Benoit Claise


Dear all,

On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:


NETMOD:

The Broadband Forum and the members of the design team who worked on the
IETF Entity module have asked that the working group considerthe ietf-entity 
YANG module
(currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which 
is
still in individual draft status) as a working group item.

Should we move to adopt draft-entitydt-netmod-entity 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.

Support.

I would strongly prefer to finish the existing items first, or at least the 
critical ones on which other work depends. Adding more items would mean that 
both old and new items receive less attention on the average. We already have 
at most one or two reviews per WGLC, and this is IMO insufficient.
While I understand the concern of work prioritization, one of the issues 
in NETMOD is that we need to grow the number of people involved in 
participating/editing/reviewing, and I'm happy to see Dan and Jimmy 
taking the lead here.


Regards, Benoit


Lada


—Tom

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

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




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


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

[netmod] operational state: next step

2015-12-15 Thread Benoit Claise


Dear all:

Background: the operational state is a blocking factor for the 
publication of the YANG models. For example, I've been told that the 
ISIS and OSPF models are ready, pending resolution on the operational state.


Let me try to clarify the situation and the next steps.

During the NETMOD WG meeting in Yokohama, Kent, as a chair, did a hum 
related to draft-ietf-netmod-opstate-reqs-00 

As explained during the previous operational state-related interim 
meetings, we wanted to extract the requirements.
Kent carefully asked: "humm if in you are in favor of the definitions of 
the requirements", meaning: have we correctly documented the requirements?
draft-ietf-netmod-opstate-reqs-01 
 will 
be published soon, with no changes to the requirements scope, but only 
clarifying text and editorial changes.

Once published, a WGLC will follow, with hopefully a quick publication.

Now, what is the next step regarding the solution?
As mentioned during the NETMOD meeting in Japan, there are currently 3 
proposals:
1. openconfig draft-openconfig-netmod-opstate-01 

2. based on the data stores draft-kwatsen-netmod-opstate-00 

3. based on the metadata draft-wilton-netmod-opstate-yang-01 



During the NETMOD WG meeting, Kent asked the sense of the room on which 
solution the community favored. There was an advantage for solution 2.

However, we want to make that the WG to make an informed decision.

Kent and I have searching for independent people who could analyze the 
different solutions, and provide the pros/cons of each solutions. Note 
that some of this has already been done (Rob Wilton's presentation in 
Yokohama, YANG Model Coordination Group email to the list, etc.)
Lou Berger and Acee Lindem have agreed to help with this, with a 
tentative date of Jan 15 for an initial analysis.
They will start collecting the arguments. Please direct emails to both 
of them (lber...@labn.net, a...@cisco.com). Note that for discussions, 
the WG mailing list is more appropriate.


This process should ease the solution selection.

Regards, Benoit












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

Re: [netmod] Broadband Forum intention of using ietf-entity YANG module

2015-12-14 Thread Benoit Claise




I personally don’t see anything that prevents this.

Same opinion here.

Regards, Benoit


—Tom


On Dec 13, 2015:6:56 AM, at 6:56 AM, Romascanu, Dan (Dan)  
wrote:

Concerning the 'draft status' - anything prevents the wg from running a short 
consensus call and adding this item to the netmod milestones?

Regards,

Dan



-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau
Thomas
Sent: Friday, December 11, 2015 4:27 PM
To: William Lupton
Cc: netmod@ietf.org
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG
module


Dependance on 1.1 should not be an issue as that is almost ready to
be approved. You should be building your model to comply with the 1.1 rules.

—Tom



On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton

 wrote:

All,

The Broadband Forum would like to use the ietf-entity YANG module

(currently draft-entitydt-netmod-entity) for equipment management but we
are a bit concerned about its draft status and its dependence on YANG 1.1.
Any advice or reassurance?

Thanks,
William

___
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] draft-ietf-netmod-rfc6087bis-05.txt

2015-11-26 Thread Benoit Claise


Andy,

Robert Wilton  wrote:

Hi,

I have one question related to "5.1.  Module Naming Conventions".

Currently, the YANG modules that I have included as part of my
individual IDs don't currently use an "ietf-" prefix because the
drafts haven't been adopted as WG documents yet.

However, this means that the pyang tool throws up a warning for this.
E.g.
interfaces-com...@2015-10-19.yang:1: warning: RFC 6087: 4.1: no module
name prefix used, suggest ietf-interfaces-common

So, am I right in not including the ietf prefix for non WG adopted
drafts?  If so, should the above warning in pyang be made
informational instead?

I think it wiuld be useful if 6087bis provided guidelines for these
kinds of modules as well.

That said, I think that pyang --ietf should still flag this as an
error.  When checking a non-WG module, use --lint instead of --ietf.

Section 4.9 mentions:


 4.9
 .
 Validation Tools



   All modules need to be validated before submission in an Internet
   Draft.  The 'pyang' YANG compiler is freely available from github:

  https://github.com/mbj4668/pyang

   If the 'pyang' compiler is used, then the "--ietf" command line
   option SHOULD be used to identify any IETF guideline issues.


You might want to insert the new pyang --lint options for other SDOs.

Regards, Benoit



/martin

___
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] YANG model coordination group: Welcome Qin Wu as a new member

2015-11-23 Thread Benoit Claise


Dear all,

As you know, YANG data modeling is getting more and more important these 
days.
Graph of the day, with only the IETF YANG data models, is here 
<http://www.claise.be/modules.png>.


To help with the YANG Model Coordination Group 
<http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html>, 
we would like to welcome Qin Wu.
At the same time, I would like to thank Eric Osborne for his 
participation to the group. Unfortunately, Eric could not dedicate all 
the time he wanted to this task.


Right now, the YANG Model Coordination Group is composed of:
Carl Moberg
Dean Bogdanovic
    Qin Wu
Benoit Claise

As mentioned in the NETMOD meeting at IETF 94 
<03%20-%20YANG%20Model%20Coordination%20Group>, our current phase 
approach is:


   Phase 1: List of the YANG models (inventory)
   Phase 2: Tooling
   Phase 3: Help with compilation
   Phase 4: Training/Education
   Phase 5: Coordination across SDOs/Opensource
   Phase 6: Model Coordination within the IETF
   Phase 7: Standardization Priorities

Regards, Benoit




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

[netmod] New NETMOD charter approved

2015-10-22 Thread Benoit Claise


Dear all,

https://datatracker.ietf.org/doc/charter-ietf-netmod/ was approved today 
on the IESG telechat.


Regards, Benoit

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

Re: [netmod] open-source yang-explorer application

2015-10-21 Thread Benoit Claise


Great. Thanks Pravin.

Regards, Benoit

Hi All,

As demonstrated in IETE 93 hackthon and Bits & Byte Session, Yang 
Explorer (beta) a open source web based yang browser and RPC 
builder/Tester(w/ncclient)  is now available on github.


https://github.com/CiscoDevNet/yang-explorer

Please let me know if you have any question/comments regarding it. You 
are welcome to contribute to the project.


Thanks,
Pravin
. 


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

Re: [netmod] And another peak of new YANG models just before the submission deadline

2015-10-20 Thread Benoit Claise


Dear all,

To extend on Dan's reply: Clearly, there is room for improvement!

The IETF 94 tutorial, 
https://www.ietf.org/meeting/94/tutorials/yang-tutorial-hackathon.html, 
which will explain how to use pyang, should be compulsory for everybody 
posting a YANG model that doesn't compile.  Actually, "must be 
compulsory" :-)


The community has been building all the necessary tools:
- Martin Bjorklund posted pyang version 1.6. Get it from 
https://github.com/mbj4668/pyang

- Carl Moberg built http://www.yangvalidator.com/
- Mahesh and I sent regular direct emails to draft authors, pointing to 
the compilation errors from 
http://www.claise.be/IETFYANGPageCompilation.html
- The tools team (Henrik Levkowetz and Robert Sparks) will be 
incorporating pyang directly in idnits by January.

- And more tools to come at this hackathon.

So no more excuses. At this point, most YANG modules must be compiling.

Regards, Benoit

COMPILATION PASSED/TOTAL ratio, sorry.

Dan



-Original Message-
From: Romascanu, Dan (Dan)
Sent: Tuesday, October 20, 2015 11:32 AM
To: 'Benoit Claise'; NETMOD Working Group
Subject: RE: [netmod] And another peak of new YANG models just before
the submission deadline

The TOTAL/COMPILATION PASSED ratio seems to have improved since April
from ~25% to ~40%. This is good, but there is room for improvement.

Regards,

Dan



-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Benoit
Claise
Sent: Tuesday, October 20, 2015 10:31 AM
To: NETMOD Working Group
Subject: [netmod] And another peak of new YANG models just before the
submission deadline

Dear all,


.



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

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

2015-09-21 Thread Benoit Claise


Thanks Rob, that clarifies the situation for me.

Regards, Benoit

On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) wrote:


Re-reading this section 4.5, I understand 6A and 6C, but is 6B also
required?
Do we need to make the link between a config node and all the derived
counters/statistics it influences, which might be in different YANG
models btw?

Yes - we need to deterministically retrieve, for a particular configuration 
object (e.g., interface, BGP peer) the set set of derived state nodes 
associated with it, such that we do not need to maintain complex mapping tables 
on the client side for this - and can efficiently query the server for them.

For instance, knowing that we configured a BGP peer at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/config/{leaf-set} 
then we would find the counters at 
$SOMEROOT/bgp/neighbors/neighbor[peer-address=‘192.0.2.1’]/state/ - allows us 
to (based on the fact that we just configured a peer) retrieve the state and 
counters that a client application will likely want to check without having to 
map to some other (set of locations).

Note that in previous discussions, it was expressed that this implied that the 
model had knowledge of how the protocol operates such that it was known that 
leaf A corresponding to some other derived-state leaf B. However, this isn’t 
true. As I expressed before, the intention is that it is possible for a NMS 
layer to easily retrieve the set of state objects that an interested client may 
require, without many disparate queries, based on the configuration path. The 
actual meaning may be completely unknown to this layer.

The openconfig-opstate approach allows state and config to be defined in 
separate modules - since the ‘state’ module in this case can simply augment the 
relevant ‘state’ containers within the config model.

Regards,
r.
.



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

[netmod] Fwd: Re: Openconfig protocol(s)

2015-09-21 Thread Benoit Claise


Forwarded Anees Shaikh's email, with permission.
Thanks Anees. I believe it's useful info for NETMOD.

Regards, Benoit
 Forwarded Message 

   hi Benoit, we will be publishing the primitives after we complete
   our internal review -- it's in progress.  There's nothing secret
   about it, or any intention on our part to not 'put our cards on the
   table.'

   As we've said publicly, at Google we are planning to use gRPC for
   example, while others in OpenConfig have expressed their intention
   to use protocols such as Thrift, and still others will use NETCONF,
   or their own REST-based protocol.  OpenConfig is not prescribing or
   endorsing any specific protocol -- we only insist that the data
   models be common.

...


   On Mon, Sep 14, 2015 at 8:00 AM, Benoit Claise <bcla...@cisco.com
   <mailto:bcla...@cisco.com>> wrote:



From the preliminary meeting minutes

   Benoit: The two suggested solutions. They are based on
   NETCONF/RESTCONF. Are they using it for other protocols?
   Aneesh: We are using other protocols. Will share primitives.
   Benoit: If the solution is for NETCONF/RESTCONF, will it
   work for other protocols.
   Rob: If the solution is mappable for NETCONF/RESTCONF, would
   it be mappable for another protocol.
   Benoit: YANG is currently not protocol agnostic. Currently,
   it is tied to NETCONF/RESTCONF.
   Benoit: If the solution is for NETCONF/RESTCONF, is that
   acceptable?
   Rob: No. The solution has to be more general.
   Christian: Is the intersection of NETCONF/RESTCONF good
   enough for the other protocols.

   Rob mentioned during the call something such as: "we would share
   the expectations of the protocol".
   Please follow up and share the primitives or those expectations.
   However, in the end, I believe it would be favorable to
   everybody if you would play all your cards on the table, and
   directly share the protocols you plan on using.

   Regards, Benoit (OPS AD)










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

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

2015-09-14 Thread Benoit Claise

Jonathan,
Looking in from outside the current problem domain I'm not sure I'm 
sufficiently informed to comment, however I have a couple of queries:

 1. The requirements talk about both synchronous and asynchronous
systems (1(D), 3, 3(A)) but really only address the behaviour for
asynchronous systems. Would it not be worth clarifying the
relationship between the intended and applied configurations for
synchronous systems (i.e. they are the same), hence there is no
need for synchronous requirements equivalent to 1(D) and 3(A)?
 2. Why does 7(A) limit the scope to IETF-defined modules of others
are now defining YANG modules?

Good point. We need to provide guidance for the other SDOs.

Regards, Benoit

Thanks,

Jonathan

- Original Message -
From:
"Kent Watsen" 

To:
"netmod@ietf.org" 
Cc:

Sent:
Fri, 11 Sep 2015 22:16:40 +
Subject:
[netmod] FW: New Version Notification for
draft-chairs-netmod-opstate-reqs-00.txt

The AD and chairs thought it best to formalize the consensus on the
requirements a bit more. So we created the I-D listed below to
track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track
issues:

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

Consistent with Tom's earlier email, we want to collect any issues
with
these requirements before EOB Monday, September 14, 2015 at 5PM
EST. If
you have an issue, in addition to posting it to the list, please
consider
adding it to the GitHub tracker, and let people know you did so. Our
goal is to close the issues as quickly as possible, some will go
to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom

On 9/11/15, 5:36 PM, "internet-dra...@ietf.org"

wrote:

>
>A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name: draft-chairs-netmod-opstate-reqs
>Revision: 00
>Title: NETMOD Operational State Requirements
>Document date: 2015-09-11
>Group: Individual Submission
>Pages: 5
>URL:
>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>xt
>Status:
>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>Htmlized:
>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>
>
>Abstract:
> This document captures consensus on operational state
requirements by
> the NETMOD working group.
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

___
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] YANG coordination feedback on draft-openconfig-netmod-opstate-01

2015-09-14 Thread Benoit Claise


Rob,

Benoit,

I want to pick up on this very specific point. I think Lou’s mails imply a 
similar position, but I want to be clear.

On September 10, 2015 at 04:40:30, Benoit Claise (bcla...@cisco.com) wrote:

A common architecture includes a central configuration data

store that is being updated by the manageability framework and
updates read by the subsystems affected by the change (e.g. the
BGP service or the interface manager). In this case, there is
no other source of configuration except for the content of the
data store.

The configuration file/‘store’ of a system shows the intent of how that system 
should be configured. We can agree that all implementations need to have this.

The applied configuration is the value of those configuration elements a 
daemon/software component/programmable memory is actually running, which can be 
compared to the intent. Essentially, this is *dynamic* information which is the 
*state* of the running system. Implementations *do* store this. I think the 
point that you are making here is not that it is not supported. The point is 
that it is dynamically built at query time, according to a different schema.

You're right. Good clarification.

Regards, Benoit


This different schema is bad news, programmatically. How did I know that the 
static (IOS-alike configuration):

router bgp 65497
  neighbor 192.0.2.1 remote-as 65500

Needs me to run:
  
show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS


and then run a regexp that extracts the following AS number after the words 
‘remote AS’. Today - I probably need to write a mapping table that tells me 
that.

The requirement is that we can determine, for a particular leaf - what the 
intended value is, AND the value which is applied, PLUS be able to “easily” 
retrieve the state associated with that construct - in a way that is 
deterministic, and does not require per-leaf mapping tables to be maintained 
like we might have to today.

The point about identical values is that *in cases where no such retrieval of 
the actual applied config values is possible* a system can simply make all the 
applied leaves pointers to the intent. This would be akin to the ‘show’ command 
doing the equivalent of ‘show running-config | i 192.0.2.1.*remote-as’ and 
extracting the remote-as from there AFAICS.

Regards,
r.



.



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

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

2015-09-14 Thread Benoit Claise


Dear all,

I have a clarification question wrt the requirement 6

  6.  Ability to relate configuration with its corresponding
   operational state

   A.  Ability to map intended config nodes to corresponding applied
   config nodes

   B.  Ability to map intended config nodes to associated derived
   state nodes

   C.  The mappings needs to be programmatically consumable

From the appendix A, we can see that this requirement comes from 
draft-openconfig-netmod-opstate-01 
, 
Section 4.5 

Re-reading this section 4.5, I understand 6A and 6C, but is 6B also 
required?
Do we need to make the link between a config node and all the derived 
counters/statistics it influences, which might be in different YANG 
models btw?


Regards, Benoit

The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

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

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-chairs-netmod-opstate-reqs-00.txt
has been successfully submitted by Kent Watsen and posted to the
IETF repository.

Name:   draft-chairs-netmod-opstate-reqs
Revision:   00
Title:  NETMOD Operational State Requirements
Document date:  2015-09-11
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
xt
Status:
https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
Htmlized:
https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00


Abstract:
   This document captures consensus on operational state requirements by
   the NETMOD working group.

  




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

The IETF Secretariat


___
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] Tomorrow's Interim Meeting Details

2015-09-10 Thread Benoit Claise


Jürgen,

On Wed, Sep 09, 2015 at 08:38:35PM -0400, Nadeau Thomas wrote:

I wanted to set things up for the interim meeting tomorrow. To frame 
the meeting, we want to achieve two main goals:

1) close on requirements around a requirement to define a structure for 
IETF models and the requirements around ops state/models


I am confused. Benoit pointed to section 4 which has essentially
requirements concerning the support of asynchronous systems. You seem
to be talking also about requirements that go beyond that. It would be
good to know well ahead of time what is exactly on the agenda.
I also mentioned: "or around the requirement that the YANG models need 
some sort of hierarchy (draft-openconfig-netmod-model-structure), like 
for the routing models, ..."


If the group acknowledges that there is a requirement to structure all 
YANG models, basically extending what's done for the routing models, 
that would already be an achievement.
I would like to verify whether my understanding is correct: there is a 
willingness to structure the YANG models at least per technology 
(routing, OAM, for example), and we're debating whether or not "/device" 
is appropriate. This "/device" is a minor point IMO.


Regards, Benoit


/js



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

Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting

2015-09-09 Thread Benoit Claise


On 04/09/2015 18:54, Juergen Schoenwaelder wrote:

On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote:

Hi,

Is there a WEB page that lists all the upcoming virtual meetings?
This would really help people remember without scanning lots of
ietf-announce email.


The official list of interim meetings is here:

 https://www.ietf.org/meeting/interim.html

Yes, you have to search for NETMOD and no I am not aware of a nicer
list directly linked to say the NETMOD WG pages (or even a calendar
file).

I filed a tool request some time ago exactly on that.

Regards, Benoit


/js



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

Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting

2015-09-09 Thread Benoit Claise


Dear all,

There is a lot of passionate debates around YANG these days, which shows 
how important YANG became.


After the last IETF meeting, the openconfig group requested a call with me.
During that call, these operators re-explained their problem to me.

Let me decompose this into three parts, and again set the stage for this 
interim meeting tomorrow.


1. The problem statement.
When a group of operators come to the IETF with a problem, we should 
take this seriously and embrace it. In other words, nobody can dispute 
the operators problem statement.


2. The requirements.
If there are still clarifications needed around the requirements in 
draft-openconfig-netmod-opstate-01 section 4, or around the requirement 
that the YANG models need some sort of hierarchy 
(draft-openconfig-netmod-model-structure), like for the routing models, 
... tomorrow interim meeting is your chance, or between now and then on 
the mailing list.


3. The solution:
There are actually 3 different solutions for the operational state.
3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already 
been presented/discussed

3.2 draft-kwatsen-netmod-opstate, not yet presented
3.3 draft-wilton-netmod-opstate-yang, not yet presented
Come prepared, and have read those drafts in advance.
This interim meeting should be about comparing solutions around the 
operational state solutions.


We also need understand whether solving those requirements within the 
context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or 
draft-wilton-netmod-opstate-yang) is satisfactory.


Regards, Benoit (OPS AD)

Dear all,

Let me set the stage for this future interim.

First of (and let me repeat), I'm happy that the operators gathered 
and collectively worked on YANG models and related requirements.


The previous two interim meetings in June on the openconfig issues 
(draft-openconfig-netmod-opstate-01 
 and 
draft-openconfig-netmod-model-structure-00 
) 
were successful in the sense that the requirements are now understood.


Unfortunately, some key players were not in Prague and we could not 
finalize the discussion.
How to represent the operational state is one important guidance from 
RFC 6087bis that we must be providing to all existing and future YANG 
models (and not only in the IETF).


We need to bring closure on that topic, and this is the plan for that 
interim meeting in September.


http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has 
been updated. Please comment on this version.
Also, any alternate proposals must be prepared for that interim in 
September. They must be prepared with the same level of rigour as 
draft-openconfig-netmod-opstate., i.e. must have the same level of 
details.


In the meeting in September, the goal is to take a decision.

Regards, Benoit (OPS AD)


Hello,
NETMOD Working Group invites you to join this WebEx meeting.

*NETMOD Interm meeting on OpenConfig*
Thursday, September 10, 2015
11:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr

*Join WebEx meeting* 
 



Meeting number: 645 732 277
Meeting password:   1234

*Join by phone*
*1-877-668-4493* Call-in toll free number (US/Canada)
*1-650-479-3208* Call-in toll number (US/Canada)
Access code: 645 732 277
Toll-free calling restrictions 



Add this meeting 
 
to your calendar.


Can't join the meeting? Contact support. 



IMPORTANT NOTICE: Please note that this WebEx service allows audio 
and other information sent during the session to be recorded, which 
may be discoverable in a legal matter. By joining this session, you 
automatically consent to such recordings. If you do not consent to 
being recorded, discuss your concerns with the host or do not join 
the session.




___
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] NETMOD WG YANG 1.1 virtual interim meetings

2015-09-09 Thread Benoit Claise


[sorry for the delay. August vacation]

See in-line.

On Fri, Aug 07, 2015 at 09:22:41AM -0700, Andy Bierman wrote:

On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:


Lets please not mix YANG 1.1 work with other discussions at this point
in time.



I would really like the WG and IESG to decide how YANG is going to be
updated to support ephemeral state and operational state.

It seems there are many documents waiting on YANG 1.1, yet
only 1 or 2 actually use anything from YANG 1.1.

If YANG 1.0 is not being deprecated then I do not see
any reason to link documents to YANG 1.1 unless they
actually use it.

Is the plan to start work on YANG 1.2 before YANG 1.1 is even published?
If so, then say so.  Let's not pretend YANG is stable
or that all new improvements after YANG 1.1 are going to be
done with extension hacks.

If the IESG and the WG had a development plan for this work,
it might help vendors decide when and what to support.


I can't speak for the IESG, I can't speak for the WG - the WG has to
speak first.

My personal goal is to complete YANG 1.1 with the feature set that we
all worked on hard during that last year. I believe in the value of
finishing something.

I would support this.

Regards, Benoit

The alternative is to keep YANG 1.1 a moving
target for at least another year to come (and likely even longer, who
knows which wishes comes next and how long it takes to settle all the
semantic issues with ephemeral state).

Since the solution direction for ephemeral state is not even set yet
(and ephemeral state might not even be a feature that every
NETCONF/RESTCONF implementation may choose to support), I would rather
work with YANG extensions as long as possible (and if not possible,
consider alternatives such as YANG 1.2 once we 'understand the
edits'). At this stage, my personal preference is to finish YANG 1.1
with the feature set that we have now.

/js



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

Re: [netmod] Motivations for Structuring Models

2015-09-09 Thread Benoit Claise


Andy,

[taking on excerpt, out of context, to make a point]


1) As a consumer of YANG models, how do I identify the set of
models that provide a set of functionality? How do YANG model
writers ensure that their models are as easy to deal with as
possible by having consistent modelling approaches for config?


RTFM

That type of language is neither polite, nor useful.

Regards, Benoit (OPS AD)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Agenda posted for IETF 93 meeting

2015-07-16 Thread Benoit Claise


Dear all,


The preliminary agenda for the two NETMOD sessions has been posted here:

https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod

Please note that a discussion regarding Open Config will not occur due 
to scheduling conflicts.

Fine, but let's not postpone these important discussions too long.

Regards, Benoit

Otherwise, please let us know if any adjustments are needed.

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

[netmod] Number of YANG models these days

2015-07-06 Thread Benoit Claise


Dear all,

Just after the IETF draft submission deadline today, here are the latest 
numbers:


   Number of correctly extracted YANG models from IETF drafts: 155
   Number of YANG models in IETF drafts that passed compilation without
   warnings: 58/155
   Number of YANG models in IETF drafts that passed compilation with
   warnings: 35/155
   Number of all YANG models in IETF drafts (example, badly formatted,
   etc. ): 253

Happy to see that more and more YANG models compile without any 
errors/warnings.


Recently (June 25th), the opendaylight shipped in first release: Lithium

   Number of YANG models in Hydrogen release: 117
   Number of YANG models in Helium release: 220
   Number of YANG models in Lithium release: 473

The numbers keep increasing. It should not be a surprise for anybody.

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

2015-06-29 Thread Benoit Claise


Dear all,

As a contributor, I browsed through draft-ietf-netmod-yang-metadata

-
   The set of annotations must be extensible in a distributed manner
   so as to allow for defining new annotations without running into
   the risk of collisions with annotations defined and used by
   others.

What does in a distributed manner mean?



- In the introduction, you mention:
   Typical use cases are:

   o  Deactivating a subtree in a configuration datastore while keeping
  the data in place.

   o  Complementing data model information with instance-specific data.

   o  RPC operations may use metadata annotations for various purposes
  in both requests and responses.  For example, the edit-config
  operation in the NETCONF protocol (seesection 7.2 of [RFC6241] 
https://tools.ietf.org/html/rfc6241#section-7.2)
  uses annotations in the form of XML attributes for identifying the
  point in the configuration and type of the operation.


Don't you have any other examples than those 3?
What about showing these examples with the spec. in this document?
Note: I see that the first one is documented with module example-inactive


- Please correct the IANA considerations as in RFC7277, in particular the 
Registrant Contact:
   This document registers a URI in the IETF XML Registry [RFC3688 
https://tools.ietf.org/html/rfc3688].
   Following the format inRFC 3688 https://tools.ietf.org/html/rfc3688, the 
following registration has been
   made.

   URI: urn:ietf:params:xml:ns:yang:ietf-ip

   Registrant Contact: The NETMOD WG of the IETF.

   XML: N/A; the requested URI is an XML namespace.

Regards, Benoit


All,

Today is the cutoff date for the Last Call for this draft, but the 
author indicated that comments received today or tomorrow can be 
incorporated into the draft-update being worked on.  So, if you have 
any lingering reviews, please send them before as soon as possible.


Thanks!
Kent



From: Kent Watsen kwat...@juniper.net mailto:kwat...@juniper.net
Date: Monday, June 15, 2015 at 6:49 PM
To: netmod@ietf.org mailto:netmod@ietf.org netmod@ietf.org 
mailto:netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 
(until 2015-06-29)



This is a notice to start a NETMOD WG last call for the document 
Defining and Using Metadata with YANG:


https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01

Please indicate your support by Monday June 29, 2015 at 9PM EST.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  I have reviewed I-D XYZ and I found no issues
  I have implemented the data model in I-D XYZ
  I am implementing the data model in I-D XYZ
  I am considering to implement the data model in I-D XYZ

This is the first Last Call for this document.

Kent, as NETMOD co-chair



___
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

< 1 2 3

201 - 262 of 262 matches

Mail list logo