On Thu, 2017-11-16 at 21:55 -0500, Joe Clarke wrote: > On 11/15/17 05:38, Ladislav Lhotka wrote: > > On Wed, 2017-11-15 at 05:27 -0500, Joe Clarke wrote: > > > On 11/15/17 05:06, Ladislav Lhotka wrote: > > > > > I suppose my gut reaction to Lou's question as to whether a server > > > > > should support multiple versions was, "no." A client may have > > > > > multiple > > > > > versions loaded to support servers that support different versions. I > > > > > may be convinced otherwise, but I feel that this will become untenable > > > > > over time (even if module names change). > > > > > > > > There are use cases for modules that are imported (i.e. not > > > > implemented): it could be that a module author wants to use some > > > > definitions from an old version of an imported module while, at the same > > > > time, other definitions from a new version. > > > > > > > > The semver-aware "import" statement should be able to deal with this. > > > > > > I think it could be, but I also think importing from different versions > > > of the same module feels messy. How would this work with different > > > module names today? Just use different prefixes? Are there defined use > > > cases for this in the wild today? > > > > Let's say a new version of a module adds new enums to two different > > enumeration > > types, but an implementor (for some reason) is only able to update one of > > them > > in the back-end and not the other. > > I read implementor to be "vendor" here. And if a vendor cannot
Instead of "implementor" I should have said "module author" - it could be a vendor or IETF WG or whatever. A realistic example might be a module for certain IANA parameters such as https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml If IANA updates this registry, the author of a module that uses it might want to update some enumerations while keeping others in the old version. The reason for doing so may be, for example, that some cipher has to be removed for security reasons, but migrating completely to the new registry version is a long shot that needs more time. > implement one of the enums, would they not just add a deviation? I Vendors generally don't like to declare deviations, and I think it would be really weird if an IETF standard track module contained a deviation. Lada > don't see why they'd have to keep the old module around for this. > > Joe -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
