Hello Rob, I would be happy to simplify the draft. Just we are restarting debates which were settled earlier. This can lead to a never-ending cycle.
So, I propose to:
- remove all mention of the revision-label
- remove the feature
- for the inline method allow just ietf-yang-library@2019-01-04 as a
_single_ file. This also means that I should remove the leaf inline-module
as there is no need for it anymore. We know the single YANG module it would
define.
Is that acceptable?
Regards Balazs
P.S. The feature was possible to use.
It could be read from " out-of-band documentation" As indicated in the YANG
module. For some use-cases (E.g. Use Case 2: Preloading Data) when the
operator/designer is sending data to the server (not receiving it), it is
useful to know whether the inline method is supported or not.
In case the file comes from the server the feature is less useful.
-----Original Message-----
From: Rob Wilton (rwilton) <rwil...@cisco.com>
Sent: 2021. július 6., kedd 17:15
To: Balázs Lengyel <balazs.leng...@ericsson.com>; 'netmod@ietf.org'
<netmod@ietf.org>; a...@yumaworks.com; Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de>
Cc: Benoit Claise <benoit.cla...@huawei.com>
Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
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 robs-random-schema-format@1.0.0, 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?
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 <balazs.leng...@ericsson.com>
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org' <netmod@ietf.org>; Rob Wilton (rwilton)
> <rwil...@cisco.com>
> Cc: Benoit Claise <benoit.cla...@huawei.com>
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
