Hi,
IMO there are some details in semver-17 that are not clear.
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.
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?
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.
It could be more clear where the different forms can be used and how
the 2 extensions work together.
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
Andy
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
