Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>>>
>>>
>>>
>>
>