Re: [netmod] CODE BEGINS ENDS for examples ?

[Balázs Lengyel]

Hello Kent,

First   is very handy and easier to use then xmllint.

Also some people (not me) are writing RFCs without XML. SO if it acceptable to 
you, the RFC editor to whoever I will use  for the examples. Is that 
acceptable?

 

Folding:

Rfcfold folds the line at a fixed 69 character length. This produces some not 
so nice results:

Rfcfold:



  



Manual folding:



  



The manual folding can keep a nice tabulation and fold the line at a word or 
element boundary. I know such editorial niceties are very hard to program in a 
script; but this is one reason to do manual folding.

 

I used rfcfold to unfold the acme-router-modules example and I don’t notice 
anything strange.

Regards Balazs

 

From: Kent Watsen  
Sent: 2020. március 21., szombat 0:01
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] CODE BEGINS ENDS for examples ?

 

Hi Balazs,

 

As I understand it, the   blocks are not appropriate for 
examples. 

 

Examples are easily extracted from XML via `xmllint` with the “—xpath” 
parameter, after which the `rfcfold` script can be run.  Strongly recommend 
setting the “name” attribute on the  or  element in the 
XML draft.  It’s good to see that you want to do it this way, as I noticed you 
hand-folded the examples and I’m pretty sure I spotted what looked like might 
result in an undesirable unfolding artifact...

 

FWIW, https://pypi.org/project/xiax attempts to do all this, but I suspended 
that effort getting distracted with other things...

 

Kent // contributor

 

 





On Mar 20, 2020, at 1:02 PM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

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 LengyelSenior Specialist   
Ericsson Hungary Ltd. 

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

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] CODE BEGINS ENDS for examples ?

[Balázs Lengyel]

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 LengyelSenior Specialist
Ericsson Hungary Ltd. 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yang-instance-file-format-10 uploaded [was: RE: WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07]

[Balázs Lengyel]

Hello Kent,
Thanks for the comments. Updated all in -10 version. See below as BALAZS2.
(XML2RFC at this point does not yet accept  netmod-yang-module-versioning. That 
needs to be changed later.)
Regards Balazs

-Original Message-
From: Kent Watsen  
Sent: 2020. március 18., szerda 3:58
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call: 
draft-ietf-netmod-yang-instance-file-format-06 to -07


> Have the examples in the draft validated against the YANG module?
> 
> BALAZS: Only manually. How do you validate samples conforming to a yang data 
> structure ?

Hmmm, seeing that the examples are still not valid, here goes:

Until such time as tools support validating structure-data-ext, 
one can rewrite the YANG module via s/sx:structure/container/ 
and perform the validation against the resulting YANG module.
BALAZS2: Validated with yanglint

> Please review the Normative/Informative status of the references.
> 
> Not looking carefully, but RFCs 2119 and 8174 should be Normative,
> 
> and I think RFCs 3688 and 6020 should be Informative, right?
> 
> BALAZS: OK, changed in rev 08

Did you check all the other references too?  (I’m trying to save having to do 
another roundtrip when I do the shepherd writeup...)
BALAZS2: I believe yes. Do you see any other problem ?


> All of the “import” statements in the YANG module are missing a
> “reference” statement.
> BALAZS:
> Added:
> rfc6991 for types added.
> Already present:
> rfc8342 for datastores
> ietf-netmod-yang-data-ext for ietf-yang-structure-ext

Again, all the “import” statements in the YANG module are missing a “reference” 
statement.
BALAZS2: OK.  Sorry I misunderstood the comment earlier it. Corrected. 
> 
> Please add a statement to the Introduction regarding why the module

> Isn’t compliant with NMDA.
> BALAZS: Sorry, don’t understand. Why is this not compliant with NMDA ?
> IMHO it is NMDA compliant, or rather it  has nothing to do with NDMA.

Either way but, per https://tools.ietf.org/html/rfc8407#section-3.5, the 
statement should be in the Introduction section.
BALAZS2: Done


> The tree diagram does not adhere to the syntax described in 
> draft-ietf-netmod-yang-data-ext.  
> BALAZS: OK I try, but what actually is the problem? Any help would be really 
> appreciated.

I was looking at the “+—rw”, which can’t be right because yang-data is not 
“configuration”...

> Sadly
> pyang -p ../ietfYams ietf-yang-instance-data\@2020-03-06.yang -f tree 
> --tree-print-yang-data --tree-print-yang-data
> doesn’t print out anything, so I am handcrafting.

`pyang`  supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been 
updated to support the new "sx:structure” statement.
BALAZS2: Done, after adding a top level container (which is not needed in 
structure) and some copy-paste+editing.


> I just updated pyang from git. Any idea why this doesn’t work for me?
> It would be good if YangValidator would print out the tree. At some point it 
> did. Not now. :-(

First, use the s/sx:structure/container/ trick mentioned above.

Then s/+--rw/+—/.

Then review 
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-05#section-3 and 
tweak accordingly until all is good.

BALAZS2: Done, I hope

NEW: looking at the new "format-version”, please add a pattern statement to 
constrain the string values appropriately.  Hint, it’s half a "date-and-time” 
type...

BALAZS2: Done




smime.p7s
Description: S/MIME cryptographic signature
___
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 to -07

[Balázs Lengyel]

-Original Message-
From: Kent Watsen  
Sent: 2020. március 18., szerda 21:07
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call: 
draft-ietf-netmod-yang-instance-file-format-06 to -07

One more thing, for non-mandatory nodes that don’t have a default value 
specified, please ensure the “description” statement states what it means for 
the node to be set or not set (whichever is easier)?   For instance:

OLD:

   leaf name {
 type string;
 description
   "Name of the YANG instance data set.";
   }

NEW (assuming this makes sense):

   leaf name {
 type string;
 description
   “An arbitrary name for the YANG instance data set.  This
value is primarily used for descriptive purposes.  However,
when the instance data set is saved to a file, then the
filename MUST encode the name’s value, per Section 3 
of RFC .";
   }
BALAZS: OK
BTW, should the requirement of it needing to be encoded into the filename place 
constraints on the “string” type?  Should a “pattern”
statement be added?
BALAZS: IMHO defining a pattern for a filename string (that may be dependent on 
the used filesystem) is out of scope for this draft.

Extended description of content-schema.
IMHO contact, description, revision, timestamp does not need to explain what 
does it mean if they are not present. It only means: no information available.
Kent



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Simple date in 6991bis-02

[Balázs Lengyel]

Hello,

This might have been discussed earlier, but I still find it strange that the


   typedef date {

has the timezone as a mandatory part. While I understand the issue that when
a day starts/ends is uncertain without the timezone, in real life people
practically never add the timezone to a date, and it does not cause major
problems. So IMHO following life we should have a simple-date datatype that
does not include any timezone. Actually we do have that datatype just we
called it revision-identifier. Really strange.

 

I would also consider to tighten up the pattern for
revision-identifier/date/date-and-time.

pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';

This would prohibit  2020-16-67 : months > 12 or days > 31

Regards Balazs

 

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [netconf] yanglint errors for ietf-subscribed-notifications

[Balázs Lengyel]

IMO this is a problem with pyang/yanglint not the model. By the way for me 
pyang 2.2.1 does not indicate an error.

 

Line 381:(379) defines 

typedef stream-ref {

type leafref {

  path "/sn:streams/sn:stream/sn:name";

This is just a type so it is unknown if it is config=false or true.

 

The only place stream-ref is used is line 591

  type stream-ref {

require-instance false;

 

According to https://tools.ietf.org/html/rfc7950#section-9.9

If the referring node represents configuration data and the

   "require-instance" property (Section 9.9.3 
 ) is "true", the referred

   node MUST also represent configuration.

 

However as the require-instance is false, this should not be a problem.

 

Regards Balazs

P.S> As yanglint does not provide line numbers it is hard to judge what it 
exactly wants.

 

 

From: netconf  On Behalf Of Mahesh Jethanandani
Sent: 2020. március 13., péntek 21:14
To: Netconf ; netmod@ietf.org
Subject: [netconf] yanglint errors for ietf-subscribed-notifications

 

As I mentioned in the other thread, I am seeing errors while trying to use 
yanglint to validate examples for modules that import 
ietf-subscribed-notifications. I see it with ietf-notification-capabilities and 
with my own draft ietf-https-notif. These errors do not appear with confd. 

 

Using ietf-notification-capabilites and the first example in the -12 version of 
the draft which I call examples-notification-capabilities-1.xml, and released 
models for ietf-yang-push and ietf-subscribed-notifications, I see two issues. 
The first one related to the statement 'required-instance’ in 
ietf-subscribed-notifications is discussed on the other thread, and I do not 
want to repeat it here. If I comment out the only instance of 
‘required-instance’ in the module, I run into more errors:

 

bash-3.2$ yanglint -s -i -t auto -p /Volumes/External/git/iana/yang-parameters/ 
ietf-system-capabilit...@2020-03-08.yang 
  
ietf-notification-capabilit...@2020-03-09.yang 
  
examples-notification-capabilities-1.xml 

err : The leafref leaf is config but refers to a non-config leaf. 
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)

err : Invalid value "subscription-policy" of "uses". 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)

err : Copying data from grouping failed. 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)

err : Module "ietf-subscribed-notifications" parsing failed.

err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" 
failed.

err : Module "ietf-yang-push" parsing failed.

err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" 
failed.

err : Module "ietf-notification-capabilities" parsing failed.

 

While pyang gives the following error:

 

bash-3.2$  pyang -f tree ietf-subscribed-notificati...@2019-09-09.yang 
  > 
ietf-subscribed-notificati...@2019-09-09-tree.txt 
 

ietf-subscribed-notificati...@2019-09-09.yang 
 :381: error: the path 
for stream is config but refers to a non-config leaf "name" defined at 
ietf-subscribed-notificati...@2019-09-09.yang 
 :1046

 

Have other encountered this error? If we agree this is an error, is there a 
-bis to fix this?

 

Thanks.

 

Mahesh Jethanandani

mjethanand...@gmail.com  

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

OK, I will remove it.
Balazs

-Original Message-
From: netmod  On Behalf Of Martin Björklund
Sent: 2020. március 12., csütörtök 17:58
To: j.schoenwael...@jacobs-university.de
Cc: netmod@ietf.org; bclaise=40cisco@dmarc.ietf.org
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06

Hi

Juergen Schoenwaelder  wrote:
> On Wed, Mar 11, 2020 at 06:58:53PM +0100, Benoit Claise wrote:
> > 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?
> >
> 
> The new sentence is this:
> 
> 
> 
> 
> [Yeah, I suggested removal so the new sentence is empty.]

I agree with Juergen.  

I find the sentence about similarity confusing.  What exactly does "similar"
mean?  Does it mean that it has a  on the top?

This section defines the prinicples / objectives, and the principle is
clear:

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


> PS: I do not mind if somewhere there is an example stated. But even
> then I would prefer something like this:
> 
>   For example, instance data of the  configuration
>   datastore is encoded similar to the response of a NETCONF
>operation on the  datastore or a GET
>   method invocation on the  datastore resource and it
>   will be embedded into a container together with the metadata
>   describing the instance data.

Hmm.   If you really want to show how a reply to  compares
to a corresponding instance file, it might be better with an example that
shows a complete reply to this get-config, and the corresponding instance
data.


/martin



> 
> (I prefer to avoid NETCONF GET and the RESTCONF unified datastore
> since they have issues. But if people insist on an example using
> operations that have issues, I will keep my mouth shut.)
> 
> -- 
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: Secdir last call review of draft-ietf-netmod-factory-default-14

[Balázs Lengyel]

As an author of netmod drafts I would like to see some general guidance on this 
issue. Can someone help please.
Balazs

-Original Message-
From: Stephen Kent via Datatracker  
Sent: 2020. március 9., hétfő 20:15
To: sec...@ietf.org
Cc: netmod@ietf.org; draft-ietf-netmod-factory-default@ietf.org; 
last-c...@ietf.org
Subject: Secdir last call review of draft-ietf-netmod-factory-default-14

Reviewer: Stephen Kent
Review result: Has Issues

SECDIR review of draft-ietf-netmod-factory-default-14

Section 6, Security Considerations, calls for use of SSH (RFC 6242) with 
NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current, 
citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH 
with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC
4253 for a description of SSH. 4253 is a very much out of date document; the 
integrity and key management algorithms in the original RFC have been updated 3 
times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all 
outdated. This discussion of SSH security for use with NETCONF, based on the 
one citation, seems to be inconsistent with current IETF crypto guidelines.
This is a problem that the net management area should address before this 
document is approved.

The discussion of how a factory-reset RPC may isolate a device, is good, as is 
the warning about not relying on this RPC to prevent recovery of 
security-sensitive data from NV storage.





smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

No, I am not aware of any IPR that applies to this draft.
Balazs

-Original Message-
From: netmod  On Behalf Of Mahesh Jethanandani
Sent: 2020. március 10., kedd 4:52
To: Lou Berger 
Cc: netmod-ver...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Regarding IPR on draft-verdt-netmod-yang-solutions-03

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

> On Mar 2, 2020, at 2:13 PM, Lou Berger  wrote:
> 
> 
> 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

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: New Version Notification for draft-ietf-netmod-yang-instance-file-format-08.txt

[Balázs Lengyel]

Hello,
New version is available. Thanks for the comments, especially for Juergen's 
contribution.
Main changes:

- Moved compatibility into appendix
- Made support of ietf-yang-library mandatory if inline-content- schema is 
supported
- Renamed yid-version to format-version as "yid" can be regarded as  a racial 
slur.  Changed format to date of the YANG module
- Removed section about XML attributes
- Other WGLC related changes

Regards Balazs


-Original Message-
From: internet-dra...@ietf.org  
Sent: 2020. március 9., hétfő 18:14
To: Balázs Lengyel ; Benoit Claise 

Subject: New Version Notification for 
draft-ietf-netmod-yang-instance-file-format-08.txt


A new version of I-D, draft-ietf-netmod-yang-instance-file-format-08.txt
has been successfully submitted by Balazs Lengyel and posted to the IETF 
repository.

Name:   draft-ietf-netmod-yang-instance-file-format
Revision:   08
Title:  YANG Instance Data File Format
Document date:  2020-03-09
Group:  netmod
Pages:  27
URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-08.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-08
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-08

Abstract:
   There is a need to document data defined in YANG models when a live
   server is not available.  Data is often needed already at design or
   implementation time or needed by groups that do not have a live
   running server available.  This document specifies a standard file
   format for YANG instance data, which follows the syntax and semantics
   of existing YANG models, and annotates it with metadata.


  


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

The IETF Secretariat




smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

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.



> > >   - Why MUST XML attributes be ignored, why is there no text about
> > > unknown JSON data, 'attributes' (or annotations)? What should
> > > implementations generally do about unknown elements, attributes,
> > > objects, arrays, ...)? Why are we specific about only one specific
> > > case?
> > > BALAZS:  Generally we want to allow users/creators to decorate the 
> > > data with additional information, that is not standardized. Like 
> > > YANG extensions  these may be usef

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

[Balázs Lengyel]

-Original Message-
From: Rob Wilton (rwilton)  
Sent: 2020. március 6., péntek 14:18
To: Balázs Lengyel 
Subject: RE: URGENT kind of - RE: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06

Not a full WGLC review, but one comment that I have on this draft (which
partly picks up a comment that Joe mentioned earlier regarding
"yid-version").


I think that we should probably avoid using the term "yid-version" because
"yid" can be regarded as a racial slur, perhaps "file-format-version" would
be safer?
BALAZS: OK, changed to format-version. Shorter & In the future an instance
data set could be transported over the wire without a file around it.

But I also agree with Joe that I think that it would be better to tie this
back to the revision-date of the YANG module rather than inventing another
versioning scheme.  Ideally, this would be a YANG Semver revision-label, but
we don't want this draft to get delayed behind the versioning work.
BALAZS: OK, go with date.

Subject to the outcome of the (so far remarkably quiet) YANG versioning
drafts adoption call, perhaps this leaf could instead be defined as a
string, which can only currently take the value "1.0.0", thus allowing it to
be extended to adopt YANG revision labels and semver in future?

Rob


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

Hello Jurgen,
See answers below as "BALAZS3". I am putting them into the -08 revision this
weekend.
One general comment:
As partial data sets are allowed, it is not always necessary to indicate if
a feature is not supported. 
E.g. If you have an instance dataset for ietf-system, which does not include
authentication data, 
you do not care whether the feature  authentication is supported or not.
Similarly if the deviation does not impact your particular instance data
items, you might not care to specify it.
Regards Balazs

-Original Message-
From: Schönwälder, Jürgen  
Sent: 2020. február 19., szerda 11:17
To: Balázs Lengyel 
Cc: Kent Watsen ; NETMOD Working Group

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

On Thu, Feb 13, 2020 at 01:40:13PM +0000, Balázs Lengyel wrote:
> See below as BALAZS2.
> 
> -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?
 
> >   - Why MUST XML attributes be ignored, why is there no text about
> > unknown JSON data, 'attributes' (or annotations)? What should
> > implementations generally do about unknown elements, attributes,
> > objects, arrays, ...)? Why are we specific about only one specific
> > case?
> > BALAZS:  Generally we want to allow users/creators to decorate the 
> > data with additional information, that is not standardized. Like 
> > YANG extensions  these may be useful, but at least should not cause
problems.
> > XML attributes are often used as meta-data and I was asked to list 
> > them specifically.
> > 
> I do not understand why there are specific rules for XML encodings but 
> not equivalent JSON rules. It looks like either the XML rules are not 
> needed or equivalent JSON rules are missing if the XML rules are 
> needed or there should be an explanation why the different encodings 
> lead to different results (which is operationally rather surprising).
> BALAZS2:XML has 2 distinct ways to encode information XML attributes 
> and elements.  JSON only has one uniform way. XML attributes are often 
> used to carry metadata which is a useful facility and they are not 
> used to encode "real" YANG defined data. So we want to allow the use 
> of XML attributes and not go for a least common denominator of the 

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

[Balázs Lengyel]

 

 

From: Andy Bierman  
Sent: 2020. március 5., csütörtök 16:43
To: Balázs Lengyel 
Cc: Benoit Claise ; NETMOD WG 
Subject: Re: [netmod] Text in import to indicate whether a module is needed as 
import-only or as implemented

 

 

 

On Thu, Mar 5, 2020 at 5:31 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

Hello,

Putting this information on individual schema nodes can be a problem if a 
module uses imported items a lot. We have modules with 100+ schema nodes that 
use an import, while  there are only 7 modules imported. Adding the statement 
(mandatory/optional to implement) 100 times would be a lot of text. I also 
doubt that people will check all 100 places.

IMHO alternatives a) or b) are feasible. (I like a) the best)

 

 

This is a strawman -- nobody suggested duplicating the same text over and over 
in data nodes.

The same issue exists with the reference-stmt.  We don't require (or encourage) 
people to

place a reference to an external RFC on every leaf. The same judgement can be 
used here.

 

Andy

 BALAZS2: If the first 50 uses of an import don’t need an implemented 
import-module  but the 51stdoes, then finding this will be difficult, unless we 
formalize it somehow e.g. with a new statement, extension, standard text, 
whatever.

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Andy Bierman
Sent: 2020. március 3., kedd 17:14
To: Benoit Claise mailto:bcla...@cisco.com> >
Cc: NETMOD WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] Text in import to indicate whether a module is needed as 
import-only or as implemented

 

 

 

On Tue, Mar 3, 2020 at 12:45 AM Benoit Claise mailto:bcla...@cisco.com> > wrote:

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.

 

 

The object descriptions are the correct level of granularity to be useful.

A boolean statement wrt/ module implementation is required vs not required is 
not very useful.

Rarely is the entire module either fully required or nothing to implement at 
all.

 

IMO it is wrong to conflate the import-stmt with conformance requirements.

It is merely a mechanism to bind local prefix usage to an external module.

Text like "revision X or derived from X is required" is appropriate for the 
import-stmt because

it refers to the binding between prefix and imported module revision used.

 

Consider how this extra documentation work scales to a big module like ietf-bgp.

There are multiple submodules, each with overlapping imports and each with 
their own module header.

 

 

Andy

 

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

Re: [netmod] Adoption of versioning design team docs

[Balázs Lengyel]

As one of the authors/contributors I support adoption.

Balazs

 

From: netmod  On Behalf Of Lou Berger
Sent: 2020. március 2., hétfő 23:30
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
 
 



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

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

-Original Message-
From: Benoit Claise  
Sent: 2020. március 3., kedd 19:22
To: Lou Berger ; jcla...@cisco.com; rrah...@cisco.com; 
rwil...@cisco.com; Balázs Lengyel ; 
jason.ste...@nokia.com; kd6...@att.com
Cc: netmod-ver...@ietf.org; netmod@ietf.org
Subject: Re: Regarding IPR on draft-verdt-netmod-yang-module-versioning-01

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



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

.org/wg/netconf/>
 WG List:   <mailto:netc...@ietf.org> <mailto:netc...@ietf.org>
 
 Editor:   Balazs Lengyel
<mailto:balazs.leng...@ericsson.com> 
<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
> > 
> 
> Andy
>  
> > > 
> > > On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka  > > <mailto:lho...@nic.cz> > 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 thi

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

[Balázs Lengyel]

Hello Chairs,
I replied to Juergen, and exchanged some additional mails with him. I updated 
the draft to draft-ietf-netmod-yang-instance-file-format-07. Please take it 
forward in the process.

https://protect2.fireeye.com/v1/url?k=ed368c2e-b1bcaefa-ed36ccb5-0cc47ad93e6a-1bf0817821133165=1=b8630aed-b037-42b0-a579-0e6e8067e0eb=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. február 9., vasárnap 20:23
To: netmod@ietf.org
Subject: Re: [netmod] WG Last Call: 
draft-ietf-netmod-yang-instance-file-format-06

This message closes the WGLC.

Authors, please respond to Juergen’s message from Jan 20, ultimately posting an 
update to the draft.

Thanks,
Kent // as shepherd



> On Jan 7, 2020, at 7:41 AM, Kent Watsen  wrote:
> 
> 
> This begins a two-week Working Group Last Call (WGLC) on 
> draft-ietf-netmod-yang-instance-file-format-06.  The WGLC ends on Jan 21.  
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors.  Objections, concerns, and suggestions are also welcomed at this 
> time.
> 
> Thank you,
> NETMOD 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


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Balázs Lengyel]

See below as BALAZS2.

-Original Message-
From: Schönwälder, Jürgen  
Sent: 2020. február 12., szerda 10:07
To: Balázs Lengyel 
Cc: Kent Watsen ; NETMOD Working Group

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

>   - I fail to see the difference between 'content-schema' and 'content
> defining YANG module(s)'. The 'content-schema' is already a set of
> YANG modules. I suggest to remove 'Content defining YANG module(s)
> as it is not a necessary term. Rewrite all places where the phrase
> 'content defining YANG modules' is used.
> BALAZS: a schema is a full set of YANG modules needed to define the 
> structure and properties of the instance data (+features, deviations).
> A  "content defining YANG module" is an individual YANG module is part 
> of the content-schema. So the difference is a set versus one item.
> I updated the description to emphasize this difference.

OK. But then what is a non-content defining YANG module? Or are these
schema-defining YANG modules? I still do not get why we need 'content
defining YANG modules' - we did not need that in other specifications so far
that define schemas. So why do we need new terms here?
BALAZS2: In some paragraphs I reference individual YANG modules that are
part of the content-schema. What would be a better term for the individual
modules?

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

>   - I do not understand that text about the default attribute. Section
> 4.8.9 defines a query parameter, not an attribute. And I do not
> know how that fits into content data.
> BALAZS: https://tools.ietf.org/html/rfc8040#section-4.8.9:
> " If the "with-defaults" parameter is set to "report-all-tagged", then
>the server MUST adhere to the default-reporting behavior defined in
>Section 3.4 of [RFC6243].  Metadata is reported by the server as
>specified in Section 5.3.  The XML encoding for the "default"
>attribute sent by the server for default nodes is defined in
>Section 6 of [RFC6243].  The JSON encoding for the "default"
>attribute MUST use the same values, as defined in [RFC6243], but
>encoded according to the rules in [RFC7952].  The module name
>"ietf-netconf-with-defaults" MUST be used for the "default"
>attribute. "
> Here the usage of the default ATTRIBUTE is defined.

I am still confused about terminology here, an attribute is an XML way of
representing meta data, JSON does this differently. Perhaps some good
examples would clear the confusion.
BALAZS2: The Restconf RFC uses the exact term " the default attribute". If
it is acceptable there IMHO I should be able to reuse it here. It is not my
terminology it's from RFC 8040. 

>   - Similarly, I do not understand why implementation specific
> metadata may be included in the content-data. This seems to be the
> wrong place, no? Should metadata not go into the header?
> BALAZS: As this might be meta-data about the individual instance data 
> nodes (e.g.  metadata following the principles from rfc7952) it 
> belongs here.

OK, perhaps my confusion is that it was not clear to me what kind of
metadata is meant here...
BALAZS2:  OK., will try to update, clarify the text.
 
>   - Why MUST XML attributes be ignored, why is there no text about
> unknown JSON data, 'attributes' (or annotations)? What should
> im

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

[Balázs Lengyel]

-Original Message-
From: netmod  On Behalf Of Schönwälder, Jürgen
Sent: 2020. január 20., hétfő 15:46
To: Kent Watsen 
Cc: NETMOD Working Group 
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06

On Tue, Jan 07, 2020 at 12:41:23PM +, Kent Watsen wrote:
> 
> This begins a two-week Working Group Last Call (WGLC) on
draft-ietf-netmod-yang-instance-file-format-06.  The WGLC ends on Jan 21.
Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is
ready for publication", are welcome!  This is useful and important, even
from authors.  Objections, concerns, and suggestions are also welcomed at
this time.
>

I have reviewed draft-ietf-netmod-yang-instance-file-format-06. I believe
this is an important document but not quite ready yet. Most of the points I
am raising below should, however, be easy to resolve, many concern
terminology and writing consolidation and do not affect the technical
solution.

/js

* Abstract

  I think we should avoid referring to some  operation. Here is a
  proposal of a rewrite:

OLD

   running server available.  This document specifies a standard file
   format for YANG instance data (which follows the syntax and semantic
   from existing YANG models, re-using the same format as the reply to a
operation/request) and annotates it with metadata.

NEW

   running server available.  This document specifies a standard file
   format for YANG instance data, which follows the syntax and semantic
   of existing YANG models, and annotates it with metadata.
BALAZS: Other have expressly asked for a reference to "get" but if you want
I can remove it.

* Terminology

  - Add missing dots (full stops) at the end of sentences
BALAZS: OK

  - I fail to see the difference between 'content-schema' and 'content
defining YANG module(s)'. The 'content-schema' is already a set of
YANG modules. I suggest to remove 'Content defining YANG module(s)
as it is not a necessary term. Rewrite all places where the phrase
'content defining YANG modules' is used.
BALAZS: a schema is a full set of YANG modules needed to define the 
structure and properties of the instance data (+features, deviations).  
A  "content defining YANG module" is an individual YANG module is 
part of the content-schema. So the difference is a set versus one item. 
I updated the description to emphasize this difference.

  - Is "YANG Instance Data" a newly defined term? It's introduction
does not follow the colon style. I also wonder why we need this
term. Why is YANG in there? I would prefer to have this defined in
RFC 7950 terms. Is 'instance data' a collection of instantiated
'data nodes'? Perhaps then we should do the following and move
this up to the first definition, so we define instance data first,
then instance data set, and finally instance data file.

OLD

   YANG Instance Data, or just instance data for short, is data that
   could be stored in a datastore and whose syntax and semantics is
   defined by YANG models.

NEW

   Instance Data: A collection of instantiated data nodes.
BALAZS: OK, updated. 

* Introduction

  - It seems UC5 subsumes UC4.
BALAS: OK UC4 and 5 merged

  - One could add UCx: Storing instance data used as test cases but
then this list of use cases does not need to be exhaustive (means
I do not care much).
BALAZS: Valid use case, but not added for now. If you say so I can add it.

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

  - P4: What is 'many'? Or did you want to use 'multiple'?
BALAZS: OK, changed to multiple,

* Instance Data File Format

  - Replace "real data" with instance data

  OLD

"real data" that we want to document/provide.

  NEW

instance data that we want to document/provide.
BALAZS: OK

  - I do not understand that text about the default attribute. Section
4.8.9 defines a query parameter, not an attribute. And I do not
know how that fits into content data.
BALAZS: https://tools.ietf.org/html/rfc8040#section-4.8.9:
" If the "with-defaults" parameter is set to "report-all-tagged", then
   the server MUST adhere to the default-reporting behavior defined in
   Section 3.4 of [RFC6243].  Metadata is reported by the server as
   specified in Section 5.3.  The XML encoding for the "default"
   attribute sent by the server for default nodes is defined in
   Section 6 of [RFC6243].  The JSON encoding for the "default"
   attribute MUST use the same values, as defined in [RFC6243], but
   encoded according to the rules in [RFC7952].  The module name
   "ietf-netconf-with-defaults" MUST be used for the 

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

[Balázs Lengyel]

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

-Original Message-
From: Martin Bjorklund  
Sent: Tuesday, January 7, 2020 2:38 PM
To: Balázs Lengyel 
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  wrote:
> As a draft author who was asked to add text about the imports IMHO
> 
> * it would be easy for me to remove the description from the import. 
> Actually I really just want to know what is acceptable to the group, so I can 
> proceed
> * I also think that adding this text is in most cases easy and it does 
> not need updates later.
> * The rules in some cases might not be trivial.
> 
> * Imported YAMs need to be implemented if
> 
> * Imported parts are included in Xpath (augment, when, must, 
> require-instance)
> 
> * Imported YAMs do not need to be implemented if only the following are 
> used
> 
> * Types
> * Features
> * extensions
> 
> * Ambiguous if
> 
> * groupings are used
> * if the dependency is not formally defined by YANG, but functionally 
> needed. (E.g. notification-capabilities does not formally need YANG-Push to 
> be implemented, however there is no sense in defining capabilities if 
> YANG-Push is itself not implemented.)
> * deviation ?
> * other cases ?
> 
> Regards Balazs
> 
>  
> 
> From: netmod  On Behalf Of Andy Bierman
> Sent: 2019. december 19., csütörtök 17:23
> To: Ladislav Lhotka 
> Cc: NetMod WG 
> Subject: Re: [netmod] Text in import to indicate whether a module is 
> needed as import-only or as implemented
> 
>  
> 
>  
> 
>  
> 
> On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka  <mailto:lho...@nic.cz> > wrote:
> 
> On Thu, 2019-12-19 at 07:52 +, Schönwälder, Jürgen wrote:
> > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote:
> > > I don't see how YANG syntax defines this. If a module imports 
> > > ietf-netconf- acm, it could be because
> > > 
> > > - it just uses a typedef, such as "node-instance-identifier", and then
> > >   ietf-netconf-acm needn't be implemented (but can be),
> > > 
> > > or
> > > 
> > > - it augments ietf-netconf-acm, which makes sense only if the latter
> > >   module is implemented.
> > > 
> > > It it the YANG library that specifies whether a module is 
> > > implemented or not, but the "import" statement itself doesn't tell you 
> > > anything.
> > > 
> > 
> > Can we not assume that an implementor will figure out the difference?
> 
> An implementor should be able to figure it out, but other potential 
> module users may not. For example, if somebody is evaluating whether 
> to use a module for their device or not, it is important to know that 
> NACM has to be implemented (or not).
> 
>  
> 
> You seem to be talking about a new conformance documentation procedure
> 
> that attempts to solve the problem "to use modules A, B, and C 
> together
> 
> to achieve some functionality X, all these conditions need to be met"..
> 
> (Sounds more like a problem for YANG Packages to solve)
> 
>  
> 
> IMO this is a much harder problem than something that can be solved
> 
> with extra description-stmt text. The writer is likely to get it wrong 
> or not
> 
> keep it up to date, so a tool to analyze the file seems like a better 
> solution.
> 
>  
> 
> Lada
> 
>  
> 
>  
> 
> Andy
> 
>  
> 
> 
> > Or someone writes a pyang plugin to determine from the schema tree 
> > the kind of imports there are (for a given set of features).
> > 
> > /js
> > 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] IPR poll on draft-ietf-netmod-yang-instance-file-format

[Balázs Lengyel]

"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] Text in import to indicate whether a module is needed as import-only or as implemented

[Balázs Lengyel]

As a draft author who was asked to add text about the imports IMHO

*   it would be easy for me to remove the description from the import. 
Actually I really just want to know what is acceptable to the group, so I can 
proceed
*   I also think that adding this text is in most cases easy and it does 
not need updates later.
*   The rules in some cases might not be trivial.

*   Imported YAMs need to be implemented if

*   Imported parts are included in Xpath (augment, when, must, 
require-instance)

*   Imported YAMs do not need to be implemented if only the following are 
used

*   Types
*   Features
*   extensions

*   Ambiguous if

*   groupings are used
*   if the dependency is not formally defined by YANG, but functionally 
needed. (E.g. notification-capabilities does not formally need YANG-Push to be 
implemented, however there is no sense in defining capabilities if YANG-Push is 
itself not implemented.)
*   deviation ?
*   other cases ?

Regards Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. december 19., csütörtök 17:23
To: Ladislav Lhotka 
Cc: NetMod WG 
Subject: Re: [netmod] Text in import to indicate whether a module is needed as 
import-only or as implemented

 

 

 

On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka mailto:lho...@nic.cz> > wrote:

On Thu, 2019-12-19 at 07:52 +, Schönwälder, Jürgen wrote:
> On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote:
> > I don't see how YANG syntax defines this. If a module imports ietf-netconf-
> > acm, it could be because
> > 
> > - it just uses a typedef, such as "node-instance-identifier", and then
> >   ietf-netconf-acm needn't be implemented (but can be),
> > 
> > or
> > 
> > - it augments ietf-netconf-acm, which makes sense only if the latter
> >   module is implemented.
> > 
> > It it the YANG library that specifies whether a module is implemented or
> > not, but the "import" statement itself doesn't tell you anything.
> > 
> 
> Can we not assume that an implementor will figure out the difference?

An implementor should be able to figure it out, but other potential module users
may not. For example, if somebody is evaluating whether to use a module for
their device or not, it is important to know that NACM has to be implemented (or
not).

 

You seem to be talking about a new conformance documentation procedure

that attempts to solve the problem "to use modules A, B, and C together

to achieve some functionality X, all these conditions need to be met".

(Sounds more like a problem for YANG Packages to solve)

 

IMO this is a much harder problem than something that can be solved

with extra description-stmt text. The writer is likely to get it wrong or not

keep it up to date, so a tool to analyze the file seems like a better solution.

 

Lada

 

 

Andy

 


> Or someone writes a pyang plugin to determine from the schema tree the
> kind of imports there are (for a given set of features).
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

Hello Mahesh, 

I was asked by the group to include in each import statement whether the 
imported module is needed as import-only or as implemented. IMHO netmod/netconf 
group should agree on some standard text for model designers to use. Maybe the 
text proposed below can be used everywhere. The sentence starting with Revision 
-mm-dd  may not always be needed.

 

 

I propose the text  

 

  import ietf-netconf-acm  {

prefix nacm;

description

   "The module ietf-netconf-acm is OPTIONAL to implement.";

  }

 

  import ietf-yang-library {

prefix yanglib;

description "The module ietf-yang-library is REQUIRED to

  be implemented. Revision 2019-01-04 or a

  revision derived from it is REQUIRED.";

  }

 

Regards Balazs

 

P.S. In Yang-Next this could be a candidate for a formal substatement instead 
of a description text.

 

 

From: Mahesh Jethanandani  
Sent: 2019. december 18., szerda 3:20
To: Kent Watsen 
Cc: Balázs Lengyel 
Subject: Re: [netconf] New Version Notification for 
draft-ietf-netconf-notification-capabilities-08.txt

 

Hi Balazs,

 

Additionally, it would be important to address some of the normative text in 
the module. Specifically, we were looking at the following description 
statements:

 

  import ietf-yang-push{
prefix yp;
description
  "This module requires ietf-yang-push to be implemented for the
two subscription-capabilities containers.";
  }
  import ietf-yang-library {
prefix yanglib;
description "This module requires ietf-yang-library to
  be implemented. Revision 2019-01-04 or a
  revision derived from it is required.";
  }

 

The requirement in the description statement feels and smells like words one 
would use to signify requirements in a specification. However, you are not 
using any of the words like REQUIRED etc. to describe it. Why is it?

 

Mahesh Jethanandani

mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] RFC 6991bis: Abridged-instance-identifier

[Balázs Lengyel]

Hello.

The following type was proposed to me. Would it be interesting  for others?

In some cases were the length of the identifier matters this can be useful
e.g. on a user interface or in an SNMP packet.

 

 

typedef abridged-instance-identifier {

type string ;

description "An instance-identifier in which the prefix is not repeated.

  The prefix is omitted where ever the last included prefix is the  

  same as the one that would be present for the current data-node. 

  The original instance-identifier syntax would be 

/ex:system/ex:user[ex:name='fred']/other:type

  The corresponding abridged-instance-identifier format is

/ex:system/user[name='fred']/other:type";

  }

 

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR poll on draft-ietf-netmod-factory-default

[Balázs Lengyel]

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

Balazs

 

From: Kent Watsen  
Sent: 2019. december 2., hétfő 17:23
To: Qin Wu ; Balázs Lengyel
; Ye Niu 
Cc: netmod@ietf.org
Subject: Re: [netmod] IPR poll on draft-ietf-netmod-factory-default

 

Qin and Ye, thank you  for your responses.

Balazs, your response is still pending.

 

Kent // shepherd

 





On Nov 12, 2019, at 1:19 PM, Kent Watsen mailto:kent+i...@watsen.net> > wrote:

 

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 draft-ietf-netmod-factory-default?  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>
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.


Kent // as Shepherd

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below: BALAZS5.

 

From: Andy Bierman  
Sent: 2019. november 19., kedd 1:17
To: Balázs Lengyel 
Cc: Martin Bjorklund ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

the following text (or similar) should be added to the description-stmt above

This node SHOULD contain a single container instance which represents 
either the /yang-library 

 or /modules-state subtree.

This allows for exceptions but still provides interoperability instructions.

Andy

BALAZS4: Others (e.g., Juergen) explicitly asked for not restricting this to 
ietf-yang-library. 

I would be happy with your proposals, but the group decided otherwise sometime 
back.

 

 

 

A tool has to be coded to understand the contents of the anydata node.

Just parsing it is not enough.  

 

Is there an email thread this is discussed and resolved?

The term SHOULD allows the rule to be broken with a good reason. 

What other data structures are needed now (or soon) other than /modules-state 
or /yang-library?

I do not see how this file is interoperable if the reader does not know what to 
expect.

Flexibility without interoperability is not success.

 

BALAZS5:  Look at the last paragraph in the email: 
https://mailarchive.ietf.org/arch/msg/netmod/h-gT2jg5Z5aREXTD-E7Yx6oi7PE

 

Also I foresee there might be (there will be)  YANG modules that augment 
yang-library  with information needed here. 

I am thinking about yang-versioning that plans to add the version-label, which 
will help determining which versions of the of the YANG module are compatible 
with the originally used schema defining modules.

 

I do not see how augment is relevant to this interoperability issue.

 

Andy

 

BALAZS5: The use case in mind is that  
<https://tools.ietf.org/html/draft-verdt-netmod-yang-module-versioning-01#section-5.2>
 
https://tools.ietf.org/html/draft-verdt-netmod-yang-module-versioning-01#section-5.2
 augments the revision-label into YANG-library. Revision-label can be used by 
the operator to understand which version of the YANG Module (YAM) we are using, 
and what other versions are compatible with it. This compatibility information 
that can be used by the operator to determine if a server with a slightly 
updated module set can use the instance data set.



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below BALAZS4.

 

From: Andy Bierman  
Sent: 2019. november 18., hétfő 7:12
To: Balázs Lengyel 
Cc: Martin Bjorklund ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

 

 

On Sun, Nov 17, 2019 at 10:01 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

See below BALAZS3.

 

From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2019. november 18., hétfő 0:58
To: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >
Cc: Martin Bjorklund mailto:m...@tail-f.com> >; NetMod WG 
mailto:netmod@ietf.org> >
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2019. november 7., csütörtök 23:58
To: Martin Bjorklund mailto:m...@tail-f.com> >
Cc: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >; NetMod WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

It seems strange that the details that don't matter at all (like the filename) 
have lots

of rules that MUST be followed and the details that actually add standards 
value are left unspecified.

Andy

BALAZS2: Actually what is missing, unspecified?

 

The inline-schema is under-specified.

There is no way for the file reader to know what to expect as the child nodes 
of inline-schema.

 

The file writer can put anything there and a 3rd party reader tool is expected 
to support it.

 

   anydata inline-schema {
 mandatory true;
 description
   "Instance data corresponding to the YANG modules
specified in the inline-module nodes defining the set
of content defining YANG modules for this
instance-data-set."; 

   } 

 

 

Andy

 

BALAZS3:

IMO the anydata is specified.  The leaf-list inline-module defines the modules 
that define how anydata inline-schema should look like.

   anydata inline-schema {

 mandatory true;

 description

   "Instance data corresponding to the YANG modules

specified in the inline-module ...

 

The fileReader/fileWriter shall look at the ‘leaf-list inline-module’ and from 
that it knows what to read/write.

 

I wanted to state that inline-schema anydata always follows the 
ietf-yang-library and maybe some YAMs augmenting it. However Juergen insisted 
in a more flexible solution.

 

 

I think the following text (or similar) should be added to the description-stmt 
above

 

This node SHOULD contain a single container instance which represents 
either the /yang-library 

 or /modules-state subtree.

 

This allows for exceptions but still provides interoperability instructions.

 

 

Andy

 

BALAZS4: Others (e.g., Juergen) explicitly asked for not restricting this to 
ietf-yang-library. 

I would be happy with your proposals, but the group decided otherwise sometime 
back.

 

Also I foresee there might be (there will be)  YANG modules that augment 
yang-library  with information needed here. 

I am thinking about yang-versioning that plans to add the version-label, which 
will help determining which versions of the of the YANG module are compatible 
with the originally used schema defining modules.

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

-Original Message-
From: Martin Bjorklund  
Sent: 2019. november 18., hétfő 0:53
To: Balázs Lengyel 
Cc: a...@yumaworks.com; netmod@ietf.org
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  > <mailto:m...@tail-f.com> > wrote:
> > 
> > 
> >   o  leaf-list module
> > 
> > The type of this leaf-list is a string with:
> > 
> >   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> > 
> > I think the revision needs to be optional, and the suffix ".yang"
> > dropped, since it doesn't add any value:
> > 
> >   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> > 
> >(same for inline-spec).
> > 
> >  
> > 
> > IMO the filespec SHOULD follow the pattern in
> > https://tools.ietf.org/html/rfc7950#section-5.2
> > 
> > BALAZS: It does follow the pattern except that I made the revision date 
> > mandatory. It is needed to properly understand the instance data.
> > 
> >  
> > 
> > Except a new file extension SHOULD be used.
> > 
> > Suggest: .yif == YANG Instance File
> > 
> >  
> > 
> > Obviously it would be a horrible idea to use .yang since that 
> > extension
> > 
> > is already used to identify a YANG schema file.
> > 
> > BALAZS: The leaf-list lists not the instance data files but the content 
> > defining YANG modules, so IMO “.yang” is an appropriate extension. It is 
> > really a YANG schema file we are listing.
> 
> No, you are not listing a file name, you are listing the name and, 
> optionally, the revision of a YANG *module*.  It can internally be stored as 
> a .yang file a .yin file, or as a blob in a database.
> 
> Hence, we should not have the ".yang" suffix here.
> BALAZS2:
> OK, I will add the '.yin' possibility.

IMO this is even worse.  Which suffix should I use?  What difference does it 
make?

> I would like to keep the file extension because 
> ietf-yang-t...@2015-12-07.yang looks more familiar

I think it is a bad idea to use something that looks familiar but change the 
meaning of it.  It is *not* a filename, it is a pair modulename + optional 
revision; an identifier for the module.

, will be easier to understand, than just
> ietf-yang-types@2019-12-07
> IMHO in practice systems might very well use it for file lookup.

But if I use this for file lookup, and I use YIN, and I try to use an instance 
file that lists the modules as ".yang", this won't work.


Perhaps solve this by changing the leaf-list into:

  container inline-modules {
list module {
  key name;
  leaf name { ... }
  leaf revision { ... }
}
  }

/martin

BALAZS3: People explicitly asked for a short, simple solution, so reusing the 
well-known module-file-naming format seemed logical,  and nobody misunderstood 
it till now.
I would really like to avoid creating a list with 2 separate leaf's: longer, 
more complex. It goes against the express wishes of other group members.
If you prefer we can drop the file extension. IMHO it will look strange.


I think a file loader can have the intelligence to look for a yin if yang is 
not found or vice-versa.
/Balazs




smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below BALAZS3.

 

From: Andy Bierman  
Sent: 2019. november 18., hétfő 0:58
To: Balázs Lengyel 
Cc: Martin Bjorklund ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 From: Andy Bierman mailto:a...@yumaworks.com> > 
Sent: 2019. november 7., csütörtök 23:58
To: Martin Bjorklund mailto:m...@tail-f.com> >
Cc: Balázs Lengyel mailto:balazs.leng...@ericsson.com> >; NetMod WG mailto:netmod@ietf.org> >
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

It seems strange that the details that don't matter at all (like the filename) 
have lots

of rules that MUST be followed and the details that actually add standards 
value are left unspecified.

Andy

BALAZS2: Actually what is missing, unspecified?

 

The inline-schema is under-specified.

There is no way for the file reader to know what to expect as the child nodes 
of inline-schema.

 

The file writer can put anything there and a 3rd party reader tool is expected 
to support it.

 

   anydata inline-schema {
 mandatory true;
 description
   "Instance data corresponding to the YANG modules
specified in the inline-module nodes defining the set
of content defining YANG modules for this
instance-data-set."; 

   } 

 

 

Andy

 

BALAZS3:

IMO the anydata is specified.  The leaf-list inline-module defines the modules 
that define how anydata inline-schema should look like.

   anydata inline-schema {

 mandatory true;

 description

   "Instance data corresponding to the YANG modules

specified in the inline-module ...

 

The fileReader/fileWriter shall look at the ‘leaf-list inline-module’ and from 
that it knows what to read/write.

 

I wanted to state that inline-schema anydata always follows the 
ietf-yang-library and maybe some YAMs augmenting it. However Juergen insisted 
in a more flexible solution. 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

 

 

From: Andy Bierman  
Sent: 2019. november 7., csütörtök 23:58
To: Martin Bjorklund 
Cc: Balázs Lengyel ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

It seems strange that the details that don't matter at all (like the filename) 
have lots

of rules that MUST be followed and the details that actually add standards 
value are left unspecified.

 

Andy

 

BALAZS2: Actually what is missing, unspecified?



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below BALAZS2.

-Original Message-
From: Martin Bjorklund  
Sent: 2019. november 7., csütörtök 16:25
To: a...@yumaworks.com
Cc: Balázs Lengyel ; netmod@ietf.org
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04
> The schema-uri looks standard but the contents of the referenced YANG 
> instance file can be anything (as opposed to a pre-defined YANG 
> template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier comments).  It is 
really 'same-schema-as-file', which means that it point to another YANG 
instance data file, which must specify its schema in one of the three ways.  
Which may be another schema-uri, but in the end the recursion must stop and you 
must find a YANG instance data file that usses 'simplified-inline' or 'inline'.
BALAZS2: leaf name changes following Martin's suggestion

> The inline-content-schema object looks broken because a YANG file is a 
> text string.

It is supposed to be data nodes for /yang-library or perhaps /module-sets, or 
perhaps something else.  See the examples in section 3.2.

BALAZS2: The draft includes the text:
" A schema-uri leaf SHALL contain a URI that references another YANG   instance 
data file."
So just as Martin says: it is a reference to a YANG file but to a yang INSTANCE 
DATA file: which is yangdata.

/martin



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below BALAZS2.
-Original Message-
From: Martin Bjorklund  
Sent: 2019. november 7., csütörtök 16:17
To: Balázs Lengyel 
Cc: a...@yumaworks.com; netmod@ietf.org
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Balázs Lengyel  wrote:
> See below!Balazs
> 
>  
> 
> From: netmod  On Behalf Of Andy Bierman
> Sent: 2019. október 10., csütörtök 17:34
> To: Martin Bjorklund 
> Cc: NetMod WG 
> Subject: Re: [netmod] comments on 
> draft-ietf-netmod-yang-instance-file-format-04
> 
>  
> 
>  
> 
>  
> 
> On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  <mailto:m...@tail-f.com> > wrote:
> 
> 
>   o  leaf-list module
> 
> The type of this leaf-list is a string with:
> 
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> 
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
> 
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> 
>(same for inline-spec).
> 
>  
> 
> IMO the filespec SHOULD follow the pattern in  
> https://tools.ietf.org/html/rfc7950#section-5.2
> 
> BALAZS: It does follow the pattern except that I made the revision date 
> mandatory. It is needed to properly understand the instance data.
> 
>  
> 
> Except a new file extension SHOULD be used.
> 
> Suggest: .yif == YANG Instance File
> 
>  
> 
> Obviously it would be a horrible idea to use .yang since that 
> extension
> 
> is already used to identify a YANG schema file.
> 
> BALAZS: The leaf-list lists not the instance data files but the content 
> defining YANG modules, so IMO “.yang” is an appropriate extension. It is 
> really a YANG schema file we are listing.

No, you are not listing a file name, you are listing the name and, optionally, 
the revision of a YANG *module*.  It can internally be stored as a .yang file a 
.yin file, or as a blob in a database.

Hence, we should not have the ".yang" suffix here.
BALAZS2:
OK, I will add the '.yin' possibility.
I would like to keep the file extension because
ietf-yang-t...@2015-12-07.yang
looks more familiar, will be easier to understand, than just
ietf-yang-types@2019-12-07
IMHO in practice systems might very well use it for file lookup.

I updated the pattern to: 
  pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*' +
'(@\d{4}-\d{2}-\d{2})?\.((yang)|(yin))';
/martin


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below BALAZS2.

-Original Message-
From: Martin Bjorklund  
Sent: 2019. november 7., csütörtök 16:08
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] comments on
draft-ietf-netmod-yang-instance-file-format-04

Hi,

>   o  leaf-list module
> The type of this leaf-list is a string with:
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
>(same for inline-spec).
> BALAZS: I disagree, IMHO we need the revision date. We want to know 
> the exact version the data was produced against. If the version would 
> be unknown it might become very hard to understand whether the 
> instance data is correct or not.

The point is that the revision statement is optional in YANG.  If the module
doesn't have a revision statement I can't list it here.
BALAZS2: OK, I will update the pattern  to make the date optional, and will
add in the description, that if it is available it must be used.

> 
>   o  schema-uri
> The description says:
>   A reference to another YANG instance data file.
>   This instance data file will use the same set of target
>   YANG modules, revisions, supported features and deviations
>   as the referenced YANG instance data file.
> 
>I don't understand what this means.  Does it mean that the schema
>for this document is the same as the schema defined in the
>schema-uri file, or that the schema-uri file defines the schema in
>its content-data?
> 
>I *think* it is the former.  In either case, the name of the leaf
>can perhaps be changed to reflect the semantics, rather than the
>syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
>Perhaps 'same-schema-as-file'.
> BALAZS:  OK, I changed the description hope it is easier to understand
now.
> description
>   "A reference to another YANG instance data file.
>This instance data file will use the same
>content schema as the referenced file.";

Thanks, better.  Perhaps: s/will use/uses/
BALAZS2: OK

/martin


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below, BALAZS

 

From: Andy Bierman  
Sent: 2019. november 7., csütörtök 7:44
To: Balázs Lengyel 
Cc: Martin Bjorklund ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

 

IMO section 3 is too specific about the content within the content-data node.

The only requirement should be that it is valid XML or JSON according to

the schema listed.  All content should be identified, so if you include 
or:origin attributes

then ietf-origin MUST be in the schema list.  It is a bad idea to force tools 
to accept

invalid XML (e.g., no xmlns for a prefix that is used.

BALAZS: Don’t really agree. We intentionally allow the violation of the schema 
(as described)
-  partial data set are allowed

*   It is allowed to only have config=false data

People requested to explicitly mention UTF-8

IMHO it is good to mention metadata/XML attributes as they are useful and are 
not regulated by the schema

 

The text about the required file-name structure if timestamps are present

seems rather arbitrary.  What if the tool generating the file is not aware of

specific YANG objects, so it does not know there are data nodes representing 
timestamps?

Why is this needed? The file contains revision and timestamp meta-data.

 

 

   If the leaf name is present in the instance data header this MUST
  be used.  Revision-date MUST be set to the latest revision date
  inside the instance data set.

 

I do not understand the text above.

IMO none of sec. 3 MUST requirements are needed.

Looks like a lot of CLRs to me.

BALAZS: To make it easier I will make the inclusion of date/timestamp optional.

 

These are nearly the exact same rules we have for naming YANG files.

Name+date

Even for a YANG module we require that an internal data element, the module’s 
argument must match the file name’s beginning.

Even for a YANG module we recommend that an internal data element, the 
revision’s argument must match the file name’s middle part.

Many people like it that the file’s name immediately tells you what it is and 
what version.

 

 

Hard to see what harm to the Internet is caused

by a YID file that is named "incorrectly".  Tools will create their own file 
extensions, because

lumping everything in with .xml or .json is shortsighted. Why does the standard 
say SHALL

use .xml or .json?  Is this a general requirement for all XML or JSON content?

If not, then why is being added here?

BALAZS: It was an earlier decision of the netmod group to use just json/xml. I 
would like a more descriptive extension but was outvoted.

 

How does the tool that reads the YID file know what version of the YID template 
is being used?

(Or do you think this module is perfect, and will never be updated?)

Seems like the very first leaf should be a "yid-version", similar to 
"yang-version" in YANG.

BALAZS:  OK, I will add the yid-version. (Otherwise the module is perfect :-)  )

 

 

Andy

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

1 comment accepted, 1 explained. See below BALAZS2. 

 

From: Andy Bierman  
Sent: 2019. november 7., csütörtök 7:15
To: Balázs Lengyel 
Cc: Martin Bjorklund ; NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund mailto:m...@tail-f.com> > wrote:


  o  leaf-list module

The type of this leaf-list is a string with:

  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:

  pattern '.+(@\d{4}-\d{2}-\d{2})?';

   (same for inline-spec).

 

IMO the filespec SHOULD follow the pattern in  
https://tools.ietf.org/html/rfc7950#section-5.2

BALAZS: It does follow the pattern except that I made the revision date 
mandatory. It is needed to properly understand the instance data.

 

 

The representation (.yang vs .yin) is not relevant here.

Revision statements are optional in a YANG module, so what fake date string do 
you

use if the module has no revision?  Seems prudent to make the date-string 
optional in the filename.

 

 

BALAZS2: OK, date mandatory only  if present in the yang module, otherwise 
absent. I will add .yin as an alternative.

I would like to keep the \.((yang)|(yin)) part in the pattern as 

 <mailto:ietf-yang-t...@2015-12-07.yang> ietf-yang-t...@2015-12-07.yang

looks more familiar than just

ietf-yang-types@2019-12-07

 

+1, except not in favor of so many ways to specify schema.

That means the file reader MUST support all of them.

 

BALAZS: All 3 formats have been explicitly requested by earlier commenters. I 
see a rational for each:

Simplified-inline: it is simple and usually enough

Inline: if you need to specify not just the modules but also the supported 
features and deviations you need this full format

Uri: if you don’t really want to specify the content-schema in detail, e.g., 
because you are generating many files with the same schema, all you need is 
reference that identifies the content-schema

 

Which one would you like to implementing? Maybe we could make the inline method 
optional with a feature (feature if-feature),

 

 

I will just deviate out the stuff not worth implementing. ;-)

I prefer the schema-uri approach but simplified-inline is probably easiest to 
implement.

 

The schema-uri looks standard but the contents of the referenced YANG instance 
file can be

anything (as opposed to a pre-defined YANG template like /yang-library).

 

The inline-content-schema object looks broken because a YANG file is a text 
string.

How does one use anydata to encode a text string? (It must be a container of 
YANG data nodes).

Even the YIN representation is not a set of YANG data nodes, so anydata 
encoding seems wrong.

Including all the YANG modules in this file seems especially heavyweight.

(I have no intention of supporting this mode.)

BALAZS2: This does not contain the YANG files themselves, rather something like 
instance data for the ietf-yang-library.

So it is anydata.

Sometimes specifying deviations and supported features may be needed. Also 
Jurgen wanted a flexible solution.

As a private comment: you may deviate it out (I can’t say this officialy :-)  )

 

 

Andy

 

 

Andy

 

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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below, Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. október 10., csütörtök 19:38
To: Martin Bjorklund 
Cc: NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

 

 

On Thu, Oct 10, 2019 at 8:34 AM Andy Bierman mailto:a...@yumaworks.com> > wrote:

 

 

On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund mailto:m...@tail-f.com> > wrote:

Hi,

I have some mostly cosmetic comments on this draft.

  o  "YANG" should be spelled "YANG".  Not Yang etc.


  o  "NETCONF" should be spelled "NETCONF".


  o  leaf-list module

The type of this leaf-list is a string with:

  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:

  pattern '.+(@\d{4}-\d{2}-\d{2})?';

   (same for inline-spec).



 

 

IMO the filespec SHOULD follow the pattern in  
https://tools.ietf.org/html/rfc7950#section-5.2

 

Except a new file extension SHOULD be used.

Suggest: .yif == YANG Instance File

 

Obviously it would be a horrible idea to use .yang since that extension

is already used to identify a YANG schema file.

 

 

 

Sorry about the confusion over this comment.

 

There should be reusable typedefs defined in rfc6991bis representing the format 
in 7950, sec. 5.2

 

There should also be file extensions defined for an XML or JSON file that is 
expected to

follow the YIF structure.  

 

 

Andy

BALAZS: 

For the modules listed in leaf-list module: These are real YANG schema files so 
IMO the “.yang” extension should be used.

For the instance data files: In the -00 version of the draft it was stated that 
the files should have their own extension “.yid” . 

“.yid-json” and “.yid-xml” was also discussed.

However, the group requested that I just use .json and .xml  as extensions (as 
described in section 3.)

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

See below!Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. október 10., csütörtök 17:34
To: Martin Bjorklund 
Cc: NetMod WG 
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

 

 

 

On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund mailto:m...@tail-f.com> > wrote:


  o  leaf-list module

The type of this leaf-list is a string with:

  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:

  pattern '.+(@\d{4}-\d{2}-\d{2})?';

   (same for inline-spec).

 

IMO the filespec SHOULD follow the pattern in  
https://tools.ietf.org/html/rfc7950#section-5.2

BALAZS: It does follow the pattern except that I made the revision date 
mandatory. It is needed to properly understand the instance data.

 

Except a new file extension SHOULD be used.

Suggest: .yif == YANG Instance File

 

Obviously it would be a horrible idea to use .yang since that extension

is already used to identify a YANG schema file.

BALAZS: The leaf-list lists not the instance data files but the content 
defining YANG modules, so IMO “.yang” is an appropriate extension. It is really 
a YANG schema file we are listing.



  o  Data node naming.

The current structure of the model is:

+--rw (content-schema-spec)?
|  +--:(simplified-inline)
| +--rw module* string
|  +--:(inline)
|  |  +--rw inline-spec*string
|  |  +--rw inline-content-schema   
|  +--:(uri)
| +--rw schema-uri?   inet:uri
...
+--rw content-data? 


To make the instance document more understandable, I suggest the
following structure, which adds a wrapping container for the
schema, and renames the inline and uri nodes:

+--rw content-schema
   +--rw (content-schema-spec)?
   |  +--:(simplified-inline)
   | +--rw module* string
   |  +--:(inline)
   |  |  +--rw inline-module*  string
   |  |  +--rw inline-schema   
   |  +--:(uri)
   | +--rw same-schema-as-file?inet:uri
...
+--rw content-data? 



 

+1, except not in favor of so many ways to specify schema.

That means the file reader MUST support all of them.

 

BALAZS: All 3 formats have been explicitly requested by earlier commenters. I 
see a rational for each:

Simplified-inline: it is simple and usually enough

Inline: if you need to specify not just the modules but also the supported 
features and deviations you need this full format

Uri: if you don’t really want to specify the content-schema in detail, e.g., 
because you are generating many files with the same schema, all you need is 
reference that identifies the content-schema

 

Which one would you like to implementing? Maybe we could make the inline method 
optional with a feature (feature if-feature),

 

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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

Hello Martin,
I will update the draft following most of your comments. See details below.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Martin Bjorklund
Sent: 2019. október 10., csütörtök 14:05
To: netmod@ietf.org
Subject: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Hi,

I have some mostly cosmetic comments on this draft.
  o  "YANG" should be spelled "YANG".  Not Yang etc.
BALAZS: OK
  o  "NETCONF" should be spelled "NETCONF".
BALAZS: OK
  o  leaf-list module
The type of this leaf-list is a string with:
  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:
  pattern '.+(@\d{4}-\d{2}-\d{2})?';
   (same for inline-spec).
BALAZS: I disagree, IMHO we need the revision date. We want to know the 
exact version the data was produced against. If the version would be 
unknown it might become very hard to understand whether the instance 
data is correct or not.

  o  schema-uri
The description says:
  A reference to another YANG instance data file.
  This instance data file will use the same set of target
  YANG modules, revisions, supported features and deviations
  as the referenced YANG instance data file.

   I don't understand what this means.  Does it mean that the schema
   for this document is the same as the schema defined in the
   schema-uri file, or that the schema-uri file defines the schema in
   its content-data?

   I *think* it is the former.  In either case, the name of the leaf
   can perhaps be changed to reflect the semantics, rather than the
   syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
   Perhaps 'same-schema-as-file'.
BALAZS:  OK, I changed the description hope it is easier to understand now.
description
  "A reference to another YANG instance data file.
   This instance data file will use the same
   content schema as the referenced file.";


  o  Data node naming.
The current structure of the model is:
+--rw (content-schema-spec)?
|  +--:(simplified-inline)
| +--rw module* string
|  +--:(inline)
|  |  +--rw inline-spec*string
|  |  +--rw inline-content-schema   
|  +--:(uri)
| +--rw schema-uri?   inet:uri
...
+--rw content-data? 


To make the instance document more understandable, I suggest the
following structure, which adds a wrapping container for the
schema, and renames the inline and uri nodes:

+--rw content-schema
   +--rw (content-schema-spec)?
   |  +--:(simplified-inline)
   | +--rw module* string
   |  +--:(inline)
   |  |  +--rw inline-module*  string
   |  |  +--rw inline-schema   
   |  +--:(uri)
   | +--rw same-schema-as-file?inet:uri
...
+--rw content-data? 
BALAZS: OK, accepted

  o  Format the YANG module
I suggest you run the YANG module through:
  pyang -f yang --keep-comments --yang-line-length 69
BALAZS: OK (I will do it, but I don't agree with a number of its formatting
changes.

  o  3.2
The element "" needs a namespace declaration.
BALAZS: OK

/martin

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-yang-instance-file-format-04

[Balázs Lengyel]

Hello,
Thanks for the comments and the updated file accordingly.  See below.
Regards Balazs

-Original Message-
From: Acee Lindem via Datatracker  
Sent: 2019. október 30., szerda 13:59
To: yang-doct...@ietf.org
Cc: draft-ietf-netmod-yang-instance-file-format@ietf.org; 
last-c...@ietf.org; netmod@ietf.org
Subject: Yangdoctors last call review of 
draft-ietf-netmod-yang-instance-file-format-04

Reviewer: Acee Lindem
Review result: Ready with Issues

Document: draft-ietf-netmod-yang-instance-file-format-04.txt
Reviewer: Acee Lindem
Review Date: Oct 30st, 2019
Review Type: Working Group Last Call
Intended Status: Standards Track
Summary: Ready with Issues

Modules: "ietf-yang-instance-d...@2019-07-04.yang"

Tech Summary: The model describes mechanisms and statically specifying
  instance data (XML or JSON) for YANG models. Use cases are
  also discussed although not in normative text. The document
  is relatively straight forward but could benefit from some
  editorial cleanup. 

Major Comments:

 None


Minor Comments: 

 1. The "Security Considerations" in section 8 do not conform to the
recommended template in https://trac.ietf.org/trac/ops/wiki/yang-security-
guidelines>. The considerations may be completely dependent on the included
instance Data Set or some of the information in the model may also be
sensitive. However, it needs to be better described.
BALAZS: Updated security considerations, tried to make it more detailed.
However the template is mostly 
not applicable to  this draft. This draft contains very little own data, most 
of 
the instance data is as you sad completely dependent on the included instance 
Data Set.
It is also planned to be accessed as a file, not via Netconf/Restconf.

 2. I feel it would be helpful to explicitly state that the both read-only
and read-write instance data may be included in the instance data set.
BALAZS: OK. Chapter 3.  Instance Data File Format will include the following:
" Config=true and config=false data MAY be mixed in the instance data  file."

 3. The document could requires some editorial cleanup. For example, use
complete sentenses for principles in section 2.1 and punctuate. Do not
begin sentenses with "E.g. ...". 
BALAZS: Principles reworded.


Nits: 

See diff below.

*** draft-ietf-netmod-yang-instance-file-format-04.txt.orig 2019-10-29 
16:36:22.0 -0400
--- draft-ietf-netmod-yang-instance-file-format-04.txt  2019-10-29 
21:40:06.0 -0400
***
*** 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and decorates it with metadata.
  
  Status of This Memo
  
--- 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and annotates it with metadata.
BALAZS: OK
  
  Status of This Memo
  
***
*** 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items decorated with metadata
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision,suupported
!features and deviations for which the instance data set contains
 instance data
  
 Content defining Yang module(s): YANG module(s) that make up the
--- 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items annotated with metadata
BALAZS: OK
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision, supported
BALAZS: OK
!features, and deviations for which the instance data set contains
BALAZS: OK
 instance data
  
 Content defining Yang module(s): YANG module(s) that make up the
***
*** 138,145 
 There is a need to document data defined in YANG models when a live
 server is not available.  Data is often needed already at design or
 implementation time or needed by groups that do not have a live
!running server available.  To facilitate this off-line delivery of
!data this document specifies a standard format for YANG instance data
 sets and YANG instance data files.
  
 The following is a list of already implemented and potential use
--- 

Re: [netmod] Default statements and deviate add/replace

[Balázs Lengyel]

Hello Kent,

As IMO practically all tools are misbehaving I would like a confirmation that 
my interpretation of the differences between deviate add and deviate replace 
are correct.  After that I will start reporting the issues to the tools.

Regards Balazs

 

From: Kent Watsen  
Sent: 2019. október 22., kedd 16:37
To: Balázs Lengyel 
Cc: netmod@ietf.org; Mark Hollmann ; Edvardas 
Lasauskas 
Subject: Re: [netmod] Default statements and deviate add/replace

 

Hi Balazs,

 

Is this for the NETMOD list, or should bugs be filed against the misbehaving 
tools?

 

Kent

 





On Oct 22, 2019, at 6:56 AM, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> > wrote:

 

Hello, 

I tried testing the following statements:

 

  deviation /nacm:nacm/nacm:enable-nacm {

deviate add {

  config false; } }



  deviation /nacm:nacm/nacm:rule-list {

deviate add {

  min-elements 1; }  }

 

In nacm both the config and the min-elements are absent, so their default 
meaning is true. I actually tried both add and replace in deviate.

I got rather confusing results whether the add/replace variant of deviate 
should be accepted or rejected because the property already exists or does not 
yet exist.

 

Pyang 2.0.2 locally:

Config=false   add-NOK  replace-OK

Min-elements=1  add-OK replace-NOK

 

YANG-Validator  pyang 2.0 & confdc

Config=false   add-OK replace-OK

Min-elements=1  add-OK replace-NOK

 

YANG-Validator yanglint

Config=false   add-OK replace-OK

Min-elements=1  add-OK replace-OK

 

IMHO the tools should always check the property, so even if the statement is 
not present the properties config=false and min-elements=0 ARE present. So add 
should be rejected and replace accepted. 

 

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

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

 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Default statements and deviate add/replace

[Balázs Lengyel]

Hello, 

I tried testing the following statements:

 

  deviation /nacm:nacm/nacm:enable-nacm {

deviate add {

  config false; } }



  deviation /nacm:nacm/nacm:rule-list {

deviate add {

  min-elements 1; }  }

 

In nacm both the config and the min-elements are absent, so their default
meaning is true. I actually tried both add and replace in deviate.

I got rather confusing results whether the add/replace variant of deviate
should be accepted or rejected because the property already exists or does
not yet exist.

 

Pyang 2.0.2 locally:

Config=false   add-NOK  replace-OK

Min-elements=1  add-OK replace-NOK

 

YANG-Validator  pyang 2.0 & confdc

Config=false   add-OK replace-OK

Min-elements=1  add-OK replace-NOK

 

YANG-Validator yanglint

Config=false   add-OK replace-OK

Min-elements=1  add-OK replace-OK

 

IMHO the tools should always check the property, so even if the statement is
not present the properties config=false and min-elements=0 ARE present. So
add should be rejected and replace accepted. 

 

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netmod-ver-dt] Adding a feature is it BC or NBC ? [was: RE: YANG packages draft - now ready for review please]

[Balázs Lengyel]

Hello Rob,

I agree: so introducing the “not” operator into if-feature IMHO was a mistake. 
It can have its uses, but it is very dangerous.

regards Balazs

(Sending it to the full netmod group.)

 

From: Rob Wilton (rwilton)  
Sent: 2019. október 11., péntek 12:50
To: Balázs Lengyel ; Reshad Rahman (rrahman) 
; netmod-ver...@ietf.org
Subject: RE: [Netmod-ver-dt] Adding a feature is it BC or NBC ? [was: RE: YANG 
packages draft - now ready for review please]

 

Hi Balazs,

 

This is an interesting example.

 

It doesn’t just break packages, but breaks YANG conformance more generally, 
particularly if the leaf was also marked as mandatory.  I.e. whether a server 
implements the radius feature will determine whether or not the configuration 
is valid.

 

Basically, I think that this is an unwise use of if-feature.  Generally, I 
think that the principle behind features is that they represent functionality 
that is optional to support, and probably should not be used in this way to 
remove nodes from the underlying model.  I think that this is probably a 
bug/flaw in YANG.

 

Thanks,
Rob

 

 

 

From: Netmod-ver-dt mailto:netmod-ver-dt-boun...@ietf.org> > On Behalf Of Balázs Lengyel
Sent: 10 October 2019 23:57
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com> >; 
Reshad Rahman (rrahman) mailto:rrah...@cisco.com> >; 
netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> 
Subject: [Netmod-ver-dt] Adding a feature is it BC or NBC ? [was: RE: YANG 
packages draft - now ready for review please]

 

Hello,

Adding a new feature MAY or MAY NOT be backward compatible. Think about the 
following YANG:

 

feature radius {}

 

leaf  {

   if-feature “not radius”;

}

 

So if I add radius it actually removes the leaf xxx. NBC.

regards Balazs

 

Regards Balazs

 

From: Netmod-ver-dt mailto:netmod-ver-dt-boun...@ietf.org> > On Behalf Of Rob Wilton (rwilton)
Sent: 2019. október 10., csütörtök 13:17
To: Reshad Rahman (rrahman) mailto:rrah...@cisco.com> >; 
netmod-ver...@ietf.org <mailto:netmod-ver...@ietf.org> 
Subject: Re: [Netmod-ver-dt] YANG packages draft - now ready for review please

 

Hi Reshad,

 

Thanks for the comments.

 

I’ve fixed all of the typos.

 

For the Abstract:

 

Old:

   This document defines YANG packages, a versioned

   organizational structure holding a set of related YANG

   modules, that can be used to simplify the conformance and

   sharing of YANG schema.  It describes how YANG instance data

   documents are used to define YANG packages, and how the YANG

   library information published by a server can be augmented

   with packaging related information.

 

Proposed:

 

   This document defines YANG packages, a versioned organizational

   structure holding a set of related YANG modules, that 
collectively

   define a YANG schema.  It describes how YANG instance data 
documents are

   used to define YANG packages, and how the YANG library 
information

   published by a server can be augmented with packaging related

   information.

 

For 5.2.1.1

Re: “Should this list also include/state “any NBC changes to a module in the 
package”?”

 

Ah, I see.  This is what the following current text of the second paragraph was 
meant to mean

 

Old:

   Changing a package import to select a package version 
that is

   non-backwards-compatible to the prior package version, or 
removing a

   previously imported package.

   Changing a module import to select a module revision that 
is

   non-backwards-compatible to the prior module revision, or 
removing a

   previously implemented module.

   Removing a previously supported feature.

   Adding, changing, or removing a deviation that is 
considered a

  non-backwards-compatible change to the affected data node in 
the

   schema associated with the prior package version.

 

Perhaps the following text would be more clear:

 

   Changing an 'imported-packages' list entry to select a 
package

   version that is non-backwards-compatible to the prior package

   version, or removing a previously imported package.

   Changing a 'modules' or 'import-only-modules' list entry 
to

   select a module revision that is non-backwards-compatible to 
the

   prior module revision, or removing a previously implemented

   module.

   Removing a feature from the 'supported-feature' 
leaf-list.

   Adding, changing, or removing a deviation that is 
considered a

   non-backwards-compatible change to the affected da

[netmod] PYANG refine fault ?

[Balázs Lengyel]

Hello,

I was trying to validate the attached model. However pyang keeps complaining
about refining a default for a leaf-list:

 

ietf-notification-capabilit...@2019-10-10.yang:184: error: "leaf-list" node
"ietf-notification-capabilities::supported-excluded-change-type" cannot be
refined with "default"

 

Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2 “A
leaf-list node may get a set of default values ...” 

..

Confdc accepts this. Could this be a bug in pyang ?

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

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

 



ietf-notification-capabilities@2019-10-10.yang
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Problems with lint validation

[Balázs Lengyel]

Hello,

I validated my model ietf-notification-capabilit...@2019-08-13.yang
  with
yangvalidator.com. My model seems fine, but I got a lot of errors from lint:

 

yanglint Validation

err : The leafref leaf is config but refers to a non-config leaf.
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/str
eam)

err : The leafref leaf is config but refers to a non-config leaf.
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/str
eam)

err : Invalid value "subscription-policy" of "uses".
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-poli
cy)

err : Copying data from grouping failed.
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-poli
cy)

err : Module "ietf-subscribed-notifications" parsing failed.

err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push"
failed.

err : Module "ietf-yang-push" parsing failed.

err : Importing "ietf-yang-push" module into
"ietf-notification-capabilities" failed.

err : Module "ietf-notification-capabilities" parsing failed.

 

At least some of these are not really errors. (pyang, confdc accepts them)

E.g.  the first error is not true because the leafref has require-instance
false.

 

It would be nice if this could be corrected. I got the same messages from
the draft submission tool too.

 

Regards Balazs



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-04.txt

[Balázs Lengyel]

Hello,
Changes v03 - v04
   o  removed entity-tag and last-modified timestamp (metadata definitions)
   o  Added simplified-inline method of content-schema specification

AFAIK this addresses all comment from IETF105 and the mails afterwards.
regards Balazs

-Original Message-
From: netmod  On Behalf Of internet-dra...@ietf.org
Sent: 2019. augusztus 12., hétfő 13:35
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action:
draft-ietf-netmod-yang-instance-file-format-04.txt


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   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-04.txt
Pages   : 25
Date: 2019-08-12

Abstract:
   There is a need to document data defined in YANG models when a live
   server is not available.  Data is often needed already at design or
   implementation time or needed by groups that do not have a live
   running server available.  This document specifies a standard file
   format for YANG instance data (which follows the syntax and semantic
   from existing YANG models, re-using the same format as the reply to a
operation/request) and decorates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format
/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-04
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-f
ormat-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-forma
t-04


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

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

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Balázs Lengyel]

I have reviewed the subject document and support publication. 
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2019. július 10., szerda 2:15
To: netmod@ietf.org
Subject: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

All,

This starts a twelve-day working group last call for
draft-ietf-netmod-intf-ext-yang-07

The working group last call ends on July 21 (the day before the NETMOD 105
sessions).  Please send your comments to the working group mailing list.

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

Thank you,
NETMOD Chairs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Balázs Lengyel]

+1, Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 14:32
To: Kent Watsen 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG next

 

 

 

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen mailto:k...@watsen.net> > wrote:

 

So you want to work on YANG 1.2, but just the parts you want to change? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.


+1. There are plenty of ambiguities and NETCONF/XML pollution in the
spec. Having the specifications in a DAG would be immensely useful :)

 

Agreed and I should've mentioned before that Martin said in Prague that he'd 
already started this effort, seeing it as a necessary pre-step before making 
other changes.  I'm unsure if the intention is to release this by itself as an 
RFC 7950 bis but, if looking for a minimal change, that might be it.  The next 
rung up would be to just add clarifications.  The next rung up from there would 
be to add only backwards-compatible changes (currently targeted by [1]).  The 
last rung being to also target NBC changes (there's no consensus to do this).

 

 

This WG sure likes to spend time refactoring documents.

Moving lots of text will create bugs and strong coupling, and only help the 
standards purists.

It will be a lot of work for the WG and IESG to review such a massive document 
split,

and in the end we have no improvement in YANG, just more RFCs to read.

 

Andy

 

[1] https://github.com/netmod-wg/yang-next/projects/2 
 

 

Kent 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Balázs Lengyel]

We already have some RFCs and drafts that propose extensions that would/could 
go into YANG 1.2.  I would like to have an “official” agreement/document/wiki 
that lists what is planned to go into 1.2 whenever it happens. That would help 
us to have a platform that contains a well defined set of additions beyond YANG 
1.1.

Regards Balazs

 

From: netmod  On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 10:10
To: Juergen Schoenwaelder ; Andy Bierman 
; NETMOD WG 
Subject: Re: [netmod] YANG next

 

 

 

On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka mailto:lho...@nic.cz> > wrote:

Juergen Schoenwaelder mailto:j.schoenwael...@jacobs-university.de> > writes:

> On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
>> 
>> This problem is actually not limited to YANG itself - people are reporting
>> problems with the transition to NMDA. 
>>
>
> The YANG update from 1 to 1.1 mostly affected compiler writers - and
> to a much lesser extend module authors and module implementors. NMDA,
> affects client and server implementors much more directly, additional
> instrumentation on the server side needs to be written, application
> logic on the client side needs to be adjusted. NMDA is an evolution of
> architectural principles and this already indicates that there is a
> certain investment to make.

But both updates induced some changes in YANG modules that affect users and 
integrators. Take ietf-ospf module as an example: it is of course a great 
addition to the YANG module collection, but in order to use it, all tools have 
to support

- YANG 1.1, e.g. because of the special XPath functions, and

- NMDA, because otherwise state data are missing.

Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may 
get frustrated if lazy authors (including myself) don't update their tools in a 
timely manner.

>
> If we discuss YANG next, we should compare it to the YANG 1 to 1.1
> transition and not to the NMDA transition. When we started YANG 1.1

Both types of changes may have similar effects on YANG users. 

> work, there were people who said that nobody would implement it. But
> then implementations were adopted relatively fast when we finalized
> YANG 1.1.

When we started YANG 1.1, there were only a few YANG modules around with little 
practical use, so nobody really cared. The situation is now very different.

 

Not that different.

The IETF does not value stability that much.

Maybe customer expectations are different, but some of us have to follow 2 
simple rules:

 

   - Whatever works SHALL continue to work 

   - If you changed how it works, you broke it (even if you fixed it)

 

Some customers even think they should be able to upgrade from any existing 
version to any new version,

and these rules still hold. Therefore every change in server behavior must be 
"opt-in" by the vendor and

maybe the client as well. Instead of automatically upgrading because of course 
you want the spiffy

new features, vendors want the behavior to stay exactly the same (unless they 
choose to change it).

 

There is no real need for YANG 1.2 unless and until NBC changes need to be made,

and we try to avoid doing that.

 

 

Lada

 

 

Andy

 

>
> While a collection of patches (updates) of YANG 1.1 may sound simpler,
> I am not sure this is really true. We will loose a common baseline and
> instead get complexity since we will get systems that all support
> different sets of patches (updates) of YANG 1.1. I believe we are all
> much better off if we have a common baseline language and tools that
> support the common baseline language. Again, if done right, YANG next
> will mostly affect compiler writers and tool makers and not so much
> module authors and implementors.
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Balázs Lengyel]

The instance-data-set’s timestamp is about the time the config dump is taken.

If the last modification happened 7 days before the dump, then the 
last-modified metadata and the instance-data-set’s timestamp will have a week 
difference.

Also the last-modified metadata can be different for different parts of the 
configuration.

Regards Balazs

 

From: Joe Clarke (jclarke)  
Sent: 2019. július 23., kedd 18:06
To: Rob Wilton (rwilton) 
Cc: Balázs Lengyel ; Andy Bierman 
; Juergen Schoenwaelder 
; netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and 
last-modified annotation ?

 

 





On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) mailto:rwil...@cisco.com> > wrote:

 

If you want to dump the configuration on the device to a file for some offline 
analysis, then it might be useful if it is possible for that file to have the 
timestamps of when the configuration changed annotated into the file.

 

Isn’t that the purpose of the “timestamp" metadata leaf in instance-data?  That 
is the timestamp of the ID set itself.

 

Joe





 

I don’t think that this is critical, but I can see that it might be useful.

 

Thanks,

Rob

 

 

From: netmod < <mailto:netmod-boun...@ietf.org> netmod-boun...@ietf.org> On 
Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman < <mailto:a...@yumaworks.com> a...@yumaworks.com>; Juergen 
Schoenwaelder < <mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@jacobs-university.de>;  <mailto:netmod@ietf.org> netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and 
last-modified annotation ?

 

Hello,

As Jurgen, Andy, Lada and Joe is opposed to defining the annotations in the 
instance model draft, and I don’t see it as crucial, I will take it out.

IMHO it is a useful bit of functionality for configuration data based 
use-cases, and I very much fear it will not happen at all now; unless people 
speak up it is removed.

Regards  Balazs

 

From: Andy Bierman < <mailto:a...@yumaworks.com> a...@yumaworks.com> 
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder < <mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@jacobs-university.de>; Balázs Lengyel < 
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com>;  
<mailto:netmod@ietf.org> netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and 
last-modified annotation ?

 

 

 

On Tue, Jul 23, 2019 at 7:24 AM Juergen Schoenwaelder < 
<mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@jacobs-university.de> wrote:

Balázs,

I am not sure these belongs to the data types collection. If these
annotations are a per datastore properties or per configuration
datastore properties (I am not sure these properties make a lot of
sense for dynamically changing data in , or these
properties only make sense for config true nodes, more discussion
needed I guess), then the logical place would be to define them would
be where the datastores are defined.

I understand the timing concern but my preference is to workout what
these annotations really are in an NMDA world and in a second step to
figure out a way to define them in a reasonable amount of time.

 

This work needs a lot more thought because this WG is sort of abusing these 
fields,

intended for HTTP caching. The values are associated with a representation of a 
response

to a request for some portion of the datastore contents.  E.g., a 
representation in XML must be a different

ETag than a JSON representation (of the exact same datastore contents).

 

I suggest new meta-data be defined that has semantics specific to datastore 
contents, not

the HTTP representation of the response.

 

IMO this meta-data is not really needed inside an instance file, but if 
included, then the values

should be associated with the representation (the instance file) and not the 
datastores.

 

 

/js

 

 

Andy

 


On Tue, Jul 23, 2019 at 02:11:23PM +, Balázs Lengyel wrote:
> Hello Jürgen,
> Could the etag and last-modified annotations be moved to 6991bis?
> Regards Balazs
> 
> -Original Message-
> From: Juergen Schoenwaelder < <mailto:j.schoenwael...@jacobs-university.de> 
> j.schoenwael...@jacobs-university.de> 
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel < <mailto:balazs.leng...@ericsson.com> 
> balazs.leng...@ericsson.com>
> Cc:  <mailto:netmod@ietf.org> netmod@ietf.org
> Subject: Re: [netmod] Instance-data-format - shall we define etag and
> last-modified annotation ?
> 
> On Mon, Jul 22, 2019 at 07:23:59PM +, Balázs Lengyel wrote:
> > Hello,
> > 
> > Restconf (rfc8040) defined to useful bits of metadata about a YANG 
> > defined
> > datastore: entity-tag and the last-modified timestamp.
> >

Re: [netmod] YANG next

[Balázs Lengyel]

+1   Balazs

-Original Message-
From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka ; NETMOD WG 
Subject: Re: [netmod] YANG next

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it
will take a couple of years to work out, maybe longer if the work doesn't
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot
of things on that list (some of which are quite small) that would be good to
do, and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Balázs Lengyel]

Hello,

As Jurgen, Andy, Lada and Joe is opposed to defining the annotations in the 
instance model draft, and I don’t see it as crucial, I will take it out. 

IMHO it is a useful bit of functionality for configuration data based 
use-cases, and I very much fear it will not happen at all now; unless people 
speak up it is removed.

Regards  Balazs

 

From: Andy Bierman  
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder ; Balázs 
Lengyel ; netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and 
last-modified annotation ?

 

 

 

On Tue, Jul 23, 2019 at 7:24 AM Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de> > wrote:

Balázs,

I am not sure these belongs to the data types collection. If these
annotations are a per datastore properties or per configuration
datastore properties (I am not sure these properties make a lot of
sense for dynamically changing data in , or these
properties only make sense for config true nodes, more discussion
needed I guess), then the logical place would be to define them would
be where the datastores are defined.

I understand the timing concern but my preference is to workout what
these annotations really are in an NMDA world and in a second step to
figure out a way to define them in a reasonable amount of time.

 

This work needs a lot more thought because this WG is sort of abusing these 
fields,

intended for HTTP caching. The values are associated with a representation of a 
response

to a request for some portion of the datastore contents.  E.g., a 
representation in XML must be a different

ETag than a JSON representation (of the exact same datastore contents).

 

I suggest new meta-data be defined that has semantics specific to datastore 
contents, not

the HTTP representation of the response.

 

IMO this meta-data is not really needed inside an instance file, but if 
included, then the values

should be associated with the representation (the instance file) and not the 
datastores.

 

 

/js

 

 

Andy

 


On Tue, Jul 23, 2019 at 02:11:23PM +, Balázs Lengyel wrote:
> Hello Jürgen,
> Could the etag and last-modified annotations be moved to 6991bis?
> Regards Balazs
> 
> -Original Message-
> From: Juergen Schoenwaelder  
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel  <mailto:balazs.leng...@ericsson.com> >
> Cc: netmod@ietf.org <mailto:netmod@ietf.org> 
> Subject: Re: [netmod] Instance-data-format - shall we define etag and
> last-modified annotation ?
> 
> On Mon, Jul 22, 2019 at 07:23:59PM +, Balázs Lengyel wrote:
> > Hello,
> > 
> > Restconf (rfc8040) defined to useful bits of metadata about a YANG 
> > defined
> > datastore: entity-tag and the last-modified timestamp.
> > 
> > These can be very useful in instance data sets, however Restconf 
> > defines an encoding for these (as part of the http headers) that can 
> > not be used in instance-data-sets.
> 
> This may actually point out a flaw or omission of RFC 8527. RFC 8040 defines
> an entity-tag for its "unified" datastore and it says "if the RESTCONF
> server is co-located with a NETCONF server, then this entity-tag MUST be for
> the "running" datastore". So it is a bit unclear what happens with other
> NMDA datastores and I did not quickly find something in RFC 8527. (For
> example, can have a distinct etag for ?
>  
> > draft-ietf-netmod-yang-instance-file-format-03#section-7.2
> >
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03# 
> <https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03> 
> > section-7.2> defines metadata annotations for these two, that can be
> > used in instance data
> > 
> >   md:annotation entity-tag {
> >   type string;
> >   description "Used to encode the entity-tag .";
> > }
> > md:annotation last-modified {
> >   type yang:date-and-time;
> >   description "Contains the date and time when the annotated
> > instance was last modified (or created).";
> > }
> > 
> > In order to be able to include this data, the annotations need to be 
> > defined in some YANG module.
> > 
> > The question has been raised whether
> > 
> > 1.  these annotations should be defined in the ietf-yang-instance-data
> > module as it needs them, as that is open or
> > 2.  the annotations should be defined in another draft in a separate
> > YANG module as any other annotation
> > 
> > The first option is better because the instance-data needs these 
> > annotations, and at this point we see no other user for the 
> > annotation, and in this case the ongoing 

Re: [netmod] YANG next

[Balázs Lengyel]

Hello,
I share your concerns. However I see some ways of mitigating the problem:
1) Maybe the extension based solution is better than many people would
believe. If we put new features (like status-information,
import-revision-or-derived, preliminary-status etc.) into extensions e.g.
Yang1-2:status-information older systems can just ignore them while never
systems would still be able to use them. This might not work for all new
functionality, but would definitely work for some.
2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
current users.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 2019. július 23., kedd 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 6991bis add protocol identities ?

[Balázs Lengyel]

Hello Jurgen,

I have seen multiple places where protocol identities are needed.
(Subscribed notifications, draft-mahesh-netconf-https-notif
 , 3GPP
YAMs). Wouldn’t it be a good idea to define these centrally e.g. in 6991bis?

I know collecting a complete set of protocols would be a problem, but
defining at least the most important ones centrally, is better than every
module defining its own identities, enums, strings.

If we provide these protocol identities, it would also be good to find a way
to specify, that a YANG module supports only a subset of them not the full
set going back to X.25 and pigeon based IP.

Regards Balazs

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Balázs Lengyel]

Hello Jürgen,
Could the etag and last-modified annotations be moved to 6991bis?
Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2019. július 22., hétfő 16:15
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and
last-modified annotation ?

On Mon, Jul 22, 2019 at 07:23:59PM +, Balázs Lengyel wrote:
> Hello,
> 
> Restconf (rfc8040) defined to useful bits of metadata about a YANG 
> defined
> datastore: entity-tag and the last-modified timestamp.
> 
> These can be very useful in instance data sets, however Restconf 
> defines an encoding for these (as part of the http headers) that can 
> not be used in instance-data-sets.

This may actually point out a flaw or omission of RFC 8527. RFC 8040 defines
an entity-tag for its "unified" datastore and it says "if the RESTCONF
server is co-located with a NETCONF server, then this entity-tag MUST be for
the "running" datastore". So it is a bit unclear what happens with other
NMDA datastores and I did not quickly find something in RFC 8527. (For
example, can have a distinct etag for ?
 
> draft-ietf-netmod-yang-instance-file-format-03#section-7.2
>
<https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03#
> section-7.2> defines metadata annotations for these two, that can be
> used in instance data
> 
>   md:annotation entity-tag {
>   type string;
>   description "Used to encode the entity-tag .";
> }
> md:annotation last-modified {
>   type yang:date-and-time;
>   description "Contains the date and time when the annotated
> instance was last modified (or created).";
> }
> 
> In order to be able to include this data, the annotations need to be 
> defined in some YANG module.
> 
> The question has been raised whether
> 
> 1.these annotations should be defined in the ietf-yang-instance-data
> module as it needs them, as that is open or
> 2.the annotations should be defined in another draft in a separate
> YANG module as any other annotation
> 
> The first option is better because the instance-data needs these 
> annotations, and at this point we see no other user for the 
> annotation, and in this case the ongoing instance data draft will 
> define it
> 
> The second option is better because, if later there are other users 
> for these annotations, it might be strange to reference the 
> ietf-yang-instance-data module. Also why provide special treatment to 
> these
> 2 annotations?
> 
> The authors support option 1 and don't have the time to start a new 
> draft to define these annotations.
> 
> On IETF105 in the room there was more support for option 1. 
> 
> Please indicate if you have an opinion about the choice of 1 or 2

Version -03 only defines these annotations but does not do anything specific
with these definitions. So if the annotations are defined elsewhere, the ID
is as complete as before. If entity-tag and last-modified are actually seen
as datastore properties, it would be nice to have them defined in the NMDA
documents (and it seems we overlooked this when we did the NMDA work).

I think this needs a bit of discussion whether these are actually seen as
datastore properties. But in this case, I would lean towards option 2.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Instance-data-format -additional simplified format to define content schema

[Balázs Lengyel]

Hello,

At the IETF 105 Netmod meeting it was stated that the flexible solution to
define the context schema inline (requested earlier on the mailing list) is
quite complex, so a fourth simpler method to define content schema inline is
needed.

The fourth method would add one more choice to “choice content-schema-spec
“

 

case simplified-inline {

  leaf-list module  {

type string {

   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

 }

 description “The list of content defining YANG 

   modules including the revision date for each. 

   Usage of this leaf-list implies the modules are 

   used without any deviations and with all features 

   supported.”;

  }

}

 

An example instant data example could be:



  read-only-acm-rules

  ietf-yang-libr...@2019-01-04.yang

  ietf-netconf-...@2012-02-22.yang
  
1776-07-04
Initial version
  
  Access control rules for a read-only role.
  ...

 

Do you like it ? Adding this case are you OK with the content-schema-spec
definition?

Regards Balazs



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Balázs Lengyel]

Hello,

Restconf (rfc8040) defined to useful bits of metadata about a YANG defined
datastore: entity-tag and the last-modified timestamp.

These can be very useful in instance data sets, however Restconf defines an
encoding for these (as part of the http headers) that can not be used in
instance-data-sets.

draft-ietf-netmod-yang-instance-file-format-03#section-7.2
 defines metadata annotations for these two, that can be
used in instance data

  md:annotation entity-tag {
  type string;
  description "Used to encode the entity-tag …";
}
md:annotation last-modified {
  type yang:date-and-time;
  description "Contains the date and time when the annotated
instance was last modified (or created).";
}

In order to be able to include this data, the annotations need to be defined
in some YANG module.

 

The question has been raised whether 

1.  these annotations should be defined in the ietf-yang-instance-data
module as it needs them, as that is open or
2.  the annotations should be defined in another draft in a separate
YANG module as any other annotation

The first option is better because the instance-data needs these
annotations, and at this point we see no other user for the annotation, and
in this case the ongoing instance data draft will define it

The second option is better because, if later there are other users for
these annotations, it might be strange to reference the
ietf-yang-instance-data module. Also why provide special treatment to these
2 annotations?

 

The authors support option 1 and don’t have the time to start a new draft to
define these annotations.

On IETF105 in the room there was more support for option 1. 

 

Please indicate if you have an opinion about the choice of 1 or 2

 

Regards Balazs

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] What's up with YANG-Next?

[Balázs Lengyel]

Hello Chairs,

I would like to hear what’s up with YANG-Next (1.2). Could you please
address it in the meeting!

Even if we just have a statement that it is pending, it would be good to
know.

Regards Balazs



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: New Version Notification for draft-ietf-netmod-yang-instance-file-format-03.txt

[Balázs Lengyel]

Hello,
A draft version , draft-ietf-netmod-yang-instance-file-format-03.txt has been 
posted.
   o  target renamed to "content-schema" and "content defining Yang  module(s)"
   o  Made name of instance data set optional
   o  Updated according to draft-ietf-netmod-yang-data-ext-03
   o  Clarified that entity-tag and last-modified timestamp are encoded
  as metadata.  While they contain useful data, the HTTP-header
  based encoding from Restconf is not suitable.
Regards Balazs

-Original Message-
From: internet-dra...@ietf.org  
Sent: 2019. július 5., péntek 13:06
To: Benoit Claise ; Balázs Lengyel 

Subject: New Version Notification for 
draft-ietf-netmod-yang-instance-file-format-03.txt


A new version of I-D, draft-ietf-netmod-yang-instance-file-format-03.txt
has been successfully submitted by Balazs Lengyel and posted to the IETF 
repository.

Name:   draft-ietf-netmod-yang-instance-file-format
Revision:   03
Title:  YANG Instance Data File Format
Document date:  2019-07-05
Group:  netmod
Pages:  25
URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-03

Abstract:
   There is a need to document data defined in YANG models when a live
   server is not available.  Data is often needed already at design or
   implementation time or needed by groups that do not have a live
   running server available.  This document specifies a standard file
   format for YANG instance data (which follows the syntax and semantic
   from existing YANG models, re-using the same format as the reply to a
operation/request) and decorates it with metadata.


  


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

The IETF Secretariat



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

[Balázs Lengyel]

  
  
I support the draft. Balazs

On 2019. 03. 25. 21:30, Kent Watsen
  wrote:


  
  This email begins a 2-week adoption poll for:

  

      https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
  

  Please voice your support or objections before
  April 8.
  

  Kent (and Lou and Joel)



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


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR poll on draft-wu-netmod-factory-default-02

[Balázs Lengyel]

  
  
No, I’m not aware of any IPR
that applies to this draft.
  
Balazs
  
On 2019. 03. 25. 21:17, Kent Watsen
  wrote:


  
  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 draft-wu-netmod-factory-default-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

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] instance data new backward compatibility text

[Balázs Lengyel]

  
  
Hello Jurgen,
I don't think these rules are Ericsson specific. In some of our
  most important use-cases (UC1, UC2, UC6) changing the keys would
  lead to problems.
UC1: If you document server capabilities using ietf-yang-library
  the name of the module sets may be/should be meaningful. It might
  be used by the NMS to compare the capabilities of different
  versions of the YANG server; changing keys without a reason will
  mislead the NMS into assuming the server capabilities changed.. 
UC2: Preloading default configuration data. E.g.  If you change
  the identifier of NACM ruleset, then during upgrade it might be
  loaded again as the server can not detect, that this is the same
  ruleset that is already in the datastore.

UC6:  Storing diagnostics data. If you change the keys used in
  diagnostic data, comparing values before and after the key change
  will be difficult.
And yes as we were using instance data for the last then years,
  we did have a lot of problem with people changing the keys without
  considering compatibility effects.
  I agree that this is not always a problem, so I only used SHOULD 
  (and not MUST) in the text.

regards Balazs


On 2019. 03. 25. 23:16, Juergen
  Schoenwaelder wrote:


  On Mon, Mar 25, 2019 at 09:59:43PM +, Balázs Lengyel wrote:

  
Hello Jurgen,

You are right that this is important mostly for instance data prepared as a
design/implementation activity; while not relevant for data coming from the
node.
I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we have
had MANY problems with people changing the key values/identities of list
entries.
They think it is a nice idea to provide better, more meaningful key values;
however the NMS designers use these key values to detect changes; also
during an upgrade process if a default configuration file is loaded again
with slightly changed key values, then e.g. access control rules become
duplicated.


  
  
The conditions under which it is meaningful to change keys and when it
is not appropriate are very application specific.  You may have
specific use cases at Ericsson where you want internal regulations but
I do not think this leads to meaningful rules outside your specific
application scenario.

/js



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on instance data draft rev -02

[Balázs Lengyel]

I wanted to have an identifier for a particular instance-data-set.
name+revision-date OR timestamp should serve that purpose.

While it would be possible to use this without a name, IMHO that would 
be a very bad practice.


Balazs

On 2019. 03. 25. 14:52, Martin Bjorklund wrote:

And a question:  why is the "name" leaf mandatory?


/martin


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on instance data draft rev -02 - Change target-module to what name?

[Balázs Lengyel]

  
  
While I agree that target might not be the best name, I want a
  name that describes that 
  "these are the modules I am providing instance data for".
I propose to use the terms:
  "content-schema" and "content defining Yang
  module(s)" (Sometimes I need to refer them
  individually.)


Just schema is a too generic word. It does not tell you which
  schema are we speaking about? The schema for 
  ietf-yang-instance-data,or  the schema just for the content part?
  Are we speaking about individual modules or the collection of all
  target modules?

regards Balazs

On 2019. 03. 25. 14:29, Joe Clarke
  wrote:


  First, I agree with Jürgen that the "target" terminology confused me,
especially so given you have target-module and inline-target-spec.  Like
Jürgen and Rob said, "schema" seems to work better.  And maybe
"inline-schema-module-spec" would be clearer that the spec modifies the
modules from which the schema is generated.

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on instance data draft rev -02

[Balázs Lengyel]

  
  
On 2019. 03. 25. 14:29, Joe Clarke
  wrote:


  To the point about yang-data-ext/structure, I see instance data was very
useful, but it's a must to be able to augment its metadata.  YANG
Catalog would use that.  If this draft moves forward without
sx:structure, then I think it would need to be straight YANG so that
augments will work (i.e., a schema element would exist to augment).

BALAZS: Fully agree. As it is more correct to
  use data-ext/structure I will keep it that way. If there is  a
  problem I will make it "straight" yang. I don't see "structure" as
  vital, but somewhat more correct.

  A few other comments (minor):

Section 2.1:

"P2 Re-use existing formats similar to the  operation/request"

Isn't the format similar to a  _response_ versus the request?

BALAZS: Will be corrected.


  ===

Section 3

s/and and/and/

BALAZS: corrected

  

Joe

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


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] instance data new backward compatibility text

[Balázs Lengyel]

Hello Jurgen,

You are right that this is important mostly for instance data prepared 
as a design/implementation activity; while not relevant for data coming 
from the node.

I will add it.

However in the first case it is vital!

For config files, and also for file documenting server capabilities we 
have had MANY problems with people changing the key values/identities of 
list entries.
They think it is a nice idea to provide better, more meaningful key 
values; however the NMS designers use these key values to detect 
changes; also during an upgrade process if a default configuration file 
is loaded again with slightly changed key values, then e.g. access 
control rules become duplicated.


regards Balazs

On 2019. 03. 25. 14:19, Juergen Schoenwaelder wrote:

Hi,

I am not sure why we have this new section. The notion of backwards
compatibility for instance data is somewhat dubious. There text that
is there now is potentially even harmful or it needs to be ignored. If
I dump datastore content into an instance file, I get what I get. The
text that is there may help with maunally edited instance files but
this is where it ends. My proposal is to simply drop section 6 again.

/js


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02

[Balázs Lengyel]

  
  
Thanks for the comments, see below. Balazs

On 2019. 03. 25. 8:03, Kent Watsen
  wrote:


  
  
  The Abstract says “re-using the same format as the reply to a
 operation/request”.  At first, I was going to
suggest replacing  with , but I
question if this is correct since the draft supports JSON, which
neither NETCONF RPC is able to return. 
  
BALAZS: Restconf does have a get method. I
  thought I could refer to it as a get request.

  
  
  The Terminology section is missing an entry for “instance
  data set”. 


BALAZS:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-1 
  second definition is instance data set

  
  
  I don’t understand what P3 means.  Add info text to draft.

BALAZS:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-3
  paragraph starting with "Metadata, information about the data set
  itself SHALL be included ..." explains it. Shall I add a
  cross-reference?

  
  
  Re: P4, if file == 1 “set”, then the distinction becomes
unclear (see earlier comment about missing “set” term).  I
understand that it’s intended to mean instance data for a set of
modules but, if there’s a 1:1 relationship between file and set,
then just pick one term for the draft.

BALAZS: The relationship is 1-to-1. You don't
  know how often I got the question: can I put multiple YANG modules
  into a file?
  Others commented, that instance data sets may be used without a
  file e.g. transfered on the wire e.g. as part of some IPC
  mechanism, so separating the set from the file seems like a good
  idea.

  
  
  I
  don’t understand what P7 means.  Add more text to draft.

BALAZS:  Explained in
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02#section-3

Instance data files MAY contain partial data sets.  This means
   mandatory, min-elements or require-instance=true constrains MAY be
   violated.
So if you have a module with 2 mandatory subtrees, you are free to specify data only for one of them.


  

  Section
  3 says this about Content data: “It MAY include entity-tags
  and timestamps as defined in [RFC8040]”.
   How is this possible?  RFC 8040 only returns such data in
  HTTP headers; there’s no defined encoding for putting the data
  into instance data.

BALAZS: See separate mail. 

  
  
  
Section 3 also says “It MAY include an explicit tag for default values as defined in
  [RFC6243] and [RFC8040]”.   Do you mean, the “default” attribute defined in Section 6 in RFC 6243 and Section 4.8.9 in RFC 8040?  The text should be more explicit.
  

BALAZS: yes,
  and I will update the text.

  


Section 3 also contains paragraphs beginning with: “It MAY include implementation specific metadata.”  and “It MAY include implementation specific XML attributes.”  I think these two paragraphs should be merged and a sentence added noting how metadata is encoded for JSON and XML.
  

BALAZS: OK

  


s/A single instance data set/An instance data set/  (since already there is only one)
  

BALAZS: OK

  


Section 3 says: “Instance data files MAY contain partial data sets.  This means mandatory, min-elements or require-instance=true constrains MAY be
   violated.”  Why?  This means validations may fail.
  

BALAZS: 
  E.g. If you want to document the module set a server supports, you
  may omit the namespace. THe name/revision clearly identifies each
  YAM. While the namespace is mandatory in the module it is not
  needed to document the module set.

E.g. if you want interface statistics as
diagnostics data, it may be enough to document the counters, but
not the if-index.
E.g. Configuration to be preloaded may be
provided partially by a file, and partially by the system
itself, or in more additional files.
  

  


Generally, I feel that the part of Section 3 describing the content should be replaced with a statement that any valid response for  or GET on a top-level resource is okay.  If this is not the case, then the draft should still start with this statement and them list out any exceptions.
  

BALAZS: In the previous version I used that
  kind of definition. However Jurgen and Rob W. objected strongly
against defining the returned data using the
  get-data/get. 
  We might also have partial-data set, we might have a mix of config
  and state data, which might not be valid get-data replies.

 

Re: [netmod] kw review of draft-ietf-netmod-yang-instance-file-format-02 - etag/timestamp

[Balázs Lengyel]

  
  
Hello Kent, 

Sadly you are right. So I should probably remove it.
On the other hand IMHO it is could be useful info. What would you
  think, if I found an alternative encoding for it. (It would be
  optional.)
  It could be encoded as metadata on the content-data
  container/anydata. It could give a quick indication whether the
  data has changed. If config data is read/provided periodically, it
  could be useful.
So is it useful enough to bother? Is the encoding as metadata OK?
Or should I just remove it?

regards Balazs

On 2019. 03. 25. 8:03, Kent Watsen
  wrote:

Section 3 says
this about Content data: “It MAY include entity-tags and
timestamps as defined in [RFC8040]”.
 How is this possible?  RFC 8040 only returns such data in HTTP
headers; there’s no defined encoding for putting the data into
instance data.
-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Balázs Lengyel]

  
  


On 2019. 03. 24. 21:05, Andy Bierman
  wrote:


  
  




  On Sun, Mar 24, 2019 at
11:39 AM Joel Jaeggli  wrote:
  
  

  

  On Mar 22, 2019, at 12:07, Lou Berger 
wrote:
  
  

  Hi,
  Thank you all for the good input on this
thread.
  
  With the understanding that a 00 working group
document is a starting point for the working
group rather than a document that is ready for
last call - we believe there is sufficient
support to adopt this document as a starting
point for the requirements we wish to address on
this topic.

It is clear that there is still work to be done
on this document before we can declare consensus
on it and, not surprisingly, that there is more
work to be done on the solution.

Authors, 
  
  Please resubmit this document as
draft-ietf-netmod-yang-revision-reqs-00 with the
only change being the name and publication
date.  The -01 version should focus on resolving
issues raised during adoption.  Of course the
document is subject to normal WG input and
processing.

Please note the 'file' name change -this is to
indicate that the requirements are not
presupposing a specific solution. It is also
consistent with how versioning is defined within
the document currently.
  Note: we would like to try to continue the list
discussion in next week's session and ask the
Authors/DT to summarize issues raised during the
adoption call and lead a discussion to help
resolve these issues.
  

  

I think this meeting is great opportunity to decide
  what steps need to be taken to advance the document
  within the working group.


Martin specifically objects to the presence of of
  Non-Backward-Compatible changes. 


Many modules outside the IETF are already
  incompatible with roc 7950 yang 1.1 revision rules. So
  that cat may be out of the bag at least with respect
  to the real world. the question remains what to do
  about that?


  

  
  
  
  
  
  I do not look at the problem as allowing NBC so much as
making it clear to toolmakers what is going on,
  like a deviation to the versioning rules.
  
  
  BTW, I do not support adoption of the requirements
document at all.
  I support the work on versioning as part of the charter,
and I am happy to
  accept the design team solution draft as the starting
point, and just work on a solution.
  
  
  But I think the solution is a bit flawed.
  
  
  1) extensions are optional and problematic since they can
be revisioned without changing
      the language version; the solution needs to use new
YANG 1.2 statements instead of extensions
  
  
  2) the version string does not have to contain all the
NBC semantics.
  The solution draft does not show modified semver.
  It should be done differently than overloading the
version string;
  
  
  Let's say a fork is done on 1..3.0.
  
 revision 2017-07-30 {
   description "Added leaf foo-64";
   semver:module-version "1.3.0";
 }

start with a legal change, just not at the HEAD
 revision 2019-01-10 {
   description "Added leaf bar-64";
   semver:module-version "1.3.1";
 }


then later, an NBC change

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

[Balázs Lengyel]

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

Balazs

On 2019. 03. 13. 21:29, Kent Watsen wrote:

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


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Balázs Lengyel]

  
  
I support the draft. (Contributor)
regards Balazs

On 2019. 03. 13. 21:22, Kent Watsen
  wrote:


  
  Seeing as how we all need to read this draft anyways, in
  preparation for our meeting in Prague, it seems like a good time
  for this poll.  Thusly, this email begins a 1-week adoption poll
  for:
  


    https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02


Please voice your support or objections before
  March 20.


Note that this draft defines *requirements* and
  its intended status is "Informational."   I believe that it is
  good for WGs to formalize requirements, even taking such
  drafts thru Last Call, in order to ensure consensus on the
  requirements.  This is the "adoption" call, to ascertain if
  the WG agrees with that statement; if adopted, a separate
  "last call" will be issued to ensure to correctness of the
  draft's content.


Kent (and Lou and Joel)
  
  
  
  
  
  
  
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IETF 104 Presentation Requests

[Balázs Lengyel]

  
  
Hello,
I would like to present our draft:
  - name of the drafts (if any)   draft-ietf-netmod-yang-instance-file-format
    - name of presentation (usually same as the name of the draft)  
  draft-ietf-netmod-yang-instance-file-format
    - name of the presenters  Balazs Lengyel
    - desired time request in minutes.   10-15

regards Balazs

On 2019. 02. 28. 4:50, Kent Watsen
  wrote:


  
  Dear WG,

The preliminary IETF 104 Agenda has been posted [1].  NETMOD is currently scheduled to meet twice, 2 hours Tuesday morning and again for two hours on Friday morning.
  If you are interested in presenting to the WG, please send your presentation requests to the "netmod-chairs" alias (CC-ed) with the following information, for each presentation request, if more than one:

  - name of the drafts (if any)
  - name of presentation (usually same as the name of the draft)
  - name of the presenters
  - desired time request in minutes.

[1] https://datatracker.ietf.org/meeting/104/agenda.html

  PS: *please* respond to *this* thread, even if you sent a request to the chairs already.
  Thanks!
Kent (and Lou and Joel)
  
  
  
  
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Obsolete feature - what does it mean?

[Balázs Lengyel]

  
  
feature oldFeature {
  status obsolete;
}

leaf myTimer {
  if-feature oldFeature ;
  mandatory true;
  config true;
  status current;
  type string;
}

So should I configure myTimer or not? I assume yes, correct?

regards Balazs



On 2019. 02. 27. 11:33, Juergen
  Schoenwaelder wrote:


  On Wed, Feb 27, 2019 at 10:19:55AM +, Balázs Lengyel wrote:

  
   Hello,

   The feature statement may have a status substatement. But what does it
   mean if a feature is deprecated or obsolete? Some ideas:

 * All if-feature statements using it should be removed. But what to do
   with "if-feature oldFeature AND otherFeature" ;
 * The feature is always considered true/false
 * this is a bug in rfc7950, there should not be such a substatement
 * something else


  
  
Deprecated means the feature is deprecated, you should not use it in
new definitions. A feature is not "true or false", a feature can be
implemented or not. A current definition being conditional on a
deprecated feature may be something tools should warn about.

Obsolete means the feature is obsolete, it likely should only be used
in obsolete definitions. A current definition likely should not depend
on an obsolete feature and if that happens, then likely brainware
needs to look at the situation and resolve it.

/js



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Obsolete feature - what does it mean?

[Balázs Lengyel]

  
  
Hello,
The feature statement may have a status substatement. But what
  does it mean if a feature is deprecated or obsolete? Some ideas:


  All if-feature statements using it should be removed. But what
to do with "if-feature oldFeature AND otherFeature" ; 
  
  The feature is always considered true/false
  this is a bug in rfc7950, there should not be such a
substatement
  something else
  

regards Balazs

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-02.txt

[Balázs Lengyel]

  
  
Hello,
A new version of the  draft YANG Instance Data File Format is
  available.
   v01 - v02
     o  Removed design time from terminology
     o  Defined the format of the content-data part by referencing
  various
    RFCs and drafts instead of the result of the get-data and
  get
    operations.
     o  Changed target-ptr to a choice
     o  Inline target-ptr may include augmenting modules and
  alternatives
    to ietf-yang-library
     o  Moved list of target modules into a separate
  
    element.
     o  Added backwards compatibility considerations
  regards Balazs

 Forwarded Message
  
  

  
Subject:

New Version Notification for
  draft-ietf-netmod-yang-instance-file-format-02.txt
  
  
Date: 
Tue, 26 Feb 2019 05:43:34 -0800
  
  
From: 
internet-dra...@ietf.org
  
  
To: 
Benoit Claise , Balazs Lengyel
  
  

  
  
  
  
  A new version of I-D,
  draft-ietf-netmod-yang-instance-file-format-02.txt
  has been successfully submitted by Balazs Lengyel and posted to
  the
  IETF repository.
  
  Name: draft-ietf-netmod-yang-instance-file-format
  Revision: 02
  Title: YANG Instance Data File Format
  Document date: 2019-02-26
  Group: netmod
  Pages: 24
  URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-02.txt
  Status:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
  Htmlized:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-02
  Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
  Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-02
  
  Abstract:
  There is a need to document data defined in YANG models when a
  live
  YANG server is not available. Data is often needed already at
  design
  or implementation time or needed by groups that do not have a live
  running YANG server available. This document specifies a standard
  file format for YANG instance data (which follows the syntax and
  semantic from existing YANG models, re-using the same format as
  the
  reply to a  operation/request) and decorates it with
  metadata.
  
  
  
  Please note that it may take a couple of minutes from the time of
  submission
  until the htmlized version and diff are available at
  tools.ietf.org.
  
  The IETF Secretariat
  

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

[Balázs Lengyel]

  
  
I am not asking for a change, but ...

 IMHO it would be better if YANG would not allow whitespace in
  enum names. 
  It is a rarely needed freedom that degrades usability and can lead
  to mistakes 
  and higher tool development costs. So it is bad for both people
  and tools.


  It is misleading, as a human user can mistakenly think that "this
is legal" is actually 3 separate values
  Some tools tend to consider spaces as separators 
  
  When creating code from YANG this needs special handling
  

regards Balazs

On 2019. 02. 22. 12:07, Juergen
  Schoenwaelder wrote:


  On Fri, Feb 22, 2019 at 10:55:31AM +0000, Balázs Lengyel wrote:

  
Do people really use enum names with whitespace within?
I always had the feeling that the name of the enum is like an identifier, so
it should follow maybe not the exact same but at least similar rules.

When such an enum name is translated into a programing language AFAIK the
translation needs to replace the spaces with something.

  
  
Not just spaces. Tool implementors will have to address this and what
needs special handling varies from target language to target language
(some target languages or implementations of target languages also
have interesting length contraints).

I think it is fine if BCPs like RFC 8407 provide guidelines that
people should avoid characters that are likely to be problematic but
the YANG specification is relatively clear that YANG itself puts
little constraints on such names (and hence tool makers in charge
to handle this).

/js



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

[Balázs Lengyel]

Do people really use enum names with whitespace within?
I always had the feeling that the name of the enum is like an 
identifier, so it should follow maybe not the exact same but at least 
similar rules.


When such an enum name is translated into a programing language AFAIK 
the translation needs to replace the spaces with something.


regards Balazs

On 2019. 02. 21. 18:45, Andy Bierman wrote:

enum "This is also legal";


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-yang-instance-file-format-01 terminology

[Balázs Lengyel]

  
  
Thanks for the comments. See below!

On 2019. 02. 07. 16:32, Juergen
  Schoenwaelder wrote:


  Hi,

I just stumbled across the terminology defined in
draft-ietf-netmod-yang-instance-file-format-01 and I have several
questions:

   Design time: A time during which a YANG model and the implementation
   behind it is created.  Sometimes in other documents this period is
   divided into design and implementation time.

Assuming that design time and implementation time are the same seems
to be odd. In the IETF, it is quite common that there is a significant
difference between design time and implementation time. So what is
mean here? Since the term is rarely used (I found two occurances),
perhaps clarify what is meant where this term is used and do not
introduce a new term. However, if the term is defined, then I suggest
that we use semantics that align with the common use of the term.

BALAZS: Following your suggestion I removed
  the term.
  (I do not know if we really have a "common use". For me (Ericsson)
  anything from specification, to SW development to testing is
  considered design time.)

  

   Instance Data Set: A named set of data items that can be used as
   instance data in a YANG data tree.

Why do we need this term? How is this different from data tree defined
in RFC 7950?

BALAZS: Instance data set is more than just
a data tree: it includes metadata and MAY include additional
items 
like XML attributes for implementation specific use. Also the
validation rules are less strict as partial data sets are
allowed.


 o  data tree: An instantiated tree of any data modeled with YANG,
  e.g., configuration data, state data, combined configuration and
  state data, RPC or action input, RPC or action output, or
  notification.

In which sense is this a 'named set'? Or is the intention here to
define a named set of YANG data trees? If a term is needed, would
'Instance Data' not be simpler and align better with Instance Data
File? Also note that 'instance data' is defined later as 'data that
could be stored in a datastore and whose syntax and semantics is
defined by YANG models'. So how does 'instance data' related to
'instance data set' and 'data tree'? Can we simplify things?

BALAZS: Instance data is used as a general
term. "Instance data set" is a specific representation of
instance data, that 
  

  has a specific format (XML or JSON)
  must be decorated with specific meta
  data and 

  must have an identity (name +
  revision-date/timestamp)
  has a specific scope (partial data sets
  are allowed)


Even for an unchanged data tree, you may
record different instance data sets e.g. representing the same
data tree at different times, thus signifying it has not
changed. 

  

   Target YANG Module: A YANG module for which the instance data set
   contains instance data, like ietf-yang-library in the examples.

I am not sure I like 'target'. It seems to me that instance data is
expected to conform to a schema defined by a collection of YANG
modules and you probably want to express that (but 'target' I find
misleading - data does not target a module).  Whatever we choose at
the end, we need to make sure that the terminology across related
documents (YANG, NMDA, YANG Library, ...) is consistent.

The leaf target-ptr triggers questions as well. If there is a choice
between two things, perhaps using a YANG choice is a more natural way
of expressing this than inventing special notations. I am also not
sure if it is a good idea to hardcode the name ietf-yang-library. Why
can I not just refer to any schema defining YANG modules? This way, we
have the freedom to create ietf-yang-library-2 if we ever want to. Do
implementations have to follow target-ptr arbitrarily deep? Do they
have to detect circular references (well they better do I guess).

BALAZS: Agreeing with you, it will be
changed to choice. That also makes finding the 
used method explicit. It also makes it easier to add new methods
later.
I will make it possible to use other YANG
modules.
Could you propose a better name instead of
"target"? IMO the concept is needed. It could be called "target"
or "instantiated" or "data-defining" or  ???
IMHO terms like "used", "referenced", "relevant" are to generic
and used for too many ways. 
  

  

/js



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt

[Balázs Lengyel]

  
  


On 2019. 02. 07. 13:10, Robert Wilton
  wrote:


  
  Hi Balazs,
  Regarding identifying the instance data using a YANG package.
  If the YANG packages work is liked by the WG and progresses,
then it seems plausible that a YANG package could become a
better way of identifying the set of modules rather than using
YANG library for a couple of reasons:
 1) It will allow modules to be identified via semantic version
rather than just revision date.  This will likely be more
meaningful to readers.
  

BALAZS: The nice thing about using yang-library is that when the
semver work augment the library with the module-version it will be
available for instance-data for free.

    2) It allows for a much more concise definition.  Rather than
having to try and infer what schema a particular set of YANG
modules related to from the list of modules, it can instead
refer to a single package definition and version number.
  

BALAZS: Using packages would be more, concise however in some cases
you might not want to declare a package. E.g. we use a modular
architecture where one design group might be responsible for only
one YANG module (YAM). They need to deliver some instance-data
related to that YAM, but they don't want to declare a package that
contains just one YAM. Also some modules are packaged in so many
ways that it is easier to define their instance data just for that
module. So while packages are an interesting idea they will never
completely replace the module level, hence we need a module level
solution too. One packages are agreed, I will be happy to expand
this specification.

    3) YANG library (certainly RFC7895bis) defines the schema in
terms of the datastore, so if this version of YANG library is
being used then it is a bit more confusing as to which datastore
is being referred to.  I appreciate that there is a datastore
leaf in the instance data that can help mitigate this.
  
  I also note that the draft currently binds that the only
allowed inline schema is YANG library, but that seems somewhat
overly restrictive, and perhaps this could be loosened to a
leaf-list of inline module@revision definitions?
  

BALAZS: IMHO ietf-yang-library contains ll the data we need in a
well defined format (and some we don't always need). So why define a
new format when we already have one. Also by using YANG library we
get for free any new data in it e.g.module-version. We also need the
info about leafs and deviations.

   
  I also appreciate that you don't want to delay the instance
data draft for YANG packages, bit I wonder whether the draft can
easily facilitate using a YANG package definition in future if
required.

BALAZS: As I agree with your comment about choice (see below) that a
package reference can be easily included in that.

  Hence, rather than using a union for the "target pointer", I
wonder whether it wouldn't be better to use a choice statement
instead.
  E.g. the choice statement could be something like this:
  
   choice "schema"
   leaf-list inline {
 type string {
   pattern '\w+@\d{4}-\d{2}-\d{2}\.yang';
 }
   }
   leaf yang-library-ref { type uri } // Points to a
  instance data document YANG library content.
 }
  In future, the package draft could then augment (or update the
revision) with something like this :
     container package-ref {
 leaf "name" { type string; }
 leaf "version" { type yang-semver; }
 leaf-list "url" { type uri; } //
Points to a instance data document containing YANG package
content.
     }

BALAZS: OK, choice maybe a better choice because it is easier
to extend and because it explicitly states the method used. So
how about:
 choice "target-specification"
   leaf inline {
 type string { pattern 'ietf-yang-library@\d{4}-\d{2}-\d{2}\.yang'; }   // I still want to use the library 
   }
   leaf yang-library-ref { type uri } 
 }

Later we can augment this choice with container package-ref.



  Thanks,
    Rob

  
  On 06/12/2018 10:15, Balázs Lengyel
wrote:
  
  
Hello,
We uploaded a new version of the instance data draft. We
  tried to address all comments and also to rework the format
  chapter to make it easier to read. We omitted 2 comments:
Rob commented that YANG packages could be used for defining
  the target modules for instance data: I would like 

Re: [netmod] Any implementation of ietf-snmp.yang RFC 7407

[Balázs Lengyel]

On 2018. 12. 18. 17:10, Martin Bjorklund wrote:

Balázs Lengyel  wrote:

Hello,

Does anyone know about implementations of the ietf-snmp YANG model?
As far as I could find none of the SW/vendors yumapro, tailf/confd,
snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia,
Juniper have implemented it.

We shave an implementation that isn't exactly the model in the RFC,
but close.  Did you ask b/c you have found some issue with the model?


/martin


I asked, because I see so little uptake for the model, I am starting to 
wonder, if this is a dead RFC no one cares about, or whether it just 
takes time for people to implement it. Whether ONAP that requires this 
RFC really wants this, or they just listed all finalized YANG models 
sonetime earlier.


regards Balazs

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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Any implementation of ietf-snmp.yang RFC 7407

[Balázs Lengyel]

Hello,

Does anyone know about implementations of the ietf-snmp YANG model?
As far as I could find none of the SW/vendors yumapro, tailf/confd, 
snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia, Juniper 
have implemented it.


regards Balazs

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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces

[Balázs Lengyel]

  
  
Hello,
While I agree with Martin, in our systems we have a number of
  places, where the system does create configuration in running, due
  to

  different levels of automation and autonomous algorithms
kick-in
  the created config needs to be possible to be further modified
by the operator
  the created config needs to be referenced from operator
created config
  the created config is not always ephemeral, it might need to
be part of backup/restore

regards Balazs

On 2018. 12. 17. 9:15, Martin Bjorklund
  wrote:


  The rule of thumb is to avoid server created config as much as
possible.


/martin


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt

[Balázs Lengyel]

  
  
Hello,
We uploaded a new version of the instance data draft. We tried to
  address all comments and also to rework the format chapter to make
  it easier to read. We omitted 2 comments:
Rob commented that YANG packages could be used for defining the
  target modules for instance data: I would like to avoid that
  because:

  Packages are not defined for YANG. Currently they are not part
of the versioning solution even though they were discussed and
are generally a good idea.
  IMHO as deviations/features are set on module level, just
specifying packages would not be enough. If we start using
package+module level deviations/features we may end up with a
more complicated hybrid solution.
  Module level YANG target definitions as described in the draft
are simple and need no new design
  

Jürgen stated that it would be better to use the YANG XML/JSON
  encoding as a format instead of referencing the get
  operation/request. I might even agree with him, but for 2 reasons
  I did not follow his idea:

  Currently there is no RFC I could reference either for XML or
JSON. AFAIK even RFC7951 does not define how multiple modules
should be encoded side by side.
  It is not the job of the instance data draft to dictate how to
encode YANG data generally e.g. on the wire. 
  
  The contents of the get operation/request are well defined
  

regards Balazs

  
   Forwarded Message 
  

  
Subject:

New Version Notification for
  draft-ietf-netmod-yang-instance-file-format-01.txt
  
  
Date: 
Thu, 6 Dec 2018 02:12:12 -0800
  
  
From: 
internet-dra...@ietf.org
  
  
To: 
Benoit Claise , Balazs Lengyel
  
  

  
  
  
  
  A new version of I-D,
  draft-ietf-netmod-yang-instance-file-format-01.txt
  has been successfully submitted by Balazs Lengyel and posted to
  the
  IETF repository.
  
  Name: draft-ietf-netmod-yang-instance-file-format
  Revision: 01
  Title: YANG Instance Data File Format
  Document date: 2018-12-06
  Group: netmod
  Pages: 21
  URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt
  Status:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
  Htmlized:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01
  Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
  Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01
  
  Abstract:
  There is a need to document data defined in YANG models when a
  live
  YANG server is not available. Data is often needed already in
  design
  time or needed by groups that do not have a live running YANG
  server
  available. This document specifies a standard file format for YANG
  instance data, which follows the syntax and semantic from existing
  YANG models, re-using existing formats from 
  operation/request
  and decorates them with metadata.
  
  
  
  Please note that it may take a couple of minutes from the time of
  submission
  until the htmlized version and diff are available at
  tools.ietf.org.
  
  The IETF Secretariat
  

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] instance file parsing - what is the target YANG module set

[Balázs Lengyel]

  
  
Hello Andy,
Give me a few days and I will come out with -01 version of the
  draft that addresses this issue. We propose 3 options:

  Include the needed information as part of instance data as
defined by ietf-yang-library, that documents module name,
revision, supported features, deviations
  Include a URI that points to the same information (if you
don't want to repeat the info again and again)
  Include nothing as the target YANG module set may already be
known, or the information is available through external
documents.

I also see a major reason for this draft: once it is agreed we
  can use instance data to document other standard things, like
  server capabilities.

regards Balazs

On 2018. 11. 30. 18:48, Andy Bierman
  wrote:


  
  Hi,


I don't see much standards value in this draft so far.
It seems the parser of the file needs to know the YANG
  library information
for the instance file data in some out-of-scope
  non-standard manner.
This is what we already have today just by naming the file
  in a specific way.


Is the intent that the instance-data-set leafs will be used
  to determine
the module revisions, features, and deviations used in the
  children
or the 'data' node?


Andy




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


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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] instance file format timestamp

[Balázs Lengyel]

  
  
On 2018. 11. 30. 13:48, Juergen
  Schoenwaelder wrote:


  
PS: I am also concerned about the revision being not fine grained
 enough to be useful. I would love to have a much more precise
 timestamp telling me when the instance data was recorded. I would
 probably replace 'revision' with simply a 'timestamp' or add next
 to a 'revision' a more fine grained 'timestamp'.

   BALAZS: I agree that in some use cases a timestamp would be useful e.g.
   diagnostic data from a real live YANG server.
   However in other use cases like documenting factory default, defining
   default configuration to be preloaded or documenting server capabilities I
   see no need for the timestamp. It is not interesting exactly at which
   hour/minute/second the server capabilities were documented.
   So while I would not like to add the timestamp in the draft, the draft
   documents, that additional metadata like a timestamp may be added to the
   instance data set.


  
  Having an (optional) timestamp with proper granularity seems rather
basic for me and I fail to see why we would not define this.

BALAZS: Don't really agree, but I will add the optional timestamp
  as you think its important.
-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Datastore leaf for yang instance data

[Balázs Lengyel]

On 2018. 11. 28. 16:43, Robert Wilton wrote:


On 28/11/2018 15:32, Juergen Schoenwaelder wrote:

On Wed, Nov 28, 2018 at 03:27:26PM +, Robert Wilton wrote:

On 28/11/2018 10:20, Juergen Schoenwaelder wrote:

On Wed, Nov 28, 2018 at 09:41:12AM +, Balázs Lengyel wrote:

I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet 
again
means something different than the same config true leaf in 
operational.


/js
BALAZS: As I understood the WG decided that this draft should only 
be about
the format of the yang instance data. What the SW does with it is 
out of
scope. So considerations whether instance data should be loaded 
into running

or candidate or not at all, are outside the scope.

If you do not know what the instance data means, any attempt to use it
is kind of broken.
I want to provide a datastore indicator, but how that should be 
used (and

thus what is exactly means) is out of scope.

I disagree. The datastore indicator is needed to understand what the
data means, i.e., to do anything meaningful with it.
I think that a datastore indicator is useful sometimes.  E.g. it 
might be
helpful in some cases to know that the data was associated with a 
particular

datastore.

But in the general case I think that this is just "data at rest", and
probably the key thing to know is whether (i) the data relates to
configuration, or (ii) the data relates to operational state.

This could potentially be inferred from a datastore leaf, or perhaps 
this
distinction could more explicitly be made by a separate field, which 
I would
make an enumeration or identity, since there might be other types of 
data in

future, such as capability information or diagnostics.


I do not understand why a datastore leaf is not sufficient and why we
need yet something new. If ever needed, NMDA does allow us to define
new datastores.


Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.


The second reason is that I don't know whether things like 
capabilities and diagnostics will be new datastores or just part of 
operational.  I don't think that either of these two areas have really 
been properly worked out yet.  I presume that they will come over 
time, once more network management becomes more automated.


Thanks,
Rob


BALAZS: You are right, that these areas are not worked out. That is 
exactly why they are out of scope. This is only about the format, and 
not about the usage. As we already have about 10 use cases with 
different needs, none of which are specified exactly, I want to avoid 
defining specific metadata for use cases we don't fully understand. 
Note: it is possible and documented that the metadata can be 
extended/augmented.


regards balazs

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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

OK, so lets go with option 3.
balazs

On 2018. 11. 30. 16:17, Juergen Schoenwaelder wrote:

On Fri, Nov 30, 2018 at 12:48:48PM +, Balázs Lengyel wrote:

Hello, Joe, Jurgen,

RFC6020 doesn't really register� file extensions, but rather media types.
I don't feel we need a new mediatype for this as we really use json and
xml. However I see it useful to document in the file extension that this
is not just any plain old XML; it is yang instance data in XML format.�
Alternatives:

 1. Use the .yid file extension (my favorite)
 2. Use 2 separate file extensions: .yidxml, .yidjson
 3. just use .xml and .json


I would have used .json or .xml; the content of the file after all is
self-describing and tools like 'file' might learn how to recognize the
content. Extensions like .yidxml and .yidjson looks a bit horrible to
me and so far I never had any real problems using .json and .xml for
arbitrary json and xml files (and .json and .xml helps generic tools
so calling it .yid means that I have to go and teach tools that .yid
is either .json and .xml). Try loading .json and .xml in your
favourite editor and then load a .yid file. Big difference for my
editor. So from my perspective, do nothing (and then people and tools
will likely use option 3).

/js


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

Hello Qin,

Do you have a better suggestion for the file extension?

regards Balazs

On 2018. 11. 29. 2:53, Qin Wu wrote:

The abbreviation of YANG instance data yid may confuse with YANG identitifer 
short name
"
YANG Identifier:  Numeric object identifier, which is a fixed-length
   numeric value that represents a particular schema node within a
   YANG module schema tree.  The length and format of a YANG
   identifier are defined in the YANG Identifier Registry.  Also
   called a "YID".
"
I believe they are not same thing.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Joe Clarke
发送时间: 2018年11月28日 22:36
收件人: Balázs Lengyel; netmod@ietf.org
主题: Re: [netmod] Fwd: New Version Notification for 
draft-ietf-netmod-yang-instance-file-format-00.txt

On 11/23/18 07:48, Balázs Lengyel wrote:

Do you have to register the ".yid" file extension as well?

BALAZS: Is there a registry for file extensions? I was not aware.

RFC6020 section 14 registers media types that include file extensions for .yin 
and .yang.  I am asking are you proposing to do the same and registering 
something like application/yang-instance-data with a .yid extension?

Joe

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


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

  
  
Hello, Joe, Jurgen,
RFC6020 doesn't really register  file extensions, but rather
  media types. I don't feel we need a new mediatype for this as we
  really use json and xml. However I see it useful to document in
  the file extension that this is not just any plain old XML; it is
  yang instance data in XML format.  Alternatives:

  Use the .yid file extension (my favorite)
  Use 2 separate file extensions: .yidxml, .yidjson
  just use .xml and .json

What is the rule, do I need to register a file extension as a
  media-type? Is that optional? Is that needed?
regards Balazs

On 2018. 11. 28. 15:48, Juergen
  Schoenwaelder wrote:


  On Wed, Nov 28, 2018 at 09:35:55AM -0500, Joe Clarke wrote:

  
On 11/23/18 07:48, Balázs Lengyel wrote:


  
Do you have to register the ".yid" file extension as well?

  
  BALAZS: Is there a registry for file extensions? I was not aware.



RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?


  
  
Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF  or RESTCONF/HTTP GET? Ideally, the format of
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/js



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] instance file format and etags/timestamps, xml attributes

[Balázs Lengyel]

  
  
Hello Jurgen,
Thanks for the comments. See answers below.
regards Balazs

On 2018. 11. 28. 11:01, Juergen
  Schoenwaelder wrote:


  draft-ietf-netmod-yang-instance-file-format-00.txt says:

   The JSON format SHALL follow the format of the reply returmed for a
   RESTCONF GET request directed at the datastore resource:
   {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
   if present SHOULD be ignored.

I assume that you mean the JSON content in the message-body of the
HTTP Response message for GET message. My understanding is that ETags
and Timestamps (what are these precisely?) are carried in the HTTP
header. So how could the ETag or 'Timestamps' be in the JSON data?  We
should not mess up the HTTP difference between header data and payload
data.

BALAZS: OK, I will correct it. Yes, it is the
  payload that I want to include in the instance data. 
  I thought that lower level etags/timestamps are returned inside
  the get-response payload. On re-reading RFC8040 I see my mistake.

  

I also do not fully understand the text concerning the XML format.

   The XML format SHALL follow the format returned for a NETCONF GET
   operation.  The  anydata (which is not part of the real data
   itself) SHALL contain all data that would be inside the 
   wrapper element of a reply to the  operation.  XML attributes
   SHOULD NOT be present, however if a SW receiving a YANG Based
   Instance data file encounters XML attributes unknown to it, it MUST
   ignore them, allowing them to be used later for other purposes.

It is unclear what exactly is the instance data - the entire reponse?
Everything inside ? Everything inside and including ? I
assume the second sentence is trying to say the later but I do not
find it very clear not does it seem to be right. The examples show to
content of the NETCONF  inside a 
container that belongs to the instance data format (two times 
but in different namespaces).

BALAZS: I will try to reword it to clarify
the issue. How about:
An instance data set is made up of header
part and content-data. The content-data is all data inside the
anydata data node. 
  
The header part is defined by the
-ietf-instance-data module while the content-data is defined by
the target YANG modules. The content-data  SHALL contain all
data that would be inside the  wrapper element of a
reply to the  operation .   
  
I hope this conveys that content data
excludes the  wrapper element from the get-reply.


  

It is also unclear to me why XML attributes are to be removed. Why is
that? If I snapshot , why should I remove important
information such origin annotations? And removing attributes is
actually plain wrong if you consider that attributes carry XML
namespaces.

BALAZS: You are right, although some
attributes might be absent in some use cases.  E.g. namespace as
you pointed out is always needed. However e.g. origin may be
present if the instance data is a snapshot of the operational
datastore, but it may be absent if the instance data is used to
document readOnly server capabilities.
  
So I propose to change the text to:
Some XML attributes (e.g. metadata like origin) MAY be absent. 
SW handling YANG Instance data MUST ignore   
XML attributes unknown to it, allowing them to be used 
later for other purposes.


  
/js

PS: I am also concerned about the revision being not fine grained
enough to be useful. I would love to have a much more precise
timestamp telling me when the instance data was recorded. I would
probably replace 'revision' with simply a 'timestamp' or add next
to a 'revision' a more fine grained 'timestamp'.

BALAZS: I agree that in some use cases a
timestamp would be useful e.g. diagnostic data from a real live
YANG server. 
However in other use cases like documenting factory default,
defining default configuration to be preloaded or documenting
server capabilities I see no need for the timestamp. It is not
interesting exactly at which hour/minute/second the server
capabilities were documented.
So while I would not like to add the timestamp in the draft, the
draft documents, that additional metadata like a timestamp may
be added to the instance data set.


  



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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

[Balázs Lengyel]

  
  
Hello, 

In a similar manner we found multiple uses for the ietf-netconf-acm:node-instance-identifier.
  We imported nacm just to reuse this type.
  Anyone else interested?
regards Balazs

On 2018. 11. 29. 12:03, Robert Wilton
  wrote:

Hi
  Juergen,
  
  
  YANG library currently defines the type "revision-identifer".  Is
  this a typedef that should logically migrate to rfc6991bis?
  
  
  Thanks,
  
  Rob
  
  
  On 14/11/2018 08:16, Ladislav Lhotka wrote:
  
  On Wed, 2018-11-14 at 09:10 +0100, Martin
Bjorklund wrote:

Hi,
  
  
  Alex Campbell  wrote:
  
  Does a percentage really need a single
standard type in the first

place? How about "units percent;"?

  
  At this point, after hearing about how different modules have
  
  differing requirement on this type, I tend to agree.
  

+1


Or even "units %;"


Lada



  
  /martin
  
  
  
  

From: netmod  on behalf of
Acee Lindem (acee)



Sent: Wednesday, 14 November 2018 5:03 a.m.

    To: Juergen Schoenwaelder; Balázs Lengyel

Cc: NETMOD WG

Subject: Re: [netmod] for a future rfc6991bis


On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
Schoenwaelder"

<netmod-boun...@ietf.org on behalf of

j.schoenwael...@jacobs-university.de> wrote:


     On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs
Lengyel wrote:

 > Hello,

 >

 > In some cases I want a percentage without
fractions. This could be

 > defined

 > using range, by specifying the numbers 0 | 1 | 2
... 99 | 100 in the

 > range's

 > argument.

 >

 > typedef percent-short {

 >   type percent { range 0 | 1 | 2 ... 99 | 100;
} // didn't type

out

 >   all the 101 integer values :-)

 > }

 >


 I guess we need to settle on a small number of
percentage types that

 people find useful and then module authors hopefully
find what they

 need. I am not sure that listing 101 numbers is a good
pattern to use

 (although it does achieve what you want). For
percentages that have no

 fraction, you likely want to derive from a base type
that is efficient

 to encode for binary encodings such as CBOR.


Or simply define a type with a base type of unit8 type and a
range of

0-100.


Acee






 /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

___

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod

  
  

Re: [netmod] Datastore leaf for yang instance data

[Balázs Lengyel]

On 2018. 11. 23. 16:49, Juergen Schoenwaelder wrote:

On Fri, Nov 23, 2018 at 01:21:23PM +, Balázs Lengyel wrote:

BALAZS: "Instance data associated with a datastore" may mean many things,
that's why this relatively loose term is used. It may mean:

  * Data was read from that datastore
  * Data is intended to be fed into that datastore
  * Something else ???

This can be useful if data is read from a datastore, but in a number of
cases it is not useful:

  * Preloading configuration data: datastore may be running or candidate.
  * Preloading mixed config and state data: We do have state data that is
very stable and thus it is documented as instance data, and the
instance data file is actually used to feed the state data into the
SW. So datastore is: running, candidate + operational if NMDA is
supported or state datastore (whatever that is) if NMDA is not
supported

regards Balazs


I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet again
means something different than the same config true leaf in operational.

/js


BALAZS: As I understood the WG decided that this draft should only be 
about the format of the yang instance data. What the SW does with it is 
out of scope. So considerations whether instance data should be loaded 
into running or candidate or not at all, are outside the scope.


I want to provide a datastore indicator, but how that should be used 
(and thus what is exactly means) is out of scope.


Anyway in some cases it would be problematic to define a single 
datastore parameter. E.g. the draft allows the real world use case of 
putting config and state data in the same file. In this case state data 
is associated with operational while config data is with 
running/candidate. In the non-NMDA case I do not even know what the 
correct daatastore is for state data.


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Datastore leaf for yang instance data

[Balázs Lengyel]

Hello Jurgen,

As we had many misunderstandings around the datastore parameter, and I 
am still not clear what you would like, could you propose a description 
text for the datastore parameter.


regards Balazs

On 2018. 11. 23. 16:49, Juergen Schoenwaelder wrote:

On Fri, Nov 23, 2018 at 01:21:23PM +, Balázs Lengyel wrote:

BALAZS: "Instance data associated with a datastore" may mean many things,
that's why this relatively loose term is used. It may mean:

  * Data was read from that datastore
  * Data is intended to be fed into that datastore
  * Something else ???

This can be useful if data is read from a datastore, but in a number of
cases it is not useful:

  * Preloading configuration data: datastore may be running or candidate.
  * Preloading mixed config and state data: We do have state data that is
very stable and thus it is documented as instance data, and the
instance data file is actually used to feed the state data into the
SW. So datastore is: running, candidate + operational if NMDA is
supported or state datastore (whatever that is) if NMDA is not
supported

regards Balazs


I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet again
means something different than the same config true leaf in operational.

/js


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] How to specify the target modules for YANG instance data [was: Re: validity of instance-data]

[Balázs Lengyel]

Hello Lada,

I like your idea idea, thanks. Adding some more details :

    Metadata MUST include:

   o  Name of the instance data set

   o  target: Specifies the method and details by which the target YANG
  modules, supported features and deviations are specified.  The
  specified target only indicates the set of modules that were used
  to define this YANG instance data set.  Whether the instance data
  set is usable for a different real-life target YANG module set
  depends on the compatibility between the specified target and the
  real-life target YANG module set (considering revisios, features,
  devaiations)

   Metadata SHOULD include:

   o  Revision date of the instance data set

   o  Description of the instance data set.  The description SHOULD
  contain information whether and how the data can change during the
  lifetime of the YANG server.

   Target SHALL use one of the following methods:

   IN-LINE Method.  Target should bet set to:

  'inline:ietf-yang-library@' revision-date '.yang'

  E.g. inline:ietf-yang-libr...@2016-06-21.yang

   The revision date is mandatory, it specifies the revision of the
   ietf-yang-library used by the in-line method.  When using the in-line
   method the first group of data inside the "anydata data" element MUST
   be the instance data targeted at the ietf-yang-library.  This data
   SHALL specify the target YANG modules, revisions, supported features
   and deviations for this and all the other target YANG modules.

   URI Method.  Target MUST bet set to a URI that references another
   YANG instance data file.  The first instance data file will use the
   same set of target YANG modules, revisions, supported features and
   deviations as this other referenced YANG instance data file.  The
   referenced YANG instance data file might use the in-line method or
   might use the URI method to reference further instance data file(s).
   However at the end of this reference chain there MUST be an instance
   data file using the in-line method.  This last instance data file
   MUST carry instance data for the ietf-yang-library, but often will
   carry no other instance data.  If a referenced instance data file is
   not available the revision data, supported features and devaitions
   for the target YANG modules are unknown.

   TODO: extend example with target.

regards Balazs

On 2018. 11. 06. 10:59, Ladislav Lhotka wrote:

Hi,

the second bullet of Appendix A in
draft-ietf-netmod-yang-instance-file-format-00 talks about
validity. This would make sense if we have a complete schema - YANG
modules, even with revisions, is not enough. The schema can be provided
off-line but it can also be specified as a part of the metadata.

I would suggest to extend the metadata with the following two optional
methods of specifying the schema:

1. the schema can be specified in-line, for example in the format of the
new YANG library, i.e. as a list of module-sets

2. A URL specifying the location of the schema.

Lada


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Datastore leaf for yang instance data

[Balázs Lengyel]

  
  
BALAZS: "Instance data associated with a datastore" may mean many
  things, that's why this relatively loose term is used. It may
  mean:


  
Data was read from that datastore
  
Data is intended to be fed into that datastore
  
Something else ???



This can be useful if data is read from a datastore, but in a
  number of cases it is not useful:

  Preloading configuration data: datastore may be running or
candidate. 
  
  Preloading mixed config and state data: We do have state data
that is very stable and thus it is documented as instance data,
and the instance data file is actually used to feed the state
data into the SW. So datastore is: running, candidate +
operational if NMDA is supported or state datastore (whatever
that is) if NMDA is not supported

regards Balazs


  


On 2018. 11. 06. 11:03, Ladislav Lhotka
  wrote:


  On Tue, 2018-11-06 at 10:41 +0100, Martin Bjorklund wrote:

  
Ladislav Lhotka  wrote:


  On Tue, 2018-11-06 at 07:36 +0100, Juergen Schoenwaelder wrote:

  
I agree that

leaf datastore {
  type ds:datastore-ref;
  description  "The identity of the datastore for which
the instance data is documented for config=true data nodes.
The leaf MAY be absent in which case the running dtastore or
if thats not writable, the candidate datastore is implied.

For config=false data nodes always the operational
data store is implied.";
}

is pretty confusing. It should be something like this:

leaf datastore {
  type ds:datastore-ref;
  description  "The identity of the datastore holding
the instance data. If the instance data is not associated

  
  
Or rather the datastore that the instance data was extracted from.



I prefer "associated with".  There are other uses cases than just
holding data "extracted from", e.g., data that is supposed to "be
inserted into" a datastore.  "associated with" is less resrictive.

  
  
It unclear what "associated with" means in this context.

Lada



  

  



  After that,
the data exists on its own and the originating datastore may later be


holding


  something else.


  
with a datastore, then this leaf MUST be absent.";

  
  
RFC 2119 language would make sense if there is anything that could break if


that


  MUST isn't observed. But we even didn't know what the data is going to be


used


  for.

I would treat the "datastore" item as a purely optional information



I agree.


/martin





  that, if
present, was provided for some reason. If it is false, what can we do?


  
}

I am against merging data from different datastores together, which
the last sentence of the original text seems to imply.

  
  
Both config true and config false data may come from , so it
doesn't necessarily mean any mixing of datastores. But then again, I think


that


  the datastore information isn't in most cases that interesting.

Lada


  

/js

On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:


  Joe Clarke  writes:

  
===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can

  

  

assume


  

  
the source datastore for config=true nodes.


  
  
The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data


  

will


  

  eventually be fed into the indicated datastore, but I don't see any
reason for such an assumption.

I can see that "datastore" can be occasionally useful as auxiliary
metadata but, in my view, this document addresses also instance data
that is not necessarily bound to any datastore.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt

[Balázs Lengyel]

  
  
Thanks for the comments. Details below.
Balazs

On 2018. 11. 06. 4:25, Joe Clarke
  wrote:


  On 11/5/18 21:54, Balázs Lengyel wrote:

  
The first WG version of the document is stored. It is the same as 
draft-lengyel-netmod-yang-instance-data-05 except for the change of title.

  
  
Thanks, Balazs.  Here is an itemized review of this draft.  Thank you
for acknowledging my requirements around augmenting YANG data/structure.
 You will definitely need that when you start to document server
capabilities.

I agree with Lada and Rob that moving the use case examples to an
appendix would make it easier to get to the meat of the document.

BALAZS: OK

  In your terminology section, you define an instance data set as
essentially a set of instance data.  I might incorporate the text from
your abstract to call instance data, data that is returned from a YANG
server.  This, too, isn't ideal, but I think it's worth being a bit more
descriptive here.


  You use "YANG Based Instance Data" as something that feels like a term
throughout the document, but you do not define this exactly.


BALAZS: OK.
  yang _BASED_ instance data is removed as it led to confusion. I
  revert to the more simple "yang instance data".
  Added definition for Yang Instance data

  Section 2.1.1

s/Capbilites/Capabilities/

s/capabilites/capabilities/g

BALAZS: OK

  You say, "While it is good practice to allow a client to query these
capabilities from the live YANG server, that is often not enough."

"Not enough" doesn't sound right.  I would say, "that is sometimes not
possible."  You may mention examples like the server is not currently
available or the code driving the server is not publicly available, etc.

BALAZS: OK, changed

  You say that, "Often when a network node is released an associated NMS
is released with it."

I don't know that this coupling happens "often."  I'd say that when new
network element code is released, operators want to understand the
capabilities that come within that new code.  Other NMS/OSS vendors want
to be able to understand the model provided by the new code so they can
adjust their client code.

You go on to say, "Network operators often build their own home-grown
NMS systems that needs to be integrated with a vendor's network node."

Again, the word "often" doesn't resonate with me.  I do agree that there
are NMS vendors that need to understand how to modify their NMS to
support other vendors' network elements and there are some operators
that are building their own NMS/OSS.

BALAZS: If we think about independent NMS
  vendors they may release the NMS update after the new network node
  version is released.
  My point is that, many operators will not wait for the NMS to be
  developed over some time. They require the NMS on day 1.
  Anyway this is only an appendix now.


  Section 2.1.2

s/configurationp/configuration/

BALAZS: OK

  Section 2.1.3

s/Dcomenting/Documenting/


BALAZS: OK

  Section 3

s/returmed/returned/

s/configuraton/configuration/

BALAZS: OK

  You say, "It SHOULD NOT be used if the file is stored in a version
control system (e.g. git) because the change of file names will break
the connection between the different revisions of the file."

I think you should drop this requirement.  I can use "git mv" or create
tags if I want to retain history.  I wouldn't try and legislate what
people do with their VCS.

BALAZS: OK, although I still think it is
  better to avoid using the date.

  You use "meta data" in a number of locations.  Might I suggest
"metadata."  I think that is a more common way to write that term.

BALAZS: OK

  Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can assume
the source datastore for config=true nodes.

BALAZS: This should be a default value.
  However as the default is a simple value, but 
  here it really depends on the config=true/false and the existence
  of writable-running 
  I put it into the description statement. If you need something
  else, like in your example, go ahead specify it.
  Reworded from imply to default.

  

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

BALAZS: OK

  Section 8

Do you have to register the ".yid" file extension as well?

BALAZS: Is there a registry for file
  extensions? I was not aware.

  Thank

Re: [netmod] Deviations and augmentations

[Balázs Lengyel]

  
  
Hello,
We also need a method for removing stuff. It does happen that
  some functionality is deemed not important enough, outdated, too
  expensive to maintain, so we want to remove it. 


  Augment is clearly not the tool for that.
  Deviations are not intended for that  (from rfc 7950: "server
deviation: A failure of the server ...")

So we still need Semver(or something akin) and the possibility to
  do NBC changes.
Balazs

On 2018. 11. 12. 18:08, Robert Wilton
  wrote:


  
  
  On 12/11/2018 16:33, Martin Bjorklund wrote:
  
  Robert Wilton 
wrote:

In the Thursday Netmod meeting, it was
  interesting to hear Rob Shakir
  
  describe how deviations and augmentations are used in
  OpenConfig to
  
  add functionality into an older YANG model where the semver
  rules
  
  prevent the version number from being incremented.
  
  
  Further, I think that someone (Martin?) stated on the audio
  bridge
  
  that this was an intended/allowed behavior for deviations.
  

I said that using augmentations (not deviations) was one idea we

originally had for solving the "branching problem".

  
  Ah, OK. I agree that makes sense.
  
  
  

I think that this works for OC b/c they don't branch their
modules.

Hence I think it is important that we decide if branching is a

requirement or not.

  
  So, I think that this probably works for adding enhancements, but
  not for the (arguably more important) bug fix case, unless there
  is a reasonable solution to having two config data nodes both
  modifying the same underlying property.  Perhaps under some
  reasonable constraints this could be made to work - but I don't
  know.
  
  
  Of course, even for enhancements it is not necessarily a perfect
  solution.  E.g. backporting some subset of a module already
  coded/implemented in latest to an older release.  And yes, we
  really do get asked to do this sometimes, although it is
  relatively rare.
  
  
  Thanks,
  
  Rob
  
  
  


/martin



This surprised me, because I thought
  that RFC 7950 was quite explicit
  
  that this is not what deviations are intended for.  My reading
  of RFC
  
  7950 is that the deviation statement represents the case where
  the
  
  server *implementation* does not match the *specification*. 
  However,
  
  the versioning issue that we are discussing are bug
  fixes/changes in
  
  the specification rather than the bug fixes in the
  implementation.
  
  
  Personally, I'm really not keen on using deviations to
  represent bug
  
  fixes to older YANG models for three reasons:
  
  
  (i) It is changing the meaning of deviation.  It is much
  cleaner to
  
  keep the meaning of deviation statements as they are defined
  today,
  
  and not conflate their semantics.
  
  (ii) A different mechanism is used to put a bug fix into an
  older
  
  branch rather than in the head of the development.
  
  (iii) For clients to track the lifecycle of modules they would
  not
  
  only need to know the module version number but would also
  need to
  
  find and track all associated deviation modules.  This seems
  
  significantly more complex for clients than the modified
  semver that
  
  was proposed.
  
  
  ---
  
  
  I think that has also been some suggestion that augmentations
  (or
  
  duplicate YANG modules with their major version number
  changed) can be
  
  used to make bug fixes in a completely backwards compatible
  way.
  
  However, I still don't understand a robust scheme of how this
  works.
  
  
  ---
  
  
  Finally, there were some comments about using augmentation
  modules for
  
  enhancements.  This is fine, where appropriate (e.g. a non
  trivial
  
  number of data nodes are being added as an enhancement) then a
  
  separate module may be the right way to go. But here, I
  presume that
  
  the new 

Re: [netmod] for a future rfc6991bis

[Balázs Lengyel]

Hello,

In some cases I want a percentage without fractions. This could be 
defined using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in 
the range's argument.


typedef percent-short {
  type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out all 
the 101 integer values :-)
}

regards Balazs

On 2018. 11. 07. 9:34, Juergen Schoenwaelder wrote:

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:


For the range, if the defintion can cover the our range(0..99.),
it will be acceptable.  In your suggestion below, does that mean the
base defintion is without range, while refined types can chosse the
range they like?

I was thinking loud. Let me detail somewhat more what was going on in
my head:

   We could define a percent type without the upper bound being
   whatever the decimal covers but fixing the precision of the
   fractional part. We could then narrow the upper bound via
   subtyping:

  typedef percent {
type decimal {
  fraction-digits 4;
  range "0..max";
}
  }

  typedef percent' {
type percent { range 0..100; }
  }

   If wanted flexibility on the fractional part, we could define
   percent with a fixed range and the largest number of fraction digits
   possible and then we could subtype this to obtain a precision that
   makes sense in the usage contexts (although it is not clear whether
   YANG 1.1 really allows this, if not this may be just due to nobody
   ever thinking about this before):

 typedef percent {
   type decimal {
 fraction-digits 16;
 range 0..100;
   }
 }

 typedef percent' {
   type percent { fraction-digits 4; }
 }

   An ideal solution would provide flexibility both on the range and
   the number of fraction digits but it seems this is impossible since
   these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js


BR,
Amy

发件人: Juergen Schoenwaelder [j.schoenwael...@jacobs-university.de]
发送时间: 2018年11月6日 22:16
收件人: Yemin (Amy)
抄送: Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; NETMOD WG
主题: Re: [netmod] for a future rfc6991bis

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +, Yemin (Amy) wrote:

If the percentage is defined as following, as a author of 
draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely 
used item.

BR,
Amy

发件人: netmod [netmod-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
发送时间: 2018年11月6日 9:25
收件人: Xufeng Liu; balazs.leng...@ericsson.com
抄送: NETMOD WG
主题: Re: [netmod] for a future rfc6991bis


Another case would be :


“

typedef percentage {

   type decimal64 {

  fraction-digits 5;

  range "0..100";

  }

description "Percentage.";
}
”
Which is defined ietf-connectionless-oam.yang module.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Xufeng Liu
发送时间: 2018年11月6日 3:49
收件人: balazs.leng...@ericsson.com
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

The draft that asked for the percentage type is: 
https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02

They currently define:

   leaf availability {
 type decimal64 {
   fraction-digits 4;
   range "0..99.";
 }
 description "Availability level of the link";
   }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:

+1 to percentage.

Balazs
On 2018. 11. 03. 3:44, Xufeng Liu wrote:
Remember that some draft asked for a type of percentage value to the nearest 
hundredth. Wondering if it can be put in.

Thanks,
- Xufeng

On Fri, Nov 2, 2018 at 11:39 AM tom petch 
mailto:ie...@btconnect.com>> w

[netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt

[Balázs Lengyel]

  
  
The first WG version of the document is stored. It is the same
  as  draft-lengyel-netmod-yang-instance-data-05 except for the
  change of title.

Balazs
  
   Forwarded Message 
  

  
Subject:

New Version Notification for
  draft-ietf-netmod-yang-instance-file-format-00.txt
  
  
Date: 
Mon, 5 Nov 2018 18:12:04 -0800
  
  
From: 
internet-dra...@ietf.org
  
  
To: 
Benoit Claise , Balazs Lengyel
  
  

  
  
  
  
  A new version of I-D,
  draft-ietf-netmod-yang-instance-file-format-00.txt
  has been successfully submitted by Balazs Lengyel and posted to
  the
  IETF repository.
  
  Name: draft-ietf-netmod-yang-instance-file-format
  Revision: 00
  Title: YANG Instance Data File Format
  Document date: 2018-11-04
  Group: netmod
  Pages: 14
  URL:
https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.txt
  Status:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
  Htmlized:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-00
  Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
  
  
  Abstract:
  There is a need to document data defined in YANG models without
  the
  need to fetch it from a live YANG server. Data is often needed
  already in design time or needed by groups that do not have a live
  running YANG server available. This document specifies a standard
  file format for YANG Based Instance data, that is data that could
  be
  stored in a datastore and whose syntax and semantics is defined by
  YANG models. Most important use cases foreseen include documenting
  server capabilities, factory-default settings, or vendor provided
  default configurations.
  
  
  
  Please note that it may take a couple of minutes from the time of
  submission
  until the htmlized version and diff are available at
  tools.ietf.org.
  
  The IETF Secretariat
  

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

  




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Balázs Lengyel]

  
  
Implementing 3.2 will be very costly. IMHO Ericsson will not
  implement it. We will do our utmost to avoid NBC changes, but if
  they do happen, I don't believe we would support multiple
  versions.

If the data models are sufficiently NBC e.g. changing a boolean
  to an integer 3.2 may not even be possible. The underlying data
  that drives the device may be an integer or a boolean, but not
  both. (Strange mapping may be possible to imagine, but they will
  not always work.)
regards Balazs


On 2018. 10. 27. 1:15, Robert Wilton
  wrote:


  
  
  
  
  On 26/10/2018 17:35, Andy Bierman
wrote:
  
  

  

  On Fri, Oct 26, 2018 at 2:33 AM,
Juergen Schoenwaelder 
wrote:
Let me add that
  there was large disagreement what a bug fix is in the
  design team. Hence, any text that talks about 'bug
  fixes' is ambiguous
  and of limited value to achieve consensus. (Or we may
  find consensus
  but then not agree on what we have found consensus
  on.)
  
  To be more concrete, I learned that Rob's notion of a
  bug fix is very
  different from my notion of a bug fix. I think it is
  important for
  having a productive discussion to be aware of this.
  
  For me, a bug fix is rather limited, i.e., fixing
  something where the
  correct intention was clear but the model did not
  properly capture the
  intention correctly, i.e., roughly what we can do with
  errata in the
  IETF. I think Rob understands bug fixes in a much
  broader sense,
  including fixes to what essentially are in my view
  module design
  errors.
  
  With my narrow definition of bug fixes, bug fixes are
  essentially
  backwards compatible (even if they may violate RFC
  7950 rules - but as
  long as the original intention was clear, we can be
  flexible).
  
  With Rob's notion of bug fixes, we have to handle them
  as part of the
  versioning system since they may be non-backwards
  compatible.
  





IMO requirements 3.1 and 3.2 are the most
   important and have the most impact
on the solution space. I do not agree with either
  of these requirements.
  

  

  
  OK.
  
  For 3.1, I think that just means that the solution has to be
  backwards compatible with existing clients (e.g. don't change the
  protocols in a non backwards compatible way).
  
  

  

  


Implementing multiple non-compatible revisions of a
  module on a server sounds hard,
not to mention that it breaks RFC 7950 rules. 
  

  

  
  Completely agree that it will be hard.  I envisage that it will
  optional for servers to implement this.
  
  

  

  
The current protocols do not support the
ability to specify different versions of the same
  QName. This change makes YANG validation
much to difficult to specify and implement (as that
  has to be rewritten as well).
  

  

  
  The way that I think of one solution for this problem is using
  datastore schema (as per the NMDA definition):
  
  Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X.
  For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y.
  
  When a client connects it chooses which schema it wants to use, X,
  Y, or latest.  If it doesn't specify then perhaps it uses the
  earliest schema (to handle requirement 3.1).
  
  If the client wants to use X, then the server has to translate the
  request into the equivalent request using schema Y instead. 
  Perhaps the server has to validate the config both in the context
  of X and Y.
  
  If the clients wants to