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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 03 May 2013 08:16 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 A36DF21F9418; Fri, 3 May 2013 01:16:19 -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 YRNLKVWDIC-v; Fri, 3 May 2013 01:16:12 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE38F21F949A; Fri, 3 May 2013 01:16:11 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0B520C27; Fri, 3 May 2013 10:16:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SvNMVkHH-y75; Fri, 3 May 2013 10:16:10 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 498FC20C26; Fri, 3 May 2013 10:16:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E4B1925F2630; Fri, 3 May 2013 10:16:08 +0200 (CEST)
Date: Fri, 03 May 2013 10:16:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20130503081608.GA4483@elstar.local>
Mail-Followup-To: 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
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <CABkgnnUe=9RsND+30y3kK39AjvEHe4KKV2qsj=ZkqCAXf0GPHA@mail.gmail.com> <20130502074157.GA4935@elstar.local> <CABkgnnUDbCt775Bk2tdQZvwUruKdkC-K+dS34q1mxG1=tP8X+A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABkgnnUDbCt775Bk2tdQZvwUruKdkC-K+dS34q1mxG1=tP8X+A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Fri, 03 May 2013 11:16:24 -0700
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
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
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Fri, 03 May 2013 08:16:19 -0000

On Thu, May 02, 2013 at 01:28:46PM -0700, Martin Thomson wrote:
> On 2 May 2013 00:41, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote:
> >> 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.
> >
> > But most of the definitions are not new and I am reluctant to make
> > changes to published RFC text.
> 
> I thought that was the purpose of revising an RFC.  If you were just
> looking to add types, an update might be more appropriate.

The new types go into existing YANG module and this requires to
republish the whole module. This is what we have been doing >20 years
for MIB modules - so there is experience with this.
 
> > If you mean by "second" the ipv6-address-no-zone typedef, please see
> > my response to Joel. This is a type derived from ipv6-address.
> 
> Ahh, both patterns apply.  My mistake; I had assumed OR (like XML
> schema), not AND.  Interesting approach.

In XML schema, you have both:

   If multiple <pattern> element information items appear as
   [children] of a <simpleType>, the [value]s should be combined as if
   they appeared in a single ·regular expression· as separate
   ·branch·es.  Note: It is a consequence of the schema representation
   constraint Multiple patterns (§4.3.4.3) and of the rules for
   ·restriction· that ·pattern· facets specified on the same step in a
   type derivation are ORed together, while ·pattern· facets specified
   on different steps of a type derivation are ANDed together.

I believe YANG is actually following XML schema here.

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