ietf
[Top] [All Lists]

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

2013-05-13 05:38:04
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





-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

<Prev in Thread] Current Thread [Next in Thread>