Subject: [netmod] yang types open issues summary

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Mar 2009 22:49:16 +0100

Hi,

below is the open issues list of <draft-ietf-netmod-yang-types-02.txt>.
Some of them require to get the right subject matter expert involved
to review definitions. Others require help of the WG. Please take a
look and see whether you can help (and if so, please start a new
thread on this list).

/js

* xpath typedef (ietf-yang-types)

  Q: Shall the name of this typedef be changed to xpath1 or xpath1-0
     to accomodate definitions of other xpath versions in the future?

  Q: What is the canonical format of an xpath expression?

* IPv6 address pattern (ietf-inet-types)

  Q: We need a "reasonable" pattern for IPv6 addresses. It seems the
     AND connection of multiple pattern does not help too much
     here. Do we really have to use a very verbose pattern like the
     one used in pyang?

* IPv6 address prefix pattern (ietf-inet-types)

  Q: Do we have support all IPv6 address writing styles or can be go
     ahead with say just the canonical IPv6 address format?

* DNS restrictions on labels (ietf-inet-types)

  C: DNS expert advice is needed so that we get the restrictions on
     DNS labels right and future proof.

* URI regex from RFC 3986 (ietf-inet-types)

  C: URI expert advice is needed to answer the question whether it is
     safe to use the URI regular expression found in Appendix B of RFC
     3986.

* ieee portlist (ietf-ieee-types)

  Q: It was suggested to add a port-list typedef but no concrete
     suggestion has been made how it could look like.

  C: One option is to represent port lists as a comma seperated list
     of port ranges where a port range is either a port number or a
     port number followed by a hyphen and a port number, e.g.

        1-5,8,10-22

     Ranges may not overlap and they may not be consecutive and they
     must be in ascending order to achieve a canonic representation.

* other vlan related types (ietf-ieee-types)

  Q: It was suggested to add more VLAN related types but no concrete
     suggestions have been made so far.

  C: Poll for concrete suggestions until <DEADLINE> and drop this if
     no concrete suggestions are being made.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 20 Mar 2009 16:24:55 +0100

>      here. Do we really have to use a very verbose pattern like the

The one used in pyang comes from RFC 3986 and doesn't use AND. I have
expressions that are considerably simpler, hopefully correct and utilize
multiple ANDed paterns. I will try to enhance them to take into account
the special formats with embedded IPv4 and we'll see whether it could be
more acceptable.

Another option is to define IPv4 and IPv6 addresses as built-in types.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Mar 2009 17:07:23 +0100

> Another option is to define IPv4 and IPv6 addresses as built-in types.

Nope. Adressing formats come and go (well, they never go). The other
option is IMHO to be happy with a regular expression that does not
attempt to catch all corner cases. There is still a description clause
- which is as good as the text in the Yang specification defining
buit-in types.

/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: Ladislav Lhotka <[email-masked]>
Date: Sun, 22 Mar 2009 09:58:07 -0700

> Nope. Adressing formats come and go (well, they never go). The other

Well, any change in the address format would induce so many changes
almost everywhere and YANG built-in type would be a very minor issue.

> - which is as good as the text in the Yang specification defining

Anyway, here is the ipv6-address typedef, it covers the full, shortened
and mixed format, following (hopefully) exactly RFC 4291:

  typedef ipv6-address {
    type string {
      pattern
        "([0-9a-fA-F]{0,4}:){0,6}"
      + "((([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])))";
      pattern
        "(([0-9a-fA-F]+:){6}(([0-9a-fA-F]+:[0-9a-fA-F]+)|[\\.0-9]+)|"
      + "(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::"
      + "((([0-9a-fA-F]+:)*[0-9a-fA-F]+)?|[\\.0-9]+))";
    }
  }

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 22 Mar 2009 18:46:06 +0100

>       + "((([0-9a-fA-F]{0,4}:)?[0-9a-fA-F]{0,4})|"

This pattern does not seem to accept ::FFFF:129.144.52.38 as an IPv6
address. Can you fix this?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 22 Mar 2009 18:58:57 -0700

> address. Can you fix this?
Thanks, fixed. Also it didn't allow 1:2:3:4:5:6:7:: and ::1:2:3:4:5:6:7.
This version should be better:

  typedef ipv6-address {
    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])))";
      pattern
        "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|"
      + "((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)";
    }
  }

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Mar 2009 12:05:34 +0100

>       + "((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|"

This passes my test cases (whatever that means). Can you now add an
optional zone index?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Mar 2009 11:24:28 -0700

> This passes my test cases (whatever that means). Can you now add an

Here it is (I also chenged double quotes to single):

  typedef ipv6-address {
    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])))'
      + '(%[\p{N}\p{L}]+)?';
      pattern
        '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
      + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
      + '(%.+)?';
    }
  }

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C