Skip to main content

Common YANG Data Types
RFC 6021

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from netmod-chairs@ietf.org, draft-ietf-netmod-yang-types@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2010-10-06
09 Cindy Morgan State changed to RFC Published from RFC Ed Queue by Cindy Morgan
2010-10-06
09 Cindy Morgan [Note]: changed to 'RFC 6021' by Cindy Morgan
2010-10-06
09 (System) RFC published
2010-06-14
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-06-14
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-06-14
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-06-11
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-06-11
09 (System) IANA Action state changed to In Progress from On Hold
2010-06-10
09 (System) IANA Action state changed to On Hold from In Progress
2010-06-10
09 (System) IANA Action state changed to In Progress
2010-06-10
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-06-10
09 Cindy Morgan IESG state changed to Approved-announcement sent
2010-06-10
09 Cindy Morgan IESG has approved the document
2010-06-10
09 Cindy Morgan Closed "Approve" ballot
2010-06-09
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2010-04-26
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-04-26
09 (System) New version available: draft-ietf-netmod-yang-types-09.txt
2010-04-23
09 (System) Removed from agenda for telechat - 2010-04-22
2010-04-22
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-04-22
09 Jari Arkko
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented …
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
2010-04-22
09 Jari Arkko
[Ballot discuss]
[Updated Discuss, most of the issues have been solved]

This is an excellent, carefully written spec. I do have a few issues,
a …
[Ballot discuss]
[Updated Discuss, most of the issues have been solved]

This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I would like to talk about
before recommending the approval of this specification. My main issue
is with the patterns and my (in)ability to verify them.

First of all, I think the description fields should explain the
rational for the patterns where they are not obvious, and point
to the relevant specifications. For instance, on the OID definition
you may want to tell the reader why the root number space is limited.

This definition:

  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}(([^:]+:[^:]+)|(.*\..*)))|'
            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
            + '(%.+)?';
    }
    description
      "The ipv6-address type represents an IPv6 address in full,
      mixed, shortened and shortened mixed notation.  The IPv6
      address may include a zone index, separated by a % sign.

      The zone index is used to disambiguate identical address
      values.  For link-local addresses, the zone index will
      typically be the interface index number or the name of an
      interface. If the zone index is not present, the default
      zone of the device will be used.

      The canonical format of IPv6 addresses uses the compressed
      format described in RFC 4291 section 2.2 item 2 with the
      following additional rules: The :: substitution must be
      applied to the longest sequence of all-zero 16-bit chunks
      in an IPv6 address. If there is a tie, the first sequence
      of all-zero 16-bit chunks is replaced by ::. Single
      all-zero 16-bit chunks are not compressed. The canonical
      format uses lower-case characters and leading zeros are
      not allowed. The canonical format for the zone index is
      the numerical format as described in RFC 4007 section
      11.2.";

Uses its own definition of a canonical format, but wouldn't referencing
draft-ietf-6man-text-addr-representation be more appropriate? That
draft has been stuck for a while, but has cleared almost all discusses
now, FYI...

I intend to verify that this matches with text-addr-representation.
Thank you for supplying sample code, it will help.

Also, this is just a comment but I have serious trouble mapping
the complex pattern definitions to other things, such as the
canonical text representation rules. How do we know that the
patterns are correct?
2010-04-22
09 Jari Arkko
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented …
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
2010-04-22
09 Jari Arkko
[Ballot discuss]
This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I …
[Ballot discuss]
This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I would like to talk about
before recommending the approval of this specification. My main issue
is with the patterns and my (in)ability to verify them.

This definition:

  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}(([^:]+:[^:]+)|(.*\..*)))|'
            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
            + '(%.+)?';
    }
    description
      "The ipv6-address type represents an IPv6 address in full,
      mixed, shortened and shortened mixed notation.  The IPv6
      address may include a zone index, separated by a % sign.

      The zone index is used to disambiguate identical address
      values.  For link-local addresses, the zone index will
      typically be the interface index number or the name of an
      interface. If the zone index is not present, the default
      zone of the device will be used.

      The canonical format of IPv6 addresses uses the compressed
      format described in RFC 4291 section 2.2 item 2 with the
      following additional rules: The :: substitution must be
      applied to the longest sequence of all-zero 16-bit chunks
      in an IPv6 address. If there is a tie, the first sequence
      of all-zero 16-bit chunks is replaced by ::. Single
      all-zero 16-bit chunks are not compressed. The canonical
      format uses lower-case characters and leading zeros are
      not allowed. The canonical format for the zone index is
      the numerical format as described in RFC 4007 section
      11.2.";

Uses its own definition of a canonical format, but wouldn't referencing
draft-ietf-6man-text-addr-representation be more appropriate? That
draft has been stuck for a while, but has cleared almost all discusses
now, FYI...

Also, this is just a comment but I have serious trouble mapping
the complex pattern definitions to other things, such as the
canonical text representation rules. How do we know that the
patterns are correct?
2010-04-22
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-04-22
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-04-22
09 Gonzalo Camarillo [Ballot comment]
2010-04-22
09 Gonzalo Camarillo [Ballot comment]
The acronym NETCONF should be expanded in the Abstract.
2010-04-22
09 Gonzalo Camarillo [Ballot comment]
The acronym NETCONF should be expanded in the Abstract.
2010-04-22
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-04-21
09 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre
2010-04-21
09 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2010-04-21
09 Jari Arkko
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented …
[Ballot comment]
From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
2010-04-21
09 Jari Arkko
[Ballot discuss]
This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I …
[Ballot discuss]
This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I would like to talk about
before recommending the approval of this specification. My main issue
is with the patterns and my (in)ability to verify them. The issues
are also related to what the specification draws in from the SNMP
world and what kind of assumptions are valid there (OID value spaces,
for instance). Unfortunately I am not an SNMP expert, so please help
me understand this better.

Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)                |
    +-----------------+-----------------------------------------------+
    ...
    | ip-address      | -                                            |
    | ipv4-address    | -                                            |
    | ipv6-address    | -                                            |

What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?
It seems that there is a corresponding type, so shouldn't it be
listed in the table above?

Various types use extensive pattern definitions. For instance, the
object identifier definition has this pattern:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while eat regexps for breakfasts daily, this one was
a bit too much to chew on. And this is probably simplest one in the
draft! Shouldn't the description fields at least explain what the
patterns are indicating?

Also, AFAICT this pattern restricts what numbers the OIDs can begin
with. Do those restrictions match what the various ISO and IANA
registries on this matter say? For instance, does the pattern say
that the first OID value must be a 0, 1 or 2? Why?

This definition:

  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}(([^:]+:[^:]+)|(.*\..*)))|'
            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
            + '(%.+)?';
    }
    description
      "The ipv6-address type represents an IPv6 address in full,
      mixed, shortened and shortened mixed notation.  The IPv6
      address may include a zone index, separated by a % sign.

      The zone index is used to disambiguate identical address
      values.  For link-local addresses, the zone index will
      typically be the interface index number or the name of an
      interface. If the zone index is not present, the default
      zone of the device will be used.

      The canonical format of IPv6 addresses uses the compressed
      format described in RFC 4291 section 2.2 item 2 with the
      following additional rules: The :: substitution must be
      applied to the longest sequence of all-zero 16-bit chunks
      in an IPv6 address. If there is a tie, the first sequence
      of all-zero 16-bit chunks is replaced by ::. Single
      all-zero 16-bit chunks are not compressed. The canonical
      format uses lower-case characters and leading zeros are
      not allowed. The canonical format for the zone index is
      the numerical format as described in RFC 4007 section
      11.2.";

Uses its own definition of a canonical format, but wouldn't referencing
draft-ietf-6man-text-addr-representation be more appropriate? That
draft has been stuck for a while, but has cleared almost all discusses
now, FYI...

Also, this is just a comment but I have serious trouble mapping
the complex pattern definitions to other things, such as the
canonical text representation rules. How do we know that the
patterns are correct?
2010-04-21
09 Jari Arkko
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while …
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while eat regexps for breakfasts daily, this one was
a bit too much to chew on. Shouldn't the description at least explain
what is going on?

From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
2010-04-21
09 Jari Arkko
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)              …
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)                |
    +-----------------+-----------------------------------------------+
    ...
    | ip-address      | -                                            |
    | ipv4-address    | -                                            |
    | ipv6-address    | -                                            |

What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?

This definition:

  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}(([^:]+:[^:]+)|(.*\..*)))|'
            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
            + '(%.+)?';
    }
    description
      "The ipv6-address type represents an IPv6 address in full,
      mixed, shortened and shortened mixed notation.  The IPv6
      address may include a zone index, separated by a % sign.

      The zone index is used to disambiguate identical address
      values.  For link-local addresses, the zone index will
      typically be the interface index number or the name of an
      interface. If the zone index is not present, the default
      zone of the device will be used.

      The canonical format of IPv6 addresses uses the compressed
      format described in RFC 4291 section 2.2 item 2 with the
      following additional rules: The :: substitution must be
      applied to the longest sequence of all-zero 16-bit chunks
      in an IPv6 address. If there is a tie, the first sequence
      of all-zero 16-bit chunks is replaced by ::. Single
      all-zero 16-bit chunks are not compressed. The canonical
      format uses lower-case characters and leading zeros are
      not allowed. The canonical format for the zone index is
      the numerical format as described in RFC 4007 section
      11.2.";

Uses its own definition of a canonical format, but wouldn't referencing
draft-ietf-6man-text-addr-representation be more appropriate? That
draft has been stuck for a while, but has cleared almost all discusses
now, FYI...

Also, this is just a comment but I have serious trouble mapping
the complex pattern definitions to other things, such as the
canonical text representation rules. How do we know that the
patterns are correct?
2010-04-21
09 Sean Turner [Ballot comment]
Sec 2: r/overview over/overview of
Sec 2: r/(if any)/(- indicates there is no corresponding SMIv2 type) X2
2010-04-21
09 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner
2010-04-21
09 Jari Arkko
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while …
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while eat regexps for breakfasts daily, this one was
a bit too much to chew on. Shouldn't the description at least explain
what is going on?

From the definition of a date object:

      using the following ABFN (replacing double quotes with

Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
2010-04-21
09 Jari Arkko
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)              …
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)                |
    +-----------------+-----------------------------------------------+
    ...
    | ip-address      | -                                            |
    | ipv4-address    | -                                            |
    | ipv6-address    | -                                            |

What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?
2010-04-21
09 Jari Arkko
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while …
[Ballot comment]
From the object identifier definition:

      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
            + '(\.(0|([1-9]\d*)))*';

I must say that while eat regexps for breakfasts daily, this one was
a bit too much to chew on. Shouldn't the description at least explain
what is going on?
2010-04-21
09 Jari Arkko
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)              …
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)                |
    +-----------------+-----------------------------------------------+
    ...
    | ip-address      | -                                            |
    | ipv4-address    | -                                            |
    | ipv6-address    | -                                            |

What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?
2010-04-21
09 Jari Arkko
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)              …
[Ballot discuss]
Section 1:

    +-----------------+-----------------------------------------------+
    | YANG type      | Equivalent SMIv2 type (module)                |
    +-----------------+-----------------------------------------------+
    ...
    | ip-address      | -                                            |
    | ipv4-address    | -                                            |
    | ipv6-address    | -                                            |

What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?
2010-04-21
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-04-21
09 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-04-21
09 Alexey Melnikov
[Ballot comment]
[RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)", …
[Ballot comment]
[RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

Should this be pointing to IDNA 2008?
2010-04-21
09 Alexey Melnikov [Ballot discuss]
2010-04-21
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-04-21
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-04-20
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-04-20
09 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2010-04-20
09 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-04-19
09 David Harrington [Ballot Position Update] New position, Recuse, has been recorded by David Harrington
2010-04-19
09 Lars Eggert
[Ballot discuss]
Section 4., paragraph 23:
>        Note that the value zero is not a valid port number. A union
>    …
[Ballot discuss]
Section 4., paragraph 23:
>        Note that the value zero is not a valid port number. A union
>        type might be used in situations where the value zero is
>        meaningful.

  DISCUSS: Zero is a valid port number. It is merely reserved by IANA.
2010-04-19
09 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2010-04-16
09 Alexey Melnikov
[Ballot comment]
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})';
    …
[Ballot comment]
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})';
    }
    description
      "The date-and-time type is a profile of the ISO 8601
      standard for representation of dates and times using the
      Gregorian calendar. The format is most easily described
      using the following ABFN (replacing double quotes with

Typo: ABNF

      single quotes):


  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}(([^:]+:[^:]+)|(.*\..*)))|'
            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
            + '(%.+)?';
    }
    description
      "The ipv6-address type represents an IPv6 address in full,
      mixed, shortened and shortened mixed notation.  The IPv6
      address may include a zone index, separated by a % sign.

      The zone index is used to disambiguate identical address
      values.  For link-local addresses, the zone index will
      typically be the interface index number or the name of an
      interface. If the zone index is not present, the default
      zone of the device will be used.

      The canonical format of IPv6 addresses uses the compressed
      format described in RFC 4291 section 2.2 item 2 with the

Is this reference Normative? It looks like.

      following additional rules: The :: substitution must be
      applied to the longest sequence of all-zero 16-bit chunks
      in an IPv6 address. If there is a tie, the first sequence
      of all-zero 16-bit chunks is replaced by ::. Single
      all-zero 16-bit chunks are not compressed. The canonical
      format uses lower-case characters and leading zeros are
      not allowed. The canonical format for the zone index is
      the numerical format as described in RFC 4007 section
      11.2.";

Is this reference Normative? It looks like.


  typedef domain-name {

[...]

      Internet domain names are only loosely specified. Section
      3.5 of RFC 1034 recommends a syntax (modified in section
      2.1 of RFC 1123). The pattern above is intended to allow
      for current practise in domain name use, and some possible
      future expansion. It is designed to hold various types of
      domain names, including names used for A or AAAA records
      (host names) and other records, such as SRV records.

And informative reference to DNS SRV document would be good here.

[...]

      The description clause of schema nodes using the domain-name
      type MUST describe when and how these names are resolved to
      IP addresses. Note that the resolution of a domain-name value
      may require to query multiple DNS records (e.g., A for IPv4
      and AAAA for IPv6). The order of the resolution process and
      which DNS record takes precedence can either be defined
      explicitely or it may depend on the configuration of the
      resolver.

I am not entirely sure how this is relevant to the definition of the domain-name data type.


  [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

Should this be pointing to IDNA 2008?
2010-04-16
09 Alexey Melnikov
[Ballot discuss]
This is a fine document, however I found some nits that should be addressed before I can recommend approval of this document.

1) …
[Ballot discuss]
This is a fine document, however I found some nits that should be addressed before I can recommend approval of this document.

1)
      date-fullyear  = 4DIGIT
      date-month      = 2DIGIT  ; 01-12
      date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
      time-hour      = 2DIGIT  ; 00-23
      time-minute    = 2DIGIT  ; 00-59
      time-second    = 2DIGIT  ; 00-58, 00-59, 00-60
      time-secfrac    = '.' 1*DIGIT
      time-numoffset  = ('+' / '-') time-hour ':' time-minute
      time-offset    = 'Z' / time-numoffset

      partial-time    = time-hour ':' time-minute ':' time-second
                        [time-secfrac]
      full-date      = date-fullyear '-' date-month '-' date-mday
      full-time      = partial-time time-offset
      date-time      = full-date 'T' full-time

Use of <'> in ABNF is not valid. Please use <"> instead.

      The date-and-time type is consistent with the semantics defined
      in RFC 3339.

The ABNF is identical to the one in RFC 3339, modulo use of <'> instead of <">. Why not reference RFC 3339 normatively and just say that the syntax is defined by the <date-time> ABNF production from RFC 3339, Section 5.6?

2).
  typedef xpath1.0 {
    type string;
    description
      "This type represents an XPATH 1.0 expression.

      When a schema node is defined which uses this type, the
      description of the schema node MUST specify the XPath
      context in which the XPath expression is evaluated.";
    reference
      "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0";

This reference must be Normative, as it is required in order to understand
and implement an XPath parser/generator.

  }

3)
  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

This should be a Normative reference, as it is required to understand/implement "typedef uri".

4)
The ABNF reference (RFC 5234) should be Normative, unless RFC 3339 is made a Normative Reference and the date-time ABNF is deleted from the document.

5)
  typedef domain-name {
    type string {
      pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
            +  '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
            +  '|\.';
      length "1..253";
    }

[...]

      The canonical format for domain-name values uses the
      US-ASCII encoding and case-insensitive characters are set
      to lowercase.";

I am quite confused by the "and case-insensitive characters are set
to lowercase". Why not just say something like:

      domain-name values use the US-ASCII encoding. Their canonical
      format uses lowercase US-ASCII characters.";

?

I would also add: "Internationalized domain names MUST be encoded
in punycode [RFC3492]". [RFC3492] would be a Normative reference.
While this can be deducted from the pattern, it would be much better to state this explicitly.
2010-04-16
09 Alexey Melnikov
[Ballot comment]
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})';
    …
[Ballot comment]
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})';
    }
    description
      "The date-and-time type is a profile of the ISO 8601
      standard for representation of dates and times using the
      Gregorian calendar. The format is most easily described
      using the following ABFN (replacing double quotes with

Typo: ABNF

      single quotes):
2010-04-16
09 Alexey Melnikov
[Ballot discuss]
1)
      date-fullyear  = 4DIGIT
      date-month      = 2DIGIT  ; 01-12
      date-mday      …
[Ballot discuss]
1)
      date-fullyear  = 4DIGIT
      date-month      = 2DIGIT  ; 01-12
      date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31
      time-hour      = 2DIGIT  ; 00-23
      time-minute    = 2DIGIT  ; 00-59
      time-second    = 2DIGIT  ; 00-58, 00-59, 00-60
      time-secfrac    = '.' 1*DIGIT
      time-numoffset  = ('+' / '-') time-hour ':' time-minute
      time-offset    = 'Z' / time-numoffset

      partial-time    = time-hour ':' time-minute ':' time-second
                        [time-secfrac]
      full-date      = date-fullyear '-' date-month '-' date-mday
      full-time      = partial-time time-offset
      date-time      = full-date 'T' full-time

Use of <'> in ABNF is not valid. Please use <"> instead.

      The date-and-time type is consistent with the semantics defined
      in RFC 3339.

The ABNF is identical to the one in RFC 3339, modulo use of <'> instead of <">. Why not reference RFC 3339 normatively and just say that the syntax is defined by the <date-time> ABNF production from RFC 3339, Section 5.6?




  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

This should be a Normative reference.

The ABNF reference should be Normative, unless RFC 3339 is made a Normative Reference and the date-time ABNF is deleted from the document.
2010-04-16
09 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-04-14
09 Dan Romascanu State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Dan Romascanu
2010-04-14
09 Dan Romascanu Placed on agenda for telechat - 2010-04-22 by Dan Romascanu
2010-04-14
09 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2010-04-14
09 Dan Romascanu Ballot has been issued by Dan Romascanu
2010-04-14
09 Dan Romascanu Created "Approve" ballot
2010-04-14
08 (System) New version available: draft-ietf-netmod-yang-types-08.txt
2010-04-09
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-04-07
09 Amanda Baber
IANA comments:


Author Note: The document uses a namespace of
"urn:ietf:params:xml:ns:yang:ietf-yang-types-DRAFT-06" in Section 3
but does not direct the RFC Editor to adjust this when …
IANA comments:


Author Note: The document uses a namespace of
"urn:ietf:params:xml:ns:yang:ietf-yang-types-DRAFT-06" in Section 3
but does not direct the RFC Editor to adjust this when the document
is finally published. Should the document tell them to do so?

There's a similar issue with the use of namespace
"urn:ietf:params:xml:ns:yang:ietf-inet-types-DRAFT-06" in Section 4.

Also note: actions in this ticket require completion of the actions
in ticket draft-ietf-netmod-yang-11.txt

Action 1:

Upon approval of this document, IANA will make the following assignments
in the "ns" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
------ ----------- --------------------- ---------
yang:ietf-yang-types urn:ietf:params:xml:ns:yang:ietf-yang-types
yang:ietf-yang-types [RFC-netmod-yang-types-07]
yang:ietf-inet-types urn:ietf:params:xml:ns:yang:ietf-inet-types
yang:ietf-inet-types [RFC-netmod-yang-types-07]


Action 2:

Upon approval of this document, IANA will make the following assignments
in the "YANG Module Names" registry at
http://www.iana.org/assignments/TBD

(Sub)Module Name | (Module) Namespace | (Module) Prefix | (SubModule) Module
| Reference
-----------------|----------------------------------------------|-----------------|--------------------|------------
ietf-yang-types | urn:ietf:params:xml:ns:yang:ietf-yang-types | yang |
| [RFC-netmod-yang-types-07]
ietf-inet-types | urn:ietf:params:xml:ns:yang:ietf-inet-types | inet |
| [RFC-netmod-yang-types-07]


We understand the above to be the only IANA Actions for this document.
2010-04-01
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Donald Eastlake.
2010-03-15
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Donald Eastlake
2010-03-15
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Donald Eastlake
2010-03-10
09 Amy Vezza Last call sent
2010-03-10
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-03-10
09 Dan Romascanu State Changes to Last Call Requested from Publication Requested by Dan Romascanu
2010-03-10
09 Dan Romascanu Last Call was requested by Dan Romascanu
2010-03-10
09 (System) Ballot writeup text was added
2010-03-10
09 (System) Last call text was added
2010-03-10
09 (System) Ballot approval text was added
2010-02-25
09 Cindy Morgan [Note]: 'David Partain (david.partain@ericsson.com) is the document shepherd.' added by Cindy Morgan
2010-02-25
09 Cindy Morgan
Document write-up for draft-ietf-netmod-yang-types-07.txt

(1.a)  Who is the Document Shepherd for this document?

        David Partain, NETMOD WG co-chair

      …
Document write-up for draft-ietf-netmod-yang-types-07.txt

(1.a)  Who is the Document Shepherd for this document?

        David Partain, NETMOD WG co-chair

        Has the Document Shepherd personally reviewed this version
        of the document and, in particular, does he or she believe
        this version is ready for forwarding to the IESG for
        publication?

        Yes, I have reviewed this document and consider it very
        much ready for IESG review and publication as a Proposed
        Standard.

(1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?

        Yes, we have had extensive review of the document itself.
        We have requested and received review from outside the
        working group.

        Does the Document Shepherd have any concerns about the
        depth or breadth of the reviews that have been performed?

        No, I do not.

(1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

The document would be well-served by further review from
the XML Directorate review as well as a broader APPS area
review.  Requests have been made for such reviews during
the normal course of WG activity, but response has been
very limited.

(1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

        No, this document has been stable and straightforward to
        reach consensus on.

        Has an IPR disclosure related to this document been filed?

        No IPR disclosures have been filed against this document.

(1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

        I believe this document represents strong consensus of the
        working group after intense work over the last 18 months.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

        No.

(1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.

        Those issues pointed out by the tool are not really issues.

        1. It incorrectly identifies one number as an IP address.
        It is not; it is instead a section number.

  == There are 1 instance of lines with non-RFC3330-compliant
    IPv4 addresses in the document.  If these are example
    addresses, they should be changed.

        2. It incorrectly identifies the main YANG spec as a
        down-ref, which it is not.

  ** Downref: Normative reference to an Informational
            draft: draft-ietf-netmod-yang (ref. 'YANG')

        3. It identifies a number of unused references.  These
        can be removed if so desired, but the editor chose to
        maintain them.

Has the document met all formal review criteria it needs
to, such as the MIB Doctor, media type, and URI type
reviews?

Yes.

(1.h)  Has the document split its references into normative and
        informative?

Yes.

Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear
state?

The companion NETMOD document (draft-ietf-netmod-yang) is
included but will be going to advancement in parallel.

If such normative references exist, what is the strategy
for their completion?

They are being advanced in parallel.

Are there normative references that are downward
references, as described in [RFC3967]?

No.

(1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?

Yes.

If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?

Yes.

If the document creates a new registry, does it define
the proposed initial contents of the registry and an
allocation procedure for future registrations?

Yes.

Does it suggest a reasonable name for the new registry?

Yes.

(1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes.

(1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary

  YANG is a data modeling language used to model
  configuration and state data manipulated by the NETCONF
  protocol.  The YANG language supports a small set of
  built-in data types and provides mechanisms to derive
  other types from the built-in types.

  This document introduces a collection of common data
  types derived from the built-in YANG data types.  The
  definitions are organized in several YANG modules.  The
  "ietf-yang-types" module contains generally useful data
  types.  The "ietf-inet-types" module contains
  definitions that are relevant for the Internet protocol
  suite.

        Working Group Summary

          Consensus was reached among all interested parties before
          requesting the publication of this document.

        Document Quality

          There are multiple independent implementations of YANG
          today, including both commercial and freely-available
          tools.
2010-02-25
09 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2010-02-24
07 (System) New version available: draft-ietf-netmod-yang-types-07.txt
2010-02-03
06 (System) New version available: draft-ietf-netmod-yang-types-06.txt
2009-12-01
05 (System) New version available: draft-ietf-netmod-yang-types-05.txt
2009-10-23
04 (System) New version available: draft-ietf-netmod-yang-types-04.txt
2009-05-13
03 (System) New version available: draft-ietf-netmod-yang-types-03.txt
2009-03-09
02 (System) New version available: draft-ietf-netmod-yang-types-02.txt
2008-11-03
01 (System) New version available: draft-ietf-netmod-yang-types-01.txt
2008-09-04
00 (System) New version available: draft-ietf-netmod-yang-types-00.txt