ietf
[Top] [All Lists]

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

2013-05-13 05:35:18
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




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