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

Martin Thomson <martin.thomson@gmail.com> (by way of S Moonesamy <sm+ietf@elandsys.com>) Mon, 29 April 2013 06:36 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3921F97EE; Sun, 28 Apr 2013 23:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fJhfTatUXZOE; Sun, 28 Apr 2013 23:36:34 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B531521F97E0; Sun, 28 Apr 2013 23:36:34 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3T6aK0S017956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2013 23:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367217393; bh=aWp8PCMxDoEoNtGBOpYa0lKKWEERyw0seaCmWBW/eHg=; h=Date:To:From:Subject:Cc; b=B1XzKBXRArZDFabUq4olawm5k2yUJuIElMxF12jQhw2zVYDUuh8utiSSxvj60fGdh FQlYhAXU2cjGR2g2LpUlUu6DUgGD2nH4uTbqz8v84KQlbYtJWYeSTFGKfy3gEBKbqW 6Q+4WEdg+5ac4Qaw5CuVe1eSGaqhEP/Ktb/7orNo=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 28 Apr 2013 23:36:08 -0700
To: apps-discuss@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org
From: Martin Thomson <martin.thomson@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: iesg@ietf.org
Subject: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2013 06:36:35 -0000

(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

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.

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.


Section 3:
phys-address: why is this optionally empty?  Maybe explain why in the
document - value absent?
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.
xpath1.0: are we expected to infer that "context" includes document
and where the namespace prefixes are bound?

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}
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
          <!-- 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}:

Nits: I didn't find anything at all, and the items that idnits found
were bogus, so it looks good.
appsdir mailing list