Subject: [Gen-art] A *new* batch of IETF LC reviews - 2013-04-18

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 18 Apr 2013 17:22:38 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Ben Campbell      2013-04-26   draft-ietf-6man-stable-privacy-addresses-06

Christer Holmberg 2013-05-10   draft-sheffer-running-code-04

David Black       2013-04-29   draft-ietf-karp-crypto-key-table-07

Dan Romascanu     2013-04-30   draft-ietf-oauth-revocation-07

Elwyn Davies      2013-05-14   draft-saintandre-impp-call-info-02

Francis Dupont    2013-05-14   draft-housley-rfc2050bis-01

Joel Halpern      2013-05-01   draft-ietf-netmod-rfc6021-bis-01

Kathleen Moriarty 2013-05-01   draft-ietf-ipfix-protocol-rfc5101bis-06

Meral Shirazipour 2013-04-24   draft-ietf-spfbis-4408bis-14 *

* Requested early Gen-ART review for WGLC

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Apr 2013 18:24:22 -0400

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:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Apr 2013 13:49:05 +0200

On Tue, Apr 30, 2013 at 12:20:31PM +0200, Benoit Claise wrote:
> Hi,
> 
> Just making sure that you saw this one.
> Next to the APPSDIR review, I believe that this is the one review left.
> 

Thanks for forwarding this. Answers inline. Thanks to Joel Halpern to
review this document.

> 
> 
> -------- Original Message --------
> Subject: 	[Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01
> Date: 	Fri, 19 Apr 2013 18:24:22 -0400
> From: 	Joel M. Halpern <[email-masked]>
> To: 	A. Jean Mahoney <[email-masked]>
> CC: 	[email-masked], IETF discussion list <[email-masked]>
> 
> 
> 

Joel,

note that ip4-address-no-zone and ipv6-address-no-zone are _derived_
from the ipv4-address and ipv6-address types:

     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
         pattern '[\.0-9]*';
       }
       // ...
     }

     typedef ipv6-address-no-zone {
       type inet:ipv6-address {
         pattern '[0-9a-fA-F:]*';
       }
       // ...
     }

This means that all rules for ipv4-address and ipv6-address
respectively apply and in addition the patterns for
ip4-address-no-zone and ipv6-address-no-zone apply. In other words,
the pattern in the -no-zone versions only aim to eliminate the zone
identifier by eliminating the % symbol.

Your comment, however, made Lada discover that I missed to allow the
. for IPv4-mapped IPv6 addresses. This was not my intention and is
indeed a bug that I think needs to be fixed. There is a thread on the
netmod mailing list about this.
 
> Nits/editorial comments:

/js

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