On Tue, Jul 6, 2021 at 8:14 AM Rob Wilton (rwilton) <[email protected]> wrote:
> Hi Balazs, > > To follow up with our conversation earlier. Andy and Juergen explicitly > copied because they may have previously commented on these issues during WG > LC. > > I think that my comment regarding the "feature statement" and the > flexibility of the inline-method are closely related. I find the > definition of the inline-content-schema to be so generic that it > effectively allows anything. E.g., the drafts would allow me to publish a > file that has an inline-content-schema based on > [email protected], and it would be very difficult for > consumers of the associated instance data file to understand the file > schema. > > Similarly, I find that allowing revision labels (as examples to avoid a > normative reference to the module versioning draft), makes it hard for a > generic implementation reader of a instance data file to know how to > interpret an inline schema. I suspect that this issue could cause problems > in the IESG reviews. > > Hence, my preference, for this RFC, that defines version 1 of the instance > file format, would be to more heavily constrain how the schema is allowed > to be specified in the inline-method. Specifically, I think that it would > be better to: > - restrict the inline schema to only be defined using > ietf-yang-library@2019-01-04 > - only allow revision-dates, not revision labels. > > I would like to understand from Andy, whether he still thinks with these > restrictions whether the inline-schema method should still be under a YANG > feature statement? > I do not remember asking for this feature statement. Who is the client and who is the server, for a YANG instance file, sitting on a hard drive? IMO the 4 separate ways to identify the schema are 3 too many, but that is what the WG wants. It seems obvious that any reader of the file has to implement all 4 methods and any writer of the file is free to pick just one. So the feature does not really help. Andy > If/when the revision labels draft gets standardized, and perhaps also > after YANG packages, then we could do a bis version of this document to > define a v2 of the instance file format that potentially allows YANG > packages to be used to define the schema, and potentially allows modules to > be identified using revision labels as well as revision dates. > > Balazs, I'm good with most of your proposed resolutions, but have answered > one further question inline below. > > > > -----Original Message----- > > From: Balázs Lengyel <[email protected]> > > Sent: 05 July 2021 13:47 > > To: '[email protected]' <[email protected]>; Rob Wilton (rwilton) > > <[email protected]> > > Cc: Benoit Claise <[email protected]> > > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hello Rob, > > Thanks for the review. Here are my answers below. I will also upload the > > new version asap. > > Regards Balazs > > ----------------------------------------------------------- > > Hi, > > > > Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. > > > > Thanks for this document, I think that it represents important useful > work > > for advancing the YANG ecosystem. > > > > This document is in good shape, and I mostly have minor comments but with > > a > > few more significant comments. > > > > Main comments: > > > > > > > 2. > > In the YANG Module: > > feature inline-content-schema { > > description > > "This feature indicates that inline content-schema > > option is supported. Support for this feature might > > be documented only via out-of-band documentation."; > > } > > > > What is the benefit of having 'inline-content-schema' as a feature? It > > seems to potentially add complexity without any benefit, given that the > > device originating the instance data file would effectively choose > whether > > to use the inline-content-schema, hence I suggest that it might be > simpler > > just to remove the feature definition. > > BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). > > The system can declare supported/not-supported in design documentation. > > In a use-case when a client or a design department is sending data to a > > server this is needed. E.g. in UC2, Preloading Default Configuration the > > designer preparing instance data, can decide to use or not use the > > inline-content-schema based on this. > > > > > > 3. > > In the YANG Module: > > > > "case inline", description: > > The first item is either ietf-yang-library or > > some other YANG module that contains a list of > > YANG modules with their name, revision-date, > > supported-features, and deviations. > > The usage of revision '2019-01-04' of the > > 'ietf-yang-library' module MUST be supported. > > Using other modules, module versions MAY also > > be supported. > > > > This seems to make interop for consumers of instance data files hard, > since > > the schema can be defined by any arbitrary YANG module without updating > > this > > module. I would suggest that it is safer to limit this to the two > currently > > published versions of YANG library. > > BALAZS: I fully agree, however this was explicitly requested by some > > reviewer earlier (Juergen ?) Shall I simplify this or not? > > > > If additional modules are supported in future, then I think that it > would be > > safer to create a new version of this YANG module that documents what > > other > > module formats can be used. > > > > > > 4. > > In the YANG Module: > > list "revision" > > > > Is revision expected to be unique, if provided? If so, should this be > > explicitly stated in the YANG module description? > > BALAZS: I don't think I understand your comment. There may be multiple > list > > entries for revision. The 'leaf date' is a key, so it is inherently > unique. > > The description may or may not be unique. > > I would suggest changing: > > For every published editorial change, a new one SHOULD be added > in front of the revisions sequence so that all > > to: > > For every published editorial change, a new unique revision SHOULD > be added in front of the revisions sequence so that all > > I.e., to also make it clear in the description that revisions dates are > required to be unique. > > > > > > > > 5. > > In the YANG Module: > > > > Is an instance-data file allowed to contain both a revision and also a > > timestamp? If so, is there any constraints on the values. If not, then > > would it make sense to put them under a choice? > > BALAZS: It is allowed to have both. There is some recommendation text > > about > > when to use each. However I can see some corner cases, when using both in > > the same file would be useful, E.g. we want a timestamp including hour, > > minutes, but we also want the history of the instance data set, including > > multible revision/descriptions. > > I propose to add: if both are included the timestamp, SHOULD contain > > the same date as the latest revision statement. > > Okay. > > Thanks, > Rob > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
