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)", … |
|
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 |