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

[Juergen Schoenwaelder <[e-mail]>]

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
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/gen-art
> >>
> >
> >
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>