Ted,
On Dec 1, 2014, at 9:06 PM, Dean Bogdanovic <deanb@xxxxxxxxxxx> wrote:
This is not the answer to my question.
It's certainly an answer to your question.
I asked about adding support for another language, not how the models are architected. Vendors can (and, in my personal opinion, will) provide proprietary and standard data models. The operator can choose then which model they want to use for their purposes.
If the YANG data model is architected badly, then the vendor may not be _able_ to support that data model, and then the operator won't be able to choose that model. If a vendor's experience of data models written in that language is that they aren't good enough, then the vendor might well decide that there's no value in supporting the language.
That said, one of the issues with YANG that has been reported back to me, but with which I do yet have specific experience of my own, is that the language is not sufficiently expressive. E.g., it was not thought possible to express DHCP option extensions in YANG. This would mean that certain basic functions of a DHCP server could not be supported without a non-YANG management model.
Can you please follow up on this claim that YANG is not sufficiently
expressive. I would like to understand if there is a (YANG) problem to
be solved.
Regards, Benoit