Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv4-active-leasequery-05

Kim Kinnear <kkinnear@cisco.com> Thu, 10 September 2015 18:44 UTC

Return-Path: <kkinnear@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED18B1B5B48 for <gen-art@ietfa.amsl.com>; Thu, 10 Sep 2015 11:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ecrciAOWthw for <gen-art@ietfa.amsl.com>; Thu, 10 Sep 2015 11:44:44 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461911B2BE2 for <gen-art@ietf.org>; Thu, 10 Sep 2015 11:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4938; q=dns/txt; s=iport; t=1441910683; x=1443120283; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=87UOjMl/mAK1drJbfmo2JnGDQEF+izPzXKqcnFq4q58=; b=XpvXxMzy99UQkJ4AQ/v/L39ym6LfvVnKW85GO2C2DGgUyf3qURJv3P48 C8+8EOrGNq/XC4it2DVWw+Ow0l4i0GlBzNeS7y7b9UJrPKa7xI9nAXMK8 InL5G7tfveAxwK7xceodGa7O9/myN6UHHtoFPpJapMZcezkXhvg/JwUS+ w=;
X-IronPort-AV: E=Sophos;i="5.17,506,1437436800"; d="scan'208";a="629650192"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Sep 2015 18:44:42 +0000
Received: from dhcp-10-131-65-131.cisco.com (dhcp-10-131-65-131.cisco.com [10.131.65.131]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8AIidxX026373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Sep 2015 18:44:40 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Kim Kinnear <kkinnear@cisco.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A4AD80@ESESSMB209.ericsson.se>
Date: Thu, 10 Sep 2015 14:44:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB4E89F4-E3D0-4C9A-B69C-96FB4872C4FC@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B37A4AD80@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
X-Authenticated-User: kkinnear
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/e9k8TyKanrXfjz-WWbdhmNYu3U8>
Cc: "draft-ietf-dhc-dhcpv4-active-leasequery.all@tools.ietf.org" <draft-ietf-dhc-dhcpv4-active-leasequery.all@tools.ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, Kim Kinnear <kkinnear@cisco.com>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv4-active-leasequery-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2015 18:44:47 -0000

Christer,

Thank you for the review.  My response to each of your issues
appears inline, below.

On Sep 6, 2015, at 9:16 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> Document:                                   draft-ietf-dhc-dhcpv4-active-leasequery-05
> Reviewer:                                     Christer Holmberg
> Review Date:                               6 September 2015
> IETF LC End Date:                       8 September 2015
> IETF Telechat Date:                   N/A
> Summary:         The document is well written, but I have a few comments and issues I’d like the authors to address.                       
> Major Issues: None
> Minor Issues: None
> Editorial Issues:
>  
> General:
> -----------
> QGEN_1:
> The text says that the document updates RFC 6926, but it is a little unclear to figure out exactly what is updated.
> I think it would be good to have an explicit “Update to RFC 6926” section which explains exactly which parts are updated.

	I will create a new section, 8.1.1, entitled "Update to RFC 6926", which 
	will contain the following words:

   In an update to the DHCPv4 Bulk Leasequery protocol [RFC6926] (which
   didn't discuss this situation explicitly), if the DHCPv4 server
   receives a DHCPv4 message containing a dhcp-message-type option with
   a value that is not supported over a TCP connection, it SHOULD close
   the TCP connection.

	And I will change the reference in the security section where this update
	is discussed from Section 8.1 to Section 8.1.1


>  
> QGEN_2:
> The draft talks about “secure mode” and “insecure mode” in a few places, and defined different procedures based on which mode is used.
> However, there is no generic definition for “secure mode” and “insecure mode”. I wonder whether it would be useful to add some text somewhere, e.g. to section 2?

	I will add both of these to Section 2, Terminology:

   o "insecure mode"

     When operating in insecure mode, the TCP connection between the
     requestor and DHCPv4 server is not protected in any way.  In
     addition, the identity of the requestor is not validated by the
     server nor is the identity of the server validated by the
     requestor.

   o "secure mode"

     When operating in secure mode, the TCP connection between the
     requestor and the DHCPv4 server is protected by TLS [RFC5246].
     In addition, the requestor uses the certificates exchanged
     between it and the DHCPv4 server while setting up the TLS
     connection to validate the identity of the server.  The DHCPv4
     server also uses these certificates to validate the identity of
     the requestor.


>  
> Abstract:
> ------------
>  
> QA_1:
>  
> The text says:
>  
> “The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been
>               extended with a Leasequery capability that allows a requestor to
>               request information about DHCPv4 bindings.”
>  
> Please indicate in which specification (RFC?) this extension has been done.

	I will add a reference to RFC 4388 to the abstract.
>  
>  
> Section 1 (Introduction):
> ---------------------------------
>  
> Q1_1:
>  
> The text says:
>  
>               “Requirements exist for external entities to keep up to date on the
>               correspondence between DHCPv4 clients and their bindings.”
>  
> Are these documented requirements, or generic requirements coming from the industry? Please clarify.

	These requirements are not documented in an RFC.  These requirements
	have come to us from users of DHCP servers in large service providers.

	In an attempt to clarify this paragraph, I will remove this sentence 
	and replace it with the one from the abstract, yielding this as the new
	paragraph:

   Continuous update of an external requestor with Leasequery data is
   sometimes desired.  These requestors need to keep up with the
   current binding activity of the DHCPv4 server.  Keeping up with
   these binding activities is termed "active" leasequery.

>  
>  
> Q1_2:
>  
> The text says:
>  
>               “This document updates DHCPv4 Bulk Leasequery [RFC6926] in that it
>               specifies the DHCPv4 server should close the TCP connection if…”
>  
> Is “should” the correct wording? Section 8.4 contains both MAY, SHOULD and MUST procedures, and I am not quite sure which procedure(s) the text above refers.

	I will add a reference to the new Section 8.1.1 in the Introduction so
	that the reference is clear.

Regards -- Kim