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

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 May 2013 10:37:41 -0400

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 May 2013 09:33:31 -0700

On Fri, May 10, 2013 at 7:37 AM, Joel M. Halpern <[email-masked]>wrote:

> 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.)
>

Yes. RFC 6020, sec. 9.4.6.
All the patterns are ANDed together.

> Joel

Andy

>> <http://wiki.tools.ietf.org/**area/gen/trac/wiki/GenArtfaq<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>> >.
>>
>> Document: draft-ietf-netmod-rfc6021-bis-**01
>>      Common YANG Data Types
>> ______________________________**_________________
>> Gen-art mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/gen-art<https://www.ietf.org/mailman/listinfo/gen-art>
>>
>>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 May 2013 12:32:57 +0200

Forwarding to the authors and WG

Regards, Benoit
> ip4-address-no-zone and ipv6-address-no-zone are drastically 
> simplified from the ipv4-address and ipv6-address patterns.  The new 
> 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:
>
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 May 2013 12:33:37 +0200

Regards, Benoit
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 May 2013 12:37:47 +0200

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:
> >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
> >

-- 
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/>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 May 2013 08:17:44 -0400

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 May 2013 09:39:34 +0300

Thank you Joel for the review. These reviews are very much appreciated, and help me decide whether to recommend or not approval in the IESG tele chats. I plan to ballot no-objection for this document in today's IESG call.

FWIW - regarding the derived types for addresses - I think I would probably have had the same question as Joel. Perhaps a comment in the derived type would have helped clarify the issue to the readers.

Thanks,

Jari