Implementing 3.2 will be very costly. IMHO Ericsson will not
implement it. We will do our utmost to avoid NBC changes, but if
they do happen, I don't believe we would support multiple
versions.
If the data models are sufficiently NBC e.g. changing a boolean
to an integer 3.2 may not even be possible. The underlying data
that drives the device may be an integer or a boolean, but not
both. (Strange mapping may be possible to imagine, but they will
not always work.)
regards Balazs
On 2018. 10. 27. 1:15, Robert Wilton
wrote:
On 26/10/2018 17:35, Andy Bierman
wrote:
OK.
For 3.1, I think that just means that the solution has to be
backwards compatible with existing clients (e.g. don't change the
protocols in a non backwards compatible way).
Completely agree that it will be hard. I envisage that it will
optional for servers to implement this.
The way that I think of one solution for this problem is using
datastore schema (as per the NMDA definition):
Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X.
For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y.
When a client connects it chooses which schema it wants to use, X,
Y, or latest. If it doesn't specify then perhaps it uses the
earliest schema (to handle requirement 3.1).
If the client wants to use X, then the server has to translate the
request into the equivalent request using schema Y instead.
Perhaps the server has to validate the config both in the context
of X and Y.
If the clients wants to use Y then it just talks to the server
normally, i.e. as it does today.
I think that this is logically the equivalent model mapping that
clients would have to do to support multiple server revisions.
Yes, I think that it is complex. No, I'm not sure how many
vendors will decide to implement this, but I think that it is OK
to require the solution to specify how this is done, so that
servers that do want to support this, and clients that want to use
this, can do so.
But all the QNames, validations, etc, I think would be constrained
to a particular schema.
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
|
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod