Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 30 April 2013 08:32 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D521F9403; Tue, 30 Apr 2013 01:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level:
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BWhmRVcANTg; Tue, 30 Apr 2013 01:32:09 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9121F9AFC; Tue, 30 Apr 2013 01:32:08 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 106AB20C19; Tue, 30 Apr 2013 10:32:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FkIdBeuzvjuP; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25EBC20C0C; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1101325E9CE6; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:32:06 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20130430083206.GD46852@elstar.local>
Mail-Followup-To: Martin Thomson <martin.thomson@gmail.com>, apps-discuss@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, iesg@ietf.org, netmod@ietf.org
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 08:32:13 -0000

Hi,

thanks for the review. I will respond to your questions inline.

/js

On Sun, Apr 28, 2013 at 11:36:08PM -0700, Martin Thomson wrote:
> (Apologies, I have this habit of not including directorates on
> directorate reviews.  Correcting this oversight.)
> 
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-netmod-rfc6021-bis-01
> Title: Common YANG Data Types
> Reviewer: Martin Thomson
> Review Date: 2013-04-29
> 
> Summary: This draft is ready for publication as a Proposed Standard
> RFC.  I have some minor issues and questions.
> 
> This is some of the most readable code that I have seen.
> 
> Major Issues: none
> 
> Minor Issues:
> 
> Section 4:
> There is an RFC that describes a canonical textual representation of
> IPv6 addresses.  You should use that: RFC 5952.

The typedef ipv6-address has a reference to RFC 5952. I believe the
text in the description statement is inline with RFC 5952. Note that
this text did not change since RFC 6021 (and other than clarifications
we likely do not want changes).

> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
> used in the text).  I assume that these are LDH-labels:
> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
> document should say as much.

I am not sure what you think is unclear. Note that the definition of
the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
you can make a concrete text change proposal so I better understand
what your concern is.

> Questions:
> 
> Section 3:
> phys-address: why is this optionally empty?  Maybe explain why in the
> document - value absent?

The primary reason is to be consistent with the PhysAddress textual
convention of RFC 2579. Note that this definition did not change since
RFC 6021. What an empty address means needs to be defined where the
type is used. I do not think we can regulate that in the type
definition itself. All we could do is add a 'warning' that this type
allows zero-length strings as values and hence users of this type
either need to subtype this type or explain the semantics of a
zero-length string.

> hex-string: why is this required to include at least one octet? The
> text does not mention this at all, I tend to find lots of uses for
> empty octet strings, so this seems odd.

I will take this to the WG. Note that in YANG you often use choices to
model situations where in other frameworks you give special meanings
to say zero-length strings.

> xpath1.0: are we expected to infer that "context" includes document
> and where the namespace prefixes are bound?

The term context is I think well defined in section 1 of the XML Path
Language specification <http://www.w3.org/TR/xpath/> (the document
cited in the reference statement). Note that this typedef is unchanged
from the one in RFC 6021.

> Section 4:
> ipv6-address: that is a very short IPv6 pattern.  Is it provably
> correct?  I only ask because I've had occasion to build a real
> pattern, and it's very long (the following is based on the "official"
> ABNF definition):
> 
>          <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
>          <!-- Double colon start -->
>          <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
>          <!-- Double colon middle -->
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
>                 (:[0-9A-Fa-f]{1,4}){1}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
>                 (:[0-9A-Fa-f]{1,4}){1,2}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
>                 (:[0-9A-Fa-f]{1,4}){1,3}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
>                 (:[0-9A-Fa-f]{1,4}){1,4}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
>                 (:[0-9A-Fa-f]{1,4}){1,5}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
>                 (:[0-9A-Fa-f]{1,4}){1,6}"/>
>          <!-- Double colon end -->
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
>          <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
>          <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
>          (:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
>          (:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
>          |((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
>          [0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
>          ?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
>          [0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
>          [0-9]?[0-9])"/>

Note sure what the "official" ABNF definition is but we believe that
the two pattern are correct. So far nobody was able to find a case
that was not properly accepted by the pattern. You are welcome to try
to find something where our two pattern break. ;-)

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