Re: Blog: YANG Really Takes Off in the Industry

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 9, 2014 at 12:00 PM, Tim Wicinski <[e-mail]> wrote:

>
>
> On 12/9/14 9:54 AM, Ted Lemon wrote:
>
>> On Dec 9, 2014, at 9:31 AM, t.p. <[e-mail]> wrote:
>>
>>> The expression that controls the permissible format of IPv6 addresses in
>>> yang-types is of this ilk.
>>> "       type string {
>>>          pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
>>>                + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
>>>                + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
>>>                + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
>>>                + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
>>>          pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
>>>                + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
>>>                + '(/.+)'; "
>>> which was got wrong several times before it became what it is now (which
>>> rings alarm bells for me).
>>>
>>
>> Wow, so there's no way to do this ABNF-style?
>> This is certainly something to be concerned about.   A syntax that is
>> difficult to internalize without working on it full-time is not a good
>> idea.   OTOH, it's hard to have a syntax that is not at least _somewhat_
>> difficult to internalize if you aren't working on it full time, so to some
>> extent this is a matter of degree.
>>
>>
> I would concur that is something that the everyday yang user should never
> have to do on a regular basis.  If we do, then we need to fix this.  I
> believe this is why libraries were invented.


I disagree.

Any tool capable of describing IPv6 should ONLY be used for describing
structures at the packet layer. That is the only layer where bit twiddling
to save a few bytes on the wire is acceptable.

When I design a tool, my objective is to narrow the gap between the
abstract formalism used to describe the specification and the concrete
specification. The above syntax does not look like this is a tool that is
of the slightest use to me because I don't think it reduces the likelihood
of error. I am just as likely to get the specification wrong as the code.

This is why I became disillusioned with formal methods back in the day.


Trying to use one tool for bit twiddling and for application work is a
disaster. The point of a specification is to take away flexibility that
does not matter. YANG is a general purpose tool that lets anything be
specified. I want greater constraints.