Thanks for your reply. Sounds good. Thanks,
—John > On Oct 7, 2021, at 10:29 AM, Balázs Lengyel <[email protected]> > 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 <[email protected]> On Behalf Of John Scudder via > Datatracker > Sent: 2021. október 7., csütörtök 15:39 > To: The IESG <[email protected]> > Cc: [email protected]; > [email protected]; [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
