See below, BALAZS

 

From: Andy Bierman <[email protected]> 
Sent: 2019. november 7., csütörtök 7:44
To: Balázs Lengyel <[email protected]>
Cc: Martin Bjorklund <[email protected]>; NetMod WG <[email protected]>
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

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to