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

Ladislav Lhotka <lhotka@nic.cz> Fri, 22 March 2013 18:07 UTC

Return-Path: <lhotka@nic.cz>
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 29DA121F852B for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 11:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6]
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 tFnb6KePW5jL for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 11:07:37 -0700 (PDT)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67621F8431 for <netmod@ietf.org>; Fri, 22 Mar 2013 11:07:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id EA943540472; Fri, 22 Mar 2013 19:07:35 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFcq5fIicoe9; Fri, 22 Mar 2013 19:07:28 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3DA7354032E; Fri, 22 Mar 2013 19:07:28 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Benoit Claise <bclaise@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD Working Group <netmod@ietf.org>
In-Reply-To: <514C93E9.8@cisco.com>
References: <514C93E9.8@cisco.com>
User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD Working Group <netmod@ietf.org>
Date: Fri, 22 Mar 2013 19:07:27 +0100
Message-ID: <m2obebl34w.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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
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 18:07:38 -0000

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

>
> 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
 
>
> Regards, Benoit (OPS AD)
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C