Thank you Juergen. I see that the pattern statement is therefore correct.
And presumably it is a judgment call as to hw to write te new pattern to
restrict the old one. Personally, I find a pattern statement that
covers a whole lot of other things, but that happens when combined with
the parent patter to give the right result, to be a confusing way to
document what is needed. But I can not claim it is technically
incorrect. (And I suppose that some would claim that repeating the more
detailed parent pattern is redundant.)
Yours,
Joel
On 5/13/2013 6:37 AM, Juergen Schoenwaelder wrote:
Joel,
this is specified in the third paragraph of section 9.4.6 of RFC 6020:
9.4.6. The pattern Statement
The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES]. It is used to restrict the built-in type
"string", or types derived from "string", to values that match the
pattern.
If the type has multiple "pattern" statements, the expressions are
ANDed together, i.e., all such expressions have to match.
If a pattern restriction is applied to an already pattern-restricted
type, values must match all patterns in the base type, in addition to
the new patterns.
/js
On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:
Forwarding to the authors and WG
Regards, Benoit
I am guessing that the authors intended the addition of the text
emphasizing that the no-zone typedefs are derived general typedef
addresses the difference in the patterns.
Is there a YANG rule that says tat if typedef X is derived from
typedef Y then the string for X must match the pattern for X and
the pattern for Y? If so, then my concern below is misplaced.
(The fact that I find the vague pattern for the child misleading
is not a fault with the document, but rather in my head, under
that requirement.)
Yours,
Joel
On 4/19/2013 6:24 PM, Joel M. Halpern wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-netmod-rfc6021-bis-01
Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A
Summary: This document is nearly ready for publication as a Standards
Track RFC
Major issues:
(The following may well be a non-issue.)
In the revision of the ietf-inet-types, the patterns for the new
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
>from the ipv4-address and ipv6-address patterns. The new
ipv4-address-no-zone allows any sequence of decimal digits an periods,
while the original was carefully defined as dotted quads of 0..255.
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
digits and colons. The original patterns were very careful to match
rules for validity. Is there a reason for the change.
Minor issues:
Nits/editorial comments:
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art