[dhcwg] [Errata Verified] RFC5007 (3763)

RFC Errata System <rfc-editor@rfc-editor.org> Sun, 02 March 2014 10:51 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 82BB01A0CC6; Sun, 2 Mar 2014 02:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 7hh2MdGLRS6B; Sun, 2 Mar 2014 02:51:55 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C003D1A0CEC; Sun, 2 Mar 2014 02:51:55 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 2FA957FC3A5; Sun, 2 Mar 2014 02:51:53 -0800 (PST)
To: damalhot@cisco.com, john_brzozowski@cable.comcast.com, kkinnear@cisco.com, volz@cisco.com, szeng@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140302105153.2FA957FC3A5@rfc-editor.org>
Date: Sun, 2 Mar 2014 02:51:53 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/UNV5Gr3D8mVhoqrlI-vdIl0_usQ
Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org, ted.lemon@nominum.com, iesg@ietf.org
Subject: [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: Sun, 02 Mar 2014 10:51:57 -0000

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