Ted,
On Dec 1, 2014, at 9:06 PM, Dean Bogdanovic <deanb(_at_)juniper(_dot_)net>
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