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

Martin Thomson <> Tue, 30 April 2013 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39DD021F984B; Tue, 30 Apr 2013 12:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0VkAPh2Ep2CC; Tue, 30 Apr 2013 12:29:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::232]) by (Postfix) with ESMTP id 2B66E21F992E; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by with SMTP id m15so831870wgh.5 for <multiple recipients>; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SA1BqMG1R8xDriSJQbUH5xR7wT9S25vujE/zleBuWS8=; b=a8uFymPea6P+YprXtI1ruGjnh4CMkh/LijzfMySq3V0cjS1a4tSlc5QqfYsy4HEYO2 2Xu3Y7xwgtyzI7IxYbthCO6VmZl8J3C5LodyRXpE3uTOOH7r5E/7Oj5wR6w9uTDuRkBA +yKZkSQY34voTaEPXp99YgCiFDH+ScMCgRBaejdzpCIH7U6P6okoMxlS0mF45YNRJ4C0 TNWOup5+kJdCpdHANxLcedWwWd5CT7UQJ0PURZX3oJkbDCDvhjrNPwk/7W5eqW52r/II +h8oRtJ0qd7JrGKq4VSXoyn18ux8yvWNYgjvBbQaqURBwVqUF8l7k2r2ivoXLIF8zw0p g3tw==
MIME-Version: 1.0
X-Received: by with SMTP id hv3mr41538571wjb.32.1367350142347; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by with HTTP; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
In-Reply-To: <20130430083206.GD46852@elstar.local>
References: <> <20130430083206.GD46852@elstar.local>
Date: Tue, 30 Apr 2013 12:29:02 -0700
Message-ID: <>
From: Martin Thomson <>
To: Juergen Schoenwaelder <>, Martin Thomson <>, IETF Apps Discuss <>,, The IESG <>,
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Apr 2013 19:29:34 -0000

One meta-comment.  I don't consider the contents of RFC 6021 to have
any bearing on the review of this document.  I'm not familiar with
6021, so I consider all of this to be new.

On 30 April 2013 01:32, Juergen Schoenwaelder
<> wrote:
>> 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).

That's unfortunate because I can't tell whether RFC 5952 and the
following are the same very easily:

   "The canonical format of IPv6 addresses uses the compressed
         format described in RFC 4291, Section 2.2, item 2 with the
         following additional rules: the :: substitution must be
         applied to the longest sequence of all-zero 16-bit chunks
         in an IPv6 address.  If there is a tie, the first sequence
         of all-zero 16-bit chunks is replaced by ::.  Single
         all-zero 16-bit chunks are not compressed.  The canonical
         format uses lowercase characters and leading zeros are
         not allowed.  The canonical format for the zone index is
         the numerical format as described in RFC 4007, Section

   "The canonical format of IPv6 addresses is described in RFC5952;
the canonical form of the zone index is described in RFC 4007, Section

Adding something to references is not the same as providing normative
text that stipulates how the information is intended to be consumed.
If the intent is to have the reference as normative, informative
references are fine as disassociated links.

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

The pattern for domain-name implies LDH label, however the textual
description does not.

Internet domain names are only loosely specified.  Section
         3.5 of RFC 1034 recommends a syntax (modified in Section
         2.1 of RFC 1123).  The pattern above is intended to allow
         for current practice in domain name use, and some possible
         future expansion.  It is designed to hold various types of
         domain names, including names used for A or AAAA records
         (host names) and other records, such as SRV records.  Note
         that Internet host names have a stricter syntax (described
         in RFC 952) than the DNS recommendations in RFCs 1034 and
         1123, and that systems that want to store host names in
         schema nodes using the domain-name type are recommended to
         adhere to this stricter standard to ensure interoperability.
  "A domain-name MUST consist of LDH-labels as defined in RFC 5890.

  Note: If fields of this type are used to store host names [RFC0952],
host names use a stricter syntax.  Systems that store host names
SHOULD enforce stronger restrictions or use a derived type for host

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

Yes, either would be nice, but I'm not that concerned about these.  I
prefer to see such surprises explained in some way.  e.g.,
"phys-address permits an empty string to so that the textual
convention established in RFC 2579 can be used.  An empty string has
no defined semantics here, subtypes SHOULD either assign semantics to
this value or eliminate it."

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

> ipv6 pattern
> 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. ;-)

Sorry, "official" is my shorthand for saying: there is an RFC out
there that defines this ABNF but I was too lazy to go and look for it
because I know that chances are I will find the wrong one.

The first pattern is overly restrictive, I think (only double colon at
the start?).  The second is definitely overly permissive.
This:sentence:is::actually:valid.  (I think).

> /js
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <>