Subject: [netmod] Problem in draft-ietf-netmod-smi-yang-04

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Apr 2012 16:13:33 +0200 (CEST)

Hi,

I just discovered a problem with draft-ietf-netmod-smi-yang-04.  I
believe this document has been sent to the IESG.

The document specifies how to translate an OCTET STRING w/
DISPLAY-HINT to a YANG 'string'.  But look at this example:

InetAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d"
    STATUS       current
    DESCRIPTION
        "Represents an IPv4 network address:

           Octets   Contents         Encoding
            1-4     IPv4 address     network-byte order

         The corresponding InetAddressType value is ipv4(1).

         This textual convention SHOULD NOT be used directly in object
         definitions, as it restricts addresses to a specific format.
         However, if it is used, it MAY be used either on its own or in
         conjunction with InetAddressType, as a pair."
    SYNTAX       OCTET STRING (SIZE (4))

becomes:

  typedef InetAddressIPv4 {
    type string {
      length "4";
      ...
    }
    ...
  }

But the length of an ipv4 address is not 4 characters!!

Conclusion: if the type is octet string, and it has a display-hint, we
must not translate the length restriction to yang.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Apr 2012 16:32:43 +0200

> believe this document has been sent to the IESG.

[...]
 
> must not translate the length restriction to yang.

I agree that this needs clarification. However, I like to see text
that says in some wording (to be determined) "must not translate to
incorrect length restrictions". For certain frequently occuring
display hint / size restriction patterns, e.g.

    DISPLAY-HINT "255a"
    ...
    SYNTAX       OCTET STRING (SIZE (0..255))

a valid length statement can easily be generated. There are cases that
require a bit more thinking to derive valid lower and upper bounds. I
think we should not forbit implementations to be smart here, just not
require it.

/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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Apr 2012 16:38:49 +0200 (CEST)

> think we should not forbit implementations to be smart here, just not

This is fine with me.

/martin