Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 22 March 2013 21:03 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 BBB7221F9198 for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 14:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.163
X-Spam-Level:
X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 CDIvQhFX5IYu for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 14:03:53 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A73DA21F9164 for <netmod@ietf.org>; Fri, 22 Mar 2013 14:03:52 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEC9220C27; Fri, 22 Mar 2013 22:03:51 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zup2E_XN2bFt; Fri, 22 Mar 2013 22:03:51 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4181720C26; Fri, 22 Mar 2013 22:03:51 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E6391252C387; Fri, 22 Mar 2013 22:03:54 +0100 (CET)
Date: Fri, 22 Mar 2013 22:03:54 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Benoit Claise <bclaise@cisco.com>, NETMOD Working Group <netmod@ietf.org>
Message-ID: <20130322210354.GA16103@elstar.local>
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, NETMOD Working Group <netmod@ietf.org>
References: <514C93E9.8@cisco.com> <m2obebl34w.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2obebl34w.fsf@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6021-bis-00.txt
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: Fri, 22 Mar 2013 21:03:53 -0000

On Fri, Mar 22, 2013 at 07:07:27PM +0100, Ladislav Lhotka wrote:
> Benoit Claise <bclaise@cisco.com> writes:
> 
> > Juergen, NETMOD participants,
> >
> > Two comments
> >
> > 1.
> > For the ip-address-no-zone, ipv4-address-no-zone, and 
> > ipv6-address-no-zone, don't you need a reference to the zone information 
> > in the description?
> >
> >       description
> >          "The ip-address-no-zone type represents an IP address without
> >           zone information in an IP version neutral way.  The format
> >           of the textual representations implies the IP version.";
> >
> > Doesn't give me a pointer to what a zone information is. So I don't know 
> > what ip-address-no-zone is.
> > Note: I faced the zone issue only a year ago. Before that, I had no clue 
> > what it was.
> >
> 
> Actually, I think it would be MUCH better to have "ipv4-address" with no mention of zone whatsoever, and then perhaps "ipv4-address-with-zone".
> 
> The problem with this is that it is not backwards compatible with the old revision of the module. But maybe it should be done anyway. My main concern is that an implementor will see the "ipv4-address" type and will not bother to look up the definition to realize that the client may append the zone id without breaking type validity. This could lead to nasty security holes.
> 
> And the problem is further amplified by the fact that this type is used in unions - "ip-address" and "host". 

Lada, we have been there, I believe there is no problem. And breaking
interoperability is IMHO a no go.
 
> >
> > 2.
> > The section "Appendix A. Changes from RFC 6021" is pretty light:
> >
> >       This version adds new type definitions to the YANG modules. For
> >     the further details, see the revision statement of the YANG modules.
> >
> > Take it or leave it. However, I can tell that its resolution will please 
> > some IESG members, specifically because the rfcdiff tool doesn't do a 
> > good job of comparing RFC6021 with draft-ietf-netmod-rfc6021-bis-00.txt
> >
> > Proposal
> >
> >       This version adds new type definitions to the YANG modules. The
> >     first YANG module, ietf-yang-types adds the following new data
> >     types: yang-identifier, hex-string, uuid, and dotted-quad. The
> >     second YANG module, ietf-inet-types, adds the following new data
> >     types: ip-address-no-zone, ipv4-address-no-zone, and
> >     ipv6-address-no-zone.
> 
> +1.
> 
> Lada
>  

Sure, I will do whatever pleases the IESG and other readers that do
not have the time to lookup the revision statements. ;-)

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