Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Accepted, last comment. Balazs -Original Message- From: Benjamin Kaduk Sent: 2021. október 7., csütörtök 23:45 To: Balázs Lengyel Cc: The IESG ; Benoit Claise ; draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) Hi Balázs, Replies inline as well (where needed) On Thu, Oct 07, 2021 at 10:43:28AM +, Balázs Lengyel wrote: > -- > COMMENT: > -- > Section 2 > >Two formats are specified based on the XML and JSON YANG encodings. >Later, as other YANG encodings (e.g., CBOR) are defined, further >instance data formats may be specified. > > I don't remember seeing a clear description of the specifics of these > two specified formats. (I assume it's just "use the XML/JSON encoding > for YANG structures", but I don't remember that stated anywhere.) > BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the model starts with a YAN structure, I included YANG Data Structure Extensions RFC8791 too. I was hoping for a statement like "The file formats are achieved by applying the respective XML and JSON encoding rules for the YANG structure included in this document." BALAZS2: OK Thanks for all the replies and updates, Ben smime.p7s Description: S/MIME cryptographic signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Hi Balázs, Replies inline as well (where needed) On Thu, Oct 07, 2021 at 10:43:28AM +, Balázs Lengyel wrote: > Hello Benjamin, > Thank you for the thorough review. I used your comments to improve the draft. > See my detailed answers below as BALAZS: > Regards Balazs > > -Original Message- > From: Benjamin Kaduk via Datatracker > Sent: 2021. október 7., csütörtök 6:55 > To: The IESG > Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; > kent+i...@watsen.net > Subject: Benjamin Kaduk's No Objection on > draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-netmod-yang-instance-file-format-20: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ > > > > -- > COMMENT: > -- > > Should we register media-types for the file formats being specified? > > Section 2 > >Two formats are specified based on the XML and JSON YANG encodings. >Later, as other YANG encodings (e.g., CBOR) are defined, further >instance data formats may be specified. > > I don't remember seeing a clear description of the specifics of these two > specified formats. (I assume it's just "use the XML/JSON encoding for YANG > structures", but I don't remember that stated anywhere.) > BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the > model starts with a YAN structure, I included YANG Data Structure Extensions > RFC8791 too. I was hoping for a statement like "The file formats are achieved by applying the respective XML and JSON encoding rules for the YANG structure included in this document." >The name of the instance data file SHOULD be of the form: > > instance-data-set-name ['@' ( revision-date / timestamp ) ] > ( '.xml' / '.json' ) > > This looks (almost? Not sure about '@' vs. "@".) like valid ABNF. Do we > want to say that and reference RFC 5234 for the interpretation of the symbols? > BALAZS: reference to ABNF added. Changed to double quotes. > >If the leaf "name" is present in the instance data header, its value >SHOULD be used for the "instance-data-set-name". If the "revision- >date" is present in the filename it MUST conform to the format of the >revision-date leaf in the YANG model. [...] > > This seems unenforcable, and contrary to the Unix ethos. Why is it necessary > to try to have consistency betwen the contents of the file and its name in > the file system, as opposed to letting the type and contents of a file speak > for itself regardless of the name in the file system? > BALAZS: We use the convention of RFC7950: to use the name of the top YANG > construct > in the filename (there the module name here the structure name). > In practice this convention proved very useful. (There already exist some > implementations of the YANG instance data). > A similar rule for YANG modules is enforced by many tools e.g., pyang and > confdc. This is just a COMMENT, so I don't specifically object, even if it seems surprising to me. >Metadata, information about the data set itself SHOULD be included in >the instance data set. Some metadata items are defined in the YANG >module "ietf-yang-instance-data", but other items MAY be used. > >Metadata MUST include: > > - Version of the YANG Instance Data format > > Doesn't the latter (MUST) effectively make the former (SHOULD) also into a > "MUST"? > BALAZS: Yes, I will change it to MUST. The format-version is a MUST either as > a default value > (not actually present according to YANG rules) or as an explicitly specified > value. > The other metadata items are only recommended (SHOULD). > > Also, if this is actually mandatory, shouldn't that be reflected in the YANG > module? > BALAZS: IN the YANG module leaf format-version has a default value. That > means that > either the default value or some explicitly set vale is always usable for
Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Hello Benjamin, Thank you for the thorough review. I used your comments to improve the draft. See my detailed answers below as BALAZS: Regards Balazs -Original Message- From: Benjamin Kaduk via Datatracker Sent: 2021. október 7., csütörtök 6:55 To: The IESG Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; kent+i...@watsen.net Subject: Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-yang-instance-file-format-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ -- COMMENT: -- Should we register media-types for the file formats being specified? Section 2 Two formats are specified based on the XML and JSON YANG encodings. Later, as other YANG encodings (e.g., CBOR) are defined, further instance data formats may be specified. I don't remember seeing a clear description of the specifics of these two specified formats. (I assume it's just "use the XML/JSON encoding for YANG structures", but I don't remember that stated anywhere.) BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the model starts with a YAN structure, I included YANG Data Structure Extensions RFC8791 too. The name of the instance data file SHOULD be of the form: instance-data-set-name ['@' ( revision-date / timestamp ) ] ( '.xml' / '.json' ) This looks (almost? Not sure about '@' vs. "@".) like valid ABNF. Do we want to say that and reference RFC 5234 for the interpretation of the symbols? BALAZS: reference to ABNF added. Changed to double quotes. If the leaf "name" is present in the instance data header, its value SHOULD be used for the "instance-data-set-name". If the "revision- date" is present in the filename it MUST conform to the format of the revision-date leaf in the YANG model. [...] This seems unenforcable, and contrary to the Unix ethos. Why is it necessary to try to have consistency betwen the contents of the file and its name in the file system, as opposed to letting the type and contents of a file speak for itself regardless of the name in the file system? BALAZS: We use the convention of RFC7950: to use the name of the top YANG construct in the filename (there the module name here the structure name). In practice this convention proved very useful. (There already exist some implementations of the YANG instance data). A similar rule for YANG modules is enforced by many tools e.g., pyang and confdc. Metadata, information about the data set itself SHOULD be included in the instance data set. Some metadata items are defined in the YANG module "ietf-yang-instance-data", but other items MAY be used. Metadata MUST include: - Version of the YANG Instance Data format Doesn't the latter (MUST) effectively make the former (SHOULD) also into a "MUST"? BALAZS: Yes, I will change it to MUST. The format-version is a MUST either as a default value (not actually present according to YANG rules) or as an explicitly specified value. The other metadata items are only recommended (SHOULD). Also, if this is actually mandatory, shouldn't that be reflected in the YANG module? BALAZS: IN the YANG module leaf format-version has a default value. That means that either the default value or some explicitly set vale is always usable for the user of the file. Added text to clarify this. Section 2.1.2 import-only dependencies MAY be excluded from the leaf-list. If they are excluded then the consumer of the instance data set has to apply the YANG language rules to resolve the imports. An example of the Do we want to say something like "Accordingly, recipients of the instance data set must be prepared to perform this processing, absent prior knowledge about the files they will be processing"? BALAZS: According to YANG rules the "implemented" module that is specified in the content schema MAY have used an Import-by-revision statement in which case the revision date of the imported module is fixed/specified in that YANG module. If import-by-revision was not used, any revision of the imported module is usable, which in practice for most tools means
Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Thanks, I will change it to double quotes. Regards Balazs -Original Message- From: Carsten Bormann Sent: 2021. október 7., csütörtök 7:37 To: Benjamin Kaduk Cc: The IESG ; netmod-cha...@ietf.org; draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) On 7. Oct 2021, at 06:54, Benjamin Kaduk via Datatracker wrote: > > instance-data-set-name ['@' ( revision-date / timestamp ) ] > ( '.xml' / '.json' ) > > This looks (almost? Not sure about '@' vs. "@".) like valid ABNF. Do > we want to say that and reference RFC 5234 for the interpretation of > the symbols? JFYI, single quotes are not used in ABNF. '.xml' / '.json’ …would need to be: %s”.xml” / %s”.json” …as per RFC 7405 to avoid accidentally allowing .XMl and .jsOn. (Please excuse the smartquotes.) Grüße, Carsten smime.p7s Description: S/MIME cryptographic signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
On 7. Oct 2021, at 06:54, Benjamin Kaduk via Datatracker wrote: > > instance-data-set-name ['@' ( revision-date / timestamp ) ] > ( '.xml' / '.json' ) > > This looks (almost? Not sure about '@' vs. "@".) like valid ABNF. Do > we want to say that and reference RFC 5234 for the interpretation of the > symbols? JFYI, single quotes are not used in ABNF. '.xml' / '.json’ …would need to be: %s”.xml” / %s”.json” …as per RFC 7405 to avoid accidentally allowing .XMl and .jsOn. (Please excuse the smartquotes.) Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-yang-instance-file-format-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ -- COMMENT: -- Should we register media-types for the file formats being specified? Section 2 Two formats are specified based on the XML and JSON YANG encodings. Later, as other YANG encodings (e.g., CBOR) are defined, further instance data formats may be specified. I don't remember seeing a clear description of the specifics of these two specified formats. (I assume it's just "use the XML/JSON encoding for YANG structures", but I don't remember that stated anywhere.) The name of the instance data file SHOULD be of the form: instance-data-set-name ['@' ( revision-date / timestamp ) ] ( '.xml' / '.json' ) This looks (almost? Not sure about '@' vs. "@".) like valid ABNF. Do we want to say that and reference RFC 5234 for the interpretation of the symbols? If the leaf "name" is present in the instance data header, its value SHOULD be used for the "instance-data-set-name". If the "revision- date" is present in the filename it MUST conform to the format of the revision-date leaf in the YANG model. [...] This seems unenforcable, and contrary to the Unix ethos. Why is it necessary to try to have consistency betwen the contents of the file and its name in the file system, as opposed to letting the type and contents of a file speak for itself regardless of the name in the file system? Metadata, information about the data set itself SHOULD be included in the instance data set. Some metadata items are defined in the YANG module "ietf-yang-instance-data", but other items MAY be used. Metadata MUST include: - Version of the YANG Instance Data format Doesn't the latter (MUST) effectively make the former (SHOULD) also into a "MUST"? Also, if this is actually mandatory, shouldn't that be reflected in the YANG module? Section 2.1.2 import-only dependencies MAY be excluded from the leaf-list. If they are excluded then the consumer of the instance data set has to apply the YANG language rules to resolve the imports. An example of the Do we want to say something like "Accordingly, recipients of the instance data set must be prepared to perform this processing, absent prior knowledge about the files they will be processing"? Section 2.2.1 i...@acme.com Unfortunately, acme.com is a real domain name; we should probably use a BCP 32 name. Likewise for urn:rdns:acme.com:oammodel:acme-system-ext, etc. Section 2.2.2 true deny deny Is there a that should be set as well? Or do we just implicitly rely on the default from RFC 8341? Section 3 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 ."; I think this requirement is currently stated in Section 2, not 3 (though in my previous comment I suggest that the requirement should be removed). Section 4 (I wrote, then deleted as duplicate, essentially all of the same things that Roman commented on. Thanks for updating in response to his comments.) The document does not specify any method to influence the behavior of a server. A few of the listed use cases seem to involve loading configuration into a server, which could perhaps be considered to influence the behavior of the server in question. The header part is not security sensitive with one possible exception. If the URI method is used for specification of the content schema and the URI includes a username and/or a password, the instance data file needs to be handled securely as mentioned below. In the terminology of RFC 3986 this is the "userinfo subcomponent", as in "the URI includes a userinfo subcomponent". NITS Section 2.2.1, 2.2.2 It's a bit challenging to get the of the file to be much older than the of the YANG modules it uses. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
