Hello Zahed, Thanks for the comments. I will update with the new text. Regards Balazs
-----Original Message----- From: Zaheduzzaman Sarker <[email protected]> Sent: 2021. október 6., szerda 17:43 To: Balázs Lengyel <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) On 2021-10-06, 17:32, "Balázs Lengyel" <[email protected]> wrote: Hello Zahed, Please see answers below as BALAZS2. Regards Balazs -----Original Message----- From: Zaheduzzaman Sarker <[email protected]> Sent: 2021. október 6., szerda 16:00 To: Balázs Lengyel <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) On 2021-10-06, 10:53, "Balázs Lengyel" <[email protected]> wrote: Hello Zaheduzzaman, Thank you for the review. See detailed replies as "BALAZS:" below. Regards Balazs -----Original Message----- From: netmod <[email protected]> On Behalf Of Zaheduzzaman Sarker via Datatracker Sent: 2021. október 6., szerda 8:02 To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: [netmod] Zaheduzzaman Sarker's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) Zaheduzzaman Sarker 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: ---------------------------------------------------------------------- Thanks for the efforts on this document. I have following comments, by addressing them I believe will improve the document quality - Section 2.1 : Should it not say if the "content-schema" node exists then one of the methods MUST be used? as I see the specification of content schema is a SHOULD, hence may not be included for whatever reason. BALAZS: In accordance with your comment the SHOULD will be changed to MUST. However, that still allows " External Method: Do not include the "content-schema" node;" People stated that when instance files are used repeatedly (a new file generated every few seconds) in a closed, well defined environment, the content-schema may already be known. In this case it is not necessary to include it in the file. I don't think we are on the same page here. I am basically saying in the context of this specification's section 2, the addition of content-schema is a SHOULD, hence one implementation can actually skip it. But then in 2.1, as the text describes the assumption seems to be the content-schema is always present (like a MUST). I am not asking to change the SHOULD to MUST in section 2, but to acknowledge the fact that section 2.1 is only applicable when there is "content-schema". BALAZS2: I see your point. I am trying to find the correct wording/documentation for it. Today Section 2.1 in -20 includes: One of the following methods MUST be used: Inline method: ... Simplified-Inline method: .... URI method: ... External Method: Do not include the "content-schema" node; the user needs to obtain the information through external documents. My idea was that the External method indicates that the content-schema might NOT be present in the instance-date-set. If you think that's not clear, I could reword it to: To properly understand and use an instance data set, the user needs to know the content-schema. The content schema can be either specified in external documents or within the instance data set. In the latter case one of the following methods MUST be used: Inline method: Include the needed information as part of the instance data set. Simplified-Inline method: Include the needed information as part of the instance data set; short specification, only the module name and revision-date is used. URI method: Include a URI that references another YANG instance data file. This instance data file will use the same content- schema as the referenced YANG instance data file. (if you don't want to repeat the info again and again) Please decide which is better! The new version is much better to express the intention you have. Thanks for the updates and addressing my comment. ----------------------------------------------------------------------------------------------- - Section 4 : it says Instance data files may contain sensitive data. OK, but what should be taken into consideration when putting the sensitive data in the data file. It feels like there should be more information provided to the user of the specification for actually materialize the statement made here. BALAZS: Instance data files may be used in many different use-cases. Whether the data within is sensitive is completely dependent on the content schema applicable to the use-case. The draft contains: " The security sensitivity of the instance data in the content part is completely dependent on the content schema." Any suggestions about what else we could say? In that case, if you think there is enough explanations, I will suggest to simply drop then one line (--Instance data files may contain sensitive data.) or make the one line part of the text you are referring to. BALAZS2: OK, I will merge it into the paragraph referenced. Thanks. BR Zahed
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
