Thanks for the review, Andy. Replies below.
1) recommended-min-version
If specified multiple times, then any module revision that
satisfies at least one of the 'recommended-min-version'
statements is an acceptable recommended version for
import.
I do not see how this OR expression would cause a lower semver
to not match, and therefore not overlap a higher semver,
according to rules in 5.2 and repeated again in the YANG extension,
e.g.
ys:recommended-min-version 1.3.0;
ys:recommended-min-version 3.1.0;
The lowest Semver will always match so I do not see the point of
multiple extensions. Please add an example in the draft showing
how this is used.
[JMC] In this case, yes. Version 1.3.0 would assume 3.1.0. In fact, the most
common case will be one recommended-min-version. However, considering the
rules in Section 5.2, the additional modifiers might necessitate multiple
recommend-min-version statements. As an example, you might need this:
ys:recommended-min-version 1.3.3_non_compatible;
ys:recommended-min-version 3.0.0;
In this case, you can use either 1.3.3_non_compatible or anything 3.0.0 or
higher. This example can be added to the draft.
2) usage of full semver vs. X.Y.Z vs. X.Y.Z[compat]
Where are the 3 different forms of the same server used?
- full: just in the 'version' extension or filename as well?
[JMC] The full version would be used in the extension and in the file name.
If the I-D names are used like in Appendix A
1.0.0-draft-ietf-netmod-example-module-00
|
1.0.0-draft-ietf-netmod-example-module-01
|
1.0.0-draft-ietf-netmod-example-module-02
ΒΆ<https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-17.html#appendix-A-6>
the recommended-min-version string "1.0.0" will match all these versions.
[JMC] Correct. But you could be more specific if you wanted.
It could be more clear where the different forms can be used and how
the 2 extensions work together.
[JMC] The version is always the full form, but you can use a YANG Semver
without modifiers in the recommended-min-ver extension. We can state this more
clearly.
3) Semver length
A YANG 1.1 revision date has a fixed length.
There is no semver text like YANG sec 6.2 for YANG identifiers
https://datatracker.ietf.org/doc/html/rfc7950#section-6.2
Should every implementation be forced to accept a 1 billion byte semver?
IMO, a similar rule is needed for Semver
- MUST support up to 256 chars and MAY support larger
[JMC] Thanks for the suggestion. That seems reasonable.
Joe
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
