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

Benoit Claise <bclaise@cisco.com> Fri, 22 March 2013 22:39 UTC

Return-Path: <bclaise@cisco.com>
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 972C421F9451 for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 15:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.394
X-Spam-Level:
X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 qexiiqyZeQth for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2013 15:39:47 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F121F944B for <netmod@ietf.org>; Fri, 22 Mar 2013 15:39:47 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MMSf1T023528 for <netmod@ietf.org>; Fri, 22 Mar 2013 23:28:41 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2MMSNpw027704 for <netmod@ietf.org>; Fri, 22 Mar 2013 23:28:34 +0100 (CET)
Message-ID: <514CDAE7.401@cisco.com>
Date: Fri, 22 Mar 2013 23:27:51 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: NETMOD Working Group <netmod@ietf.org>
References: <514C93E9.8@cisco.com> <m2obebl34w.fsf@nic.cz> <20130322210354.GA16103@elstar.local>
In-Reply-To: <20130322210354.GA16103@elstar.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 22:39:48 -0000

On 22/03/2013 22:03, Juergen Schoenwaelder wrote:
> 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.
Agreed. It's 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. ;-)
The time ... or the willingness ;-)

Regards, Benoit
>
> /js
>