Re: Blog: YANG Really Takes Off in the Industry

[Dean Bogdanovic <[e-mail]>]

Phillip,

Thank you for bringing us back to the topic and a very good post.

So my original comment was that YANG as language that is being used for modeling.  Models can be done badly in any language, it doesn't matter which one. If Arista has a good model, the representation of that model shouldn't matter if it is in YANG or another language. Using YANG, it gives a more widely understanding then using a proprietary language.

Dean
On Dec 2, 2014, at 9:43 AM, Phillip Hallam-Baker <[e-mail]> wrote:

> Please, it is not a question of whether YANG is a good or a bad data
> model. Whether it is applicable to a problem depends on what that
> problem is.
> 
> There are two sorts of (useful) schema language for two different problems.
> 
> If your problem is modeling existing data formats then you need an
> expressive schema language that allows the irregularities and
> inconsistencies of the existing formats to be described. XML Schema is
> horribly complex because one of the constraints was that it should be
> a superset of SGML DTDs to allow automatic translation from DTDs to
> Schema.
> 
> I have schemas that describe DNS and RFC822 headers and the like and
> while they are fairly straightforward, they are not 'clean'. There are
> six different ways to encode headers in RFC822 style and DNS RRs are
> much more complicated.
> 
> So if you are trying to model IP headers or the like you are going to
> want an expressive language.
> 
> 
> If what you want to do is to define an application protocol that does
> not need to be backwards compatible with a legacy system then you want
> as little flexibility as possible. Because standards writing is taking
> decisions that don't matter out of the equation.
> 
> This is why ASN.1 is so unfit for purpose. Despite the claim to be
> 'abstract', the data model is full of design choices that only exist
> to micromanage the wire format. The distinction between sets and
> lists, implicit versus explicit tagging etc. etc.
> 
> At the end of the day, every message in an application protocol is
> going to map to an API call or return somewhere in the application
> implementation. We can make that mapping complicated or we can make it
> simple.
> 
> If we have a protocol TimeService with method for finding the time:
> 
> class TimeService {
>    public Status GetTime (out DateTime Now);
>    }
> 
> We can have a schema language that allows fifty different encodings
> for the DateTime object or we can pick one and stick to it. If we are
> using a JSON encoding which is text, we would probably map DateTime
> onto a string and use ISO 8601 or RFC 3339 to describe the encoding.
> 
> If we were dealing with legacy we might have to deal with other forms.
> But the best schema language for writing new apps would not provide
> that flexibility.
> 
> {GetTimeResult : {Now: "2014-01-02T13:10:00Z"}}
> 
> Now the reason I chose this particular example is that time is
> actually a case where encoding does matter because embedded devices
> might not know about the leap seconds which some idiots have managed
> to visit on us:
> 
> class TimeService {
>    public Status GetTime (out DateTime Now, out Int64? ElapsedSeconds);
>    }
> 
> Here we do have a schema issue since JSON integers can be of any size
> while using bignum arithmetic in an API has a severe impact on
> performance and convenience. And in this case we will have bigger
> problems long before the Int64 time rollover occurs.
> 
> Now since the C# syntax for a nullable type (Int64?) doesn't make the
> message signature obvious, I actually use my own private schema
> language:
> 
> Message GetTimeResult
>    DateTime Now
>        Required
>    Integer ElapsedSeconds
>        Bits 64
> 
> 
> YANG is a lot more powerful and flexible than my system. And that is
> why I would not use it for the type of applications I work on. I do
> not want to have the option of encoding the data in more than one way
> because in a new application that is 'bikeshedding'.
> 
> If your problem is dealing with legacy systems and requires modeling
> of statefull interactions then you need that flexibility.
> 
> 
> In summary, there is a place for YANG but it is certainly not the only
> schema language that is useful. There is also a place for XML Schema
> but that place is not describing Web Service protocols. There is also
> a place for simpler schema formats that allow a direct mapping of API
> calls to messages. And there are some schema languages that should
> never be used at all.