Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
Martin Thomson <martin.thomson@gmail.com> Tue, 30 April 2013 19:29 UTC
Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DD021F984B; Tue, 30 Apr 2013 12:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 0VkAPh2Ep2CC; Tue, 30 Apr 2013 12:29:32 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66E21F992E; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by mail-wg0-f50.google.com 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; d=gmail.com; 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 10.194.109.227 with SMTP id hv3mr41538571wjb.32.1367350142347; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
In-Reply-To: <20130430083206.GD46852@elstar.local>
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local>
Date: Tue, 30 Apr 2013 12:29:02 -0700
Message-ID: <CABkgnnUe=9RsND+30y3kK39AjvEHe4KKV2qsj=ZkqCAXf0GPHA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Thomson <martin.thomson@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, netmod@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [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: 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 <j.schoenwaelder@jacobs-university.de> 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 11.2." Suggest: "The canonical format of IPv6 addresses is described in RFC5952; the canonical form of the zone index is described in RFC 4007, Section 11.2." 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: >> 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. The pattern for domain-name implies LDH label, however the textual description does not. OLD: 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. NEW: "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 names." >> 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 <http://www.jacobs-university.de/>
- [apps-discuss] [appsdir] Fwd: APPSDIR review of d… Martin Thomson
- Re: [apps-discuss] [appsdir] Fwd: APPSDIR review … Juergen Schoenwaelder
- Re: [apps-discuss] [appsdir] Fwd: APPSDIR review … Martin Thomson
- Re: [apps-discuss] [appsdir] Fwd: APPSDIR review … Juergen Schoenwaelder
- Re: [apps-discuss] [appsdir] Fwd: APPSDIR review … Martin Thomson
- Re: [apps-discuss] [appsdir] Fwd: APPSDIR review … Juergen Schoenwaelder