[dhcwg] Follow-up from IETF-93 (Prague) - DHCPv6 bis Issues (T1/T2 Times) - Respond by 8/24/2015

"Bernie Volz (volz)" <volz@cisco.com> Mon, 10 August 2015 15:33 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5064C1B36F4 for <dhcwg@ietfa.amsl.com>; Mon, 10 Aug 2015 08:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Em6g8YLfd_Md for <dhcwg@ietfa.amsl.com>; Mon, 10 Aug 2015 08:33:42 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9471B36EC for <dhcwg@ietf.org>; Mon, 10 Aug 2015 08:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6596; q=dns/txt; s=iport; t=1439220823; x=1440430423; h=from:to:subject:date:message-id:mime-version; bh=hgSum75qtLKet8Hsr35UN+F5Z3GyG4w+QL5GJZXtYF0=; b=gAM+9Fds07rUn+TmgEZglU5LtPg+yNCNZcSh1FyW0LZDSVzOABvCoQK+ 54QZdUCDHly/lGg3tq+BCCFJ0HIevlRIcwgF5md9DFCx1dXwwvUjvTtmR 0B2IvNyPPL3dug1xNGSWvwa6yIhotxz0J826adoD0aa83qnA3Dm91M6dy A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,646,1432598400"; d="scan'208,217";a="177176678"
Received: from rcdn-core-2.cisco.com ([]) by alln-iport-7.cisco.com with ESMTP; 10 Aug 2015 15:33:42 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com []) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7AFXfgB029550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Mon, 10 Aug 2015 15:33:41 GMT
Received: from xch-rcd-009.cisco.com ( by XCH-RCD-009.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 10:33:41 -0500
Received: from xhc-rcd-x15.cisco.com ( by xch-rcd-009.cisco.com ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 10:33:41 -0500
Received: from xmb-rcd-x04.cisco.com ([]) by xhc-rcd-x15.cisco.com ([]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 10:33:40 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Follow-up from IETF-93 (Prague) - DHCPv6 bis Issues (T1/T2 Times) - Respond by 8/24/2015
Thread-Index: AdDTgZt2vYEy0n38RM+KqYUwAa4Wtw==
Date: Mon, 10 Aug 2015 15:33:39 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CC2E924@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CC2E924xmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/TocQXqZ7xwNYHMgEncHb_Nk_ppM>
Subject: [dhcwg] Follow-up from IETF-93 (Prague) - DHCPv6 bis Issues (T1/T2 Times) - Respond by 8/24/2015
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 10 Aug 2015 15:33:44 -0000


As a follow-up from the IETF-93 (Prague) DHC WG session and the DHCPv6 bis Issues (see https://www.ietf.org/proceedings/93/slides/slides-93-dhc-7.pdf):

For slide #5, T1/T2 Times (#131), we want to confirm the WG consensus to adopt the proposal to define T1 = T2 = valid lifetime to mean client should Rebind or Solicit when lifetime expires.

Please respond if you do not agree with this proposal and please indicate why.

The rationale for this proposal is to make it clear what a server sends when it is unable to extend lifetimes on a lease (and the remaining lifetime is 'short').

-          Bernie (for draft-ietf-dhc-rfc3315bis coauthors)