[netmod] draft-ietf-netmod-yang-semver: version or semantic-version

[Benoit Claise]

Dear all,

Looking at 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-yang-semver-12=draft-ietf-netmod-yang-semver-13=--html 
, 
we went from revision-label to version



We used this field in draft-ietf-netconf-yang-notifications-versioning

leaf revision-label {
  type ysver:version;
  description
"This references the YANG module semversion to be sent in the
subscription.";
}
  }

One question: why not have a better name directly indraft-ietf-netmod-yang-semver  
,
 which we could reuse?
For example: semantic-version

Regards, Benoit





___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] comments on draft-jouqui-netmod-yang-full-include

[Benoit Claise]

Hi Andy,


On 3/21/2024 5:35 PM, Andy Bierman wrote:

Hi,

The presentation yesterday helped me understand the motivation for 
this work.

Seems simple enough, but rife with unintended consequences.
RFC 8528 does a good job of dealing with most of these issues, but it 
is not a design-time

modification like this draft is proposing.

I would like to see this work as part of yang-next, but not thrown in 
with YANG 1.1.
Yes, we could always push enhancement to YANG-Next.However, don't we 
have enough requests now, not only from the IETF (



 draft-ietf-opsawg-collected-data-manifest

)  
but also from the BBF (Scott Mansfield) and 3GPP (Balazs), as mentioned 
in meeting minutes 
?

Let's keep in mind that
I don't see YANG-Next being standardized any time soon.

Regards, Benoit


Just some of the major issues to solve:

1) XPath
The issue of leafrefs was raised but of course this also applies to 
must/when statements.


2) Shared yanglib
This draft shares the top yanglib.
Schema Mount implementations allow completely separate YANG libraries
that are decoupled from the top yanglib and other mount points.  This 
allows

deviations, features, etc.


3) No way to include data nodes only at the mount point.
To a YANG 1.1 tool, if a module is listed in the yanglib then all its
implemented top-level objects are part of .

4) Not clear what is included and scoped at the mount point
There are lots of top-level YANG statements that are not data-def-stmts.
Are these ignored? What exactly is included?  What changes to 
identifier scope resolution

are being made?

5) anydata as root
This causes more problems than it is supposed to solve.
IMO Schema Mount got this right, keeping it a container or list.

6) Recursion and Loops
This adds significant complexity to the implementation.

IMO this is an interesting topic for yang-next.

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

Re: [netmod] New instance serving yangcatalog.org

[Benoit Claise]

Hi Robert,

Thanks for the proactive note.
> All modules (particularly vendor modules) are not yet populated at 
the new server. We'll address that as soon as we can.

    On this one, can you post a note on the web site front page

Regards, Benoit

On 12/28/2023 3:40 PM, Robert Sparks wrote:

Yang communty:

We are shifting yangcatalog,org to a new server tomorrow 29Dec.

We had hoped this would be achieved with no noticeable changes, but 
there will be a period into the first few days of next year where the 
service is degraded or down.


All modules (particularly vendor modules) are not yet populated at the 
new server. We'll address that as soon as we can.


This is a transitional deployment. We are working towards a repeatable 
automated build/test/deploy of the service that will run in the new 
infrastructure.


Apologies in advance for any inconvenience while we work through the 
remaining issues with this first redeployment.


RjS

___
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] Poll on YANG Versioning NBC Approach

[Benoit Claise]

On 9/13/2023 4:36 PM, Ladislav Lhotka wrote:



Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):

On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to 
stay true to YANG RFC sections 10 and 11 also. Well done. :-)


I intentionally used "compiler" rather than "toolchain", "IDE" or 
something more open ended, because a compiler is what I have and can 
speak for.


Even so, I have a hard time thinking the customers of even the best 
YANG IDEs would be interested to pay the effort for distinguishing 
between YANG 1.1 and YANG 1.2 solely on the proposed RFC wording 
difference. Since a BC verification capability apparently already 
exists in some IDEs, I think it would make sense for their vendors 
to turn the checks it into a warnings (if they aren't already), 
regardless of which yang-version statement is found in the module 
header.


This might mean a non-zero implementation effort for a few YANG 
toolchain implementors. While this is a good point, it does not 
really sway my opinion about what the pragmatic choice for IETF is. 
Or Jernej, do you think the users of those good IDEs would prefer a 
new YANG version? If so, why?


If you are asking whether I'd like to see a new version of YANG for 
the sole purpose of changing those MUST and MUST NOTs - no, I would 
not. However, a change like this mandates a yang-version bump, IMHO.


Right, so we have two ugly options, but bumping YANG version really 
makes no sense, so breaking those few tools that check update rules 
looks like a better choice to me.


We have already seen cases that the update rules prevented fixing 
problems in YANG modules in a straightforward way, and 
backward-compatible fixes negatively affected module readability. This 
is inevitable until the ecosystem of YANG modules stabilizes. That's 
why I think changing update rules from MUST to SHOULD is appropriate - 
it should have been so from the beginning.

Well said Lada.

Regards, Benoit



Lada



Jernej



Best Regards,
/jan





On 13 Sep 2023, at 10:57, Jernej Tuljak  
wrote:


On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the 
YANG language version number, but digging a bit deeper, I think 
the question is not as clear-cut as it might seem at first.


Altering the contents of the backwards-compatibility section of 
RFC 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in 
YANG module authors' behavior.


Speaking as a YANG compiler implementor, however, I don't see any 
changes that have to made to the compiler because of this RFC 
change. There are no new keywords, none are removed. There is no 
change in the meaning of existing keywords. There is no difference 
in the output the compiler needs to generate.


So while there are changes to the YANG *standard* (meaning RFCs) 
there is no actual change to the YANG *language*. If we require 
user's to mark their modules with version 1.2 (or 2.0), from the 
compiler's pov, that would just be an alias for YANG 1.1. It means 
a fair amount of trouble to update all the tools out there to 
accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go 
through all YANG 1.1 modules and mark them 1.2, for no change in 
meaning. For organizations with some modules still on YANG 1.0, 
the bar is even higher.


I think the most pragmatic approach in this case would be to 
change the RFC text in the backwards-compatibility sections and 
not update the yang-version number as long as no change is 
required in the compilers. If anyone can point to actual things 
the compiler needs to do differently, I'd be interested to hear.


You will first have to define what a YANG compiler is before you 
can make such assumptions. YANG code validation rules may be 
implemented in several ways, depending on what the tool that 
utilizes them is used for. I choose to call that a "validation 
engine" - "compiler" implies translation into a lower level 
language in my world and not all tools require that. I know of at 
least one tool that utilizes a validation engine that performs the 
checks in Updating a Module sections of RFC 6020 and RFC 7950, when 
requested. And I would expect a YANG authoring tool to do the same 
if it claims full RFC compliance. Those are not optional guidelines 
intended just for humans. It is true that some of the rules can 
only be reliably checked by a human, but not all (or even most) of 
them. Point being - there are implementations out there that rely 
on the text of this Section to remain unchanged. I would imagine 
that they represent a drop in the sea compared to implementations 
that have chosen to completely ignore the spec (forking YANG into 
YANG' in the process), but they do exist.


I disagree that changing those sections does not change the 
language. Of course it does. It makes combinations of 

Re: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

[Benoit Claise]

Dear all,

For the same reasons as Adrian, I support adoption.

However, I would not rush to publish the new version.
We keep learning and we must document this knowledge (see "List name: 
singular or plural?" which we all thought was documented).
Also, we will hopefully soon have a significant change (see 
https://notes.ietf.org/netmod-2023-sept-poll?view): we should make sure 
that RFC8407bis takes this into account. In other words, I see a 
dependency for this document: the NBC outcome.


Regards, Benoit

On 9/12/2023 10:40 AM, Adrian Farrel wrote:

Hi Lou,

Yes, it is totally appropriate that we revisit this guidance. A lot has been
learned in the five years since 8407 and the long list of updates already in
this draft show that there is work to be done.

Adopt and work.

Cheers,
Adrian

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: Monday, September 11, 2023 11:22 PM
To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

Hello,

This email begins a 2-week adoption poll for:
https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/

Please voice your support or technical objections to adoption on the
list by the end of the day (any time zone) Sept 25.

Thank you,
Lou (as 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



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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt

[Benoit Claise]

Dear all,

I am generically not in favor of publishing requirement documents.
However, it might have proven beneficial in this particular case.

Regards, Benoit

On 6/26/2023 6:02 PM, tom petch wrote:

From: netmod  on behalf of Joe Clarke (jclarke) 

Sent: 26 June 2023 16:53

This revision is a resurrection of the expired I-D to help frame the LC 
discussions around module versioning and YANG Semver.


Joe

Thank you for that

Tom Petch


Joe

From: netmod  on behalf of internet-dra...@ietf.org 

Date: Monday, June 26, 2023 at 11:49
To: i-d-annou...@ietf.org 
Cc: netmod@ietf.org 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Network Modeling
(NETMOD) WG of the IETF.

Title   : YANG Module Versioning Requirements
Author  : Joe Clarke
Filename: draft-ietf-netmod-yang-versioning-reqs-08.txt
Pages   : 12
Date: 2023-06-26

Abstract:
This document describes the problems that can arise because of the
YANG language module update rules, that require all updates to YANG
module preserve strict backwards compatibility.  It also defines the
requirements on any solution designed to solve the stated problems.
This document does not consider possible solutions, nor endorse any
particular solution.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-versioning-reqs-08

Internet-Drafts are also available by rsync at rsync.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



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

[netmod] Fwd: New Version Notification for draft-tgraf-netconf-yang-notifications-versioning-03.txt

[Benoit Claise]

Dear NETMOD WG,

Note the change of WG from NETCONF to NETMOD

Is this something that should be discussed during the Tuesday "NETMOD 
YANG Version Discussions " calls?


Regards, Benoit


 Forwarded Message 
Subject: 	Re: New Version Notification for 
draft-tgraf-netconf-yang-notifications-versioning-03.txt

Date:   Thu, 19 Jan 2023 17:26:06 +0100
From:   Alex Huang Feng 
To: Netconf 
CC: 	Pierre Francois , Benoit Claise 
, Thomas Graf 




Dear Netconf WG,

I would like to raise a discussion on how this YANG module should be 
used and therefore if the current types are the right ones.


First of all, this draft wants to address two main issues:
1. Adds the version or the semver in the stablish-subscription and 
modify-subscription rpcs to allow selecting the versionned YANG module 
in YANG-push
2. Adds the version and the semver in the subscription-started and 
subscription-modified notifications and the subscription datastore to 
have the version and the semver in them.


My concern is the following:
In the rpc, the current “revision" is a "rev:revision-date-or-label", 
meaning that in the “revision” leaf you can chose either the revision 
“2020-01-10” or the semver “1.0.0”. Should this be “rev:revision-date” 
instead?
I am asking myself which is the wanted use-case of the different leaves. 
I understand that if the "revision-label" is used, there is no need for 
the “revision” (in the subscription rpc)?


On the notification side, I do think both are necessary, but the same 
issue, the “revision” should maybe be “rev:revision-date”.


Two ways to solve this:

1.
in the rpc: the "revision" being “rev:revision-date” and the 
"revision-label” be “ysver:version”
in the notifications and datastore: the revision being 
“rev:revision-date” and the "revision-label” be “ysver:version”


OR

2.
in the rpc: only having “revision” leaf being 
“rev:revision-date-or-label” and removing "revision-label" leaf.
in the notifications and datastore: the "revision" being 
“rev:revision-date” and the "revision-label” be “ysver:version”


Does this make sense? What are your thoughts?

Regards,

Alex Huang Feng



On 17 Jan 2023, at 15:43, thomas.g...@swisscom.com wrote:

Dear netconf wg,

We addressed in section 4.2 a copy paste error on the yang module and 
published the document in the -03 version.


Best wishes
Thomas

A new version of I-D, 
draft-tgraf-netconf-yang-notifications-versioning-03.txt
has been successfully submitted by Thomas Graf and posted to the IETF 
repository.


Name: draft-tgraf-netconf-yang-notifications-versioning
Revision: 03
Title: Support of Versioning in YANG Notifications Subscription
Document date: 2023-01-17
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-tgraf-netconf-yang-notifications-versioning-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-notifications-versioning
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-tgraf-netconf-yang-notifications-versioning-03


Abstract:
This document extends the YANG notifications subscription mechanism
to specify the YANG module semantic version at the subscription.
Then, a new extension with the revision and the semantic version of
the YANG push subscription state change notification is proposed.

The IETF Secretariat

-Original Message-
From: Graf Thomas, INI-NET-VNC-HCS Sent: Saturday, January 14, 2023 
7:27 AM

To: netc...@ietf.org
Cc: Pierre Francois ; Alex Huang Feng 
; Benoit Claise 
Subject: FW: New Version Notification for 
draft-tgraf-netconf-yang-notifications-versioning-02.txt


Dear netconf wg,

On top of the changes in the -01 version based on inputs from IETF 115 
from of Jason Stern and Rob Wilton, we added in section 4.1.2 the YANG 
full tree view, added descriptions and resolved some issues in the 
YANG module raised by the YANG validation.
On the behalf of the authors I like to request the adoption of the 
document to the netconf working group and request a slot at IETF 116 
to present an update, discuss and conclude how to progress on 
subscription id being mandatory.


Best wishes
Thomas


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

Re: [netmod] What to reference when importing an IANA module?

[Benoit Claise]

Hi Med,

On 1/17/2023 2:46 PM, mohamed.boucad...@orange.com wrote:


If we want to add an IANA link to update RFC 8407, Section 3.9, a 
couple of remarks:

- It's not clear what "a normative reference with the IANA URL" is.
    Is it 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml?
    Or is it 
https://www.iana.org/assignments/yang-parameters/iana-if-t...@2022-08-24.yang?

    The more precise the later, right?

*//*

*/[Med] None of them. IANA is using dedicated URLs:/*

*/* 
https://www.iana.org/assignments/iana-bgp-l2-encaps/iana-bgp-l2-encaps.xhtml/*


*/* 
https://www.iana.org/assignments/iana-pseudowire-types/iana-pseudowire-types.xhtml/*


*/* https://www.iana.org/assignments/iana-bfd-types/iana-bfd-types.xhtml/*


That would work.
We would need
    - to get the guarantee (from IANA) that those URLs are permanent
    - to clearly mention that THIS URL type is required for IETF YANG 
modules


Regards, Benoit


*//*


    However, the latter, which is a typical example of IANA maintained 
YANG module does NOT work, as the revision in the URL changes with any 
IAN update
- So this leads to have both RFC and IANA, so 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml 
+ 
RFC7224 (in the above example)
- Also, we should make more generic for some other SDOs, as IANA is 
for IETF only.

And the guidelines are followed by others: BBF, IEEE, etc.

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

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Benoit Claise]

No, I'm not aware of any IPR that applies to this draft.

Regards, Benoit



On 1/16/2023 11:59 PM, Kent Watsen wrote:

[NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your
response.


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

Re: [netmod] What to reference when importing an IANA module?

[Benoit Claise]

Dear all,

On 1/13/2023 9:22 PM, Randy Presuhn wrote:

Hi -

On 2023-01-13 10:20 AM, Kent Watsen wrote:



On Jan 13, 2023, at 11:25 AM, Benoit Claise 
 wrote:


Hi Tom,
Yes I do think that people outside the IETF may be ignorant of the 
nuances of the way the IETF works and  may not realise that a URL 
to the IANA website must be used in preference to an RFC.  There is 
more to YANG modules than extracting the code from somewhere in 
order to incorporate it into something.  I have even seen RFC 
reference the obsolete list of possibilities  in the RFC that set 
up an IANA registry
If this is the case (And Randy supports this), then we should update 
RFC 8047.


Benoit's reference to RFC 8047 had me puzzled until I saw Kent's
response regarding RFC 8407.  :-)


Agreed - as a hold for document update?

Currently RFC 8407, Section 3.9 says:

    For every import or include statement that appears in a module
    contained in the specification that identifies a module in a 
separate

    document, a corresponding normative reference to that document MUST
    appear in the Normative References section.  The reference MUST
    correspond to the specific module version actually used within the
    specification.


I agree with Kent's "hold for document update" assessment.  The
difficultly with the existing text is that it correctly reflects
the concerns that were at the forefront when it was written -
e.g. making it as easy as possible for developers to get the
necessary context for implementing a module, but, as far as
I can recall, the group hadn't thought as deeply about
registries spun off from an initial document.


Want to take a swing at it?


Not me.  :-)  There are competing requirements, and the "best" answer
will very much depend on each situation.  I think the *spirit* of
the RFC 8407 Section 3.9 is  "point to whatever resource will be most
enlightening to the developer / user."  But the letter of the law is
"point to whatever is needed to generate a tree of normative
reference dependencies" - that is, use what will be most helpful
to the people writing the standards.  There's a point to both kinds of
pointers.

When in doubt, my preference is to go whichever way will make it
harder for implementations to get it wrong.

Agree on the principles, but there is no quick fix.
Look at Med's proposal:

   If an IANA-maintained module is imported by another module, a
   normative reference with the IANA URL from where to retrieve the
   IANA-maintained module SHOULD be included.  Although not encouraged,
   referencing the RFC that defines the initial version of the IANA
   module is acceptable in specific cases (e.g., the imported version is
   specifically the initial version, the RFC includes useful description
   about the usage of the module).

If we want to add an IANA link to update RFC 8407, Section 3.9, a couple 
of remarks:

- It's not clear what "a normative reference with the IANA URL" is.
    Is it 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml?
    Or is it 
https://www.iana.org/assignments/yang-parameters/iana-if-t...@2022-08-24.yang?

    The more precise the later, right?
    However, the latter, which is a typical example of IANA maintained 
YANG module does NOT work, as the revision in the URL changes with any 
IAN update
- So this leads to have both RFC and IANA, so 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml + 
RFC7224 (in the above example)
- Also, we should make more generic for some other SDOs, as IANA is for 
IETF only.

  And the guidelines are followed by others: BBF, IEEE, etc.

Regards, Benoit


Randy

___
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] What to reference when importing an IANA module?

[Benoit Claise]

Hi Tom,

Yes I do think that people outside the IETF may be ignorant of the nuances of 
the way the IETF works and  may not realise that a URL to the IANA website must 
be used in preference to an RFC.  There is more to YANG modules than extracting 
the code from somewhere in order to incorporate it into something.  I have even 
seen RFC reference the obsolete list of possibilities  in the RFC that set up 
an IANA registry
If this is the case (And Randy supports this), then we should update RFC 
8047.


Regards, B.

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

Re: [netmod] What to reference when importing an IANA module?

[Benoit Claise]

Hi Tom,

On 1/12/2023 5:51 PM, tom petch wrote:

From: netmod  on behalf of Benoit Claise 

Sent: 12 January 2023 14:45

Dear all,

>From the initial problem statement:
During a WG adoption poll we have received a comment that the URL
should be added in the reference statement when importing a YANG
module maintained by IANA
The important question to me is: is this reference text supposed to be read by 
a machine or a human?
It seems to me that the answer is "a human". 
https://datatracker.ietf.org/doc/html/rfc6020#section-7.19.4

If this is true, why do we care about having a URL in there?


One of the requirements in the design of URL was that they could be easily used 
by humans, written on  a napkin and handed over from one human to another to be 
consumed later so URL are designed for human consumption.

Also,  the version of the module in an RFC is obsolete as soon as the RFC is 
published because IANA has change control so including an RFC number is 
directing users to out-of-date information, misleading them.  A well-written 
RFC will make this point and direct the reader to the IANA website (but most 
RFC are not well written).  Often the aim of putting data into IANA is to make 
it more readily available to others outside the IETF process and while experts 
like you will know the caveats, others may think that a reference to e.g.
X.690 is a reference to the current, latest version.  So, if you want to 
mislead such people, point users at the RFC.
Oh, because you conclude that, if we put a RFC number in the reference, 
the community will (be stupid enough to) conclude that it has to extract 
the YANG module from the RFC text directly ... as opposed to look for a 
location where it's already store? IANA, yangcatalog.

Ok, if you think that this is really a problem...

Regards, Benoit


Tom Petch

Regards, Benoit

On 1/12/2023 1:20 PM, Italo Busi wrote:
Hi all,

Happy New Year

During a WG adoption poll we have received a comment that the URL should be 
added in the reference statement when importing a YANG module maintained by 
IANA and we are not sure how to address this comment

See: https://mailarchive.ietf.org/arch/msg/ccamp/zD6gAfEUlYJ4W3qQlz6Y_gfX5TY/

I have checked RFC8407 but I have not found any guideline on what to reference 
when importing an IANA module

I have checked a couple of examples I knew (RFC8343 and RFC8348) and noted that 
the IANA modules are imported with no reference

I have also noted that within the IANA YANG model registry, the reference for 
the IANA modules is the RFC where the module has been initially defined:

https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

What would be your suggestion?

Are there any guidelines I have missed?

Do you know if there are other examples of published RFCs importing an IANA 
module?

Thanks in advance

Italo





___
netmod mailing list
netmod@ietf.org<mailto: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] What to reference when importing an IANA module?

[Benoit Claise]

Dear all,

From the initial problem statement:

   During a WG adoption poll we have received a comment that the URL
   should be added in the reference statement when importing a YANG
   module maintained by IANA

The important question to me is: is this reference text supposed to be 
read by a machine or a human?
It seems to me that the answer is "a human". 
https://datatracker.ietf.org/doc/html/rfc6020#section-7.19.4


If this is true, why do we care about having a URL in there?

Regards, Benoit

On 1/12/2023 1:20 PM, Italo Busi wrote:

Hi all,
Happy New Year
During a WG adoption poll we have received a comment that the URL 
should be added in the reference statement when importing a YANG 
module maintained by IANA and we are not sure how to address this comment
See: 
_https://mailarchive.ietf.org/arch/msg/ccamp/zD6gAfEUlYJ4W3qQlz6Y_gfX5TY/_ 

I have checked RFC8407 but I have not found any guideline on what to 
reference when importing an IANA module
I have checked a couple of examples I knew (RFC8343 and RFC8348) and 
noted that the IANA modules are imported with no reference
I have also noted that within the IANA YANG model registry, the 
reference for the IANA modules is the RFC where the module has been 
initially defined:
_https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml_ 


What would be your suggestion?
Are there any guidelines I have missed?
Do you know if there are other examples of published RFCs importing an 
IANA module?

Thanks in advance
Italo

___
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] WG adoption call: draft-dbb-netmod-acl-03

[Benoit Claise]

Support adoption.

Regards, Benoit

On 12/20/2022 12:00 AM, Lou Berger wrote:

Hello,

This email begins a 3-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/


Please voice your support or technical objections to adoption on the
list by the end of the day (any time zone) January 9.

This is an extended call due to the holiday/New Year.

Thank you,
Lou (as 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

Re: [netmod] Change in NETMOD Chairs

[Benoit Claise]

A big "Thank you" Joel!

Regards, Benoit

On 10/13/2022 5:30 PM, Rob Wilton (rwilton) wrote:

I've decided to reduce the number of NETMOD chairs from 3 chairs down to 2.  
Kent and Lou will continue as NETMOD chairs, Joel is stepping down.

For the current amount of work in NETMOD, having two chairs is the optimal 
number.  In addition, having a free third chair slot potentially allows 
community members to try WG chairing alongside experienced chairs.  As a 
reminder, ADs and chairs are always keen to encourage and help IETF 
participants who may be interested in taking on increased leadership 
responsibilities within the IETF.  If that is something that interests you then 
please reach out to me, Warren, or the WG chairs.

I would like to thank Joel for his time and contributions to managing the 
NETMOD WG.

Regards,
Rob

___
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] Tree diagram comment lines

[Benoit Claise]

Hi Tom,

Martin beat me on this one.
So the famous +1 to his "in combination with explanatory text to explain 
certain aspects of the module design "reply :-)

We got rid a page number for a good reason (in the YANG world).

Regards, Benoit

On 4/11/2022 1:02 PM, Martin Björklund wrote:

tom petch  wrote:

Can a YANG tree diagram contain comment lines?

draft-ietf-teas-yang-te has a tree diagram of 40 pages and since the
IETF has abolished the page number, then any reference into it could
be a challenge.  For a YANG module, this can be ameliorated by
inserting comment lines every page or two.

Can this be done with tree diagrams?

Yes, "//" introduces a (line) comment.  See 2.5 of RFC 8340.

But a 40 page tree diagram isn't very useful anyway, imo.  If I want
the full tree diagram I can run a tool to generate it.  Tree diagrams
are best used in combination with explanatory text to explain certain
aspects of the module design.  Perhaps section 3.4 in RFC 8407 should
be updated to explain this.


/martin





Tom Petch
___
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] IPR Poll on draft-ietf-netmod-node-tags-06

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

Regards, Benoit



On 4/8/2022 8:09 PM, Kent Watsen wrote:

[ Note: existing IPR declaration: https://datatracker.ietf.org/ipr/4216 ]


Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This
document will not advance to the next stage until a response
has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


.


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

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Benoit Claise]

+1  to Jürgen point of view.

Regards, Benoit

From:Jürgen Schönwälder 
To:William Lupton 
Cc:NetMod WG 
Date:2022-03-03 20:01:06
Subject:Re: [netmod] iana-if-type.yang has multiple revisions with the same date

The obvious thing to do in this particular case (where there are only
allocations of new values) is to collapse the revisions and to move
on. Slightly better would be to ensure this does not happen again.

/js

On Thu, Mar 03, 2022 at 05:45:25PM +, William Lupton wrote:
> > It is too late to do anything about this module.
>
> This module is republished every time a new ifType is added. Are you saying
> that it would be unacceptable to collapse the duplicate revisions next time
> it's updated? If so then we will live with this FOR EVER!
>
> >

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


--
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Benoit Claise]

+1

B.

On 2/14/2022 11:49 PM, Mahesh Jethanandani wrote:
I have followed the discussions on this draft and believe it is ready 
for publication.




On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
 wrote:



Dear NETMOD WG,

This message begins a two-week WGLC for 
draft-ietf-netmod-rfc6991-bis-11 ending on Friday, February 18th.  
Here is a direct link to the HTML version of the draft:


https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

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


Thank you,
Kent (as 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


___
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] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

Regards, Benoit

On 1/31/2022 10:57 PM, Lou Berger wrote:



Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


.


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

Re: [netmod] too long lines from IANA module inclusion

[Benoit Claise]

Dear all,

`pyang` and I think `yanglint` also know how to extract folded
 and  elements.

Just a correction; pyang doesn't extract anything, but rfcstrip does,
and it supports folded artwork, and in the latest greatest 1.3 release
it even reconizes the proper RFC8792-defined magic strings ;-)
Do we have a couple of IETF drafts with long too long lines, next to 
https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ?
I would like to make sure that the yangcatalog.org extracts the YANG 
module(s) correctly.

Note: the yangcatalog.org uses xym.

Regards, Benoit

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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-08.txt

[Benoit Claise]

+1.

Regards, Benoit

On 11/9/2021 10:17 AM, Rob Wilton (rwilton) wrote:

Hi Juergen,

My preference would be to last call this document so that other YANG modules 
can make use of the new types.  We can always spin a future bis document if 
further common types are useful.

draft-ietf-netmod-yang-module-versioning also makes use of the 
revision-identifier type defined in this draft.

Regards,
Rob

// As a contributor



-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: 07 November 2021 16:36
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-08.txt

On Sun, Nov 07, 2021 at 08:18:36AM -0800, internet-dra...@ietf.org wrote:
s.

This draft is a work item of the Network Modeling WG of the IETF.

   Title   : Common YANG Data Types
   Author  : Juergen Schoenwaelder
Filename: draft-ietf-netmod-rfc6991-bis-08.txt
Pages   : 41
Date: 2021-11-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-08


This is a mostly editorial update. The draft has no open issues I am
aware of. The WG has to decide whether we wrap this up by sending the
document to WG last call and then through the publication pipeline or
we leave this I-D hanging around just in case more additions get
proposed and finally worked out so that they can be added. In later
case, it is crucial to provide concrete and actionable proposals.
Rough ideas "please add X" where it is left somewhat open what "X"
really boils down to or how "X" will be used makes it difficult to
work out the details.

/js

PS: I have not registered for IETF 112, I guess I will watch the
 session recordings once they are available.



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

Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Benoit Claise]

Hi Murray,

On 10/4/2021 8:25 PM, Murray Kucherawy via Datatracker wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

The shepherd writeup is incomplete with respect to the first question.

All of the SHOULDs in Section 2 leave me wondering under what conditions one
might legitimately deviate from what they are saying.  Since SHOULD offers a
choice, I recommend making this more clear.

The draft mentions some SHOULD related to the file name.
    Ex: The name of the instance data file SHOULD be of the form:
For those SHOULD, we followed the RFC 7950, 
https://datatracker.ietf.org/doc/html/rfc7950#section-5.2, which also 
used SHOULD


For this instance ...
To properly understand and use an instance data set, the user needs to 
know the content-schema. One of the following methods SHOULD be used:

... I don't recall why we have a SHOULD here. History I guess.
A MUST seems more appropriate and we propose to change to a MUST.

Regards, Benoit

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

Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities

[Benoit Claise]

Hi Rob,

Thanks for your detailed review.
A new draft version has been posted.

URL:https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt
Status:https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities
Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17


See the justifications below.

On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote:

Hi,

Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16

Thanks for this draft, sorry for the delay in reviewing.  It looks like it is 
in good shape.

I think that most of my comments are minor or cosmetic suggestions to 
potentially improve the phrasing of the text.


1.
Abstract:

The module "ietf-system-capabilities" provides a placeholder
structure that can be used to discover YANG related system
capabilities for servers.  The module can be used to report
capability information from the server at run-time or implementation-
time, per the YANG Instance Data File Format.

Suggest "by making use of" rather than "per".

DONE.



2.
1.  Introduction

There is a need to publish this capability information as it is part
of the contract between the server and client.

Suggest "contract" -> "API contract".

DONE



3.
There is a need to publish this capability information as it is part
of the contract between the server and client.  Examples include
maximum size of data that can be stored or transferred, information
about counters (whether a node supports "on-change" telemetry), etc.
Such capabilities are often dependent on a vendor's implementation or
the available resources at deployment.  Many such capabilities are
specific to either the complete system, individual YANG datastores
[RFC8342] or specific parts of the YANG schema, or even individual
data nodes.  It is a goal of this document to provide a common way of
representing such capabilities in a format that is:

Suggest: maximum -> the maximum
  "or specific" -> ", specific"

DONE



4.
o  available in identical format both at implementation-time and run-
   time

Suggest: "in an identical", and a period at the end.

DONE



5.
If the information is
not documented in a way available to the NMS designer, but only as
instance data from the network node once it is deployed, the NMS
implementation will be delayed

Suggest: "way available" => "way that is readily available"

DONE



6.
The network operator needs to plan his
management practices and NMS implementation before he even decides to
buy the specific network node type.

Suggest: "him" -> "their", "he even decides" -> "they decide"

DONE



7.
Run-time information is needed:

Suggest: Run-time capability information is needed:

DONE.



8.
o  to check that capability information provided earlier, at
   implementation-time is what the publisher has implemented.

Suggest: "at implementation-time, is"

DONE



9.
  To find a capability value for a specific data node in a
  specific datastore the user SHALL:

Please clarify that the capability value is selected by the relative path
to the datanode defining the capability.  i.e., the same name/path must be
used both under the system level and per datastore level capabilties.

NEW SENTENCE.

"When stating a specific capability, the relative path for any specific
capability must be the same under the system-capabilities container and
under the per-node-capabilities list: the same grouping for defining the
capabilities MUST be used. "


10.
2) If the datastore entry is found within that entry, process all
  per-node-capabilities entries in the order they appear in the list.
  The first entry that specifies the specific capability and has a
  node-selector selecting the specific data node defines the
  capability value.

I'm not sure this is required, but perhaps consider adding text to make it clear
that longest path matching can be achieved by ordering more specific
matches before less specific matches.
ADDED "Note that longest path matching can be achieved by ordering more 
specific matches before less specific ones"

under

list per-node-capabilities {
description
  "Each list entry specifies capabilities for the selected
   data nodes. The same capabilities apply for the data nodes
   in the subtree below the selected nodes.

   The system SHALL order the entries according to their
   precedence. The order of the entries MUST NOT change unless
   the underlying capabilities also change.";

We did NOT add next to "2) If the datastore entry is found within that 
entry ..." because that section focuses on the user (as opposed to the 
implementer on the server), as mentioned in "To find a capability 

Re: [netmod] Regarding IPR on draft-wwx-netmod-event-yang-10

[Benoit Claise]

Hi Lou,

No, I'm not aware of any IPR that applies to this draft

Regards, Benoit

Hi Qin,

It's sub-optimal, but sufficient IMO.  Please note you didn't respond 
for yourself!


we're still missing responses from:

Qin Wu
Benoit Claise
Andy Bierman

Thanks,

Lou

On 12/7/2020 8:46 PM, Qin Wu wrote:


Hi, Lou:

Does forwarding confirmation from the authors to the list count?

I have done this accidentally. If not, I will leave this to my 
coauthors.


-Qin

*发件人:*Lou Berger [mailto:lber...@labn.net]
*发送时间:*2020年12月8日6:20
*收件人:*Qin Wu ; Igor Bryskin 
; Henk Birkholz 
; Xufeng Liu 
; Benoit Claise 
*抄送:*NetMod WG Chairs ; NetMod WG 


*主题:*Fwd: Regarding IPR on draft-wwx-netmod-event-yang-10

Authors,

    My apologies -- I failed to cc the WG on this.  Can you please 
re-reply so that your response make it into the WG archive.


Thank you!

Lou


 Forwarded Message 

*Subject: *



Regarding IPR on draft-wwx-netmod-event-yang-10

*Date: *



Mon, 23 Nov 2020 18:08:59 -0500

*From: *



Lou Berger  <mailto:lber...@labn.net>

*To: *



Qin Wu  <mailto:bill...@huawei.com>, Igor Bryskin 
 <mailto:i_brys...@yahoo.com>, Henk Birkholz 
 
<mailto:henk.birkh...@sit.fraunhofer.de>, Xufeng Liu 
 <mailto:xufeng.liu.i...@gmail.com>, 
Benoit Claise  <mailto:bcla...@cisco.com>


*CC: *



NetMod WG Chairs  
<mailto:netmod-cha...@ietf.org>




Authors,

Per the 109 session, it is the chairs intent to do another adoption 
call on this draft. In preparation for that, we’ve determined both 
that the draft has changed significantly and that there is a new 
author, and therefore feel it necessary to issue another IPR call, as 
follows:



Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors. If you
contributed to the document please respond. Alternatively, please feel
free to state that you didn't materially contribute to the draft and
would like your name removed from the contribution section (and moved to
acknowledgments after WG adoption).

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
<http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty>.


Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your
response.


.


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

Re: [netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-06

[Benoit Claise]

Hi,

"No, I'm not aware of any IPR that applies to this draft"

Regards, B.

Authors,

Per the 109 session, it is the chairs intent to do another adoption call on the 
"yang-node-tags” draft.  In preparation for that, we’ve determined both that 
the draft has changed significantly and that there is a new author, and therefore 
feel it necessary to issue another IPR call, as follows:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you
contributed to the document please respond.  Alternatively, please feel
free to state that you didn't materially contribute to the draft and
would like your name removed from the contribution section (and moved to
acknowledgments after WG adoption).

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your
response.
.


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

Re: [netmod] rfc6991bis: yang:percentage

[Benoit Claise]

On 30/07/2020 15:25, Juergen Schoenwaelder wrote:

On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:

On 20/07/2020 11:19, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


- Percentages are frequently used in YANG models but usages differ a
  lot in precision and range. It is not clear what the proper
  generic definition of a percentage type would be and whether it is
  worth having it.

  RFC 7950 example:

   typedef percent { type uint8 { range "0 .. 100"; } }

  RFC 8294:

   typedef percentage { type uint8 { range "0..100"; } }

  I-Ds:
   typedef percentage { type decimal64 { fraction-digits 5; } }
   typedef percentile { type decimal64 { fraction-digits 2; } }

  The yang catalogue seems to be down. :-(

- Proposal: do not add a percentage type since it is trivial to
  define a context specific percentage type that matches range and
  precision requirements (and there is already a definition in RFC
  8294 for those who need exactly that definition).

I agree with this proposal. It is also possible to use

 units percent;

where necessary.

On the other hand, when I look at the numerous percent/percentage
occurrences in YANG model, it doesn't hurt to define that typedef.

https://yangcatalog.org/yang-search/ => search on "node name" and typedef
only
We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
Most of them points to:

*typedef*  percent {
*type*  uint8 {
*range*  "0 .. 100";

}
}


But that one is already defined in RFC 8294 in ietf-routing-types.
Does it make sense to define it again in yang-types?



My point was taht it makes sense to group typedefs in a few documents: 
RFC6991, 6991bis (hopefully published soon) and  my bad,  I forgot 
that RFC 8294 is "Common YANG _data types_ for the routing area"


So we're good. Thanks.

Regards, Benoit



/js



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

Re: [netmod] rfc6991bis: yang:percentage

[Benoit Claise]

On 20/07/2020 11:19, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


   - Percentages are frequently used in YANG models but usages differ a
 lot in precision and range. It is not clear what the proper
 generic definition of a percentage type would be and whether it is
 worth having it.

 RFC 7950 example:

  typedef percent { type uint8 { range "0 .. 100"; } }

 RFC 8294:

  typedef percentage { type uint8 { range "0..100"; } }

 I-Ds:
  typedef percentage { type decimal64 { fraction-digits 5; } }
  typedef percentile { type decimal64 { fraction-digits 2; } }

 The yang catalogue seems to be down. :-(

   - Proposal: do not add a percentage type since it is trivial to
 define a context specific percentage type that matches range and
 precision requirements (and there is already a definition in RFC
 8294 for those who need exactly that definition).

I agree with this proposal. It is also possible to use

units percent;

where necessary.
On the other hand, when I look at the numerous percent/percentage 
occurrences in YANG model, it doesn't hurt to define that typedef.


https://yangcatalog.org/yang-search/ => search on "node name" and 
typedef only

We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
Most of them points to:

   *typedef*  percent {
*type*  uint8 {
*range*  "0 .. 100";

}
   }
 


Regards, Benoit




Lada


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

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


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

Re: [netmod] Regarding IPR on draft-tao-netmod-yang-node-tags-01

[Benoit Claise]

Hi,

"No, I'm not aware of any IPR that applies to this draft"

Regards, B.

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you
contributed to the document please respond.  Alternatively, please feel
free to state that you didn't materially contribute to the draft and
would like your name removed from the contribution section (and moved to
acknowledgments after WG adoption).

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



.


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

Re: [netmod] CODE BEGINS ENDS for examples ?

[Benoit Claise]

Hi Balázs,

https://tools.ietf.org/html/rfc8407


   3.2.1 .
   Example Module



   Example modules are not code components.  The 
   convention MUST NOT be used for example modules.

Regards, Benoit


Hello,

Is it allowed/recommended to use   around 
examples. In my case it would be examples of XML and JSON instance 
data. I would find it rather useful.


As a second step if someone could combine rfcstrip with 
artwork-unfolding that would be even better.


Regards Balazs

--

Balazs Lengyel    Senior 
Specialist   Ericsson Hungary Ltd.


Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com


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


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

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06

[Benoit Claise]

Juergen,

On on side, Balazs mentions:

4+ people asked me explicitly to state this similarity during the
development of the draft.

The current text is:

   P2  Instance data shall reuse existing encoding rules for YANG
   defined data.  Its format will be similar to the response of a
   NETCONF  operation or the RESTCONF response to a GET method
   invocation on the (unified) datastore resource.

This modification is based on your feedback:

Well, then the correct wording would be "similar to the response of a
NETCONF  operation or the RESTCONF response to a GET method
invocation on the (unified) datastore resource". Sounds complex and I
still prefer the text to be agnostic to specific operations

On the other side, you insist now on removing the latter sentence.
Could you propose a similar sentence that would satisfy your concern?

Regards, Benoit

On Mon, Mar 09, 2020 at 04:17:40PM +, Balázs Lengyel wrote:

See BALAZS4 below

-Original Message-
From: Juergen Schoenwaelder 
Sent: 2020. március 9., hétfő 10:44
To: Balázs Lengyel 
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06


-Original Message-
From: Schönwälder, Jürgen 
Sent: 2020. február 12., szerda 10:07
Subject: [Not Scanned] - Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06


   - Is it necessary to describe P2 in terms of (presumably) NETCONF
 operations? I would prefer to have the document written in a
 protocol agnostic style. Perhaps simply drop "similar to the
 response of a  operation/request".
BALAZS: This is a reference both to NETCONF and RESTCONF. It was
explicitly asked for by other reviewers.

Well, then the correct wording would be "similar to the response of
a NETCONF  operation or the RESTCONF response to a GET method
invocation on the (unified) datastore resource". Sounds complex and
I still prefer the text to be agnostic to specific operations - in
particular since  and the unified datastore have their
limitations. The format is simply reusing the already defined data
model encoding formats, i.e., the format has nothing to do with the

operations used to retrieve the data. So I suggest:

P2  Instance data shall reuse existing encoding rules for
YANG defined data.

There is no need to refer to specific protocol operations.
BALAZS: I will use both of your texts. That is the most common
question I
get: Will this use the same format as a get-reply? People like to
think in terms of a specific easy-to-grasp function instead of a
non-descript set of "existing" rules. Existing means you need to
understand X number of RFCs, while just looking up a get-reply is
easy. It is not precise, but IMHO that's how people think.

If you write "reuse existing encoding rules", then actually fewer
documents need to be understood. And operations have additional issues
in how they interact with 'datastores', so they may even be misleading
and I rather have the standards precise (and minimal normative

dependencies).

BALAZS3: Sorry, I don't fully understand your point. What would you
like in P2?
The text now is:
P2  Instance data shall reuse existing encoding rules for YANG
defined data.  Its format will be similar to the response of a
NETCONF  operation or the RESTCONF response to a GET method
invocation on the (unified) datastore resource.
It refers to existing rules as you asked for and also  says" similar"
to a get response, using phrasing from your email on 2020-02-12.
Are you OK with this? Or how would you like to change it?

What I proposed above:

P2  Instance data shall reuse existing encoding rules for
YANG defined data.

Your additional sentence is simply wrong. Instance data from lets say
 with _not_ be 'similar' to the response of a NETCONF 
operation or the RESTCONF response to a GET method invocation on the
(unified) datastore resource. The same holds true for instance data from
.
BALAZS4:  I would like to keep the second part of the sentence.
4+ people asked me explicitly to state this similarity during the
development of the draft. While your methodical and somewhat abstract way of
thinking has greatly helped me/us in many cases, IMHO other people often
think in the terms of examples and  in recognizing known similar
methodology. As the we use the same encoding rules for get replies and for
instance data, IMHO they are similar even if instance data allows some
additions/omissions. (People liked/requested this statement, even though
"similar" is a rather subjective term.)
Anyway it is only included in the introduction part, so while it helps some
people, it should not cause problems with the precise definition of the
format. On your request I already removed a similar statement from the
normative parts.

What the sentence says is unclear or plain wrong in a number of valid
use cases (depends on how one understands the word "similar") and thus
this sentence is misleading 

Re: [netmod] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-solutions-03

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

https://tools.ietf.org/html/draft-verdt-netmod-yang-solutions-03#section-3

   o  Balazs Lengyel

   o  Benoit Claise

   o  Ebben Aries

   o  Jason Sterne

   o  Joe Clarke

   o  Juergen Schoenwaelder

   o  Mahesh Jethanandani

   o  Michael (Wangzitao)

   o  Qin Wu

   o  Reshad Rahman

   o  Rob Wilton

   o  Susan Hares

   o  Wu Bo

Regards, B.

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please 
feel free to state that you didn't materially contribute to the draft 
and would like your name removed from the contribution section (and 
moved to acknowledgments after WG adoption).


If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



___
Netmod-ver-dt mailing list
netmod-ver...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod-ver-dt
.


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

Re: [netmod] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-schema-comparison-00

[Benoit Claise]

Hi Lou,

"No, I'm not aware of any IPR that applies to this draft"

Note: there are more contributors. See
https://tools.ietf.org/html/draft-verdt-netmod-yang-schema-comparison-00#section-8

   o  Balazs Lengyel

   o  Benoit Claise

   o  Bo Wu

   o  Ebben Aries

   o  Jason Sterne

   o  Joe Clarke

   o  Juergen Schoenwaelder

   o  Mahesh Jethanandani

   o  Michael Wang

   o  Qin Wu

   o  Reshad Rahman

   o  Rob Wilton

regards, Benoit.

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please 
feel free to state that you didn't materially contribute to the draft 
and would like your name removed from the contribution section (and 
moved to acknowledgments after WG adoption).


If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



___
Netmod-ver-dt mailing list
netmod-ver...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod-ver-dt
.


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

Re: [netmod] Adoption of versioning design team docs

[Benoit Claise]

Support.

Regards, B.


As a contributor/DT-member I support the adoption of this set of 
documents.


*From:*netmod  *On Behalf Of *Lou Berger
*Sent:* Monday, March 2, 2020 5:30 PM
*To:* NETMOD Group 
*Cc:* netmod-cha...@ietf.org
*Subject:* [netmod] Adoption of versioning design team docs

Hi,
We'd like to start a two week adoption call for the set of documents described 
below by Rob.  To be specific, this includes
1) draft-verdt-netmod-yang-solutions-03
2) draft-verdt-netmod-yang-module-versioning-01
3) draft-verdt-netmod-yang-semver-01
4) draft-rwilton-netmod-yang-packages-03
5) draft-wilton-netmod-yang-ver-selection-02
6) draft-verdt-netmod-yang-schema-comparison-00
The adoption call ends in two weeks, on March 16.
Please voice your support or objections on list.  While we prefer to adopt as a 
set, objections on specific documents are acceptable.
Netmod Chairs
On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote:

Netmod chairs,

The version selection draft draft-wilton-netmod-yang-ver-selection-02 is 
now posted.  With that, the YANG versioning design team would like to please 
request you make an WG adoption call for these documents.

The updated full list is:

1) draft-verdt-netmod-yang-solutions-03

   - Solution overview, updated since 106 to cover updates to version 
selection and schema comparison drafts.

2) draft-verdt-netmod-yang-module-versioning-01

   - Base module versioning solution, unchanged from the version presented 
at 106.

3) draft-verdt-netmod-yang-semver-01

   - YANG Semantic version numbers, unchanged from the version presented at 
106.

4) draft-rwilton-netmod-yang-packages-03

   - YANG packages draft, updated since 106

   


5) draft-wilton-netmod-yang-ver-selection-02

   - Version selection, updated since 106, as per notes below

6) draft-verdt-netmod-yang-schema-comparison-00

   - Schema comparison tooling, unchanged from the version presented at 106.

The main changes to the version selection draft are:

   - We have tried to simplify the model, but at the same time give servers 
more flexibility about how they implement version selection and what it can be 
used for.  E.g. if the server wants to allow a client to choose between 
different schema versions, but require that all clients use the same schema 
version, that is now possible

   - The draft explicitly disallows schema-selection happening mid-session

   - The solution allows the server to require clients to configure 
schema-sets before they are used

   - The solution provides more information about which schema-sets are 
compatible with each other

Regards,

Rob


___
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] Regarding IPR on draft-verdt-netmod-yang-module-versioning-01

[Benoit Claise]

Hi,

No, I'm not aware of any IPR that applies to this draft

Regards, B.



Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please 
feel free to state that you didn't materially contribute to the draft 
and would like your name removed from the contribution section (and 
moved to acknowledgments after WG adoption).


If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



.


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

Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented

[Benoit Claise]

Hi,



On Mon, Mar 2, 2020 at 10:23 AM Ladislav Lhotka <mailto:lho...@nic.cz>> wrote:


On Mon, 2020-03-02 at 09:52 -0800, Andy Bierman wrote:
>
>
> On Mon, Mar 2, 2020 at 8:57 AM Benoit Claise mailto:bcla...@cisco.com>> wrote:
> > Sorry to resurrect this old email thread.
> > To me, it's an important piece of information to know that
ietf-netconf-acm
> > is optional to implement.
> >
> > It seems that we have 3 potential places where to insert this
information
> > 1. The associated document. We could and should insert it into
the RFC text.
> >     Drawback: Somehow the YANG module is looked at
independently of the
> > associated document
> > 2. import-stmt: people on the list apparently don't like this
> > 3. module description? What harm would it do if the
description could
> > contain this info?
> >
> >
>
> IMO it makes more sense to summarize the imported modules that
need to be
> implemented
> and not mention the ones that are not required.  The module
description-stmt
> is better
> than each import. (YANG 1.1 allows the same module to be
imported multiple
> times).

Modules that have to be implemented can be imported only once.
Adding this
information to the import statement for such modules is IMO more
effective than
having it in the module description. I don't get how it could
become a problem.


I do not think this info helps very much. It is duplicate info.
It should be in the description-stmts for the objects defined in the 
module.

Well, I had in mind the module description
The "description-stmts for the objects defined in the module" is yet 
another place.
It is also self-evident (and defined in YANG) that if you augment some 
external node

you have to implement the augmented module.

 This is the classic definition of a CLR.

Lada




Trying to decompose the problem space 
I believe it's common sense to include in the RFC text that 
ietf-netconf-acm is optional to implement (to take the example in 
question in 
https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-11)
Do we agree that this information should also be contained somewhere, 
somehow in the YANG module? I would say: yes


If yes, what are the options?
I agree with Juergen (in a reply in this email thread): ideally a 
tooling answer would be better. This will take some time. So what do we 
do now?

3 options:
a. import description (description-stmt in import-stmt)

   module ietf-system-capabilities {
  yang-version 1.1;
  namespace
"urn:ietf:params:xml:ns:yang:ietf-system-capabilities";
  prefix sysc;

  import ietf-netconf-acm
{ prefix nacm; }
description "_ietf-netconf-acm is optional to implement_.";
}


b. module description (description-stmt in  meta-stmts in 
module-stmt/submodule-stmt)


   module ietf-system-capabilities {
  yang-version 1.1;
  namespace
"urn:ietf:params:xml:ns:yang:ietf-system-capabilities";
  prefix sysc;

  import ietf-netconf-acm { prefix nacm; }

  import ietf-yang-library {
prefix yanglib;
description "Revision 2019-01-04 or a
  revision derived from it is REQUIRED.";
  }

  organization
"IETF NETCONF (Network Configuration) Working Group";
  contact
"WG Web:   <https://datatracker.ietf.org/wg/netconf/>
 WG List:  <mailto:netc...@ietf.org>

 Editor:   Balazs Lengyel
   <mailto:balazs.leng...@ericsson.com>";
  description
"This module specifies a module intended to contain system
  capabilities. System capabilities may include capabilities of a
  NETCONF or RESTCONF server or a notification publisher.

  ...

 
  _ietf-netconf-acm is optional to implement."_


c. description-stmts for the objects defined in the module

  leaf node-selector {
type nacm:node-instance-identifier;
description
  "Selects the data nodes for which capabilities are
   specified. The special value '/' denotes all data nodes
   in the datastore._ietf-netconf-acm is optional to 
implement._";
  }


c. looks weird to me, and might need repetitions in different YANG 
objects. In the end, as an implementer, I only care to understand 
whether I need to implement "ietf-netconf-acm" as a prequesite to 
implement ietf-system-capabilities.


Between a. and b., I have no strong preferences.
However, a. seems to be the logical place to me.

Regards, Benoit



>
> > Regards, Benoit
>

Re: [netmod] Regarding IPR on draft-verdt-netmod-yang-semver-01

[Benoit Claise]

Hi,

No, I'm not aware of any IPR that applies to this draft

Regards, B.


Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please 
feel free to state that you didn't materially contribute to the draft 
and would like your name removed from the contribution section (and 
moved to acknowledgments after WG adoption).


If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



.


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

Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented

[Benoit Claise]

Sorry to resurrect this old email thread.
To me, it's an important piece of information to know that 
ietf-netconf-acm is optional to implement.


It seems that we have 3 potential places where to insert this information
1. The associated document. We could and should insert it into the RFC text.
    Drawback: Somehow the YANG module is looked at independently of the 
associated document

2. import-stmt: people on the list apparently don't like this
3. module description? What harm would it do if the description could 
contain this info?


Regards, Benoit



On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka > wrote:


On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote:
>
> On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka mailto:lho...@nic.cz>> wrote:
> > On Tue, 2020-01-07 at 14:29 +, Balázs Lengyel wrote:
> > > If that is the consensus, I can remove the description
statements, no big
> > > deal. (I actually like the statements, but they are not
important for this
> > > draft)
> >
> > Of course, it is not that important, but I don't see how this
information
> > could
> > be harmful, if it is included with the import. In my view, it
is not meant
> > as a
> > conformance requirement but just an info from the module
author about the
> > meaning of the import statement.
> >
>
> It adds a lot of extra work but more importantly the import-stmt
is the wrong
> place

What work do you mean? I thought that it would be just info for
potential
developers (or their managers) that implementing the module requires
implementing other modules and functionality - or not.



It is duplication because the individual data-def statements should 
have any notes

about implementation requirements. The duplication may even be wrong.
E.g., in the module it says NACM is not required, but what if some objects
have NACM requirements listed in the Security Considerations section?
That is the RFC section to discuss NACM requirements.


For example, if a module imports ietf-netconf-nacm only for using
"node-
instance-identifier" type, it is relatively uninteresting. Otherwise,
implementation of the module may just be out of question.


> to document such a complex and unrelated issue as server conformance
> requirements.
>
>
> > The root of this problem (and design flaw of YANG, IMO) is
that import is
> > "overloaded" with two different purposes, one of which
effectively requires
> > that
> > the imported module be also implemented, while the other doesn't.
> >
>
> The import-stmt is only used to map a local prefix to an
external module.

But one thing is using a prefix for accessing top-level types and
groupings
(i.e. stuff in YANG modules), and another thing is accessing
schema nodes, which
have to be present in the schema tree. In complicated data models,
it is not
exactly easy to figure out all these dependencies.


I do not agree these are different things.
In both cases the prefix is used to determine the imported module that 
contains the identifier.



So maybe what is really overloaded are the namespace prefixes:
they are used for
addressing YANG modules, schema nodes and instances (in XPath).

Lada



Andy


> This proposal to add conformance info the the import-stmt would
overload it
> with
> another purpose.
>
> Not even a typedef is easy to classify  (e.g., leafref requires
implementation
> of a data node).
> I certainly agree that YANG conformance is poorly specified, poorly
> understood, and
> in real need of improvement. Likewise, the import-stmt is also
in need of some
> improvement
> since import-by-exact-revision is (and has always been) poorly
designed.
>
>
> > Lada
> >
> > > Balazs
>
> Andy
>
>
> > > -Original Message-
> > > From: Martin Bjorklund mailto:m...@tail-f.com>>
> > > Sent: Tuesday, January 7, 2020 2:38 PM
> > > To: Balázs Lengyel mailto:balazs.leng...@ericsson.com>>
> > > Cc: a...@yumaworks.com ;
lho...@nic.cz ; netmod@ietf.org

> > > Subject: Re: [netmod] Text in import to indicate whether a
module is
> > needed as
> > > import-only or as implemented
> > >
> > > Hi
> > >
> > > I agree w/ Andy and others that we should not add this to
the import's
> > > description.  I don't think this kind of conformance text
belongs to the
> > > import's description.  If you think it is important to state
this, the
> > best
> > > place is probably as plain text in the document itself.
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > > Balázs Lengyel 

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

[Benoit Claise]

Jürgen,

To tell that I was skeptical about the SUPA work is just wrong.

I had great hopes for SUPA, as having consistent policy constructs in 
YANG module was key. The big hope was that those SUPA constructs could 
be re-used in other YANG modules

    example: routing, ACL, security ...
    Regardless of the location: in a network element or in a 
controller/orchestrator

    Regardless of the function: network element and service YANG modules
If successful, in the end, SUPA would have helped to reuse code.

Was I disappointed by the progress? Yes. The results were not there 
while the rest of the world uses their YANG policy constructs. Timing 
was key so, as AD, I had to pull the plug.

The world has moved on. So be it.
You can't infer skepticism from pragmatism.

Now, back to the draft.
From a network element point, I stressed the need to take have _simple 
_ECA rules directly routers.
Think about RMON event/alarm but for YANG. Think about removing the RMON 
event/alarm restrictions that it works only for integer/counter.

If your point is that the draft is not perfect, fair point.
Should we solve attempt to solve that issue? Yes.

A confusion comes from the abstract that implies that this work is based 
on SUPA.


Abstract

   RFC8328 defines a policy-based management framework that allows
   definition of a data model to be used to represent high-level,
   possibly network-wide policies.  Policy discussed in RFC8328 are
   classified into imperative policy and declarative policy, Event
   Condition Action (ECA) policy is an typical example of imperative
   policy.  This document defines a YANG data model for the ECA policy
   management.  The ECA policy YANG provides the ability for the network
   management function (within a network element) to control the
   configuration and monitor state change and take simple and instant
   action on the server when a trigger condition on the system state is
   met.

Actually, in my mind, the abstract should be simplified to something 
such as (and yes, it could be improved)


Abstract

   This document defines a YANG data model for the ECA policy
   management.  The ECA policy YANG provides the ability for the network
   management function (within a network element) to control the
   configuration and monitor state change and take simple and instant
   action on the server when a trigger condition on the system state is
   met.

And then, somewhere in the introduction, the following text should be 
reused:


   RFC8328 defines a policy-based management framework that allows
   definition of a data model to be used to represent high-level,
   possibly network-wide policies.  Policy discussed in RFC8328 are
   classified into imperative policy and declarative policy, Event
   Condition Action (ECA) policy is an typical example of imperative
   policy.


Regards, Benoit.

On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:

This email begins a 2 week working group adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06

Please voice your support or objections before the poll completes on
March 3rd.

I am against adoption of this draft. I wonder whether Benoit will
explain his contributions to this document; Benoit was added as a
co-author in -06 and he used to be rather sceptical about the SUPA
work (and this is essentially part of the SUPA work resubmitted to the
NETMOD WG). Despite this, the YANG definitions are clearly not up to
the level one would expect for WG adoption. Many descriptions are
just repetition of leaf names and there are obvious errors such as

   leaf-list day-of-month {
 type uint8 {
   range "0..59";
 }
 description
   "A set of days of the month at which this
scheduling timing will trigger.";
   }

Despite the strange range, it is unclear how a number will in the
range will identify a set. Note, this is an example, there are lots of
them in the document. The examples provides are not convincing and
technically wrong (how can 10m match

   leaf interval {
 type uint32 {
   range "1..max";
 }
 units "seconds";
 mandatory true;
 description
   "The number of seconds between two triggers
generated by this periodic timing object.";
   }

and I have serious doubts that the design is anywhere close to be
practically usable. There need to be mechanisms to bind 'variables'
while matching conditions that and be reused in action definitions, it
is not scalable to have constants such as interface names in the
examples hard-coded in policy rules - this would lead to a huge number
of rules if you want to apply policy rules to all interfaces.

There is also a lack of extensibility, which is important for a core
policy language, and definitions like:

   identity function-type {
 description
   "Possible 

Re: [netmod] ID submission YANG validation errors?

[Benoit Claise]

Fixed, thanks to Miroslav, in cc.
Yangvalidator is working now, and correctly saying that there are no 
errors.
Datatracker is still not using the yangvalidator API to validate modules 
and therefore it is saying that there are errors.

This task is on our todo list.

If you find more issues like the one below, open an issue:
https://github.com/YangCatalog
(or https://github.com/YangCatalog/bottle-yang-extractor-validator)

Regards, Benoit

Also, the YANG validator tool is broken - 
https://www.yangcatalog.org/yangvalidator/

On 1/22/20, 9:41 AM, "netmod on behalf of Christian Hopps" 
 wrote:

 
 I've just submitted a YANG module draft and received what i think to be a bogus validation error:
 
   https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/
 
 It's saying it can't find the ietf-isis module. Has anyone else experienced this issue with referencing draft modules? It seems broken that we can't refer to works-in-progress, inside our works-in-progress.
 
 Thanks,

 Chris.
 


___
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] IPR poll on draft-ietf-netmod-yang-instance-file-format

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

Regards, B.


"No, I'm not aware of any IPR that applies to this draft"

Regards Balazs

*From:* Kent Watsen 
*Sent:* Tuesday, January 7, 2020 1:46 PM
*To:* Balázs Lengyel ; Benoit Claise 


*Cc:* NETMOD Working Group 
*Subject:* IPR poll on draft-ietf-netmod-yang-instance-file-format

To each author and contributor listed on the "To" line.


In order to complete the WGLC poll, are you aware of any IPR that 
applies to


draft-ietf-netmod-yang-instance-file-format?  Please Reply-All to 
*this* email


and state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think 
appropriate.


If you are listed as a document author or contributor please answer 
the above by
responding to this email regardless of whether or not you are aware of 
any relevant
IPR.  This document will not advance to the next stage until a 
response has been
received from each author and listed contributor.  NOTE: THIS APPLIES 
TO ALL

OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not 
listed as an author
or contributor, we remind you of your obligations under the IETF IPR 
rules which
encourages you to notify the IETF if you are aware of IPR of others on 
an IETF
contribution, or to refrain from participating in any contribution or 
discussion related
to your undisclosed IPR. For more information, please see the RFCs 
listed above

and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.



NETMOD Chairs





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

Re: [netmod] [Editorial Errata Reported] RFC8199 (5924)

[Benoit Claise]

Dear all,

This errata should be accepted.

Regards, B.

The following errata report has been submitted for RFC8199,
"YANG Module Classification".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5924

--
Type: Editorial
Reported by: Mohamed Boucadair 

Section: Section 6.1

Original Text
-
6.1.  Normative References

...

[RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
   Model for L3VPN Service Delivery", RFC 8049,
   DOI 10.17487/RFC8049, February 2017,
   .

Corrected Text
--
6.1.  Informative References

...

[RFC8049]  Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
   Model for L3VPN Service Delivery", RFC 8049,
   DOI 10.17487/RFC8049, February 2017,
   .

Notes
-
RFC8049 is cited only as an example (Section 2.1):

"An example of a Network Service YANG Module is in [RFC8049]..."

Not sure why it was listed as normative.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC8199 (draft-ietf-netmod-yang-model-classification-08)
--
Title   : YANG Module Classification
Publication Date: July 2017
Author(s)   : D. Bogdanovic, B. Claise, C. Moberg
Category: INFORMATIONAL
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG
.



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

Re: [netmod] IPR poll on yang-versioning-reqs-02

[Benoit Claise]

No, I'm not aware of any IPR that applies to this draft.

Benoit

To each author and contributor listed on the "To" line.

In order to complete the Adoption poll, are you aware of any IPR that 
applies
to yang-versioning-reqs-02?  Please Reply-All to *this* email and 
state either:


"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If "yes", has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If "yes" again, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think 
appropriate.


If you are listed as a document author or contributor please answer 
the above by
responding to this email regardless of whether or not you are aware of 
any relevant
IPR.  This document will not advance to the next stage until a 
response has been
received from each author and listed contributor.  NOTE: THIS APPLIES 
TO ALL

OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not 
listed as an author
or contributor, we remind you of your obligations under the IETF IPR 
rules which
encourages you to notify the IETF if you are aware of IPR of others on 
an IETF
contribution, or to refrain from participating in any contribution or 
discussion related
to your undisclosed IPR. For more information, please see the RFCs 
listed above

and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent // as co-Chair



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

Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08

[Benoit Claise]

No, I am not aware of any IPR related to this draft.

Regards, B.


No, I am not aware of any IPR related to this draft.

-Qin
-邮件原件-
发件人: Kent Watsen [mailto:kwat...@juniper.net]
发送时间: 2018年10月17日 5:56
收件人: adr...@olddog.co.uk; 'Lou Berger'; 'Benoit Claise'; Qin Wu; Adrian Farrel
抄送: 'NetMod WG Chairs'; 'NetMod WG'
主题: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08

No, I'm not aware of any IPR that applies to this draft

Kent // as an author


-Original Message-
From: Adrian Farrel 
Reply-To: "adr...@olddog.co.uk" 
Date: Tuesday, October 16, 2018 at 5:24 PM
To: 'Lou Berger' , Kent Watsen , Benoit Claise 
, "bill...@huawei.com" , Adrian Farrel 

Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" 

Subject: RE: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
Resent-From: 
Resent-To: , , , 

Resent-Date: Tuesday, October 16, 2018 at 5:24 PM

Hi Lou,

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Adrian


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: 16 October 2018 21:26
To: Kent Watsen; Benoit Claise; bill...@huawei.com;
afar...@juniper.net
Cc: NetMod WG Chairs; NetMod WG
Subject: [netmod] Regarding IPR on
draft-kwatsen-netmod-artwork-folding-08

Authors, Contributors, WG,

As part of preparation for WG Adoption

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer
the above by responding to this email regardless of whether or not you
are aware of any relevant IPR. This document will not advance to the
next stage until a response has been received from each author and
listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF if
you are aware of IPR of others on an IETF contribution, or to refrain
from participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed
above and
https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_group_iesg_trac_wiki_IntellectualProperty=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484=2agdiBlSJ2yMLyrlwdw80WL5jskn_fuVgO2jffkyfFY=.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
man_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484=iYr0TUeVJZ2xSBy9gvelUf2HiK2uP3Lh5EsoBqfoACw=




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

Re: [netmod] Regarding IPR on draft-lengyel-netmod-yang-instance-data-04

[Benoit Claise]

"No, I'm not aware of any IPR that applies to this draft"

Regards, B.

Authors, Contributors, WG,

As part of preparation for WG Adoption

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



.



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

Re: [netmod] "iana" in yang modules' name/namespace/prefix

[Benoit Claise]

Martin,

I'm wonder whether this is really an important optimization, worth 
changing now, in the hypothetical case that IANA is not called IANA any 
longer in the future?

Right now, "iana" n the YANG module name correctly states what this is about
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
    => "maintained by IANA"
I agree with Jürgen that documenting this in 6087bis is the right way 
forward.


Regards, Benoit.

Hello

As part of a recent IESG review (of draft-bfd-yang) a point came up on 
the use of "iana" in yang modules' name/namespace/prefix.
This is typically used in the case where the module refers to an IANA 
maintained registry. However, the point raised was that the name of 
the registry operator might not always be IANA, and that using that 
name might not put modules on the most stable deployment footing under 
all possible circumstances.


On top of that, as far as I can tell, the use of "iana" is an 
undocumented convention.


So, I wanted to collect views:
on whether a convention should be documented,
and, with regards to the point raised in IESG, on whether that keyword 
should be changed going forward. In that context, what about "reg" 
(for registry) or "regop" (for registry operator)? Other proposals are 
welcome.


Thanks
-m

___
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] Mail regarding draft-ietf-netmod-sub-intf-vlan-model

[Benoit Claise]

Hi,

Note that draft-ietf-netmod-sub-intf-vlan-model expired.
As a consequence, we're not extracting the YANG module(s) any longer in 
the IETF and yangcatalog.org toolchain.


Regards, Benoit

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

Re: [netmod] schema mount situation and next steps

[Benoit Claise]

Dear all,

Some recent news regarding the schema mount.
Sometimes, magic happens when people speak to each others face to face.
It did happen this week and there is a new schema mount plan that should 
make everybody a little bit happier.
The second NETMOD  session (Wednesday) will exclusively focus on the 
schema mount.


Regards, Benoit (OPS AD)

Dear all,

In the last two weeks, I've been multiplying the schema mount discussions.
It's now time to draw the conclusions and to move on.

I'm sad that schema-mount is not NMDA compliant. We approved 
RFC6087bis with the NMDA transition guidelines.
I'm sad that progression to IETF-LC has not been completed on the 
schema-mount document since the WGLC in November.


As discussed with the document shepherd Joel, there is not a strong 
support position for the schema mount document (version 08), but rough 
consensus. The interaction with YANG library bis has been noted during 
the WGLC. What happened since that WGLC closure on Nov6th is that the 
people position became tougher and that multiple possible tracks have 
been investigated. I believe we heard the arguments from everybody.


Taking my AD responsibilities, what's next?

1. We have been losing so much time (which I regret) since the WGLC 
that publishing 08 now makes sense, solving one aspect of the problem: 
the situation where the set of YANG modules is the same in all 
datastores. Is this perfect solution? Certainly not.
The LNE and NI documents, in the RFC editor queue, depend on the 
version 8 of schema mount.

So let's pursue that publication path.

2. The document 08 should be edited before requesting the publication.
- The draft should be clearly specified that this solution is not 
fully NMDA complaint. For example, in the abstract
- The draft should mention an applicability statement, such as the one 
the chairs proposed:


This work was produced during the period when NMDA solutions were being
developed in parallel. While the model defined in this document can be
used with both NMDA and non-NMDA supporting implementations, there are
limitations in its NMDA applicability. When used with Yang Library
[RFC7895] only non-NMDA implementations can be supported. When used with
the revised Yang Library defined in [I.D.ietf-netconf-rfc7895bis], NMDA
implementations can be supported with certain limitations. Specifically,
this document requires use of the now deprecated module-list grouping,
and the same schema represented in schema list of ietf-schema-mount MUST
be used in all datastores. Inline type mount points, which don't use the
schema list, don't have this limitation as they  can support different
schema in different datastores by instantiating the
[I.D.ietf-netconf-rfc7895bis] version of YANG library under the inline
mount point. A future revision of this work is expected to provide for
full NMDA support.

- Some edits are needed: the nits from the YD review
https://www.ietf.org/mail-archive/web/netmod/current/msg19443.html
Another one, addressing one of Lada's important complaints.

The use of mount points does not impact the nature of the mounted data
or in which datastore information is made available. For example, the
datastore from which YANG Library module information may be obtained is
not impacted by the use of schema mount.  This is case for both the top
level YANG Library module and any YANG Library modules included under a
mount point. The Schema Mount module itself MUST be present in the same
datastore as the YANG Library module.

Next, we want to work on a NMDA solution, based on the pre-09 version 
... I guess.
This solution will obsolete the current 08 document and reference the 
YANG library bis.


Let's dedicate the full second NETMOD session (on Wednesday) to schema 
mount and let's use our energy to focus on the best solution.


Regards, Benoit (as OPS AD)




___
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] schema mount situation and next steps

[Benoit Claise]

Dear all,

In the last two weeks, I've been multiplying the schema mount discussions.
It's now time to draw the conclusions and to move on.

I'm sad that schema-mount is not NMDA compliant. We approved RFC6087bis 
with the NMDA transition guidelines.
I'm sad that progression to IETF-LC has not been completed on the 
schema-mount document since the WGLC in November.


As discussed with the document shepherd Joel, there is not a strong 
support position for the schema mount document (version 08), but rough 
consensus. The interaction with YANG library bis has been noted during 
the WGLC. What happened since that WGLC closure on Nov6th is that the 
people position became tougher and that multiple possible tracks have 
been investigated. I believe we heard the arguments from everybody.


Taking my AD responsibilities, what's next?

1. We have been losing so much time (which I regret) since the WGLC that 
publishing 08 now makes sense, solving one aspect of the problem: the 
situation where the set of YANG modules is the same in all datastores. 
Is this perfect solution? Certainly not.
The LNE and NI documents, in the RFC editor queue, depend on the version 
8 of schema mount.

So let's pursue that publication path.

2. The document 08 should be edited before requesting the publication.
- The draft should be clearly specified that this solution is not fully 
NMDA complaint. For example, in the abstract
- The draft should mention an applicability statement, such as the one 
the chairs proposed:


   This work was produced during the period when NMDA solutions were being
   developed in parallel. While the model defined in this document can be
   used with both NMDA and non-NMDA supporting implementations, there are
   limitations in its NMDA applicability. When used with Yang Library
   [RFC7895] only non-NMDA implementations can be supported. When used with
   the revised Yang Library defined in [I.D.ietf-netconf-rfc7895bis], NMDA
   implementations can be supported with certain limitations. Specifically,
   this document requires use of the now deprecated module-list grouping,
   and the same schema represented in schema list of ietf-schema-mount MUST
   be used in all datastores. Inline type mount points, which don't use the
   schema list, don't have this limitation as they  can support different
   schema in different datastores by instantiating the
   [I.D.ietf-netconf-rfc7895bis] version of YANG library under the inline
   mount point. A future revision of this work is expected to provide for
   full NMDA support.

- Some edits are needed: the nits from the YD review
https://www.ietf.org/mail-archive/web/netmod/current/msg19443.html
Another one, addressing one of Lada's important complaints.

   The use of mount points does not impact the nature of the mounted data
   or in which datastore information is made available. For example, the
   datastore from which YANG Library module information may be obtained is
   not impacted by the use of schema mount.  This is case for both the top
   level YANG Library module and any YANG Library modules included under a
   mount point. The Schema Mount module itself MUST be present in the same
   datastore as the YANG Library module.

Next, we want to work on a NMDA solution, based on the pre-09 version 
 I guess.
This solution will obsolete the current 08 document and reference the 
YANG library bis.


Let's dedicate the full second NETMOD session (on Wednesday) to schema 
mount and let's use our energy to focus on the best solution.


Regards, Benoit (as OPS AD)


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

[netmod] RFC 8340 to 8346 published

[Benoit Claise]

Dear all,

RFC8340 | 
draft-ietf-netmod-yang-tree-diagrams-06.txt
RFC8341 | 
draft-ietf-netconf-rfc6536bis-09.txt
RFC8342 | 
draft-ietf-netmod-revised-datastores-10.txt
RFC8343 | 
draft-ietf-netmod-rfc7223bis-03.txt
RFC8344 | 
draft-ietf-netmod-rfc7277bis-03.txt
RFC8345 | 
draft-ietf-i2rs-yang-network-topo-20.txt
RFC8346 | 
draft-ietf-i2rs-yang-l3-topology-16.txt


Congratulations to all persons involved.

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

[netmod] YANG modules publication: what to focus on next? March 14th

[Benoit Claise]

Added: draft-ietf-lime-yang-connection-oriented-oam-model-06 
<https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/> 




 Forwarded Message 
Subject: 	[netmod] YANG modules publication: what to focus on next? Feb 
16th

Date:   Fri, 16 Feb 2018 11:35:45 +0100
From:   Benoit Claise <bcla...@cisco.com>
To: NETMOD Working Group <netmod@ietf.org>



Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
<https://www.rfc-editor.org/current_queue.php>)


Recently, we processed some more YANG modules:
    On the Feb 22nd telechat we added: 
draft-ietf-lime-yang-connection-oriented-oam-model-06 
<https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/>
    On the March 8th telechat, we added: 
draft-ietf-netmod-syslog-model-24 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/>
    One last DISCUSS on draft-ietf-pim-yang-15 
<https://datatracker.ietf.org/doc/draft-ietf-pim-yang/>


We now have many YANG modules in RFC editor queue:**
**draft-ietf-netconf-rfc6536bis-09 (AUTH48) 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis>**
draft-ietf-netmod-revised-datastores-10 (AUTH48) 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>
*draft-ietf-netmod-yang-tree-diagrams-05 (expedited processing) 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/>
**draft-ietf-lime-yang-connectionless-oam-18 
<https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam>**
draft-ietf-lime-yang-connectionless-oam-methods-13 
<https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods>**
**draft-ietf-lime-yang-connection-oriented-oam-model-06 
<https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/>
draft-ietf-i2rs-yang-l3-topology-16 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology>**
draft-ietf-i2rs-yang-network-topo-20 
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo>**
draft-wu-l3sm-rfc8049bis-11 
<https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis>
*draft-ietf-netmod-rfc7223bis-03 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/>
draft-ietf-netmod-rfc7277bis-03 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/>
draft-ietf-rtgwg-yang-vrrp-09 
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/>
draft-ietf-rtgwg-yang-rip-08 
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/>
draft-ietf-netmod-rfc8022bis-10 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/>
draft-ietf-netmod-entity-08 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/>
draft-ietf-rtgwg-ni-model-06 
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/>
draft-ietf-rtgwg-lne-model-09 
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/>
draft-ietf-pim-yang-15 (almost there: one last DISCUSS) 
<https://datatracker.ietf.org/doc/draft-ietf-pim-yang/>



Here are the YANG module dependencies 
<https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ip[]=ietf-connectionless-oam[]=ietf-lime-time-types[]=ietf-connectionless-oam-methods[]=ietf-l3-unicast-topology[]=ietf-l3-unicast-topology-state[]=ietf-network-topology[]=ietf-network-topology-state[]=ietf-network[]=ietf-network-state[]=ietf-l3vpn-svc[]=ietf-netconf-acm[]=ietf-interfaces[]=ietf-vrrp[]=ietf-rip[]=ietf-datastores[]=ietf-origin[]=ietf-ipv4-unicast-routing[]=ietf-ipv6-unicast-routing[]=ietf-ipv6-router-advertisements[]=ietf-routing[]=iana-hardware[]=ietf-hardware[]=ietf-hardware-state[]=ietf-logical-network-element[]=ietf-network-instance[]=ietf-syslog[]=ietf-connection-oriented-oam[]=ietf-pim-base[]=ietf-pim-dm[]=ietf-pim-sm[]=ietf-pim-bidir[]=ietf-pim-rp=1=1_subm=1_dir=dependencies> 
for these RFC editor modules, as requirement before publishing.


It takes a little bit of re-arrangering the elements, but all the 
information regarding YANG module dependency is there.


The next bottlenecks for publishing those YANG modules are:
    draft-ietf-netmod-schema-mount (kind of an impasse right now: to be 
discussed in NETMOD)

    ietf-bfd-yang (currently under review by the YANG doctors)
    draft-ietf-ospf-yang (currently under review by the YANG doctors)
    draft-ietf-isis-yang-isis-cfg (currently under review by the YANG 
doctors)

    draft-ietf-netconf-keystore (to be discussed in NETMOD)
    draft-ietf-netconf-tls-client-server
Pleas

Re: [netmod] Closing this issue: choice/case in tree diagrams (draft-ietf-netmod-yang-tree-diagrams-06)

[Benoit Claise]

Thanks all.
This issue is closed and we will apply this change right now, part of 
the AUTH48 process.


Regards, Benoit

Dear all,

The document draft-ietf-netmod-yang-tree-diagrams-06 is in AUTH48.
It's time to close this issue, let me copy i...@ietf.org.
If you object to the change below, let me know before the end of the 
week.


The changes are to the text, so that the text is adapted to what the 
tools do.  No need to change the examples, or tooling.


OLD:
    is one of:
   rw  for configuration data
   ro  for non-configuration data, output parameters to rpcs
   and actions, and notification parameters
   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement
  NEW:
    is one of:
   rw  for configuration data- and choice nodes
   ro  for non-configuration data- and choice nodes,
   output parameters to rpcs and actions, and
   notification parameters
   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement
 case nodes do not have any .

and

OLD:

  is the name of the node
   () means that the node is a choice node
  :() means that the node is a case node

   If the node is augmented into the tree from another module,
   its name is printed as :, where  is the
   prefix defined in the module where the node is defined.

NEW:

  is the name of the node
   () means that the node is a choice node
  :() means that the node is a case node

   If the node is augmented into the tree from another module,
   its name is printed as :, where  is the
   prefix defined in the module where the node is defined.

   If the node is a case node, there is no space before the
   .

Regards, Benoit


Juergen Schoenwaelder  writes:


On Tue, Mar 06, 2018 at 10:44:11AM +0100, Martin Bjorklund wrote:

OLD:

     is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

NEW:

     is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

  case nodes do not have any .

I still think that it should be 'data node' instead of just
'data'. While not formally imported, the term 'data node' has a
definition in RFC 7950.

NEWER:

  is one of:
   rw  for configuration data nodes

If we keep it also for choices, then it has to be "schema nodes".

   ro  for non-configuration data nodes, output parameters 
to rpcs

   and actions, and notification parameters

Same here.

Lada


   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement

   case nodes do not have any .
  /js

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

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


.



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

Hi,

On Thu, Mar 08, 2018 at 04:08:32PM -0800, Andy Bierman wrote:

I don't really know what a guideline should say about patterns.
I will try to add something that says to document the pattern limitations
and keep the pattern as simple as possible,


I object to a statement that "pattern should be as simple as
possible".
The only guideline that makes sense is: "the pattern must be correct" or 
"the pattern must be meaningful". Not even worth mentioning, as this is 
so obvious!
Whether it's a simple or a complex regex is orthogonal here: the pattern 
must fulfill its job.


Adam, if you still believe something is missing, can you suggest some text.

Regards, Benoit


/js



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

On 3/9/2018 2:27 AM, Adam Roach wrote:

On 3/8/18 12:18 PM, Clyde Wildes (cwildes) wrote:

Adam,

An earlier version of the model (draft-ietf-netmod-syslog-model-08 
and prior) included “terminal” as a syslog destination which 
addresses your requirement below:


 +--rw terminal {terminal-action}?
 |  +--rw all-terminals!
 |  |  +--rw log-selector
 |  | +--rw (selector-facility)
 |  | |  +--:(no-log-facility)
 |  | |  |  +--rw no-facilities?   empty
 |  | |  +--:(log-facility)
 |  | | +--rw log-facility* [facility]
 |  | |    +--rw facility union
 |  | |    +--rw severity union
 |  | |    +--rw severity-operator? enumeration 
{selector-sevop-config}?
 |  | +--rw pattern-match?   string 
{selector-match-config}?
 |  +--rw terminal* [name] 
{terminal-facility-user-logging-config}?

 | +--rw name    string
 | +--rw log-selector
 |    +--rw (selector-facility)
 |    |  +--:(no-log-facility)
 |    |  |  +--rw no-facilities?   empty
 |    |  +--:(log-facility)
 |    | +--rw log-facility* [facility]
 |    |    +--rw facility union
 |    |    +--rw severity union
 |    |    +--rw severity-operator? enumeration 
{selector-sevop-config}?
 |    +--rw pattern-match?   string 
{selector-match-config}?


A consensus of the group was that it was best to remove this 
destination in the model as a simplification, and that vendors that 
supported same could add it back through an augmentation.


Thanks for the history -- that's useful to know. I don't have any 
desire to re-open a settled issue, so please don't read my response as 
a request to go back to the older, more complex model.


My concern now is that the unstated assumption above isn't indicated 
in the document; and absent such a treatment, I fear that some vendors 
may do what you expect (extend the model), while some may do what I 
mentioned (expect terminal syslog output to be provisioned via a 
special filesystem node using the "file" subtree). This ambiguity 
doesn't seem ideal.


I would suggest that the document have text specifically indicating 
that terminal output with requirements more complex than the console 
subtree currently provides are expected to be supported via vendor 
extensions rather than handled via the file subtree.

That makes sense.

Regards, B.


/a

.



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

On 3/8/2018 3:31 PM, Martin Bjorklund wrote:

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

On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:

I see two solutions from here.
1. we mention "pyang -f yang --yang-canonical --keep-comments FILE" in
RFC6087bis, with a warning such as: "As the tool matures, a human
might need
to polish the results"
2. we don't mention "pyang -f yang --yang-canonical --keep-comments
FILE" in
RFC6087bis, but we ask the YANG doctors to run the tests.

I am not sure it is a good idea to hard code command line options of
specific tools in a BCP document. We should require that things are
consistently indented and stay away from the advice of the day how
to achieve that.

RFC 6087 mentions "pyang --ietf"  and
draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree
--tree-line-length 50"

Maybe we can say that "for example, a tool like pyang can be used ..."

This is a good compromise I would say.

Regards, Benoit



If not in RFC6087bis, where would we document this?
As a rhetorical question: How many of the YANG doctors were aware of
and are enforcing this command?

Background Info.
Typical question I've been receiving lately (in this case from IANA):
When requesting the final files from the RFC-Editor, the file they
extracted using their tool and the yang modules appear to have a lot
of blank space in them. Is this OK?

The extraction tools often produce additional blank lines b/c it is
tricky to know how many blank lines were in the original module when
all you have is the RFC in ascii.


/martin
.



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:

I see two solutions from here.
1. we mention "pyang -f yang --yang-canonical --keep-comments FILE" in
RFC6087bis, with a warning such as: "As the tool matures, a human might need
to polish the results"
2. we don't mention "pyang -f yang --yang-canonical --keep-comments FILE" in
RFC6087bis, but we ask the YANG doctors to run the tests.

I am not sure it is a good idea to hard code command line options of
specific tools in a BCP document. We should require that things are
consistently indented and stay away from the advice of the day how
to achieve that.
RFC 6087 mentions "pyang --ietf"  and 
draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree 
--tree-line-length 50"


If not in RFC6087bis, where would we document this?
As a rhetorical question: How many of the YANG doctors were aware of and 
are enforcing this command?


Background Info.
Typical question I've been receiving lately (in this case from IANA):
When requesting the final files from the RFC-Editor, the file they 
extracted using their tool and the yang modules appear to have a lot of 
blank space in them. Is this OK?


Regards, Benoit


/js



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

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

On 3/8/2018 2:15 PM, Eric Rescorla wrote:



On Thu, Mar 8, 2018 at 12:41 AM, Benoit Claise <bcla...@cisco.com 
<mailto:bcla...@cisco.com>> wrote:


Eric,

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
<https://www.ietf.org/iesg/statement/discuss-criteria.html>
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
<https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/>



--
COMMENT:
--

https://mozphab-ietf.devsvcdev.mozaws.net/D4614
<https://mozphab-ietf.devsvcdev.mozaws.net/D4614>

It's not a problem with this document, but I took a quick look at
draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a 
few
examples:

- You can set the cipher suite but not key sizes and groups You can
- say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
  1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)

I'll try to get a chance to give this a real review, but I wanted to 
mention it
before I forgot.

We are using definitions of syslog protocol from [RFC5424] in this
RFC.
Not a big deal, but this introduction feels like it ought to say what the
document is about, not just about syslog.

The severity is one of type syslog-severity, all severities, or none.
None is a special case that can be used to disable a filter.  When
filtering severity, the default comparison is that messages of the
This seems to be the first use of the term filter to mean this entity

I'm not sure I understand the call for action here.
In the YANG module, we called this facility-filter:


The introductory text here says:

"

   Within each action, a selector is used to filter syslog messages.  A
   selector consists of a list of one or more facility-severity matches,
   and, if supported via the select-match feature, an optional regular
   expression pattern match that is performed on the [RFC5424] field."

Perhaps"

"A selector consists of a list of one or more filters specified by
facility-severity pairs and, if supported..."

Got it. That makes sense.




       container facility-filter {

  description
"This container describes the syslog filter parameters.";
  list facility-list {
...


  subtree, implementations MUST NOT specify a private key that is
  used for any other purpose.
It seems like the data that syslog writes is sensitive, so the ability to 
write
a destination reflects a high degree of risk.

Again, what is the call for action here?


That the text say that writing those fields is dangerous. This is 
related to the secdir review comment that Kathleenamplifies in her 
comment.

Ack.


Regards, Benoit


-Ekr


Regards, B.

.






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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

Hi Adam,

Adam Roach has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/



--
COMMENT:
--

Thanks for this document. It is well-written and I believe it will be helpful.
Comments follow.

---

General:

I've reviewed a couple of YANG modules where the indentation and/or wrapping was
awkward and inconsistent. I would love to see guidance in this document that
authors be careful to run their modules through pyang (or a similar tool) to
ensure consistent formatting. It may be worthwhile to give an example of the
exact commandline invocation of pyang to achieve a formatting that is consistent
with existing published modules.
We've been in discussion with the RFC editor lately (Sandy, cc'ed) on 
this important topic.
And also with IANA, which should be keep the source of truth for IETF 
YANG modules (but this is not that easy. More on this later).


From a YANG language point of view, as long as the module validates, 
we're good.
But OTOH, we do require some common style from the published modules, 
for example we want all lines to be properly indented and we require 
space characters between some tokens etc. Consistency is easier for readers


With the RFC editors, we agreed on this high level process:
    - extract the YANG file
    - run pyang -f yang --yang-canonical --keep-comments FILE
    - ask the authors if they are okay with the output file (before 
replacing it in the RFC (to be) for review)

    - assuming they agree, update the RFC
    - then transmit the module to IANA for publication.

During the discussion, Martin Bjorklund (THE pyang main developer), 
expressed:


 Such a tool will of course blindly produce consistent output, but
 sometimes a human needs to polish the result anyway.

 ...

   Unfortunately, I don't think the tool is quite ready to be used in an
   automated fashion.  It does produce consistent output wrt indentation
   and quotes etc, but it doesn't do a good job when it comes to handling
   long lines.  As an example, if the original module has:

  pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

   the tool will print:

  pattern 
'[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';


   I have just released a new version of pyang, 1.7.4, which fixes one
   issue with "-f yang" that has been discussed on the mailing list.

I see two solutions from here.
1. we mention "pyang -f yang --yang-canonical --keep-comments FILE" in 
RFC6087bis, with a warning such as: "As the tool matures, a human might 
need to polish the results"
2. we don't mention "pyang -f yang --yang-canonical --keep-comments 
FILE" in RFC6087bis, but we ask the YANG doctors to run the tests.


Considering that not many people know those specific pyang parameters, I 
would favor solution 1.


Feedback?

Regards, Benoit

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

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

Eric,

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/



--
COMMENT:
--

https://mozphab-ietf.devsvcdev.mozaws.net/D4614

It's not a problem with this document, but I took a quick look at
draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a few
examples:

- You can set the cipher suite but not key sizes and groups You can
- say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
  1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)

I'll try to get a chance to give this a real review, but I wanted to mention it
before I forgot.

We are using definitions of syslog protocol from [RFC5424] in this
RFC.
Not a big deal, but this introduction feels like it ought to say what the
document is about, not just about syslog.

The severity is one of type syslog-severity, all severities, or none.
None is a special case that can be used to disable a filter.  When
filtering severity, the default comparison is that messages of the
This seems to be the first use of the term filter to mean this entity

I'm not sure I understand the call for action here.
In the YANG module, we called this facility-filter:

   container facility-filter {
 description
   "This container describes the syslog filter parameters.";
 list facility-list {
   ...



  subtree, implementations MUST NOT specify a private key that is
  used for any other purpose.
It seems like the data that syslog writes is sensitive, so the ability to write
a destination reflects a high degree of risk.

Again, what is the call for action here?

Regards, B.



.



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

Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

Hi Alvaro,

Alvaro Retana has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/



--
COMMENT:
--

(1) This sentence in the Introduction caught my attention: "This document
defines a set of usage guidelines for Standards Track documents containing
YANG...data models."The Abstract extends to say that "Applicable portions
may be used as a basis for reviews of other YANG data model documents."

I don't remember a non-Standards Track document off the top of my head [*], but
I'm sure the guidelines apply to any IETF document containing a module.  Is
that true?

In my mind, yes. I don't see why we would make a distinction.
I believe the text should be improved.

As history, this sentence is a cut/paste from RFC6087.


I see, for example, that in 4.1 (Module Naming Conventions) it is clear how
modules published by the IETF should be named...and a note is included about
what other SDOs might do.  Are there cases where the guidelines are only
applicable to Standards Track documents, but would not apply to other IETF
documents?

I don't think so.

Regards, B.


This may be a nit, but I think it is good to close this door before the
justification for non-compliance starts being the Status of a document.

[*] I do remember the IESG talking about whether a document with a module for
an Experimental protocol should be in the Standards Track or not.  IMHO, what
matters is for the module to be used (i.e. correct, implementable, implemented,
etc.) and not the status of the document it is in.

(2) The second paragraph in 2.1. (Requirements Notation) is not needed: "RFC
2119 language...as if it were describing best current practices."  This
document is now a BCP.


___
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] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

Hi Alexey, Warren,

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/



--
COMMENT:
--

Thank you for this document.

I also prefer for TCP to be documented, if used in real world.
I've seen this comment in Warren's comment at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/#warren-kumari. 
However, I can't find his ballot in email.

So let me reply to both of you here.

This was discussed on the NETMOD mailing list. See subject "I-D Action: 
draft-ietf-netmod-syslog-model-19.txt"

The fact is that RFC 6587 is now historic, implying a historic downref.

I'm in favor to publish the document as it is right now, whose 00 WG 
doc. version dates from Nov 2014.

Augmenting a YANG module, if TCP is required, is not that hard.

Regards, Benoit


Some minor comments:

1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when you
mention it for the first time.

2) On page 19:

Example: compare->equals and action->no-match means
messages that have a severity that is not equal to the
specified severity will be logged.";

Do you mean "action->block" instead of "action->no-match"?

3) When logging to file: how is the file name constructed from the name file:
URI if multiple files are preserved by the system? E.g. if the log file is
rotated daily and 5 last files are preserved, how does each individual filename
look? If I understood how this is used, this needs more clarification.

4) Nit: on page 18, typo in "spectify"


.



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

Re: [netmod] Alexey Melnikov's Yes on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

Alexey,

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/



--
COMMENT:
--

Thank you for a great document. Some minor comments:

3.8.  IANA Considerations Section

In order to comply with IESG policy as set forth in
http://www.ietf.org/id-info/checklist.html, every Internet-Draft that
is submitted to the IESG for publication MUST contain an IANA
Considerations section.  The requirements for this section vary
depending on what actions are required of the IANA.  If there are no
IANA considerations applicable to the document, then the IANA
Considerations section stating that there are no actions is removed
by the RFC Editor before publication.

IANA's and RFC Editor opinion about empty IANA Considerations section has
changed over time (and might change again), so I would not make this statement.
I don't think this is necessarily the current policy. RFC Editor asks, but
doesn't enforce this. So I suggest changing "is removed" to "might be removed".

That makes sense.


[I-D.ietf-netmod-revised-datastores] - I am pretty sure that some uses of this
document are normative, so you should move it to Normative References.

Well spot. This is required by the terminology section 2.4


Regards, Benoit



.



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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)

[Benoit Claise]

Suresh,



On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan > wrote:


Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/




--
DISCUSS:
--

* Section 4.25

I think this might be a simple misunderstanding but I have no idea
what
compliance with this statement implies.

"A YANG module MUST NOT be designed such that the set of modules
found on a
server implementation can be predetermined in advance."

Can you please clarify?



OK to remove this sentence.
Not sure where it came from


--
COMMENT:
--

Section 3.2:
  The date looks to be contradictory between the explanatory text

"The following example is for the '2010-01-18' revision of the 
'ietf-foo'
module:"

and the actual code component defined right after

                    file "ietf-...@2016-03-20.yang"
...
                                 revision 2016-03-20 {
...



OK will update revision date


* Section 4.8

I went over this text several times to figure out what it means.
Can you
simplify this, or provide examples as to when revision dates
are/are not to be
updated.

   It is not required to keep the full revision history of draft
   versions (e.g., modules contained within Internet-Drafts). 
That is,
   within a sequence of draft versions, only the most recent revision
   need be recorded in the module.  However, whenever a new (i.e.
   changed) version is made available (e.g., via a new version of an
   Internet-Draft), the revision date of that new version MUST be
   updated to a date later than that of the previous version.


OK -- will clarify that the same revision-stmt can be reused in an 
Internet Draft.

The revision date is updated if the module is changed.
What we mean here is that the published RFC should contain something 
such as:


 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }


As opposed to the full draft history and change log

 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }

 revision 2017-11-01 {
   description
 "Updated to address AD review.";
   reference
 "draft-ietf-netmod-rfc7223bis-03";
 }

 revision 2017-09-01 {
   description
 "Updated to address issue X, Y, Z";
   reference
 "draft-ietf-netmod-rfc7223bis-02";
 }




* Section 4.20

What does "cannot" imply here? MUST NOT? SHOULD NOT?



MUST NOT -- per RFC 7950, 7.20.3


"The YANG "deviation" statement cannot appear in IETF YANG modules"



Will change "cannot" to is not allowed to"
There is not point to repeat the RFC7950 specifications, but we want to 
add to it.

Therefore, let me propose:

OLD:

   The YANG "deviation" statement cannot appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.



NEW:

   Per RFC 7950, 7.20.3, the YANG "deviation" statement is not allowed to 
appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.

Regards, Benoit

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

[netmod] Closing this issue: choice/case in tree diagrams (draft-ietf-netmod-yang-tree-diagrams-06)

[Benoit Claise]

Dear all,

The document draft-ietf-netmod-yang-tree-diagrams-06 is in AUTH48.
It's time to close this issue, let me copy i...@ietf.org.
If you object to the change below, let me know before the end of the week.

The changes are to the text, so that the text is adapted to what the tools do.  
No need to change the examples, or tooling.

OLD:
is one of:
   rw  for configuration data
   ro  for non-configuration data, output parameters to rpcs
   and actions, and notification parameters
   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement
  NEW:
is one of:
   rw  for configuration data- and choice nodes
   ro  for non-configuration data- and choice nodes,
   output parameters to rpcs and actions, and
   notification parameters
   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement
 case nodes do not have any .

and

OLD:

  is the name of the node
   () means that the node is a choice node
  :() means that the node is a case node

   If the node is augmented into the tree from another module,
   its name is printed as :, where  is the
   prefix defined in the module where the node is defined.

NEW:

  is the name of the node
   () means that the node is a choice node
  :() means that the node is a case node

   If the node is augmented into the tree from another module,
   its name is printed as :, where  is the
   prefix defined in the module where the node is defined.

   If the node is a case node, there is no space before the
   .

Regards, Benoit


Juergen Schoenwaelder  writes:


On Tue, Mar 06, 2018 at 10:44:11AM +0100, Martin Bjorklund wrote:

OLD:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

NEW:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

  case nodes do not have any .

I still think that it should be 'data node' instead of just
'data'. While not formally imported, the term 'data node' has a
definition in RFC 7950.

NEWER:

  is one of:
   rw  for configuration data nodes

If we keep it also for choices, then it has to be "schema nodes".


   ro  for non-configuration data nodes, output parameters to rpcs
   and actions, and notification parameters

Same here.

Lada


   -w  for input parameters to rpcs and actions
   -u  for uses of a grouping
   -x  for rpcs and actions
   -n  for notifications
   mp  for nodes containing a "mount-point" extension statement

   case nodes do not have any .
  
/js


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

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


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

Re: [netmod] choice/case in tree diagrams

[Benoit Claise]

On 3/6/2018 10:44 AM, Martin Bjorklund wrote:

Hi,

After thinking some more about this, realizing that this document is
in AUTH48, and looking at the first sentence in the Abstract:

This document captures the current syntax used in YANG module tree
diagrams.

I have reached the conclusion that we probably shouldn't make any
drastic changes.

Obviously, otherwise I send the document back to the WG.

Regards, Benoit


The current syntax, with flags for choice but not for case, may look a
bit odd, but it does follow RFC 7950 where a choice node can have a
config property, but case cannot.  Also, this syntax has now been used
for several years w/o causing much confusion.

I suggest the following changes to this document:

OLD:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

NEW:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statement

  case nodes do not have any .

Then, since the syntax requires whitespace before :

  --   

we need to fix the examples:

OLD:

  +--rw (root-type)
 +--:(vrf-root)

NEW:

  +--rw (root-type)
 +-- :(vrf-root)

(two occurances)



/martin



Vladimir Vassilev  wrote:


On 03/05/2018 06:40 PM, Per Hedeland wrote:

On 2018-03-05 16:06, Ladislav Lhotka wrote:

On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:

On 2018-03-05 15:41, Ladislav Lhotka wrote:

On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:

Juergen Schoenwaelder  wrote:

On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:

So it seems the running code got it right. ;-)

As the author of that code, I think that was purely by accident...

But I'm not convinced it is the correct solution.  We have one example
in the other thread where someone was confused by the "rw" flag and
thought that it implied that the node would be present in the data
tree.


So what does rw mean?

(i)  The schema node has a rw property.
(ii) The schema node can be instantiated and the instantiated data
node
   has a rw property.

I think it is difficult to have both at the same time. If the tree is
a representation of schema nodes, then (i) seems to make more
sense. That said, the explanation in 2.6 is somewhat vague since it
says 'data' and not 'nodes' (like everywhere else):

OLD:

  is one of:
   rw  for configuration data
   ro  for non-configuration data, output parameters to rpcs
   and actions, and notification parameters

NEW:

  is one of:
   rw  for configuration data nodes
   ro for non-configuration data nodes, output parameters to
   rpcs
   and actions, and notification parameters

I think this is ok.  But that means that we also have to add:

 --  for a choice or case node

But in order to be consistent, we should probably have:

 --  for a choice, case, input or output node

But unlike the three other statements, "choice" can have the config
substatement, so "rw/ro" makes sense there.

I don't think so - that config statement does not a define a property
of
the choice node (it can obviously neither be read nor written), only a
default for descendant data nodes, as described in section 7.21.1 of
RFC
7950.

It is not a default - if a choice has "config false", then no
descendant can be
"config true". One of the benefits of having rw/ro in the ascii tree
is to see
where a state data subtree actually starts.

It is a default, but yes, it is also a restriction in the specific
case
of the argument being "false" at a point where the default would
otherwise be "true". And in that case it is equivalent to having
"config
false" on all the descendant data nodes, and they will of course be
flagged as "ro" regardless of whether the "config false" comes from
the
choice or the individual data nodes - and that is where the state
*data*
suntree(s) actually start(s).

So I guess the question then is whether this specific case motivates
always having flags on specifically choice nodes, while the other
non-data nodes have no flags. Since the 'config' statement is ignored
in
rpc/action input/output and notification, choice nodes there should
then
presumably have 

[netmod] pyang updated to 1.7.4 and yandump-pro to 17.10.5 and yanglint to 0.14.70

[Benoit Claise]

Dear all,

The subject says it all. Please check your module validation. A few 
issues have been solved.

For now, check at http://www.claise.be/IETFYANGPageCompilation.html
Allow an big hour for the results to propagate to yangcatalog.org.

Regards, Benoit

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

Re: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18

[Benoit Claise]

Jürgen,

It makes sense.
This comment should be considered as an IETF LC comment.

Regards, B.

Hi,

I think it was common practice to write

   reference "RFC 6991: Common YANG Data Types";

instead of just

   reference "RFC 6991";

that is to include the RFC title (this can be especially useful with
longer lists of references and less commonly known RFC numbers). It
seems that draft-ietf-netmod-rfc6087bis-18 kind of suggests to only
use the RFC number (section 3.2 and section 4.7).

/js



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

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Benoit Claise]

On 2/22/2018 11:49 AM, t.petch wrote:

- Original Message -
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC

number

is assigned.

Therefore, a note asking the I-D reference to be updated to reflect

the

assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED


Except I know that this draft will be stuck in MISREF state and

tree-diagrams

will in fact be assigned an RFC number by the time this draft is

published.

Kent

Corner case:-)
Note that, for this corner case, the IESG agreed for the tree-diagrams 
to go through expedited processing.
Even if this is an informative reference, it's nicer to get an RFC as a 
reference.


Regards, Benoit



You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.




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

Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2

[Benoit Claise]

Thank you Andy.
Sending to IETF LC now.

Regards, Benoit

Hi,

I think draft-18 addresses all these issues.
A guideline about key leaf order has also been added.

Andy


On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise <bcla...@cisco.com 
<mailto:bcla...@cisco.com>> wrote:


Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in 
various ways"?
Which data? YANG modules, YANG objects, object instances, from different 
YANG server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and 
which guidelines this section
is going to provide to "authors and reviewers of Standards Track specifications 
containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
It is sometimes useful to separate configuration data and operational
state, so that they do not not even share the exact same naming
characteristics.  The correlation between configuration the
operational state that is affected by changes in configuration is a
complex problem.  There may not be a simple 1:1 relationship between
a configuration data node and an operational state node.  Further
work is needed in YANG to clarify this relationship.  Protocol work
may also be needed to allow a client to retrieve this type of
information from a server.  At this time the best practice is to
clearly document any relationship to other data structures in the
"description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:

Designers SHOULD describe and justify any NMDA exceptions in detail,
such as the use of separate subtrees and/or separate leafs.

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?

- section 4.23

Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs 
Guidelines"

- section 4.26.1

  Multiple revisions of the same module can be imported, provided that
  different prefixes are used.

Readinghttps://tools.ietf.org/html/rfc7950#section-7.1.5
<https://tools.ietf.org/html/rfc7950#section-7.1.5>. Any contradiction?
Then reading:
This MAY be done if the authors can
demonstrate that the "avoided" definitions from the most recent of
the multiple revisions are somehow broken or harmful to
interoperability.

"avoided" definitions?
I simply don't understand this sentence.

- section 4.26.4
The NETCONF Access Control Model (NACM) [RFC6536 
<https://tools.ietf.org/html/rfc6536>] does not support
parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

YANG Module Registry: Register the YANG module name, prefix,
  namespace, and RFC number, according to the rules specified
  in [RFC7950 <https://tools.ietf.org/html/rfc7950>].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" 
registry is specified in RFC6020/.
See for 
examplehttps://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6
<https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6>

- Appendix B
References -- verify that the references are properly divided
   between normative and informative references, thatRFC 2119 
<https://tools.ietf.org/html/rfc2119>  is
   included as a normative reference if the terminology defined
   therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words 
about:
   If a YANG module has a Reference or Description clause specifying an
   I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit


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




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

[netmod] YANG modules publication: what to focus on next? Feb 16th

[Benoit Claise]

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
)


We now have many YANG modules in RFC editor queue:**
**draft-ietf-netconf-rfc6536bis-09 (AUTH48) 
**
draft-ietf-netmod-revised-datastores-10 (AUTH48) 

*draft-ietf-netmod-yang-tree-diagrams-05 (expedited processing) 

**draft-ietf-lime-yang-connectionless-oam-18 
**
draft-ietf-lime-yang-connectionless-oam-methods-13 
**
draft-ietf-i2rs-yang-l3-topology-16 
**
draft-ietf-i2rs-yang-network-topo-20 
**
draft-wu-l3sm-rfc8049bis-11 

*draft-ietf-netmod-rfc7223bis-03 

draft-ietf-netmod-rfc7277bis-03 

draft-ietf-rtgwg-yang-vrrp-09 

draft-ietf-rtgwg-yang-rip-08 

draft-ietf-netmod-rfc8022bis-10 

draft-ietf-netmod-entity-08 

draft-ietf-rtgwg-ni-model-06 

draft-ietf-rtgwg-lne-model-05 
 
(actually, almost in the RFC editor queue)



Here are the YANG module dependencies 
 
for these RFC editor modules, as requirement before publishing.


Some more YANG modules are on the IESG table:
    draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)

Assuming this one is in the RFC editor queue, this is the new set of 
YANG module dependencies 
.
It takes a little bit of re-arrangering the elements, but all the 
information regarding YANG module dependency is there.


The next bottlenecks for publishing those YANG modules are:
    draft-ietf-netmod-schema-mount
    ietf-bfd-yang (currently in WG LC)
    draft-ietf-ospf-yang
    draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NETMOD:_
draft-ietf-netmod-syslog-model-17 
 (in 
IETF LC)
draft-ietf-netmod-acl-model-15 
(WG LC 
closed, writeup time)
draft-ietf-netmod-rfc6087bis-17 
 (AD 
review done)

    draft-ietf-netmod-schema-mount:

_NETCONF:_
    Time to progress this set of documents (TLS, SSH, client, server, 
keystore) 

[netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2

[Benoit Claise]

Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various 
ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG 
server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and 
which guidelines this section
is going to provide to "authors and reviewers of Standards Track specifications 
containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
   It is sometimes useful to separate configuration data and operational
   state, so that they do not not even share the exact same naming
   characteristics.  The correlation between configuration the
   operational state that is affected by changes in configuration is a
   complex problem.  There may not be a simple 1:1 relationship between
   a configuration data node and an operational state node.  Further
   work is needed in YANG to clarify this relationship.  Protocol work
   may also be needed to allow a client to retrieve this type of
   information from a server.  At this time the best practice is to
   clearly document any relationship to other data structures in the
   "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?

- section 4.23

Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs 
Guidelines"

- section 4.26.1

 Multiple revisions of the same module can be imported, provided that
 different prefixes are used.

Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
   This MAY be done if the authors can
   demonstrate that the "avoided" definitions from the most recent of
   the multiple revisions are somehow broken or harmful to
   interoperability.

"avoided" definitions?
I simply don't understand this sentence.

- section 4.26.4
   The NETCONF Access Control Model (NACM) [RFC6536 
] does not support
   parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

   YANG Module Registry: Register the YANG module name, prefix,
 namespace, and RFC number, according to the rules specified
 in [RFC7950 ].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry 
is specified in RFC6020/.
See for example 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
  between normative and informative references, thatRFC 2119 
  is
  included as a normative reference if the terminology defined
  therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
  If a YANG module has a Reference or Description clause specifying an
  I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit

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

[netmod] AD review of draft-ietf-netmod-syslog-model-20

[Benoit Claise]

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] 
should be an informative reference, not normative.


- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit

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

Re: [netmod] Missing references

[Benoit Claise]

Hi Henrik,

It makes sense. Thanks.

Regards, B.

Hi Benoit,

On 2018-02-07 12:56, Benoit Claise wrote:

Hi Henrik,

Could this check be added to idnits?

Yes.  I thought I had something like this already, but it was specifically
to look out for mentions of RFC2119.

As you may know, I'm due to begin a complete rewrite of idnits, from the
current implementation (idnits started as a 10-line AWK program to check
draft line lengths, in 2000 or 2001) to Python, this March.  I'd like to
defer this till then; adding code to the now close to 4000 lines of mixed
AWK and bash isn't always straightforward.


Best regards,

Henrik


Regards, Benoit

I just came across (yet) another example of a reference to an RFC in a
description clause of a YANG module that appears nowhere else in the
I-D.

This seems to be a systematic error that some YANG module authors make;
can the tools be modified to pick it up?  The logic is simple enough.

The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to
reference RFC5952;  I think that the I-D is in the RFC Editor queue.

Tom Petch

.





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

Re: [netmod] Missing references

[Benoit Claise]

Hi Henrik,

Could this check be added to idnits?

Regards, Benoit

I just came across (yet) another example of a reference to an RFC in a
description clause of a YANG module that appears nowhere else in the
I-D.

This seems to be a systematic error that some YANG module authors make;
can the tools be modified to pick it up?  The logic is simple enough.

The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to
reference RFC5952;  I think that the I-D is in the RFC Editor queue.

Tom Petch

.



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

Re: [netmod] YANG tree diagram uses

[Benoit Claise]

Martin, Michal,

Do we need any clarification in the draft?

Regards, B.

Michal Vaško  wrote:

Hi,

we have encountered some problem while implementing a feature from
draft-ietf-netmod-yang-tree-diagrams-05, specifically not resolving
groupings and printing uses names instead (Section 2.2).

We have 2 example models, A and B. A defines a container and a
grouping. B defines an augment that adds uses into the container from
A and resolves to the grouping from model A.

grouping A:g;
A:c {
   B:uses A:g;
}

Now, if printing model A with the augment not resolving uses we
currently print

+--rw c
+---u B:A:g;

pyang prints this as well, but it is more "by accident".   It looks
quite odd.

It wouldn't be correct to write

 +---u B:g;

since 'g' isn't defined in B.

OTOH,


 +---u A:g;

is correct in the sense that "A:g" is the "name of the grouping", and
that is what the current document says should be printed.  Granted,
this doesn't show the whole picture, but maybe this is good enough.

It might be wise to not print a grouping like this in order to avoid
confusion.


/martin



since the uses is foreign. We could not decide what the "correct"
output should be and it is likely left to various interpretations but
we were wondering what some of you think. Should it perhaps be only
"B:g" since the grouping becomes local? But what if the grouping would
be from a third model, are 2 prefixes okay? Thanks for your opinions.

Regards,
Michal

___
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] [Fwd: Protocol Action: 'A YANG Data Model for Routing Management (NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)]

[Benoit Claise]

Hi Lada,

The error you see comes from 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/


Yang Validation 
	☯ 1 errors, 0 warnings. 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/#>



So this is flagged at the time of posting the draft.

I covered this false positive in my toolchain, as a daily cronjob
See http://www.claise.be/IETFYANGPageCompilation.html
See 
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv6-router-advertiseme...@2018-01-25.yang


And this populates the following entries.
Additional URLs 

- Yang catalog entry for ietf-ipv4-unicast-rout...@2018-01-25.yang 
<https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv4-unicast-rout...@2018-01-25.yang> 

- Yang catalog entry for ietf-ipv6-router-advertiseme...@2018-01-25.yang 
<https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv6-router-advertiseme...@2018-01-25.yang> 

- Yang catalog entry for ietf-ipv6-unicast-rout...@2018-01-25.yang 
<https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-ipv6-unicast-rout...@2018-01-25.yang> 

- Yang catalog entry for ietf-rout...@2018-01-25.yang 
<https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-rout...@2018-01-25.yang> 

- Yang impact analysis for draft-ietf-netmod-rfc8022bis 
<https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-ipv6-router-advertiseme...@2018-01-25.yang[]=ietf-rout...@2018-01-25.yang[]=ietf-ipv4-unicast-rout...@2018-01-25.yang[]=ietf-ipv6-unicast-rout...@2018-01-25.yang=0=1_subm=1_dir=both> 



See the "compilation-status" field.

The ideal solution is a flag in yanglint not to take into account the 
submodule (that would also simplify my live). I discussed this with 
Radek in the past.
Asking Henrik to take care of the different validator exceptions is very 
time consuming, believe me. So we can't impose that.


The alternative solution is a better integration between the toolchains. 
I'm looking for some extra funding for this (btw, everything is 
opensource). If anybody is able to help, contact me privately.


Regards, Benoit

Hi Benoit,

Yang Validation reports one error for this document:

ietf-ipv6-router-advertiseme...@2018-01-25.yang:
pyang 1.7.3: pyang --verbose --ietf -p {libs} {model}:
No validation errors

yanglint 0.14.59: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib}
{model} -i:
err : Unable to parse submodule, parse the main module instead.

I discussed it with Radek, and the problem is caused by the validation procedure
that tries to validate the submodule ietf-ipv6-router-advertisements separately,
which yanglint cannot do. The submodule is validated along with the main module
ietf-ipv6-unicast-routing to which it belongs.

Is it possible to fix this false positive?

Thanks, Lada

 Forwarded Message 
From: The IESG <iesg-secret...@ietf.org>
To: IETF-Announce <ietf-annou...@ietf.org>
Cc: netmod-cha...@ietf.org, netmod@ietf.org, The IESG <i...@ietf.org>, draft-iet
f-netmod-rfc8022...@ietf.org, rfc-edi...@rfc-editor.org
Subject: [netmod] Protocol Action: 'A YANG Data Model for Routing Management
(NMDA Version)' to Proposed Standard (draft-ietf-netmod-rfc8022bis-11.txt)
Date: Mon, 29 Jan 2018 08:50:48 -0800

The IESG has approved the following document:
- 'A YANG Data Model for Routing Management (NMDA Version)'
   (draft-ietf-netmod-rfc8022bis-11.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/





Technical Summary

This document contains a specification of three YANG modules and one
submodule.  Together the modules  form the core routing data model that
serves as a framework for configuring and managing a routing
subsystem.  These modules are augmented by additional YANG modules
defining data models for control-plane protocols, route filters, and other
functions.  The core routing data model provides common building blocks
for such extensions -- routes, Routing Information Bases (RIBs), and
control-plane protocols.
   
This bis  update to RFC 8022 fully conforms to the Network Management

Datastore Architecture (NMDA). Consequently, this document obsoletes
RFC 8022.

Working Group Summary

Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

Document Quality

WGLC commenced Wed, 29 Nov 2017 completed on Fri, 15 Dec
2017.  A draft revision was performed during the last call to address
editorial issues.  The draft itself is a mechanical update to include
support for the Network Management  Datastore Ar

[netmod] YANG modules publication: what to focus on next? Jan 26th

[Benoit Claise]

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.
Here is an update after yesterday telechat: 
draft-ietf-netmod-rfc8022bis-10 
 and 
draft-ietf-netmod-entity-08 
 are approved


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
)
  Note that draft-ietf-netmod-revised-datastores, a normative reference 
for many YANG modules,

  was just approved. Good news!

We now have many YANG modules in RFC editor queue:
***draft-ietf-lime-yang-connectionless-oam-18 
**
draft-ietf-lime-yang-connectionless-oam-methods-13 
**
draft-ietf-i2rs-yang-l3-topology-16 
**
draft-ietf-i2rs-yang-network-topo-20 
**
draft-wu-l3sm-rfc8049bis-11 

**draft-ietf-netconf-rfc6536bis-09 

*draft-ietf-netmod-rfc7223bis-03 

draft-ietf-netmod-rfc7277bis-03 

draft-ietf-rtgwg-yang-vrrp-09 

draft-ietf-rtgwg-yang-rip-08 

draft-ietf-netmod-revised-datastores-10 

draft-ietf-netmod-rfc8022bis-10 

draft-ietf-netmod-entity-08 



Here are the YANG module dependencies 
 
for these RFC editor modules, as requirement before publishing.


Some more YANG modules are on the IESG table:
    draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)
draft-ietf-rtgwg-ni-model-06 
 is on the 
Feb 8th IESG telechat
draft-ietf-rtgwg-lne-model-05 
 is on the 
Jan 25th IESG telechat
draft-ietf-netmod-yang-tree-diagrams-05 
is 
on the Jan 25th IESG telechat


Assuming those are in the RFC editor queue, this is the new set of YANG 
module dependencies 
.
It takes a little bit of re-arrangering the elements, but all the 
information is there.


The next bottlenecks for publishing those YANG modules are:
    draft-ietf-netmod-schema-mount
    ietf-bfd-yang (currently in WG LC)
    draft-ietf-ospf-yang
    draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NI, LNE, and schema mount, RFC7895bis, schema mount:_
    draft-ietf-rtgwg-lne-model
        Status: on the next IESG telechat
    draft-ietf-rtgwg-ni-model
        Status: on the next IESG telechat
    draft-ietf-netmod-schema-mount:
        Status: Under discussion in NETMOD
    draft-ietf-netconf-rfc7895bis
        Status: Under discussion 

Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1

[Benoit Claise]

Kent,


I see a lot of suggestions to reference other drafts as examples.  I 
would discourage doing that.  I recommend this draft clearly stating 
the desire, including its own examples if needed.


I recall a remark by Rajiv (in cc) during a NETMOD meeting, along the 
lines of:
I want to create a YANG module but I don't have the time/willingness to 
read every single RFCs before doing so. I want a kind of template, along 
with examples on how to populate it.


We have to understand that a document such as RFC6087bis is not for the 
people who know YANG by heart.

So more examples to illustrate the point is obviously better.
Copying examples inside RFC6087bis we could simply references seems a 
waste of time.


Regarding referencing the tree-diagrams draft, I don't agree that 
having a "Tree Diagrams" section in the Introduction is better than an 
inline reference where used:


1) the term "tree diagram" is not anywhere defined

2) sections having tree diagrams have to reference the section in the 
Introduction, and why reference the Intro section when it's just as 
easy to reference the draft?


3) it makes the Introduction and Table of Contents unnecessarily busy


Again, people want easy guidelines/template.

Regards, Benoit


Kent // contributor

On 1/25/18, 6:20 AM, "netmod on behalf of Benoit Claise" 
<netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org> on behalf of 
bcla...@cisco.com <mailto:bcla...@cisco.com>> wrote:


Dear all,


Thank you for this important document.
I've been spending quite some time trying to relay feedback seen on 
multiple fronts.

This is part 1 of the review, till section 4.21


-

    This document defines a set of usage guidelines for Standards Track
    documents containing [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=t8fshSpe0Dhh5uTE8sRNgSXoLTkY-4-nlePaYc1My0A=>] data models.

This is not inline with:
    This section contains the module(s) defined by the specification.
    These modules SHOULD be written using the YANG 1.1 [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=t8fshSpe0Dhh5uTE8sRNgSXoLTkY-4-nlePaYc1My0A=>] syntax.
    YANG 1.0 [RFC6020 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6020=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=L8LZohUWZQHgCc69tSH78w3mmeBF7ZpEaYGfDPYf5-8=>] syntax MAY be used if no YANG 1.1 constructs or

    semantics are needed in the module.
So it should be changed to
    This document defines a set of usage guidelines for Standards Track
    documents containing YANG 1.1 [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=t8fshSpe0Dhh5uTE8sRNgSXoLTkY-4-nlePaYc1My0A=>] and YANG 1.0 [RFC6020] data models.

Similarly in section 4
OLD:

    Modules in IETF Standards Track specifications MUST comply with all
    syntactic and semantic requirements of YANG [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=t8fshSpe0Dhh5uTE8sRNgSXoLTkY-4-nlePaYc1My0A=>].

NEW:
    Modules in IETF Standards Track specifications MUST comply with all
    syntactic and semantic requirements of YANG 1.1 [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_mc=t8fshSpe0Dhh5uTE8sRNgSXoLTkY-4-nlePaYc1My0A=>]. See the exception

    for YANG 1.0 in section 3.6
Note that I tried to add some new text around the following sentence but that 
paragraph became clumsy.
    Alternatively,
    if YANG 1.0 is used, then Modules in IETF Standards Track specifications
    MUST comply with all syntactic and semantic requirements of YANG 1.0 
[RFC6020].
Finally, in section 3.6, I would add a sentence to this paragraph
    This section contains the module(s) defined by the specification.
    These modules SHOULD be written using the YANG 1.1 [RFC7950 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7950=DwMDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=LtO2RQQIegWlN4MIzNkbubIXiwPDj_Uk_qYxqyLA_

Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1

[Benoit Claise]

On 1/25/2018 12:59 PM, Juergen Schoenwaelder wrote:

On Thu, Jan 25, 2018 at 12:20:11PM +0100, Benoit Claise wrote:
  

PROPOSAL (replacing the previous paragraph)

If YANG tree diagrams are used, then a normative reference to the
YANG tree diagrams specification MUST be provided. As an example 
guideline
(from 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
here is a subsection in the terminology section

The current practice is that the tree diagrams reference is an
informative reference and not a normative reference.

Good catch Jürgen.

Regards, Benoit


/js



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

[netmod] AD review of draft-ietf-netmod-rfc6087bis-16 Part 1

[Benoit Claise]

Dear all,

Thank you for this important document.
I've been spending quite some time trying to relay feedback seen on 
multiple fronts.

This is part 1 of the review, till section 4.21


-

   This document defines a set of usage guidelines for Standards Track
   documents containing [RFC7950 ] data 
models.

This is not inline with:
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950 
] syntax.
   YANG 1.0 [RFC6020 ] syntax MAY be used 
if no YANG 1.1 constructs or
   semantics are needed in the module.

So it should be changed to
   This document defines a set of usage guidelines for Standards Track
   documents containing YANG 1.1 [RFC7950 
] and YANG 1.0 [RFC6020] data models.

Similarly in section 4
OLD:
   
   Modules in IETF Standards Track specifications MUST comply with all

   syntactic and semantic requirements of YANG [RFC7950 
].

NEW:
   Modules in IETF Standards Track specifications MUST comply with all
   syntactic and semantic requirements of YANG 1.1 [RFC7950 
]. See the exception
   for YANG 1.0 in section 3.6

Note that I tried to add some new text around the following sentence but that 
paragraph became clumsy.
   Alternatively,
   if YANG 1.0 is used, then Modules in IETF Standards Track specifications
   MUST comply with all syntactic and semantic requirements of YANG 1.0 
[RFC6020].

Finally, in section 3.6, I would add a sentence to this paragraph
   This section contains the module(s) defined by the specification.
   These modules SHOULD be written using the YANG 1.1 [RFC7950 
] syntax.
   YANG 1.0 [RFC6020 ] syntax MAY be used 
if no YANG 1.1 constructs or
   semantics are needed in the module.

The sentence such as:
   if any the imported YANG modules is based on YANG 1.1, the main YANG
   module MUST also be written in YANG 1.1.

 - section 3, editorial:
   There are three usage scenarios for YANG that can appear in an
   Internet-Draft or RFC:

   o  normative module or submodule

   o  example module or submodule

   o  example YANG fragment not part of any module or submodule

   The guidelines in this document refer mainly to a normative_complete_
   module or submodule, but may be applicable to example modules and
   YANG fragments as well.

Either add "complete" to "o  normative module or submodule)" and be consistent 
throughout the document,
or remove it from the last sentence.


- section 3.2

   The "" tag SHOULD be followed by a string identifying
   the file name specified inSection 5.2 of [RFC7950] 
.  The name string
   form that includes the revision-date SHOULD be used.  The following
   example is for the '2010-01-18' revision of the 'ietf-foo' module:

file "ietf-...@2016-03-20.yang"

I would add that both revision versions (on the  and in the 
module) MUST match.
I ran into all sort of tooling issues because of such discrepancies.

- section 3.2.1
Add "see section 4.9 regarding the namespace guidelines for example modules"

- The following in paragraph in section 3.3 seems misplaced.

   If YANG tree diagrams are used, then a normative reference to the
   YANG tree diagrams specification MUST be provided for each diagram.
   (Refer to the example in the next section.)

It should be in section 3.4.
Btw, no need to have the specifications for each diagram!
Also, we want to add some guidelines on how to reference the tree 
diagram convention

For ex: no need to copy over the conventions
Basically, we just need: 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3


PROPOSAL (replacing the previous paragraph)

   If YANG tree diagrams are used, then a normative reference to the
   YANG tree diagrams specification MUST be provided. As an example 
guideline
   (from 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3),
   here is a subsection in the terminology section

   Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [I-D.ietf-netmod-yang-tree-diagrams
   
].

- section 3.5
You should add a good example to illustrate the second paragraph (Based 
on some previous feedback, YANG module designer wants to work from examples)
I would suggest to add 
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-09#section-2.3



- section 3.6, editorial
OLD:

  Note that all YANG statements within a YANG module are considered
   normative, if the module itself is considered normative, and not an
   example module.
NEW:

  Note that 

[netmod] Validators updated in the toolchain

[Benoit Claise]

Dear all,

yanglint upgraded to 0.14.65 from 0.13.79
yangdump-pro upgraded to 17.10-4 from 17.10-3
pyang upgraded to the latest github version (still version 1.7.3), but 
compliant to draft-ietf-netmod-yang-tree-diagrams-05 


confd: not yet upgraded

Some bugs have been fixed with the new versions.

So please checked your YANG modules:
    http://www.claise.be/IETFYANGPageCompilation.html
    OR
    from the tracker
        => Additional URLS
        => Yang catalog entry for 
        => compilation-result
    For example: 
https://yangcatalog.org/results/ietf-lisp-etr@2017-07-01_ietf.html

Note: those results come from the same toolchain

Next step is to upgrade the toolchain on yangvalidator.org

Regards, Benoit



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

Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Benoit Claise]

on is modified, then the system MUST behave as if
   it re-initializes itself, and follow the procedure in
(1).";

NEW:

   When the server detects a new hardware component, it
   initializes a list entry in the operational state.

   If the server does not support configuration of hardware
   components, list entries in the operational state are
   initialized with values for all nodes as detected by the
   implementation.

   Otherwise, the following procedure is followed:

 1. If there is an entry in the /hardware/component list in
the intended configuration with values for the nodes
'class', 'parent', 'parent-rel-pos' that are equal to
the detected values, then the list entry in operational
state is initialized with the configured values,
including the 'name'.  The leafs 'serial-num',
'mfg-name', and 'model-name' are treated specially; see
their descriptions for details.

 2. Otherwise (i.e., there is no matching configuration
entry), the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation.

   If the /hardware/component list in the intended
   configuration is modified, then the system MUST behave as if
   it re-initializes itself, and follow the procedure in
(1).";



/martin




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

On 12/20/2017 4:00 PM, Martin Bjorklund wrote:

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

Hi Martin,

Thanks.
Only kept the relevant excerpts.

- Some objects are read-write in RFC6933:
  entPhysicalSerialNum
  entPhysicalAlias
  entPhysicalAssetID
  entPhysicalUris

For example, entPhysicalSerialNum being read-write always
bothered me.
serial-num is now "config false", which is a good news IMO.

Actually, this was not the intention.  In
draft-ietf-netmod-entity-03 this is configurable.  I missed
this in the conversion to NMDA.

Ah. So no good news in this case...

In the reverse direction, entPhysicalMfgName is read-only
in RFC6933, while it's "config true" in
draft-ietf-netmod-entity

Yes, this was added per request from the WG.  See e.g. the
thread "draft-ietf-netmod-entity issue #13".

Sure. It was mainly an observation.

However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.

I would like to know what the WG thinks about this.

Talking as a contributor this time.
It seems that inventory management is kind of broken when
someone can change 'serial-num', 'mfg-name', and 'model-name.

They can't really change them.  The configured values are only
used (i.e. visible in the operational state) if the device
cannot detect them automatically.  I.e., they work as "post-it" notes only.

If I look at, for example, the mfg-name, description, this is
not what it says.

 leaf mfg-name {
 type string;
 description
   "The name of the manufacturer of this physical component.
The preferred value is the manufacturer name string
actually printed on the component itself (if present).

Note that comparisons between instances of the model-name,
firmware-rev, software-rev, and the serial-num nodes are
only meaningful amongst component with the same value of
mfg-name.

If the manufacturer name string associated with the
physical component is unknown to the server, then this
node is not instantiated.";
 reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
 entPhysicalMfgName";

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 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] [Editorial Errata Reported] RFC7950 (5237)

[Benoit Claise]

Thanks.
It's now verified.

Regards, Benoit.

Hi,

This errata should be applied.  It is an obvious typo.


/martin



RFC Errata System  wrote:

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5237

--
Type: Editorial
Reported by: Muly Ilan 

Section: 6.4.1.1

Original Text
-
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "when" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Corrected Text
--
The accessible tree for an action invocation of "reset" on
/a/b[id="1"] with the "delay" parameter set to "10" would be:



1

10



2


// possibly other top-level nodes here

Notes
-
The example action "reset" has an input parameter named "delay" and not a parameter named 
"when".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG


.



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Benoit Claise]

Hi Tom,

Hi Tom,


On 17/01/2018 09:52, t.petch wrote:

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM


+1 to (2) as preference, followed by (1).  I don't think (3) is needed

here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'
The text based YANG tree diagram (i.e. covered by this draft) doesn't 
need to be browsable by tooling.  The purpose of these diagrams should 
be to go in text documents to help explain and illustrate (to human 
readers) the structure of a YANG model.


By "In the end, the tree view should be browsed with tooling.", what I 
mean is that I think that tools like YANG catalog will be the long 
term way of interacting with and browsing YANG modules. For example, 
the link below for the RIP module.


https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip

This provides an interactive GUI "tree view" of a YANG model, which 
should be structurally equivalent as the text tree diagram, but 
otherwise the information may be represented in a more visual way. 
This will become even more powerful when all of the standard YANG 
modules are available together in a single browsable tree.



Exactly what I meant.
'In the end, the tree view should be browsed with tooling.' doesn't mean 
that the tree diagram, to be inserted in the RFC text,(according to 
draft-ietf-netmod-yang-tree-diagrams-04 
should 
be browsed with tooling.


Sorry if it was not clear.

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt

[Benoit Claise]

On 1/17/2018 9:59 AM, Martin Bjorklund wrote:

Hi,

These errors seem to be issues with the tool, not the draft.

Good to know Martin. Thanks.

Regards, Benoit



/martin

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

Hi Mahesh,

There is an error with the yangdump-pro:

Error: Feature 'match-on-eth and match-on-ipv4' not found for
if-feature statement
ietf-access-control-l...@2018-01-16.yang:242.16: error(250):
definition not found

Error: Feature 'match-on-eth and match-on-ipv6' not found for
if-feature statement
ietf-access-control-l...@2018-01-16.yang:248.16: error(250):
definition not found

Error: Feature 'match-on-eth and match-on-ipv4
and match-on-ipv6' not found for if-feature statement
ietf-access-control-l...@2018-01-16.yang:253.16: error(250):
definition not found

***
*** 3 Errors, 0 Warnings

See http://www.claise.be/IETFYANGPageCompilation.html

Also, you want to inform and help the dependent YANG modules (Yang
impact analysis for draft-ietf-netmod-acl-model
<https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-access-control-l...@2018-01-16.yang[]=ietf-etherty...@2018-01-16.yang[]=ietf-packet-fie...@2018-01-16.yang=0=1_subm=1_dir=both>)
validate correctly.

Regards, Benoit

This version of the drafts addresses comments received during the last
run of the LC. We, the authors, believe that this document is ready
for LC.


On Jan 16, 2018, at 7:11 PM, 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 Network Modeling WG of the IETF.

 Title   : Network Access Control List (ACL) YANG Data Model
 Authors : Mahesh Jethanandani
   Lisa Huang
   Sonal Agarwal
   Dana Blair
Filename: draft-ietf-netmod-acl-model-15.txt
Pages   : 51
Date: 2018-01-16

Abstract:
This document describes a data model of Access Control List (ACL)
basic building blocks.

Editorial Note (To be removed by RFC Editor)

This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication.  This note
summarizes all of the substitutions that are needed.  Please note
that no other RFC Editor instructions are specified anywhere else in
this document.

Artwork in this document contains shorthand references to drafts in
progress.  Please apply the following replacements

o  "" --> the assigned RFC value for this draft both in this
   draft and in the YANG models under the revision statement.

o  Revision date in model needs to get updated with the date the
   draft gets approved.  The date also needs to get reflected on the
   line with .


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15

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


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

Mahesh Jethanandani
mjethanand...@gmail.com

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


.



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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt

[Benoit Claise]

Hi Mahesh,

There is an error with the yangdump-pro:

   Error: Feature 'match-on-eth and match-on-ipv4' not found for
   if-feature statement
   ietf-access-control-l...@2018-01-16.yang:242.16: error(250):
   definition not found

   Error: Feature 'match-on-eth and match-on-ipv6' not found for
   if-feature statement
   ietf-access-control-l...@2018-01-16.yang:248.16: error(250):
   definition not found

   Error: Feature 'match-on-eth and match-on-ipv4
   and match-on-ipv6' not found for if-feature statement
   ietf-access-control-l...@2018-01-16.yang:253.16: error(250):
   definition not found

   ***
   *** 3 Errors, 0 Warnings

See http://www.claise.be/IETFYANGPageCompilation.html

Also, you want to inform and help the dependent YANG modules (Yang 
impact analysis for draft-ietf-netmod-acl-model 
) 
validate correctly.


Regards, Benoit

This version of the drafts addresses comments received during the last run of 
the LC. We, the authors, believe that this document is ready for LC.


On Jan 16, 2018, at 7:11 PM, 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 Network Modeling WG of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Mahesh Jethanandani
  Lisa Huang
  Sonal Agarwal
  Dana Blair
Filename: draft-ietf-netmod-acl-model-15.txt
Pages   : 51
Date: 2018-01-16

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "" --> the assigned RFC value for this draft both in this
  draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
  draft gets approved.  The date also needs to get reflected on the
  line with .


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15

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


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

Mahesh Jethanandani
mjethanand...@gmail.com

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



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

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

[Benoit Claise]

Hi,


   ** Downref: Normative reference to an Historic RFC: RFC 6587

Kent: hmmm, what's going on here?  This YANG module is providing an ability to configure 
the "tcp" transport, even though the IESG made that ability historic in 2012 
(see IESG Note below).  Searching online, it looks like Cisco supports this, but Juniper 
does not.  What about other vendors, is it widely supported?  Was this discussed in the 
WG?  Answering my own question, searching my local mailbox, I don't see this ever being 
discussed before, other than Martin questioning if it was a good idea in Mar 2016 (no 
response).  Please start a thread on the list to get WG opinion if it's okay for the 
draft to proceed as is or not.  Here's the IESG Note from RFC 6587:

IESG Note

The IESG does not recommend implementing or deploying syslog over
plain tcp, which is described in this document, because it lacks the
ability to enable strong security [RFC3365].

Implementation of the TLS transport [RFC5425] is recommended so that
appropriate security features are available to operators who want to
deploy secure syslog.  Similarly, those security features can be
turned off for those who do not want them.




Well, I believe it's clear plain TCP should not be in the YANG module.

Regards, Benoit

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

[netmod] YANG modules publication: what to focus on next?

[Benoit Claise]

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
)
  Note that draft-ietf-netmod-revised-datastores, a normative reference 
for many YANG modules,

  was just approved. Good news!

We now have many YANG modules in RFC editor queue:
***draft-ietf-lime-yang-connectionless-oam-18 
**
draft-ietf-lime-yang-connectionless-oam-methods-13 
**
draft-ietf-i2rs-yang-l3-topology-16 
**
draft-ietf-i2rs-yang-network-topo-20 
**
draft-wu-l3sm-rfc8049bis-11 

**draft-ietf-netconf-rfc6536bis-09 

*draft-ietf-netmod-rfc7223bis-03 

draft-ietf-netmod-rfc7277bis-03 

draft-ietf-rtgwg-yang-vrrp-09 

draft-ietf-rtgwg-yang-rip-08 

draft-ietf-netmod-revised-datastores-10 



Here are the YANG module dependencies 
 
for these RFC editor modules, as requirement before publishing.


Some more YANG modules are on the IESG table:
    draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)
    draft-ietf-netmod-rfc8022bis is on the Jan 25th IESG telechat
    draft-ietf-netmod-entity is on the Jan 25th IESG telechat

Assuming those are in the RFC editor queue, this is the new set of YANG 
module dependencies 
.
It takes a little bit of re-arrangering the elements, but all the 
information is there.


The next bottlenecks for publishing those YANG modules are:
    draft-ietf-netmod-schema-mount
    draft-ietf-rtgwg-ni-model
    ietf-bfd-yang
    draft-ietf-ospf-yang
    draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NI, LNE, and schema mount, RFC7895bis, schema mount:_
    draft-ietf-rtgwg-lne-model
        Status: Publication requested, Alia's AD review
    draft-ietf-rtgwg-ni-model
        Status: Publication requested, Alia's AD review
    draft-ietf-netmod-schema-mount:
        Status:  WG LC closed, not sure on the next steps ...
    draft-ietf-netconf-rfc7895bis
        Status not clear...

_LIME:_
draft-ietf-lime-yang-connection-oriented-oam-model-00
        Status: Benoit to perform the AD review.

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

Re: [netmod] Reminder: WGLC - draft-ietf-netmod-yang-tree-diagrams

[Benoit Claise]

On 1/15/2018 4:48 PM, Robert Wilton wrote:

OLD:

    If the node is augmented into the tree from another module,
    its name is printed as :.

NEW:

    If the node is augmented into the tree from another module,
    its name is printed as :, where  is the
    prefix defined in the module where the node is defined.

This is OK with me, but there is still a potential for a prefix
namespace clash (since prefixes are not guaranteed to be unique).

An alternative solution would be for the YANG tree diagram to list (at
the beginning or the end of the diagram) the mappings from prefix ->
module name used.

The tree diagram is supposed to give a simplified overview of the
structure of a module.  I agree with your statemenet below that such a
mappig adds noise...  I prefer to keep the diagram as is.
That is fine with me, really just raising so that the point could be 
discussed and closed.
Sections such as this one are super useful and should ideally become 
common practice.

https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-08#section-2.3

Regards, Benoit


Thanks,
Rob 


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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Benoit Claise]

Hi Tom,

IMO, the best to proceed is exactly like done in the RIP draft.
Some sections 2.* explains how the module was build, based one excerpts 
of the tree diagram.

Then we have the full tree if someone wants to see the big structure.

In the end, the tree view should be browsed with tooling.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rip/
   => Yang catalog entry for ietf-...@2018-01-09.yang 

   => [Tree View for ietf-rip] Tree View 



Regards, Benoit

I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

Tom Petch

- Original Message -
From: "joel jaeggli" 
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Benoit Claise]

 this document.

 1b. Otherwise (i.e., there is no matching configuration
 entry), the list entry in the operational state is
 initialized with values for all nodes as detected by
 the implementation.

   If the /hardware/component list in the intended
   configuration is modified, then the system MUST behave as if
   it re-initializes itself, and follow the procedure in
(1).";

NEW:

   When the server detects a new hardware component, it
   initializes a list entry in the operational state.

   If the server does not support configuration of hardware
   components, list entries in the operational state are
   initialized with values for all nodes as detected by the
   implementation.

   Otherwise, the following procedure is followed:

 1. If there is an entry in the /hardware/component list in
the intended configuration with values for the nodes
'class', 'parent', 'parent-rel-pos' that are equal to
the detected values, then the list entry in operational
state is initialized with the configured values,
including the 'name'.  The leafs 'serial-num',
'mfg-name', and 'model-name' are treated specially; see
their descriptions for details.

 2. Otherwise (i.e., there is no matching configuration
entry), the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation.

   If the /hardware/component list in the intended
   configuration is modified, then the system MUST behave as if
   it re-initializes itself, and follow the procedure in
(1).";



/martin




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

On 12/20/2017 4:00 PM, Martin Bjorklund wrote:

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

Hi Martin,

Thanks.
Only kept the relevant excerpts.

- Some objects are read-write in RFC6933:
  entPhysicalSerialNum
  entPhysicalAlias
  entPhysicalAssetID
  entPhysicalUris

For example, entPhysicalSerialNum being read-write always bothered
me.
serial-num is now "config false", which is a good news IMO.

Actually, this was not the intention.  In
draft-ietf-netmod-entity-03 this is configurable.  I missed this
in the conversion to NMDA.

Ah. So no good news in this case...

In the reverse direction, entPhysicalMfgName is read-only in
RFC6933, while it's "config true" in draft-ietf-netmod-entity

Yes, this was added per request from the WG.  See e.g. the
thread "draft-ietf-netmod-entity issue #13".

Sure. It was mainly an observation.

However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.

I would like to know what the WG thinks about this.

Talking as a contributor this time.
It seems that inventory management is kind of broken when someone
can change 'serial-num', 'mfg-name', and 'model-name.

They can't really change them.  The configured values are only
used (i.e. visible in the operational state) if the device cannot
detect them automatically.  I.e., they work as "post-it" notes only.

If I look at, for example, the mfg-name, description, this is not
what it says.

 leaf mfg-name {
 type string;
 description
   "The name of the manufacturer of this physical component.
The preferred value is the manufacturer name string
actually printed on the component itself (if present).

Note that comparisons between instances of the model-name,
firmware-rev, software-rev, and the serial-num nodes are
only meaningful amongst component with the same value of
mfg-name.

If the manufacturer name string associated with the
physical component is unknown to the server, then this
node is not instantiated.";
 reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
 entPhysicalMfgName";

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 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] AD review of draft-ietf-netmod-entity-06

[Benoit Claise]

tional state.

   If the server does not support configuration of hardware
   components, list entries in the operational state are
   initialized with values for all nodes as detected by the
   implementation.

   Otherwise, the following procedure is followed:

 1. If there is an entry in the /hardware/component list in
the intended configuration with values for the nodes
'class', 'parent', 'parent-rel-pos' that are equal to
the detected values, then the list entry in operational
state is initialized with the configured values,
including the 'name'.  The leafs 'serial-num',
'mfg-name', and 'model-name' are treated specially; see
their descriptions for details.

 2. Otherwise (i.e., there is no matching configuration
entry), the list entry in the operational state is
initialized with values for all nodes as detected by
the implementation.

   If the /hardware/component list in the intended
   configuration is modified, then the system MUST behave as if
   it re-initializes itself, and follow the procedure in
(1).";



/martin




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

On 12/20/2017 4:00 PM, Martin Bjorklund wrote:

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

Hi Martin,

Thanks.
Only kept the relevant excerpts.

- Some objects are read-write in RFC6933:
  entPhysicalSerialNum
  entPhysicalAlias
  entPhysicalAssetID
  entPhysicalUris

For example, entPhysicalSerialNum being read-write always bothered
me.
serial-num is now "config false", which is a good news IMO.

Actually, this was not the intention.  In
draft-ietf-netmod-entity-03 this is configurable.  I missed this
in the conversion to NMDA.

Ah. So no good news in this case...

In the reverse direction, entPhysicalMfgName is read-only in
RFC6933, while it's "config true" in draft-ietf-netmod-entity

Yes, this was added per request from the WG.  See e.g. the
thread "draft-ietf-netmod-entity issue #13".

Sure. It was mainly an observation.

However, I think that what we have now is probably not correct.
I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
should be config true, and the description of list 'component'
updated to reflect that all these tree leafs are handled the same way.

I would like to know what the WG thinks about this.

Talking as a contributor this time.
It seems that inventory management is kind of broken when someone
can change 'serial-num', 'mfg-name', and 'model-name.

They can't really change them.  The configured values are only
used (i.e. visible in the operational state) if the device cannot
detect them automatically.  I.e., they work as "post-it" notes only.

If I look at, for example, the mfg-name, description, this is not
what it says.

 leaf mfg-name {
 type string;
 description
   "The name of the manufacturer of this physical component.
The preferred value is the manufacturer name string
actually printed on the component itself (if present).

Note that comparisons between instances of the model-name,
firmware-rev, software-rev, and the serial-num nodes are
only meaningful amongst component with the same value of
mfg-name.

If the manufacturer name string associated with the
physical component is unknown to the server, then this
node is not instantiated.";
 reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
 entPhysicalMfgName";

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 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] Adam Roach's No Objection on draft-ietf-netmod-entity-07: (with COMMENT)

[Benoit Claise]

On 1/11/2018 10:12 AM, Juergen Schoenwaelder wrote:

On Thu, Jan 11, 2018 at 09:49:24AM +0100, Martin Bjorklund wrote:


Will do.  As it happens, I always just look into the MIBs distributed
by libsmi, and it seems the MIB is not updated there ;-)

OK. My fault.


Which leads
to an interesting issue - the errata for the MIB not only changes the
description in the comment, but it also changes the *value*.  I will
thus do the same in the YANG module:

   enum peta {
 value 14;
 description
   "Data scaling factor of 10^15.";
   }
   enum exa {
 value 15;
 description
   "Data scaling factor of 10^18.";
   }

This matches the verified MIB Errata, but since the original MIB is
probably present in most distributions, I wouldn't be surprised if
this object is not correctly implemented in real code...  When I
googled for the MIB I found several instances of NON-updated MIBs, and
zero instances of an updated MIB.

Yes. This is very subtle. Not changing the value would also have been
somewhat odd since tera and exa are then 'out of natural order'. But
it might have been more robust. Anyway, the errata says what it says
and all we can do now is likely to hope that people running into this
at the end find the errata linked to the RFC. Hence, I will commit the
errata fix to the libsmi repository now.

Exactly the discussion we've been having on the YANG doctor list.
"- errata on the YANG module inside a RFC: this is looking for troubles 
IMO."

Obviously the same applies for MIB modules.

Regards, Benoit



/js



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

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[Benoit Claise]

On 1/9/2018 8:27 AM, Martin Bjorklund wrote:

Hi,

Kathleen Moriarty  wrote:

--
DISCUSS:
--

Hello,

I'm a little confused on the Security Consideration section as it doesn't use
the latest template, but does specify SSH for NETCONF, so I'm good with that
part.  Will RESTCONF also be used as a transport or is there some reason it
won't be used for this YANG module?

Here's what I think is the latest template and please let me know if sections
of it do not apply to this draft and I'll drop the discuss for correcting the
security considerations section.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

I have updated to the latest version in my local copy.

Thanks Martin.
The IETF LC finishes today. So please post a new version tomorrow.

Regards, B.



/martin

.



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

Re: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt

[Benoit Claise]

On 1/2/2018 12:59 PM, Acee Lindem (acee) wrote:

Hi Lada, Tom,

Okay - no sense in derailing this draft based on an example if there isn’t
consensus.

Fine with me.

Regards, B.


Thanks,
Acee

On 1/2/18, 5:42 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:


On Wed, 2017-12-27 at 17:25 +, Acee Lindem (acee) wrote:

Hi Benoit,

On 12/27/17, 6:18 AM, "Benoit Claise (bclaise)" <bcla...@cisco.com>
wrote:


Thanks Acee,

Minor question for the working group and the draft-ietf-rtgwg-yang-rip
authors.

The appendix is about adding a new control-plane protocol. It takes as
an example RIP.
However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG
telechat on Jan 11th).
Does it make sense to keep the RIP example? If so, is the example
consistent with draft-ietf-rtgwg-yang-rip?
Or should we just point to draft-ietf-rtgwg-yang-rip as the example?

It is probably better just to reference the RIP module draft. Does
anyone
disagree?

I tend to disagree. For this document, we need a simple example to
illustrate
the steps that need to be done. Any production module, be it ietf-rip or
anything else, necessarily involves some complexity that defeats the
purpose of
the example.

In my view, the present RIP example is fine. Perhaps we can extend the
disclaimer saying that it is not intended as a production module and also
provide a non-normative reference to the "real" RIP module.

Lada


Thanks,
Acee

Not strong views on my side.

Regards, Benoit

This version includes Martin’s YANG doctor comments and some

updates to

the examples (e.g., YANG Library data) from Lada.

Thanks,
Acee

On 12/22/17, 1:28 PM, "netmod on behalf of internet-dra...@ietf.org"
<netmod-boun...@ietf.org 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 Network Modeling WG of the IETF.

 Title   : A YANG Data Model for Routing Management
(NDMA
Version)
 Authors : Ladislav Lhotka
   Acee Lindem
   Yingzhen Qu
Filename: draft-ietf-netmod-rfc8022bis-06.txt
Pages   : 77
Date: 2017-12-22

Abstract:
This document contains a specification of three YANG modules

and one

submodule.  Together they form the core routing data model that
serves as a framework for configuring and managing a routing
subsystem.  It is expected that these modules will be

augmented by

additional YANG modules defining data models for control-plane
protocols, route filters, and other functions.  The core

routing

data
model provides common building blocks for such extensions --

routes,

Routing Information Bases (RIBs), and control-plane protocols.

The YANG modules in this document conform to the Network

Management

Datastore Architecture (NMDA).  This document obsoletes RFC

8022.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06


https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06

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


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

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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-06.txt

[Benoit Claise]

Hi,

While the abstract mentions: "This document obsoletes RFC 8022 
.", you forgot the obsolete tag in 
the header.


Regards, Benoit.

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

 Title   : A YANG Data Model for Routing Management (NDMA 
Version)
 Authors : Ladislav Lhotka
   Acee Lindem
   Yingzhen Qu
Filename: draft-ietf-netmod-rfc8022bis-06.txt
Pages   : 77
Date: 2017-12-22

Abstract:
This document contains a specification of three YANG modules and one
submodule.  Together they form the core routing data model that
serves as a framework for configuring and managing a routing
subsystem.  It is expected that these modules will be augmented by
additional YANG modules defining data models for control-plane
protocols, route filters, and other functions.  The core routing data
model provides common building blocks for such extensions -- routes,
Routing Information Bases (RIBs), and control-plane protocols.

The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06

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


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
.



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

[netmod] Fwd: New datatracker release: v6.68.1

[Benoit Claise]

Dear all,

I want to draw your attention to this entry below:

  * Added a data migration to create yang catalog links for yang documents
published before the yang catalog link feature was introduced in the
datatracker.

Ex: https://datatracker.ietf.org/doc/rfc7223/

Happy New Year to all of you.

Regards, Benoit

 Forwarded Message 
Subject:New datatracker release: v6.68.1
Date:   Sat, 23 Dec 2017 13:53:59 -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.68.1, generated when running the mkrelease script.

Release notes:

ietfdb (6.68.1) ietf; urgency=medium

  This is a bugfix release, with a number of minor fixes, as follows:

  * Tweaked the query filter for 'latest' meetings in the
fetch_meeting_attendance management command to deal with future meetings
beyond the current meeting in the database.

  * Added a guard against infinite recursion in document replacement listing
methods to deal better with circular relationships.

  * Enhanced doc event notification emails with who and when.  Fixes issue
#2428.

  * Added a data migration to create yang catalog links for yang documents
published before the yang catalog link feature was introduced in the
datatracker.

  * Fixed an ungarded object attribute access.

  * Updated the API notes page with improved descriptions and information.

  * Limited the iesg ballot position API to ADs (excluding secretariat).

  * Modified the run_yang_model_checks management command to accept
document aliases (not only canonical names) on the command line.

  * Reverted an inadvertently included patch version.

  * Fixed some reStructuredText issues in the changelog

 -- Henrik Levkowetz   22 Dec 2017 11:29:14 -0800

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

For development, copy the new development version instead:
  'svn copyhttps://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.68.2.dev0' 


Regards,

Henrik
(via the mkrelease script)

.

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

Re: [netmod] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt

[Benoit Claise]

Thanks Acee,

Minor question for the working group and the draft-ietf-rtgwg-yang-rip 
authors.


The appendix is about adding a new control-plane protocol. It takes as 
an example RIP.
However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG 
telechat on Jan 11th).
Does it make sense to keep the RIP example? If so, is the example 
consistent with draft-ietf-rtgwg-yang-rip?

Or should we just point to draft-ietf-rtgwg-yang-rip as the example?

Not strong views on my side.

Regards, Benoit

This version includes Martin’s YANG doctor comments and some updates to
the examples (e.g., YANG Library data) from Lada.

Thanks,
Acee

On 12/22/17, 1:28 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 Network Modeling WG of the IETF.

Title   : A YANG Data Model for Routing Management (NDMA
Version)
Authors : Ladislav Lhotka
  Acee Lindem
  Yingzhen Qu
Filename: draft-ietf-netmod-rfc8022bis-06.txt
Pages   : 77
Date: 2017-12-22

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).  This document obsoletes RFC 8022.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06

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


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


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

Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-09.txt

[Benoit Claise]

Dear all,

We all know it's important to deliver NMDA soon.
I'm sending this document to IETF LC now, till Jan 10th.
If Vladimir's concern needs to be discussed further, let's do so part 
the IETF LC.


Regards, Benoit

Just an FYI - I requested that the authors republish so that all could
see the current state of the document.  I note that a post-LC
discussions is taking place and I leave it to the AD to decide how he'd
like to handle it, e.g., as part of WG LC or as an early IETF LC comment.

Lou

(as Shepherd)


On 12/21/2017 1:45 PM, 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 Network Modeling WG of the IETF.

 Title   : Network Management Datastore Architecture
 Authors : Martin Bjorklund
   Juergen Schoenwaelder
   Phil Shafer
   Kent Watsen
   Robert Wilton
Filename: draft-ietf-netmod-revised-datastores-09.txt
Pages   : 38
Date: 2017-12-21

Abstract:
Datastores are a fundamental concept binding the data models written
in the YANG data modeling language to network management protocols
such as NETCONF and RESTCONF.  This document defines an architectural
framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well
supported in the initial model.  This document updates RFC 7950.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-09
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-09


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


___
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] AD review of draft-ietf-netmod-entity-06

[Benoit Claise]

On 12/21/2017 1:03 PM, Juergen Schoenwaelder wrote:

On Thu, Dec 21, 2017 at 12:58:26PM +0100, Martin Bjorklund wrote:

Juergen Schoenwaelder  wrote:

On Thu, Dec 21, 2017 at 12:37:46PM +0100, Martin Bjorklund wrote:

Hi,

I need WG input on this issue.  The question is how to handle
'serial-num', 'mfg-name', and 'model-name'.  I think they should all
be treated the same.  Based on previous WG discussion (see e.g. the
mail thread "draft-ietf-netmod-entity issue #13"), I think they should
all be configurable, but the configured value is only used in
operational state if the system cannot read it from the hardware.

So I suggest the following changes:

OLD:

   leaf serial-num {
 type string;
 config false;
 description
   "The vendor-specific serial number string for the
component.  The preferred value is the serial number
string actually printed on the component itself (if
present).";
 reference "RFC 6933: entPhysicalSerialNum";
   }

NEW:

   leaf serial-num {
 type string;
 description
   "The vendor-specific serial number string for the
component.  The preferred value is the serial number
string actually printed on the component itself (if
present).

The last sentence is not useful since nobody knows what 'preferred'
value means. So remove it.

This text comes from RFC 6933.  Do you really think it is not clear
what the intention is?

I guess I read too fast. No, the sentence is fine. My comment was wrong.

[...]
  

Agreed.  So we'd have a single paragraph:

This leaf can be configured.  The configured value is used only if
the server cannot determine the vendor-specific serial number from
the component itself.

Yes, I think this covers it.

That works for me.

Regards, B.


/js



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