Re: [dhcwg] [Errata Verified] RFC5007 (3763)
"Hemant Singh (shemant)" <shemant@cisco.com> Tue, 04 March 2014 02:08 UTC
Return-Path: <shemant@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81CA1A02AD; Mon, 3 Mar 2014 18:08:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 y8epyXr7Rhas; Mon, 3 Mar 2014 18:08:41 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9391A0265; Mon, 3 Mar 2014 18:08:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4233; q=dns/txt; s=iport; t=1393898918; x=1395108518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M7nkHzF6H+6qRnKw0N76HJ6En3rp32MvdNeZIRYHRP0=; b=WAsOpJj13QJTwW/FXzHc6ej+uSUDjvmM6Y0lTUOdxoXp0+2XTagZNxiF 0sYMn/epD4wwiTiDMbPEsZgocPVSULw9a+KLRFekWmyeQiGcWiovZ/gwS RLrptzv/bnoygJF88ELTP9rEPmEgYpwUXpId/azlqiT6TkxU849LxirCa I=;
X-IronPort-AV: E=Sophos;i="4.97,582,1389744000"; d="scan'208";a="24669386"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 04 Mar 2014 02:08:37 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2428bKl005493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 02:08:37 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 20:08:37 -0600
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "Darpan Malhotra (damalhot)" <damalhot@cisco.com>, "john_brzozowski@cable.comcast.com" <john_brzozowski@cable.comcast.com>, "Kim Kinnear (kkinnear)" <kkinnear@cisco.com>, "Bernie Volz (volz)" <volz@cisco.com>, "szeng@cisco.com" <szeng@cisco.com>
Thread-Topic: [dhcwg] [Errata Verified] RFC5007 (3763)
Thread-Index: AQHPNgVwmlSIJ2y5pEGRAoKvx7m8R5rQMDFQ
Date: Tue, 04 Mar 2014 02:08:36 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B891160577F@xmb-rcd-x06.cisco.com>
References: <20140302105153.2FA957FC3A5@rfc-editor.org>
In-Reply-To: <20140302105153.2FA957FC3A5@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.243.24]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gon4FnYD2NKmJQu_CKq_4r1lvB4
X-Mailman-Approved-At: Tue, 04 Mar 2014 01:29:06 -0800
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "ted.lemon@nominum.com" <ted.lemon@nominum.com>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [dhcwg] [Errata Verified] RFC5007 (3763)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 02:08:44 -0000
Sorry for the delayed reply. Why change 4.3.4? If one response does not include the OPTION_CLT_TIME while another does, the current text suffices to deal with this case because there is only one OPTION_CLT_TIME to pick. Note the issue raised against 4.3.3 will not arise if the DHCPv6 server resides in a chassis supported by 1:1 redundancy on hardware cards in the chassis. Hemant -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Sunday, March 02, 2014 5:52 AM To: Darpan Malhotra (damalhot); john_brzozowski@cable.comcast.com; Kim Kinnear (kkinnear); Bernie Volz (volz); szeng@cisco.com Cc: dhcwg@ietf.org; rfc-editor@rfc-editor.org; ted.lemon@nominum.com; iesg@ietf.org Subject: [dhcwg] [Errata Verified] RFC5007 (3763) The following errata report has been verified for RFC5007, "DHCPv6 Leasequery". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5007&eid=3763 -------------------------------------- Status: Verified Type: Technical Reported by: Darpan Malhotra <damalhot@cisco.com> Date Reported: 2013-10-23 Verified by: Ted Lemon (IESG) Section: GLOBAL Original Text ------------- 4.3.3. Receipt of LEASEQUERY-REPLY 1. If the server had bindings for the requested client, the message includes an OPTION_CLIENT_DATA option and the requestor extracts the client data from the LEASEQUERY-REPLY and updates its binding information database. If the OPTION_CLIENT_DATA contains no OPTION_CLT_TIME, the requestor SHOULD silently discard the OPTION_CLIENT_DATA option. 4.3.4. Handling DHCPv6 Client Data from Multiple Sources The requestor SHOULD use the OPTION_CLT_TIME to resolve data conflicts originated from different servers, and SHOULD accept data with most recent OPTION_CLT_TIME. Corrected Text -------------- 4.3.3. Receipt of LEASEQUERY-REPLY 1. If the server had bindings for the requested client, the message includes an OPTION_CLIENT_DATA option and the requestor extracts the client data from the LEASEQUERY-REPLY and updates its binding information database. 4.3.4. Handling DHCPv6 Client Data from Multiple Sources The requestor SHOULD use the OPTION_CLT_TIME to resolve data conflicts originated from different servers, and SHOULD accept data with most recent OPTION_CLT_TIME. If OPTION_CLT_TIME is not present in a response, then response from other servers having OPTION_CLT_TIME should be preferred. Notes ----- Consider the scenario of DHCPv6 Failover (as mentioned in RFC 7031), there will be cases where only one server (Main) would have communicated with the client. Bindings for the client will be present on both servers, but the partner server (Backup) will not have Client Last Transaction Time. When a requestor sends Leasequery to the backup server, the response should not contain OPTION_CLT_TIME. Further, consider the following scenarios: 1. Requestor gets response for Leasequery from both servers (main and backup). In this scenario, response having OPTION_CLT_TIME should be preferred by the requestor. This is the justification for adding the text in Section 4.3.4. 2. Requestor gets response for Leasequery from only from one server (as other server is down). Consider main to be down. So, the requestor gets response only from Backup. The requestor should still accept this data. This is justification of removing the text from Section 4.3.3. -------------------------------------- RFC5007 (draft-ietf-dhc-dhcpv6-leasequery-01) -------------------------------------- Title : DHCPv6 Leasequery Publication Date : September 2007 Author(s) : J. Brzozowski, K. Kinnear, B. Volz, S. Zeng Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] [Technical Errata Reported] RFC5007 (3763) RFC Errata System
- [dhcwg] [Errata Verified] RFC5007 (3763) RFC Errata System
- Re: [dhcwg] [Errata Verified] RFC5007 (3763) Hemant Singh (shemant)