Hi - On 10/19/2017 2:18 PM, Adrian Farrel wrote:
You make a good point Randy, but I wonder where it takes us. As you note, it has always been the case that people could make implementations that claim to be conformant to a spec, but which are not. Whether the divergences are deliberate (to make vendor-specific variants, or to fix specification bugs) or accidental (implementation bugs) doesn't change the fact. The same is true of whether the variance is done in good or bad faith. We cannot (even using Warren's Internet Police badge) stop any of that from happening.
Full agreement.
What we can do is keep our specification heritage clean.
Also agree, but this is what leads me to a slightly different conclusion, to wit that the YANG rules for revising modules should be followed if the module name is retained, rather than simply re-using the module name as though the broken version had never been published. TLDR: If keeping the module name the same is so important, then we should follow the rules for updating modules.
That means that if an implementation is truly conformant to the specification it claims to conform to, then there must be no "on the wire" confusion with an implementation that is truly conformant to another of our specifications. That argument would go your way if it was possible to have a functional implementation of 8049. But sadly it isn't. Any implementation claiming conformance with 8049 (whether in good faith or not) is not actually conformant.
... The rules for revision of modules are a matter of *schema* configuration management sanity, and maintaining a potentially usable schema doesn't depend on whether a specific subset of the schema has been implemented in the wild, but it *does* depend on the rules for updating modules being followed. (The same problem would appear if we re-used a standards-track MIB module name, ignoring the SMI update rules, even if the previous version had never been implemented.) This case sets a really bad precedent. Randy