Subject: Re: [netmod] review of yang-types

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Feb 2010 14:36:16 +0100

On Thu, Jan 21, 2010 at 06:16:13PM +0100, Ladislav Lhotka wrote:
 
> I reviewed the document, especially concentrating on the regular
> expressions. My comments:
> 
> 1. In several cases, the expressions use superfluous parentheses which
> make the expressions longer and less comprehensible. I think they should
> be removed. For example:
> OLD
>    typedef object-identifier {
>      type string {
>        pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
>              + '(\.(0|([1-9]\d*)))*';
>      }
> NEW
>    typedef object-identifier { 
> type string {
>        pattern '([01]\.[1-3]?[0-9]|2\.(0|[1-9]\d*))(\.(0|[1-9]\d*))*';
>      }

Too few parenthesese can hurt readability since the reader needs to
remember precedences well to understand an expression.  I included
some superfluous parentheses in an attempt to make the idea behind the
expression more clear. But I understand that this is debatable.

> 2. In the pattern for object-identifier-128, the dot should be escaped:
> OLD
>    typedef object-identifier-128 {
>      type object-identifier {
>        pattern '\d*(.\d*){1,127}';
>      }
> NEW
>    typedef object-identifier-128 {
>      type object-identifier {
>        pattern '\d*(\.\d*){1,127}';
>      }

fixed
 
> 3. Another minor simplification (the sign for timezone):
> OLD
>    typedef date-and-time {
>      type string {
>        pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
>              + '(Z|(\+|-)\d{2}:\d{2})';
>      }
> NEW
>    typedef date-and-time { 
> type string {
>        pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
>              + '(Z|[\-+]\d{2}:\d{2})';
>      }
> 
> (This pattern is rather lax, but I guess it is intentional.)

changed - saves a character :-)

> 4. phys-address - is it correct that it is allowed to be empty?

This is what the corresponding SMIv2 type allows and it is easy to
exclude zero length addresses when the type is used as needed.

> 5. The pattern for ipv4-address doesn't allow leading zeros in any of
> the four octets, for example, this doesn't match: 127.000.000.001.

Yes, I think this is by intention.

> Moreover, the pattern is unnecessarily complicated. I propose to use the
> same pattern as is used later for ipv4-prefix:
> OLD
>    typedef ipv4-address {
>      type string {
>        pattern '((0'
>              +   '|(1[0-9]{0,2})'
>              +   '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))'
>              +   '|([3-9][0-9]?)'
>              +  ')'
>              + '\.){3}'
>              + '(0'
>              +  '|(1[0-9]{0,2})'
>              +  '|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))'
>              +  '|([3-9][0-9]?)'
>              + ')(%[\p{N}\p{L}]+)?';
>      }
> NEW
>    typedef ipv4-address { 
> type string {
>        pattern '((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])'
> 	    + '(%[\p{N}\p{L}]+)?';
>      }

I agree. For consistency with the ipv4-prefix pattern, I will use:

    type string {
      pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
            + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
            + '(%[\p{N}\p{L}]+)?';
    }
 
> 6. An isolated dot "." matches the pattern for domain-name. I understand
> it is used e.g. in DNS zone files, but IMO it is the same case as the
> zero value for port-number and should be handled via a union where
> appropriate.

We got DNS expert advice for this TC and we were told that allowing
. to match the root is a feature. Concerning port-number, I meanwhile
believe not allowing 0 is a bad idea. Not only does this make
port-number different from InetPortNumber (means the current statement
that they are similar is wrong), it also makes using the type more
difficult. It is easy to exclude values, adding a zero via a union
however is a relatively complex procedure. If we need a
nonzero-port-number type, we could easily derive it from port-number
(like we can easily derive a nonroot-domain-name from domain-name).
I will change the definition of port-number.
 
> 7. In the descriptions of gauge32 and gauge64:
>    s/can not/cannot/

fixed

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>