> I believe this was a deliberate decision. The info about module versions is
> available elsewhere (in the module proper and/or in YANG library data), so I
> don't see any necessity of having it in the namespace.
Yes, but I wonder if it assumed the update rules in Section 11. Thinking out
loud, even if NBC changes are supported, a server can only implement one
revision of a module at a time, which seems unambiguous.
That said, I recall some hoping a server could support more than one revision
at a time, to support graceful upgrades. But if we ever get to that, it could
be that the client selects the version in the RPC, so the RPC-reply wouldn’t
have to be versioned.
> Can you (or somebody) provide details why "backward compatibility becomes a
> nightmare”?
I asked, but after providing an answer, the response was just “that makes
sense, thanks”, leaving me to wonder. It may be because there exists some
namespaces with version numbers, and so they thought a discrepancy had been
found. For instance:
- urn:ietf:params:xml:ns:netconf:base:1.0
- urn:ietf:params:xml:ns:yang:1
> Speaking practically, the namespace identifier in JSON representation is just
> the module name, so adding versions to namespaces would cause troubles.
Indeed.
> Lada
K.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
