Re: [netmod] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Thanks for your reply. Sounds good. Thanks, —John > On Oct 7, 2021, at 10:29 AM, Balázs Lengyel > wrote: > > Hello John, > Thank you for the review. I used your comments to improve the draft. See my > detailed answers below as BALAZS: > Regards Balazs > > -Original Message- > From: netmod On Behalf Of John Scudder via > Datatracker > Sent: 2021. október 7., csütörtök 15:39 > To: The IESG > Cc: netmod-cha...@ietf.org; > draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org > Subject: [netmod] John Scudder's No Objection on > draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) > > John Scudder 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 your work on this spec. Thanks also to Kent Watsen for his hard > work shepherding it. > > I have some comments below which I hope may be helpful. > > 1. Section 1, nit, s/In Appendix C describes/Appendix C describes/ (delete > the > "in") > BALAZS: OK, will be updated > > 2. Section 1.4: > > A YANG instance data set is created at a specific point of time. If > the data changes afterwards, this is not represented in the instance > data set anymore. The current values may be retrieved at run-time > > I think "anymore" should be cut, for several reasons, the most important of > which is that it seems to be objectively wrong. The cut would be the minimal > fix, but did you mean something more like this? "If the data changes > afterwards, the instance data will no longer represent the current data, > unless it is updated." > BALAZS: OK, will be updated with the additional text. > > 3. Section 2, nit, s/constrains MAY be violated/constraints MAY be violated/ > BALAZS: OK, will be updated > > 4. Section 2.1: I was amazed that the "external method" option, which is > essentially the "simply don't bother" option, was acceptable to the WG and > other reviewers. To my eye, the URI method option seems functionally just as > good (it keeps the content of the file itself small) while providing a > stronger (though still not very strong) assurance that the schema will > actually be available. > Was "external method" discussed in the WG? Or am I simply in the rough > for even thinking it surprising? > BALAZS: 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. > > 5. Appendix C: I'm inclined to agree with the shepherd's recommendation to > remove this entire section > (https://mailarchive.ietf.org/arch/msg/netmod/5DfEi8swOmLEPykBpFICJK6398s/) > since readability is problematic and it doesn't seem to add to the usability > of the spec. Since it is, as it says, only a non-normative appendix I don't > insist, but I strongly encourage you to consider trimming or rewriting it. > BALAZS: We will consider it. Some editorial updates, trimming done. > > > ___ > 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] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
Hello John, Thank you for the review. I used your comments to improve the draft. See my detailed answers below as BALAZS: Regards Balazs -Original Message- From: netmod On Behalf Of John Scudder via Datatracker Sent: 2021. október 7., csütörtök 15:39 To: The IESG Cc: netmod-cha...@ietf.org; draft-ietf-netmod-yang-instance-file-for...@ietf.org; netmod@ietf.org Subject: [netmod] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT) John Scudder 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 your work on this spec. Thanks also to Kent Watsen for his hard work shepherding it. I have some comments below which I hope may be helpful. 1. Section 1, nit, s/In Appendix C describes/Appendix C describes/ (delete the "in") BALAZS: OK, will be updated 2. Section 1.4: A YANG instance data set is created at a specific point of time. If the data changes afterwards, this is not represented in the instance data set anymore. The current values may be retrieved at run-time I think "anymore" should be cut, for several reasons, the most important of which is that it seems to be objectively wrong. The cut would be the minimal fix, but did you mean something more like this? "If the data changes afterwards, the instance data will no longer represent the current data, unless it is updated." BALAZS: OK, will be updated with the additional text. 3. Section 2, nit, s/constrains MAY be violated/constraints MAY be violated/ BALAZS: OK, will be updated 4. Section 2.1: I was amazed that the "external method" option, which is essentially the "simply don't bother" option, was acceptable to the WG and other reviewers. To my eye, the URI method option seems functionally just as good (it keeps the content of the file itself small) while providing a stronger (though still not very strong) assurance that the schema will actually be available. Was "external method" discussed in the WG? Or am I simply in the rough for even thinking it surprising? BALAZS: 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. 5. Appendix C: I'm inclined to agree with the shepherd's recommendation to remove this entire section (https://mailarchive.ietf.org/arch/msg/netmod/5DfEi8swOmLEPykBpFICJK6398s/) since readability is problematic and it doesn't seem to add to the usability of the spec. Since it is, as it says, only a non-normative appendix I don't insist, but I strongly encourage you to consider trimming or rewriting it. BALAZS: We will consider it. Some editorial updates, trimming done. ___ 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] John Scudder's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
John Scudder 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 your work on this spec. Thanks also to Kent Watsen for his hard work shepherding it. I have some comments below which I hope may be helpful. 1. Section 1, nit, s/In Appendix C describes/Appendix C describes/ (delete the "in") 2. Section 1.4: A YANG instance data set is created at a specific point of time. If the data changes afterwards, this is not represented in the instance data set anymore. The current values may be retrieved at run-time I think "anymore" should be cut, for several reasons, the most important of which is that it seems to be objectively wrong. The cut would be the minimal fix, but did you mean something more like this? "If the data changes afterwards, the instance data will no longer represent the current data, unless it is updated." 3. Section 2, nit, s/constrains MAY be violated/constraints MAY be violated/ 4. Section 2.1: I was amazed that the "external method" option, which is essentially the "simply don't bother" option, was acceptable to the WG and other reviewers. To my eye, the URI method option seems functionally just as good (it keeps the content of the file itself small) while providing a stronger (though still not very strong) assurance that the schema will actually be available. Was "external method" discussed in the WG? Or am I simply in the rough for even thinking it surprising? 5. Appendix C: I'm inclined to agree with the shepherd's recommendation to remove this entire section (https://mailarchive.ietf.org/arch/msg/netmod/5DfEi8swOmLEPykBpFICJK6398s/) since readability is problematic and it doesn't seem to add to the usability of the spec. Since it is, as it says, only a non-normative appendix I don't insist, but I strongly encourage you to consider trimming or rewriting it. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
