From internet-drafts@ietf.org Fri Jan 4 05:57:47 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B007021F894C; Fri, 4 Jan 2013 05:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfCPv36gvEPO; Fri, 4 Jan 2013 05:57:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D7421F88C4; Fri, 4 Jan 2013 05:57:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104135747.13777.40010.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 05:57:47 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:57:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RADIUS Option for DHCPv6 Relay Agents on Broadband Acces= s Server Author(s) : Leaf Y. Yeh Mohamed Boucadair Ted Lemon Filename : draft-ietf-dhc-dhcpv6-radius-opt-06.txt Pages : 11 Date : 2013-01-04 Abstract: The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-radius-opt-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ted.Lemon@nominum.com Mon Jan 7 07:51:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483BA21F890F for ; Mon, 7 Jan 2013 07:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSHRCNBSUVWf for ; Mon, 7 Jan 2013 07:51:18 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A687321F8945 for ; Mon, 7 Jan 2013 07:51:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUOru9ZiG58fhuQ+7g4HIaL4xUj93hDV0@postini.com; Mon, 07 Jan 2013 07:51:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5BCA11B817A for ; Mon, 7 Jan 2013 07:51:17 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 559AB190052 for ; Mon, 7 Jan 2013 07:51:17 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 07:51:11 -0800 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Thread-Index: AQHN3GhuXCE3BUxBlE28h7Sn+Ze5c5g+qusA Date: Mon, 7 Jan 2013 15:51:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <61F79EC97A4D9B49B627762333C46EBA@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:51:19 -0000 On Dec 17, 2012, at 10:08 AM, Ted Lemon wrote: > Based on some feedback from the working group, we have a new version of t= he triggered-reconfigure document that I think addresses the concerns that = were raised during the previous last call. For those who tuned in late, t= his document describes a mechanism for triggering a reconfigure when a rela= y agent is sending some relay options to the server, and the information in= those options has changed (e.g., the RSOO, or Leaf's RADIUS options). >=20 > So this is a second last call, so the working group can review the change= s. The diffs are here: We got two responses to this WGLC. I'm also in favor, so that makes three= , which isn't enough to advance the document. Bernie, have your objections to the previous draft been corrected in the cu= rrent draft? Others, could you please respond to this WGLC if you think t= he document should advance? Kim Kinnear, Bud Millwood, Tomek Mrugalski, T= ina Tsou and Andre Kostur commented on the document, but didn't say anythin= g in response to the WGLC. From wwwrun@rfc-editor.org Mon Jan 7 13:51:17 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F0621F87BA; Mon, 7 Jan 2013 13:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhwXswrPnB1Y; Mon, 7 Jan 2013 13:51:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AD59421F8496; Mon, 7 Jan 2013 13:51:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 54057B1E00F; Mon, 7 Jan 2013 13:41:00 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130107214100.54057B1E00F@rfc-editor.org> Date: Mon, 7 Jan 2013 13:41:00 -0800 (PST) Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 6842 on Client Identifier Option in DHCP Server Replies X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:51:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6842 Title: Client Identifier Option in DHCP Server Replies Author: N. Swamy, G. Halwasia, P. Jhingran Status: Standards Track Stream: IETF Date: January 2013 Mailbox: nn.swamy@samsung.com, ghalwasi@cisco.com, pjhingra@cisco.com Pages: 5 Characters: 10030 Updates: RFC2131 I-D Tag: draft-ietf-dhc-client-id-07.txt URL: http://www.rfc-editor.org/rfc/rfc6842.txt This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From akostur@incognito.com Wed Jan 9 09:09:58 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1521F8610 for ; Wed, 9 Jan 2013 09:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3l5YP-en5ca for ; Wed, 9 Jan 2013 09:09:57 -0800 (PST) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id B318821F85FC for ; Wed, 9 Jan 2013 09:09:56 -0800 (PST) Received: from mail-oa0-f72.google.com ([209.85.219.72]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUO2kZBYQtgGN1FqD0qhh5XkQEeoF+aHO@postini.com; Wed, 09 Jan 2013 09:09:57 PST Received: by mail-oa0-f72.google.com with SMTP id h2so5748758oag.3 for ; Wed, 09 Jan 2013 09:09:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=3zMGRjfw114B2Oln9GoBcTlFbU3GrrICGpbYTb/hS/A=; b=NdO5ci2nlscAh+RUEz+x7sWNiNytIOZMJsm589UsUQtyGj5a95yWsQlwA8dx44poYr 8OZNrHHGF5BvkwwSEnrZSV+xyweowSScZSBasgWnYWuxBDAHoFb8YOiy0akL6XRQosrA 2bujTVtqEDq9ezLh2CRC1rk/Op5hqZ8hZaJNSAOjWEQP9wCurE0rd8UkJ+Bonh5EVWIn AK8gFazp3Kz78UsgDB9TVGObRqDTZrA730eMzWYXTgD1Dx6r2uUYv19C+iN4ccGgMQ6L K7BIvSPnI6QbWvDaKAhDYbC9vjEHNpk27f8tpcPvA4aKDoxdLMZgPugSr6I1WFhr/Skq FtaA== X-Received: by 10.43.92.72 with SMTP id bp8mr52257447icc.49.1357751395724; Wed, 09 Jan 2013 09:09:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.92.72 with SMTP id bp8mr52257439icc.49.1357751395581; Wed, 09 Jan 2013 09:09:55 -0800 (PST) Received: by 10.64.51.3 with HTTP; Wed, 9 Jan 2013 09:09:55 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> Date: Wed, 9 Jan 2013 09:09:55 -0800 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnONdUAezWuDQME4GjRZFAwQUG5/kZZSiMbkmHVFNAjl1vodypnAeV6VmILSo+eptUjz5+noIkELsixvEX4k30dcSnChKORL55tYaqve63bUVCcyqfycUEx2TjV0JsHdu8n6K+7tSGTtER1IwU1yADP3n9oiQ== Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 17:09:58 -0000 Thank-you for the reminder... my turn to have been on vacation. I support this draft for advancement. On Mon, Jan 7, 2013 at 7:51 AM, Ted Lemon wrote: > On Dec 17, 2012, at 10:08 AM, Ted Lemon wrote: >> Based on some feedback from the working group, we have a new version of = the triggered-reconfigure document that I think addresses the concerns that= were raised during the previous last call. For those who tuned in late, = this document describes a mechanism for triggering a reconfigure when a rel= ay agent is sending some relay options to the server, and the information i= n those options has changed (e.g., the RSOO, or Leaf's RADIUS options). >> >> So this is a second last call, so the working group can review the chang= es. The diffs are here: > > We got two responses to this WGLC. I'm also in favor, so that makes thr= ee, which isn't enough to advance the document. > > Bernie, have your objections to the previous draft been corrected in the = current draft? Others, could you please respond to this WGLC if you think= the document should advance? Kim Kinnear, Bud Millwood, Tomek Mrugalski,= Tina Tsou and Andre Kostur commented on the document, but didn't say anyth= ing in response to the WGLC. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From volz@cisco.com Sun Jan 13 20:56:40 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770E21F86FF for ; Sun, 13 Jan 2013 20:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1iiHS1Vg0Vf for ; Sun, 13 Jan 2013 20:56:39 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7683021F8698 for ; Sun, 13 Jan 2013 20:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4852; q=dns/txt; s=iport; t=1358139399; x=1359348999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U1t76a0nhattGHebfd6vB7Ho8eWDtOmrwluMLNocscA=; b=aTPyWuod/EXuJmCB/ww2gjqbLcHjHGc/ZWmreJfh5pFFYwUa3xdACMA+ cGELriAx6m2JXHzHrBYsQCQC8rkcIjR39SPrNpwZvwwTZ+voF4S8t8RrE on9+z6u5TcXy4Qw49V6GveTyteUg5zrrOY5jt8WexfS4ZBDazcbdkCYTZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF6P81CtJXHA/2dsb2JhbABEvgUWc4IeAQEBBAEBATctBwsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQgWh3sMs24EjGsWg0xhA6ZUgnWBZz0 X-IronPort-AV: E=Sophos;i="4.84,465,1355097600"; d="scan'208";a="162006520" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jan 2013 04:56:38 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0E4ucpo006054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 04:56:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sun, 13 Jan 2013 22:56:38 -0600 From: "Bernie Volz (volz)" To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Thread-Index: AQHN7ow2IVckQpKbO0SQ+GFGR9exyZhIQy0A Date: Mon, 14 Jan 2013 04:56:37 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1843B12B@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 04:56:40 -0000 While this now does better address my earlier comments, I have more. What are the retransmission parameters / algorithm for the Reconfigure-Requ= est? (See RFC 3315 as to the algorithm there and the parameters that are us= ually specified). As there is no direct response to the Reconfigure-Request (such as a Reply)= , but instead the Relay knows if it was accepted by the fact that it gets a= (Relay-Reply containing) a Reconfigure (for the client(s)). So, I assume that the Relay might try the Reconfigure-Request again if it g= ets no Reconfigure? Perhaps the Reconfigure-Request was "lost" in the netwo= rk or the server had no resources to process the packet at the time it was = received? Also, what happens if the server has no record of one or more client's in t= he Reconfigure-Request or has not negotiated for Reconfigure support with t= hat client? As it can't generate a Reconfigure to the client, how does the = Relay know this and stop retrying? Or, are you really intending this to be a 'fire once' and hope for the best= ? Perhaps there might be some value in having some kind of Reply message as t= hen the server could say, "OK, starting reconfigure" or "OK, but failed on = some clients", or "Not allowed" or whatever? (This also has potential benef= it for the server to rate limit Reconfigures, as mentioned below as the tim= e before a 'Reconfigure' message is seen by the Relay could be variable and= thus having an explicit Reply can be a win.) I also question the requirement that the link-address cannot be 0. While I = don't know if it was ever used, I have heard of cases where people had want= ed to have no link-address (0::0) because they were going to use other info= rmation in Relay-Forw to determine the client's location. And this then req= uired that other information to be included (such as Interface-ID, etc.). I= think the Relay should include those items in the Reconfigure-Request that= it would include if it were relaying a client request -- the link-address = is just one of those items. Thus, I think you should just drop the followin= g paragraph in section 3 (the earlier requirement that it is the "equivalen= t" to what was used for Relay-Forw's for the client is sufficient!): The relay agent MUST NOT use the IPv6 unspecified address (0::0) in this option. The server MUST discard any Reconfigure Request message containing a Link Address Option that carries the unspecified address. And, perhaps we leave it as a server issue or undefined, but there might al= so be a rate limiting issue to avoid a flood of Reconfigures? The Relay has= some ability to do that in how many client identifiers it includes in a Re= configure-Request and how many Reconfigure-Request(s) it may send at what r= ate. If the Relay has 10,000 clients that all used the RSOO options that ch= anged, it would likely not want to have all 10,000 reconfigure 'at once'. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of A= ndre Kostur Sent: Wednesday, January 09, 2013 12:10 PM To: Ted Lemon Cc: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Thank-you for the reminder... my turn to have been on vacation. I support this draft for advancement. On Mon, Jan 7, 2013 at 7:51 AM, Ted Lemon wrote: > On Dec 17, 2012, at 10:08 AM, Ted Lemon wrote: >> Based on some feedback from the working group, we have a new version of = the triggered-reconfigure document that I think addresses the concerns that= were raised during the previous last call. For those who tuned in late, = this document describes a mechanism for triggering a reconfigure when a rel= ay agent is sending some relay options to the server, and the information i= n those options has changed (e.g., the RSOO, or Leaf's RADIUS options). >> >> So this is a second last call, so the working group can review the chang= es. The diffs are here: > > We got two responses to this WGLC. I'm also in favor, so that makes thr= ee, which isn't enough to advance the document. > > Bernie, have your objections to the previous draft been corrected in the = current draft? Others, could you please respond to this WGLC if you think= the document should advance? Kim Kinnear, Bud Millwood, Tomek Mrugalski,= Tina Tsou and Andre Kostur commented on the document, but didn't say anyth= ing in response to the WGLC. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Jan 14 11:15:23 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE421F8B0A for ; Mon, 14 Jan 2013 11:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcwY0ceCEWod for ; Mon, 14 Jan 2013 11:15:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C45AD21F8B1A for ; Mon, 14 Jan 2013 11:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=615; q=dns/txt; s=iport; t=1358190922; x=1359400522; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sXhaY6K9OHW8bop8Hut/P+0RIchrZJd59Bc1dxyOlUE=; b=W8///BQguFtW+9PM/N76Z5EPFwoKu3X7NRB+zAIXSIyyXn0t2AMrsI4l E/m+NaGiy9604FXgiDA1bG3yXQShfbmMJ0bH6q/FyCwvgnA2/gItkBKHn NwQb55tGMMfkzpJbixcUlu4rrbz9L/Z3ZIfFaEJP7cnsVVxiBYUMChBGn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgGABhZ9FCtJV2Y/2dsb2JhbABEhXO0UYM1FnOCHgEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIgRDLRtBIxrg2JhA6ZUgnWCJA X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162307680" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jan 2013 19:15:21 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0EJFLTU001654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 19:15:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 13:15:21 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" , "Dhc Chairs (dhc-chairs@tools.ietf.org)" Thread-Topic: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXA Date: Mon, 14 Jan 2013 19:15:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> In-Reply-To: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:15:23 -0000 A 2nd Query regarding this as I heard nothing since the first. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ernie Volz (volz) Sent: Sunday, December 02, 2012 8:26 PM To: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi: I think I had addressed the issues raised to date ... Can a last call be st= arted? Or, what else needs to be done to move this forward? - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Mon Jan 14 11:34:24 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125621F8B0A for ; Mon, 14 Jan 2013 11:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZzoF6+FgtX6 for ; Mon, 14 Jan 2013 11:34:24 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 21EC021F8835 for ; Mon, 14 Jan 2013 11:34:24 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUPRdv9HyXDLONIs9rc1+EpHEa/GH84BU@postini.com; Mon, 14 Jan 2013 11:34:24 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8BD501B8206 for ; Mon, 14 Jan 2013 11:34:23 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 829D5190052 for ; Mon, 14 Jan 2013 11:34:23 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 11:34:23 -0800 From: Ted Lemon To: dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soA= Date: Mon, 14 Jan 2013 19:34:23 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2686CBF77EAD0340A29B68782358E5BF@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:34:24 -0000 On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: > A 2nd Query regarding this as I heard nothing since the first. Oops, sorry about that, Bernie. Folks, the authors of this draft feel it's ready for a WGLC. There's been= substantial discussion and comment already. This is pretty important IPv= 6 deployment work, so more eyes are better. Please review the draft and i= ndicate whether or not you feel it is ready to be published. We have been= getting very anemic responses to working group messages recently. Your r= esponse matters, so please do respond. We will evaluate consensus after January 28. Thanks! From volz@cisco.com Mon Jan 14 11:55:38 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0F621F89B9 for ; Mon, 14 Jan 2013 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sayEW7E+YXt for ; Mon, 14 Jan 2013 11:55:37 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5F52E21F8958 for ; Mon, 14 Jan 2013 11:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3885; q=dns/txt; s=iport; t=1358193337; x=1359402937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jIXvLRHqu/EjFlB7GO5Cl4IxQg9uI2KZ6qXZ8SeL9+g=; b=LhvCNtjw43M5GPhe5vNeBiSb7JxgpZubtZi+QjCpqIJX07kL8g1sajVb wD94gWUscJz56QGERb6l8Kqs5sKr2JSmFkMORF/Iu6XiYKc7tmknnNT5M mwQh9S4ORASdvi8+k5bW3l8F6Fd9goZBk8/32CYvMEvityyqDmif3envY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIFh9FCtJV2b/2dsb2JhbABEukSDNhZzgh4BAQEEOjcIDAQCAQgRBAEBAQoUBQQHMhQJCAEBBA4FCIgRtRKMa4NiYQOmVIJ1gWYHNw X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="162282763" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jan 2013 19:55:36 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EJtaHt015559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 19:55:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 13:55:36 -0600 From: "Bernie Volz (volz)" To: Ted Lemon Thread-Topic: [dhcwg] Multiple Provisioning Domains (future work mentioned in draft-ietf-dhc-dhcpv6-stateful-issues) Thread-Index: Ac3X8EJJkzabn3NcQL+2USumBHFQCAAZBskABo40VeA= Date: Mon, 14 Jan 2013 19:55:35 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1843B96C@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F5E84B0@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747437190@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747437190@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned in draft-ietf-dhc-dhcpv6-stateful-issues) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:55:38 -0000 Ted was the only one that responded with an interest in this. Is there anyone else interested in this (perhaps you figured Ted's response= was good enough)? So, Ted, would be good for us to chat at some time to make sure we are on t= he same page. I assume: - Multiple provisioning domains can apply at any time (they are not just re= stricted to the case where one server returns IA_NA and no IA_PD or vice ve= rsa). - A client that is not multiple provisioning domain aware will behave as be= fore (it will pick 'one' of the Advertisements). Is there any advantage for= the servers to know whether a client supports multiple provisioning domain= s? (I assume not. Though on the other hand, it would just be to include the= provisioning domain name option in the ORO so perhaps it is good to requir= e this.) - A client that is multiple provisioning domain aware would potentially for= k Requests for each of the provisioning domains that it has been configured= to support. What should it do if there are no supported provisioning domai= ns (continue to Solicit -- though adhering to SOLMAX to avoid sending Solic= its too frequently). And, what if there is an Advertisement without a provi= sioning domain identified; how is that treated - process only if no Request= s issued for provisioning domains Basically there are the following situations: 1. Only advertise messages without provisioning domains. 2. Only advertise messages with provisioning domains. There may be provisio= ning domains that should be used and ones that should not be used. 3. A mix of advertise messages with and without provisioning domains. The likely basic client processing is: 1. If advertise specifies a known provisioning domain, save it (in a list f= or that provisioning domain). If server preferences is 255, start Request i= mmediately (and basically ignore any other advertisements for that provisio= ning domain but continue waiting for other Advertisements). 2. If advertise specifies a unknown provisioning domain, ignore it. There m= ight be some value in creating a list of unknown provisioning domain names = so that a user could select to use a provisioning domain in the future with= out having to know the name. 3. If advertise specifies no provisioning domain, save it (in the no-provis= ioning domain list). If server preferences is 255 ... if no allowed provisi= oning domains configured, process immediately and ignore other advertisemen= ts. Otherwise, probably want to place this at the top of the no-provisionin= g domain list but continue waiting until timeout for other advertisements f= or known provisioning domains. When timeout is reached, process any Advertisements received for known prov= isioning domains. If none (or perhaps always?), also process the 'no provis= ioning domain' list. There's also Rapid-Commit to consider. I think that would basically be simi= lar except of course there is no need to send a Request (just process the R= eply). Or, did you have a different model in mind? May be best to discuss via phone and post some notes (or just the I-D) when= done? - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Tuesday, December 11, 2012 9:35 PM To: Bernie Volz (volz) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned i= n draft-ietf-dhc-dhcpv6-stateful-issues) On Dec 11, 2012, at 5:39 PM, Bernie Volz (volz) wrote: > If there is someone that believes they have a need for this or feels stro= ngly that a draft to address this exist, please let me (or the WG) know so = that perhaps we can partner on this draft and make use of those real world = requirements. Yes, _please_! I've been feeling guilty about not writing this for at lea= st a year now. From akostur@incognito.com Mon Jan 14 12:57:12 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02621F8AE3 for ; Mon, 14 Jan 2013 12:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vncMZBbuV6AQ for ; Mon, 14 Jan 2013 12:57:11 -0800 (PST) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id 4E97221F8859 for ; Mon, 14 Jan 2013 12:57:10 -0800 (PST) Received: from mail-oa0-f69.google.com ([209.85.219.69]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUPRxJh0BEPN+QCKYeb1ARma4F91LZGsu@postini.com; Mon, 14 Jan 2013 12:57:11 PST Received: by mail-oa0-f69.google.com with SMTP id j6so21353814oag.0 for ; Mon, 14 Jan 2013 12:57:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=PBiMvYTlfbsJG2EicihbesW9R0OKX89F1xi7r8VIenY=; b=VTgNwMo/em7qq0TMUe6T0UaEoW/OJ+rXgd4u8Ae9f6zq0k/dzVL/6gxEKxiH/GeIjW k2d3rzauOc8VKEnoeAjsqRVSC2ng7T/G7jwf3Aag7LKlBZ6dSQWOllbnD2ej+4KcT3oQ bW44OhWsan1AedgZmkxiTzq4Z4h98/seqRJDze0UB4yKXBEgeDuj9r8tAnMyaRSfMLvz zugs1v7gSJUYsogzRfH8KVDpjjY1KWjYQwflwLtcX0uWYtdsBLlL641BR+3I4fMVUjM0 TxLsPN+su3O3W+uMYYlJWtVjxTrABJmjFd/cJsfR2//au/mmN3kpgHhRx24Xba0cHbOu cY6Q== X-Received: by 10.50.89.163 with SMTP id bp3mr7977076igb.89.1358196532939; Mon, 14 Jan 2013 12:48:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.89.163 with SMTP id bp3mr7977069igb.89.1358196532804; Mon, 14 Jan 2013 12:48:52 -0800 (PST) Received: by 10.64.51.3 with HTTP; Mon, 14 Jan 2013 12:48:52 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1843B96C@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E0F5E84B0@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747437190@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E1843B96C@xmb-rcd-x04.cisco.com> Date: Mon, 14 Jan 2013 12:48:52 -0800 Message-ID: From: Andre Kostur To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlPyYnigHGP7FHDX5ZIrn7D7MNZ169gvLbN+hqunOgY1EimjsfV0kcxLo8dOZRa6Fd1ulY5TzKHwHQ7VxqebdLoi/WnK2vTxmTUjcE/BnVDTDTeYTWUryM2cB6xLQuZqv13WK4gB4Vqb1DlbRofMqUa0DOWKQ== Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned in draft-ietf-dhc-dhcpv6-stateful-issues) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:57:12 -0000 Should some of those decisions be left to a client-side policy decision as to whether it will prefer a particular provisioning domain vs. require a particular provisioning domain? On the server-side, I think the server would only need to know that it is responding with a provisioning domain, perhaps keyed off of whether the client did an ORO for a provisioning domain, plus preference. On Mon, Jan 14, 2013 at 11:55 AM, Bernie Volz (volz) wrote= : > Ted was the only one that responded with an interest in this. > > Is there anyone else interested in this (perhaps you figured Ted's respon= se was good enough)? > > So, Ted, would be good for us to chat at some time to make sure we are on= the same page. I assume: > - Multiple provisioning domains can apply at any time (they are not just = restricted to the case where one server returns IA_NA and no IA_PD or vice = versa). > - A client that is not multiple provisioning domain aware will behave as = before (it will pick 'one' of the Advertisements). Is there any advantage f= or the servers to know whether a client supports multiple provisioning doma= ins? (I assume not. Though on the other hand, it would just be to include t= he provisioning domain name option in the ORO so perhaps it is good to requ= ire this.) > - A client that is multiple provisioning domain aware would potentially f= ork Requests for each of the provisioning domains that it has been configur= ed to support. What should it do if there are no supported provisioning dom= ains (continue to Solicit -- though adhering to SOLMAX to avoid sending Sol= icits too frequently). And, what if there is an Advertisement without a pro= visioning domain identified; how is that treated - process only if no Reque= sts issued for provisioning domains > > Basically there are the following situations: > > 1. Only advertise messages without provisioning domains. > 2. Only advertise messages with provisioning domains. There may be provis= ioning domains that should be used and ones that should not be used. > 3. A mix of advertise messages with and without provisioning domains. > > The likely basic client processing is: > > 1. If advertise specifies a known provisioning domain, save it (in a list= for that provisioning domain). If server preferences is 255, start Request= immediately (and basically ignore any other advertisements for that provis= ioning domain but continue waiting for other Advertisements). > 2. If advertise specifies a unknown provisioning domain, ignore it. There= might be some value in creating a list of unknown provisioning domain name= s so that a user could select to use a provisioning domain in the future wi= thout having to know the name. > 3. If advertise specifies no provisioning domain, save it (in the no-prov= isioning domain list). If server preferences is 255 ... if no allowed provi= sioning domains configured, process immediately and ignore other advertisem= ents. Otherwise, probably want to place this at the top of the no-provision= ing domain list but continue waiting until timeout for other advertisements= for known provisioning domains. > > When timeout is reached, process any Advertisements received for known pr= ovisioning domains. If none (or perhaps always?), also process the 'no prov= isioning domain' list. > > There's also Rapid-Commit to consider. I think that would basically be si= milar except of course there is no need to send a Request (just process the= Reply). > > Or, did you have a different model in mind? > > May be best to discuss via phone and post some notes (or just the I-D) wh= en done? > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, December 11, 2012 9:35 PM > To: Bernie Volz (volz) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Multiple Provisioning Domains (future work mentioned= in draft-ietf-dhc-dhcpv6-stateful-issues) > > On Dec 11, 2012, at 5:39 PM, Bernie Volz (volz) wrote: >> If there is someone that believes they have a need for this or feels str= ongly that a draft to address this exist, please let me (or the WG) know so= that perhaps we can partner on this draft and make use of those real world= requirements. > > Yes, _please_! I've been feeling guilty about not writing this for at l= east a year now. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From ghalwasi@cisco.com Mon Jan 14 19:46:46 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD27321F87ED for ; Mon, 14 Jan 2013 19:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kWYbgXnI1e5 for ; Mon, 14 Jan 2013 19:46:45 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C63B521F87D9 for ; Mon, 14 Jan 2013 19:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1358221606; x=1359431206; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6d5PwPHaHIZLBNSAd2VOBy3ob6+IYZKyBpuPgXcPqH4=; b=FJT8C52J7TSO+p1tUmWgH0wFdk9vqZlz8qFySmJBtVJc+jAJlZnyqkpT QGbo/0EHF4+vOnVrY6KxBNUtD2kLJQZdsNpYQZEgj7KoQVuHTVjpoajHY WcVnrlotYZDElABhEjc8/e4izwlu6hyagsNKhpgk1bIdA/2ggYbioUV06 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAKXQ9FCtJXG8/2dsb2JhbABEujqDOBZzgh4BAQEEAQEBNzQXBAIBCBEEAQEBChQJBycLFAkIAQEEARIIiBEMp3SOIwSQTWEDplSCaA2CJA X-IronPort-AV: E=Sophos;i="4.84,469,1355097600"; d="scan'208";a="162390564" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 15 Jan 2013 03:46:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0F3kjij027728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 03:46:45 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.172]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 21:46:45 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soAAAQ+uMA== Date: Tue, 15 Jan 2013 03:46:44 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 03:46:46 -0000 I read/reviewed this document and I support this document to move forward. I do have some comments and it would be good if authors can consider them. = Even otherwise I support this document.=20 1.) In Abstract :- "Implementation experience of the CPE model described in has shown multiple issues" I think you wanted to specify RFC6204 after "described in" 2.) Section 4.2 Placement of Status codes. In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, NoBinding) are encapsulated in the IA option. I think we should include "NoPrefixAvail" as well in the above line. I see = no reason why it should not be. 3.) For Confirm message. As I understand, we are now allowing CONFIRM messa= ge for IA_PD. I think we should update the definition of CONFIRM message in= RFC3315 which currently only talks about *address* CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: > A 2nd Query regarding this as I heard nothing since the first. Oops, sorry about that, Bernie. Folks, the authors of this draft feel it's ready for a WGLC. There's been= substantial discussion and comment already. This is pretty important IPv= 6 deployment work, so more eyes are better. Please review the draft and i= ndicate whether or not you feel it is ready to be published. We have been= getting very anemic responses to working group messages recently. Your r= esponse matters, so please do respond. We will evaluate consensus after January 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Tue Jan 15 06:50:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA54421F869A; Tue, 15 Jan 2013 06:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM1jrmn-eR1X; Tue, 15 Jan 2013 06:50:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC2621F869F; Tue, 15 Jan 2013 06:50:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115145012.8386.70398.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 06:50:12 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-12.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:50:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : The DHCPv4 Relay Agent Identifier Suboption Author(s) : Bharat Joshi D.T.V Ramakrishna Rao Mark Stapp Filename : draft-ietf-dhc-relay-id-suboption-12.txt Pages : 9 Date : 2013-01-15 Abstract: This document defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-id-suboption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-relay-id-suboption-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-id-suboption-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From volz@cisco.com Tue Jan 15 13:07:52 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA0E21F8415 for ; Tue, 15 Jan 2013 13:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBx8W8mjGoUA for ; Tue, 15 Jan 2013 13:07:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 31E7921F8230 for ; Tue, 15 Jan 2013 13:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1358284072; x=1359493672; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HY3adh7lwoQ9LGX7EJ7cyI8USTX9f6WTOY49OTEUy34=; b=bUdlGYw2qDqRyIFUsa5xZ8fj3LKy9+ZZfY6jhZHxzk69Omsc35ypTNBy bLxtApxPNueCbK8Jgus5JEXh1S/kFVRaGQOxCIg5GZJSnEuaCel2CWjoO Vn+K9AlF7Per1Fvy14e0i5aoxBs7JFnA9z3+SnFi1dbycuzQUS6JTVQG7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAO/D9VCtJV2Y/2dsb2JhbABFuj6DSRZzgh4BAQEEAQEBNzQXBAIBCBEEAQEBChQJBycLFAkIAQEEARIIiBEMqDaOdwSQV2EDplWCdYIk X-IronPort-AV: E=Sophos;i="4.84,475,1355097600"; d="scan'208";a="162798573" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 15 Jan 2013 21:07:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0FL7piw011680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 21:07:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 15:07:50 -0600 From: "Bernie Volz (volz)" To: "Gaurav Halwasia (ghalwasi)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soAAAQ+uMAAjJu7g Date: Tue, 15 Jan 2013 21:07:50 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:07:53 -0000 Hi: Thanks for the comments, I've made some comments below (BV>). Let's wait until the 28th before I draft the -04 version. Hopefully there w= ill be more comments! - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of G= aurav Halwasia (ghalwasi) Sent: Monday, January 14, 2013 10:47 PM To: Ted Lemon; dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 I read/reviewed this document and I support this document to move forward. I do have some comments and it would be good if authors can consider them. = Even otherwise I support this document.=20 1.) In Abstract :- "Implementation experience of the CPE model described in has shown multiple issues" I think you wanted to specify RFC6204 after "described in" BV> Yes.=20 2.) Section 4.2 Placement of Status codes. In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, NoBinding) are encapsulated in the IA option. I think we should include "NoPrefixAvail" as well in the above line. I see = no reason why it should not be. BV> Yes. Might be best to use (i.e.) too so that it is clear that this is j= ust a partial list. 3.) For Confirm message. As I understand, we are now allowing CONFIRM messa= ge for IA_PD. I think we should update the definition of CONFIRM message in= RFC3315 which currently only talks about *address* CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocatio= n. A RFC 3315bis would definitely want to reword it as such (as I would exp= ect it to combine 3315 and 3633). This really falls into the changes to RFC= 3633 that it would extend Confirm to include prefixes. We tried (I hope) t= o keep the RFC 3315 changes consistent with what RFC 3315 contained and PD = changes to RFC 3633. There might be more we could add to RFC 3633, but do w= e really think that is necessary? I guess we could replace "addresses" with= something more generic ("configuration information explicitly assigned to = the client", which comes from the definition of binding in RFC 3315), but I= think that doesn't really improve anything. BV> Thus, I will not make this change. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: > A 2nd Query regarding this as I heard nothing since the first. Oops, sorry about that, Bernie. Folks, the authors of this draft feel it's ready for a WGLC. There's been= substantial discussion and comment already. This is pretty important IPv= 6 deployment work, so more eyes are better. Please review the draft and i= ndicate whether or not you feel it is ready to be published. We have been= getting very anemic responses to working group messages recently. Your r= esponse matters, so please do respond. We will evaluate consensus after January 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ghalwasi@cisco.com Tue Jan 15 20:43:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2411E80FC for ; Tue, 15 Jan 2013 20:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7U1XGu0JkhY for ; Tue, 15 Jan 2013 20:43:23 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A82FA11E80E1 for ; Tue, 15 Jan 2013 20:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4019; q=dns/txt; s=iport; t=1358311402; x=1359521002; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=B4xEL6k4EGFDpBhBEPyhSPD2dkPdCyE7fKgyYTFwnaU=; b=PDbLGfBTBOIBhEWSoZiA2I9m+4gFnW3pb0uxWDHlNexXyaOx+aTJig5k 7CzeGLz3Es/Ettnzf1kT3gPVWMVv3SzLxf7Jmj9yEDQ7RD8XO5Mi9VDry VsEyUquIuqkMDX2VlaIq97PWRBC7nVeG1vmT8w90843pm6SPxiylBj57o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAP8u9lCtJV2a/2dsb2JhbABFukODSxZzgh4BAQEEAQEBNzQXBAIBCBEEAQEBChQJBycLFAkIAQEEARIIiBEMtz0EkFdhA6ZVgnWCJA X-IronPort-AV: E=Sophos;i="4.84,476,1355097600"; d="scan'208";a="162753345" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 16 Jan 2013 04:43:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0G4hLrn018239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 04:43:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.172]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 22:43:21 -0600 From: "Gaurav Halwasia (ghalwasi)" To: "Bernie Volz (volz)" , Ted Lemon , dhc WG Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soAAAQ+uMAAjJu7gABBy2LA= Date: Wed, 16 Jan 2013 04:43:20 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 04:43:25 -0000 Thanks for taking care of comments. I agree with you point regarding point = (3). -Gaurav -----Original Message----- From: Bernie Volz (volz)=20 Sent: Wednesday, January 16, 2013 2:38 AM To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Hi: Thanks for the comments, I've made some comments below (BV>). Let's wait until the 28th before I draft the -04 version. Hopefully there w= ill be more comments! - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of G= aurav Halwasia (ghalwasi) Sent: Monday, January 14, 2013 10:47 PM To: Ted Lemon; dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 I read/reviewed this document and I support this document to move forward. I do have some comments and it would be good if authors can consider them. = Even otherwise I support this document.=20 1.) In Abstract :- "Implementation experience of the CPE model described in has shown multiple issues" I think you wanted to specify RFC6204 after "described in" BV> Yes.=20 2.) Section 4.2 Placement of Status codes. In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, NoBinding) are encapsulated in the IA option. I think we should include "NoPrefixAvail" as well in the above line. I see = no reason why it should not be. BV> Yes. Might be best to use (i.e.) too so that it is clear that this is j= ust a partial list. 3.) For Confirm message. As I understand, we are now allowing CONFIRM messa= ge for IA_PD. I think we should update the definition of CONFIRM message in= RFC3315 which currently only talks about *address* CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocatio= n. A RFC 3315bis would definitely want to reword it as such (as I would exp= ect it to combine 3315 and 3633). This really falls into the changes to RFC= 3633 that it would extend Confirm to include prefixes. We tried (I hope) t= o keep the RFC 3315 changes consistent with what RFC 3315 contained and PD = changes to RFC 3633. There might be more we could add to RFC 3633, but do w= e really think that is necessary? I guess we could replace "addresses" with= something more generic ("configuration information explicitly assigned to = the client", which comes from the definition of binding in RFC 3315), but I= think that doesn't really improve anything. BV> Thus, I will not make this change. Thanks, Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, January 15, 2013 1:04 AM To: dhc WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: > A 2nd Query regarding this as I heard nothing since the first. Oops, sorry about that, Bernie. Folks, the authors of this draft feel it's ready for a WGLC. There's been= substantial discussion and comment already. This is pretty important IPv= 6 deployment work, so more eyes are better. Please review the draft and i= ndicate whether or not you feel it is ready to be published. We have been= getting very anemic responses to working group messages recently. Your r= esponse matters, so please do respond. We will evaluate consensus after January 28. Thanks! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From mohamed.boucadair@orange.com Wed Jan 16 05:01:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27021F86FF for ; Wed, 16 Jan 2013 05:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwb5Y4GWT+Xk for ; Wed, 16 Jan 2013 05:01:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2721F86BE for ; Wed, 16 Jan 2013 05:01:12 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E41FD264354; Wed, 16 Jan 2013 14:01:10 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BF2D023807C; Wed, 16 Jan 2013 14:01:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 16 Jan 2013 14:01:10 +0100 From: To: "Bernie Volz (volz)" , dhc WG Date: Wed, 16 Jan 2013 14:01:08 +0100 Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Thread-Index: AQHN7ow2IVckQpKbO0SQ+GFGR9exyZhIQy0AgAG92SA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EA601E3D7@PUEXCB1B.nanterre.francetelecom.fr> References: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E1843B12B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1843B12B@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 13:01:13 -0000 Dear Bernie, Many thanks for the review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com]=20 >Envoy=E9 : lundi 14 janvier 2013 05:57 >=C0 : dhc WG >Cc : BOUCADAIR Mohamed OLNC/OLN; POUGNARD Xavier OLNC/OLN >Objet : RE: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 > >While this now does better address my earlier comments, I have more. > >What are the retransmission parameters / algorithm for the=20 >Reconfigure-Request? (See RFC 3315 as to the algorithm there=20 >and the parameters that are usually specified). > >As there is no direct response to the Reconfigure-Request=20 >(such as a Reply), but instead the Relay knows if it was=20 >accepted by the fact that it gets a (Relay-Reply containing) a=20 >Reconfigure (for the client(s)). > >So, I assume that the Relay might try the Reconfigure-Request=20 >again if it gets no Reconfigure? Perhaps the=20 >Reconfigure-Request was "lost" in the network or the server=20 >had no resources to process the packet at the time it was received? > >Also, what happens if the server has no record of one or more=20 >client's in the Reconfigure-Request or has not negotiated for=20 >Reconfigure support with that client? As it can't generate a=20 >Reconfigure to the client, how does the Relay know this and=20 >stop retrying? > >Or, are you really intending this to be a 'fire once' and hope=20 >for the best? Med: The scheme I had in mind is re-transmission is triggered by out-of-ban= d mechanism controlling the relay. I do agree this may not be generic and a= s such I see a value in defining a re-transmission procedure in the relay i= tself (the default values for the retrans parameters would be identical to = those in RFC5007 + relay monitors the reconfigure messages received from th= e server or the expected request from the client). The re-transmission proc= edure can be disabled by configuration if an out-of-band mechanism is used.= If retrans is enabled in the relay, retrans parameters should be configura= ble. If you agree with the proposed logic, I can propose some text in this direc= tion.=20 > >Perhaps there might be some value in having some kind of Reply=20 >message as then the server could say, "OK, starting=20 >reconfigure" or "OK, but failed on some clients", or "Not=20 >allowed" or whatever? (This also has potential benefit for the=20 >server to rate limit Reconfigures, as mentioned below as the=20 >time before a 'Reconfigure' message is seen by the Relay could=20 >be variable and thus having an explicit Reply can be a win.) Med: Defining an explicit response to the reconfigure-request is imho redun= dant with the receipt of a reconfigure message from the server (or receipt = of a request from the client to request for the updated config).=20 > > >I also question the requirement that the link-address cannot=20 >be 0. While I don't know if it was ever used, I have heard of=20 >cases where people had wanted to have no link-address (0::0)=20 >because they were going to use other information in Relay-Forw=20 >to determine the client's location. And this then required=20 >that other information to be included (such as Interface-ID,=20 >etc.). I think the Relay should include those items in the=20 >Reconfigure-Request that it would include if it were relaying=20 >a client request -- the link-address is just one of those=20 >items. Thus, I think you should just drop the following=20 >paragraph in section 3 (the earlier requirement that it is the=20 >"equivalent" to what was used for Relay-Forw's for the client=20 >is sufficient!): > > The relay agent MUST NOT use the IPv6 unspecified address (0::0) in > this option. The server MUST discard any Reconfigure=20 >Request message > containing a Link Address Option that carries the unspecified > address. > Med: Isn't odd to include a "Link Address Option" which carries a link-addr= ess set to "0::0"?=20 If you think there is a value to cover the scenario you described, wouldn't= be better to relax the text to explicitly allow the use of Interface-ID if= link-address =3D0::0 (but no "Link Address Option" is included). In other = words, my proposal is: * maintain the definition of "Link Address Option" as it is in the current = version. * if link-address=3D0:0, update the validation text to include to require i= ncluding Interface-ID. Do you agree/disagree with this proposition? > >And, perhaps we leave it as a server issue or undefined, but=20 >there might also be a rate limiting issue to avoid a flood of=20 >Reconfigures? The Relay has some ability to do that in how=20 >many client identifiers it includes in a Reconfigure-Request=20 >and how many Reconfigure-Request(s) it may send at what rate.=20 >If the Relay has 10,000 clients that all used the RSOO options=20 >that changed, it would likely not want to have all 10,000=20 >reconfigure 'at once'. Med: Would you be fine If the text is updated to reflect the following:=20 * The server MUST implement a local policy to rate-limit reconfigure messag= es triggered by a reconfigure-request.=20 * The relay SHOULD be configured with the maximum number of distinct client= identifiers to be included in the same reconfigure-request message. > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of Andre Kostur >Sent: Wednesday, January 09, 2013 12:10 PM >To: Ted Lemon >Cc: dhc WG >Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 > >Thank-you for the reminder... my turn to have been on vacation. > >I support this draft for advancement. > >On Mon, Jan 7, 2013 at 7:51 AM, Ted Lemon=20 > wrote: >> On Dec 17, 2012, at 10:08 AM, Ted Lemon=20 > wrote: >>> Based on some feedback from the working group, we have a=20 >new version of the triggered-reconfigure document that I think=20 >addresses the concerns that were raised during the previous=20 >last call. For those who tuned in late, this document=20 >describes a mechanism for triggering a reconfigure when a=20 >relay agent is sending some relay options to the server, and=20 >the information in those options has changed (e.g., the RSOO,=20 >or Leaf's RADIUS options). >>> >>> So this is a second last call, so the working group can=20 >review the changes. The diffs are here: >> >> We got two responses to this WGLC. I'm also in favor, so=20 >that makes three, which isn't enough to advance the document. >> >> Bernie, have your objections to the previous draft been=20 >corrected in the current draft? Others, could you please=20 >respond to this WGLC if you think the document should advance?=20 > Kim Kinnear, Bud Millwood, Tomek Mrugalski, Tina Tsou and=20 >Andre Kostur commented on the document, but didn't say=20 >anything in response to the WGLC. >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > > >-- >Andre Kostur >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From volz@cisco.com Wed Jan 16 07:10:13 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F3C21F8A05 for ; Wed, 16 Jan 2013 07:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUXofqhTuhb0 for ; Wed, 16 Jan 2013 07:10:12 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 76E1621F8935 for ; Wed, 16 Jan 2013 07:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8880; q=dns/txt; s=iport; t=1358349012; x=1359558612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mbAZgIyVAARTvcmMJaCwZjoXINjq0ijECPZuU5BIqEQ=; b=VMA/HkbvFKzoVSlISD45RO1+fMIVoPWWsBrcmY/GCJ2GoviAAN6X8Gh3 fe5cRUHq0pZdSBWflp9IBaGhuir9efErkckYpjSahZ7QiNk8ExpvhL6kZ 4Qo4NBfbAjL4oHuR2lFKpy4i5W67W70xw4/X4oyfIojrKkQakIjT3zeu3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAJnB9lCtJXG9/2dsb2JhbABFukSDQxZzgh4BAQEEAQEBZAcLDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIFod7DLgSBIx1FoNMYQOILJ4pgnWBZwEeBhg X-IronPort-AV: E=Sophos;i="4.84,479,1355097600"; d="scan'208";a="163203745" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jan 2013 15:10:11 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0GFABB5030407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jan 2013 15:10:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 09:10:11 -0600 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Thread-Index: AQHN7ow2IVckQpKbO0SQ+GFGR9exyZhIQy0AgAG92SCAAhTNgA== Date: Wed, 16 Jan 2013 15:10:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1843E628@xmb-rcd-x04.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63074743D696@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074745EBA7@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E1843B12B@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EA601E3D7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA601E3D7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.232] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 15:10:13 -0000 Hi: 1. I think the link-address option should always be present, even if it has= 0::0. Just remove that one paragraph about it not being 0::0. 2. Whether interface-id and other Relay options are present is worth discus= sing. The main reason for including interface-id in Relay-Forw/Relay-Reply = is that it is sent back to Relay. That is not necessary in this case (as th= ere is no Reply). I guess my choice would be silent as to the issue -- or t= o indicate that Relay options normally included in the Relay-Forw MAY (SHOU= LD?) be added. (See #4 which may suggest making this a MUST or SHOULD.) 3. Just limiting the number of client-ids in a Reconfigure-Request is insuf= ficient as the Relay can just send more packets. It is really the "total" t= hat is important. Rate limiting the packets is also important -- Relay shou= ldn't blast out 100 packets at once. 4. If the server rate limits the reconfigures, the Relay may have to wait a= long time (many 10s of seconds or minutes) if a lot of Reconfigures are re= quested. This may complicate the any retransmissions of the Reconfigure-Req= uest or result in duplicated requests (not necessarily the messages, but th= e clients being reconfigured). I still think having a Reply has some value,= IMHO. - Bernie -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Wednesday, January 16, 2013 8:01 AM To: Bernie Volz (volz); dhc WG Cc: POUGNARD Xavier OLNC/OLN Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 Dear Bernie, Many thanks for the review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@cisco.com] Envoy=E9 : lundi 14=20 >janvier 2013 05:57 =C0 : dhc WG Cc : BOUCADAIR Mohamed OLNC/OLN; POUGNARD= =20 >Xavier OLNC/OLN Objet : RE: [dhcwg] WGLC:=20 >draft-ietf-dhc-triggered-reconfigure-02 > >While this now does better address my earlier comments, I have more. > >What are the retransmission parameters / algorithm for the=20 >Reconfigure-Request? (See RFC 3315 as to the algorithm there and the=20 >parameters that are usually specified). > >As there is no direct response to the Reconfigure-Request (such as a=20 >Reply), but instead the Relay knows if it was accepted by the fact that=20 >it gets a (Relay-Reply containing) a Reconfigure (for the client(s)). > >So, I assume that the Relay might try the Reconfigure-Request again if=20 >it gets no Reconfigure? Perhaps the Reconfigure-Request was "lost" in=20 >the network or the server had no resources to process the packet at the=20 >time it was received? > >Also, what happens if the server has no record of one or more client's=20 >in the Reconfigure-Request or has not negotiated for Reconfigure=20 >support with that client? As it can't generate a Reconfigure to the=20 >client, how does the Relay know this and stop retrying? > >Or, are you really intending this to be a 'fire once' and hope for the=20 >best? Med: The scheme I had in mind is re-transmission is triggered by out-of-ban= d mechanism controlling the relay. I do agree this may not be generic and a= s such I see a value in defining a re-transmission procedure in the relay i= tself (the default values for the retrans parameters would be identical to = those in RFC5007 + relay monitors the reconfigure messages received from th= e server or the expected request from the client). The re-transmission proc= edure can be disabled by configuration if an out-of-band mechanism is used.= If retrans is enabled in the relay, retrans parameters should be configura= ble. If you agree with the proposed logic, I can propose some text in this direc= tion.=20 > >Perhaps there might be some value in having some kind of Reply message=20 >as then the server could say, "OK, starting reconfigure" or "OK, but=20 >failed on some clients", or "Not allowed" or whatever? (This also has=20 >potential benefit for the server to rate limit Reconfigures, as=20 >mentioned below as the time before a 'Reconfigure' message is seen by=20 >the Relay could be variable and thus having an explicit Reply can be a=20 >win.) Med: Defining an explicit response to the reconfigure-request is imho redun= dant with the receipt of a reconfigure message from the server (or receipt = of a request from the client to request for the updated config).=20 > > >I also question the requirement that the link-address cannot be 0.=20 >While I don't know if it was ever used, I have heard of cases where=20 >people had wanted to have no link-address (0::0) because they were=20 >going to use other information in Relay-Forw to determine the client's=20 >location. And this then required that other information to be included=20 >(such as Interface-ID, etc.). I think the Relay should include those=20 >items in the Reconfigure-Request that it would include if it were=20 >relaying a client request -- the link-address is just one of those=20 >items. Thus, I think you should just drop the following paragraph in=20 >section 3 (the earlier requirement that it is the "equivalent" to what=20 >was used for Relay-Forw's for the client is sufficient!): > > The relay agent MUST NOT use the IPv6 unspecified address (0::0) in > this option. The server MUST discard any Reconfigure Request=20 >message > containing a Link Address Option that carries the unspecified > address. > Med: Isn't odd to include a "Link Address Option" which carries a link-addr= ess set to "0::0"?=20 If you think there is a value to cover the scenario you described, wouldn't= be better to relax the text to explicitly allow the use of Interface-ID if= link-address =3D0::0 (but no "Link Address Option" is included). In other = words, my proposal is: * maintain the definition of "Link Address Option" as it is in the current = version. * if link-address=3D0:0, update the validation text to include to require i= ncluding Interface-ID. Do you agree/disagree with this proposition? > >And, perhaps we leave it as a server issue or undefined, but there=20 >might also be a rate limiting issue to avoid a flood of Reconfigures?=20 >The Relay has some ability to do that in how many client identifiers it=20 >includes in a Reconfigure-Request and how many Reconfigure-Request(s)=20 >it may send at what rate. >If the Relay has 10,000 clients that all used the RSOO options that=20 >changed, it would likely not want to have all 10,000 reconfigure 'at=20 >once'. Med: Would you be fine If the text is updated to reflect the following:=20 * The server MUST implement a local policy to rate-limit reconfigure messag= es triggered by a reconfigure-request.=20 * The relay SHOULD be configured with the maximum number of distinct client= identifiers to be included in the same reconfigure-request message. > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 >Of Andre Kostur >Sent: Wednesday, January 09, 2013 12:10 PM >To: Ted Lemon >Cc: dhc WG >Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-02 > >Thank-you for the reminder... my turn to have been on vacation. > >I support this draft for advancement. > >On Mon, Jan 7, 2013 at 7:51 AM, Ted Lemon =20 >wrote: >> On Dec 17, 2012, at 10:08 AM, Ted Lemon > wrote: >>> Based on some feedback from the working group, we have a >new version of the triggered-reconfigure document that I think=20 >addresses the concerns that were raised during the previous >last call. For those who tuned in late, this document=20 >describes a mechanism for triggering a reconfigure when a relay agent=20 >is sending some relay options to the server, and the information in=20 >those options has changed (e.g., the RSOO, or Leaf's RADIUS options). >>> >>> So this is a second last call, so the working group can >review the changes. The diffs are here: >> >> We got two responses to this WGLC. I'm also in favor, so=20 >that makes three, which isn't enough to advance the document. >> >> Bernie, have your objections to the previous draft been >corrected in the current draft? Others, could you please=20 >respond to this WGLC if you think the document should advance?=20 > Kim Kinnear, Bud Millwood, Tomek Mrugalski, Tina Tsou and Andre=20 >Kostur commented on the document, but didn't say anything in response=20 >to the WGLC. >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > > > >-- >Andre Kostur >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg > From budmillwood@gmail.com Mon Jan 21 07:28:22 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8355021F854C for ; Mon, 21 Jan 2013 07:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDJGBRcEoCqI for ; Mon, 21 Jan 2013 07:28:21 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF421F8558 for ; Mon, 21 Jan 2013 07:28:21 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id k1so6169015oag.30 for ; Mon, 21 Jan 2013 07:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gw7xjKtZSBUHAa3lT724l72KmMU0Nbxkgb5CXutc5JM=; b=OIc4jJSQkEt/jfPG42S8AIJ+XrWx7ST+JOmtOJeu/vFUumBLK2UmkCpBxE/ElhHy/S s9nAW+hei4KYE/pJGOQ6pjGHeBseMIm/Krrlyx7zqUNpJ5ej9ZlMZFXwa2WN2MuiUxQa PRoNErreRS44vWfyLcSyplyupPBKUB14ck+RTevlHGjpMwpUZItylsdnBB+y7aLgNULf nHWGnHImBrymrd5Vl/ErsuJd43QQirPTHbnaqWW1mPwEkEzs5XXsZ7ZnqBROA6IEZYn3 SrlVpQl+jPz7zmtkUQ9XTO/4W/6NsTlerHs0x5TNma5HzLST0Rrw+KZsaUIDztaFGp2u VDjQ== MIME-Version: 1.0 X-Received: by 10.60.32.193 with SMTP id l1mr13866469oei.114.1358782101078; Mon, 21 Jan 2013 07:28:21 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.60.80.166 with HTTP; Mon, 21 Jan 2013 07:28:20 -0800 (PST) In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> Date: Mon, 21 Jan 2013 16:28:20 +0100 X-Google-Sender-Auth: z23c1umzSk1MfITqWUXf_lJNpUM Message-ID: From: Bud Millwood To: "Gaurav Halwasia (ghalwasi)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , "Bernie Volz \(volz\)" , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:28:22 -0000 4.2: Proposed solution: No change. For backwards compatibility, the NoAddrsAvail Status Code option when no addresses are available will be kept in the global scope for Advertise messages. Question: Does it need to be further clarified that in Advertise, "NoAddrsAvail" now may mean "SomeAddrsAvail"? 4.4: Note that clients that communicate with servers that do not support this updated Renew processing will receive the NoBinding status for the IA which had no bindings. Question: isn't this also a valid response if the server does support updated Renew processing, but cannot fulfill the binding for the IA? 4.5: It lets a server without a binding to reply to the message, under the assumption that the server only needs knowledge about the prefix(es) on the link, to inform the client that the address is likely valid or not. - Change "lets" to "enables" or "allows", alt. remove "to" between "binding" and "reply". - Bud On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: > Thanks for taking care of comments. I agree with you point regarding poin= t (3). > > -Gaurav > > -----Original Message----- > From: Bernie Volz (volz) > Sent: Wednesday, January 16, 2013 2:38 AM > To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG > Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > Hi: > > Thanks for the comments, I've made some comments below (BV>). > > Let's wait until the 28th before I draft the -04 version. Hopefully there= will be more comments! > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Gaurav Halwasia (ghalwasi) > Sent: Monday, January 14, 2013 10:47 PM > To: Ted Lemon; dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > I read/reviewed this document and I support this document to move forward= . > > I do have some comments and it would be good if authors can consider them= . Even otherwise I support this document. > > 1.) In Abstract :- > > "Implementation experience of the CPE model > described in has shown multiple issues" > I think you wanted to specify RFC6204 after "described in" > > BV> Yes. > > 2.) Section 4.2 Placement of Status codes. > In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, > NoBinding) are encapsulated in the IA option. > I think we should include "NoPrefixAvail" as well in the above line. I se= e no reason why it should not be. > > BV> Yes. Might be best to use (i.e.) too so that it is clear that this is= just a partial list. > > 3.) For Confirm message. As I understand, we are now allowing CONFIRM mes= sage for IA_PD. I think we should update the definition of CONFIRM message = in RFC3315 which currently only talks about *address* > > > CONFIRM (4) A client sends a Confirm message to any > available server to determine whether the > addresses it was assigned are still appropriate > to the link to which the client is connected. > > > BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocat= ion. A RFC 3315bis would definitely want to reword it as such (as I would e= xpect it to combine 3315 and 3633). This really falls into the changes to R= FC 3633 that it would extend Confirm to include prefixes. We tried (I hope)= to keep the RFC 3315 changes consistent with what RFC 3315 contained and P= D changes to RFC 3633. There might be more we could add to RFC 3633, but do= we really think that is necessary? I guess we could replace "addresses" wi= th something more generic ("configuration information explicitly assigned t= o the client", which comes from the definition of binding in RFC 3315), but= I think that doesn't really improve anything. > > BV> Thus, I will not make this change. > > > Thanks, > Gaurav > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ted Lemon > Sent: Tuesday, January 15, 2013 1:04 AM > To: dhc WG > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >> A 2nd Query regarding this as I heard nothing since the first. > > Oops, sorry about that, Bernie. > > Folks, the authors of this draft feel it's ready for a WGLC. There's be= en substantial discussion and comment already. This is pretty important I= Pv6 deployment work, so more eyes are better. Please review the draft and= indicate whether or not you feel it is ready to be published. We have be= en getting very anemic responses to working group messages recently. Your= response matters, so please do respond. > > We will evaluate consensus after January 28. Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Jan 21 07:54:15 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1421821F8569 for ; Mon, 21 Jan 2013 07:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl6uJkC3OfAD for ; Mon, 21 Jan 2013 07:54:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD121F8555 for ; Mon, 21 Jan 2013 07:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6790; q=dns/txt; s=iport; t=1358783653; x=1359993253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kyT/bj47H4puu8pnVzaURPlEQBazn99R4KIzihWi0NM=; b=eUsJRevBuhYKUiSSbj5fFlu57sMI4UWm1vmvknR0+yqcRz/hfwZXa1Q6 dNtMe96gAuvdmy/tuJFRBVmQ2VvRHaQxyhk0LlCWfje/0GDW5mxaOu9xe 1wdlc/8sCwBkjlqb+g0ZnvEX81Vh1eOGxeYKldsJ+8tuQkv0kPbtfTzK1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANBj/VCtJXG9/2dsb2JhbABEvi0Wc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBOHeAYMun8EkFhhA6ZVgnWCJA X-IronPort-AV: E=Sophos;i="4.84,507,1355097600"; d="scan'208";a="165436547" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jan 2013 15:54:12 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0LFsCct010489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jan 2013 15:54:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 09:54:12 -0600 From: "Bernie Volz (volz)" To: Bud Millwood , "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66Cw Date: Mon, 21 Jan 2013 15:54:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:54:15 -0000 Hi: Regarding 4.2, how is that? It always means no addresses available but may = mean prefixes available. Regarding 4.4, I would expect the server to return the IA_* option but with= out any IAADDR/IAPREFIX options. (The server would not really create a reco= rd of this binding since it has no leases.) Perhaps the text should be clar= ified regarding this. Note that perhaps a question exists as to which behav= ior to document for the Reply in this case: 1. Return the IA_* option, empty. 2. Do not return the IA_* option. Either approach would work. 1 may provide more information to the client (b= ut client implementers may prefer 2) -- it is also sending back what the cl= ient sent (since it had no IAADDR/IAPREFIXes to include). Regarding 4.5, ok one of those edits can be done in a -04 (after 28th when = WGLC ends). Usually the RFC-Editor also catches things like this, but best = to give them a better document to start with. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ud Millwood Sent: Monday, January 21, 2013 10:28 AM To: Gaurav Halwasia (ghalwasi) Cc: dhc WG; Bernie Volz (volz); Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 4.2: Proposed solution: No change. For backwards compatibility, the NoAddrsAvail Status Code option when no addresses are available will be kept in the global scope for Advertise messages. Question: Does it need to be further clarified that in Advertise, "NoAddrsA= vail" now may mean "SomeAddrsAvail"? 4.4: Note that clients that communicate with servers that do not support this updated Renew processing will receive the NoBinding status for the IA which had no bindings. Question: isn't this also a valid response if the server does support updat= ed Renew processing, but cannot fulfill the binding for the IA? 4.5: It lets a server without a binding to reply to the message, under the assumption that the server only needs knowledge about the prefix(es) on the link, to inform the client that the address is likely valid or not. - Change "lets" to "enables" or "allows", alt. remove "to" between "binding= " and "reply". - Bud On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: > Thanks for taking care of comments. I agree with you point regarding poin= t (3). > > -Gaurav > > -----Original Message----- > From: Bernie Volz (volz) > Sent: Wednesday, January 16, 2013 2:38 AM > To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG > Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > Hi: > > Thanks for the comments, I've made some comments below (BV>). > > Let's wait until the 28th before I draft the -04 version. Hopefully there= will be more comments! > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Gaurav Halwasia (ghalwasi) > Sent: Monday, January 14, 2013 10:47 PM > To: Ted Lemon; dhc WG > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > I read/reviewed this document and I support this document to move forward= . > > I do have some comments and it would be good if authors can consider them= . Even otherwise I support this document. > > 1.) In Abstract :- > > "Implementation experience of the CPE model > described in has shown multiple issues" > I think you wanted to specify RFC6204 after "described in" > > BV> Yes. > > 2.) Section 4.2 Placement of Status codes. > In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, > NoBinding) are encapsulated in the IA option. > I think we should include "NoPrefixAvail" as well in the above line. I se= e no reason why it should not be. > > BV> Yes. Might be best to use (i.e.) too so that it is clear that this is= just a partial list. > > 3.) For Confirm message. As I understand, we are now allowing CONFIRM=20 > message for IA_PD. I think we should update the definition of CONFIRM=20 > message in RFC3315 which currently only talks about *address* > > > CONFIRM (4) A client sends a Confirm message to any > available server to determine whether the > addresses it was assigned are still appropriate > to the link to which the client is connected. > > > BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix allocat= ion. A RFC 3315bis would definitely want to reword it as such (as I would e= xpect it to combine 3315 and 3633). This really falls into the changes to R= FC 3633 that it would extend Confirm to include prefixes. We tried (I hope)= to keep the RFC 3315 changes consistent with what RFC 3315 contained and P= D changes to RFC 3633. There might be more we could add to RFC 3633, but do= we really think that is necessary? I guess we could replace "addresses" wi= th something more generic ("configuration information explicitly assigned t= o the client", which comes from the definition of binding in RFC 3315), but= I think that doesn't really improve anything. > > BV> Thus, I will not make this change. > > > Thanks, > Gaurav > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Ted Lemon > Sent: Tuesday, January 15, 2013 1:04 AM > To: dhc WG > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >> A 2nd Query regarding this as I heard nothing since the first. > > Oops, sorry about that, Bernie. > > Folks, the authors of this draft feel it's ready for a WGLC. There's be= en substantial discussion and comment already. This is pretty important I= Pv6 deployment work, so more eyes are better. Please review the draft and= indicate whether or not you feel it is ready to be published. We have be= en getting very anemic responses to working group messages recently. Your= response matters, so please do respond. > > We will evaluate consensus after January 28. Thanks! > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From internet-drafts@ietf.org Mon Jan 21 08:18:11 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960EE21F86CC; Mon, 21 Jan 2013 08:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3u2eFZuUA5R; Mon, 21 Jan 2013 08:18:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3439321F871E; Mon, 21 Jan 2013 08:18:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130121161811.29426.67355.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 08:18:11 -0800 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 16:18:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : RECONFIGURE Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-03.txt Pages : 12 Date : 2013-01-21 Abstract: This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Ack. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. This document updates RFC 3315 and RFC 6422. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-reconfigure-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Mon Jan 21 08:23:54 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61221F858A for ; Mon, 21 Jan 2013 08:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFYYSo2A6R+H for ; Mon, 21 Jan 2013 08:23:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D08A21F84BA for ; Mon, 21 Jan 2013 08:23:53 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2196E26410B for ; Mon, 21 Jan 2013 17:23:53 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0A91A238055 for ; Mon, 21 Jan 2013 17:23:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 21 Jan 2013 17:23:52 +0100 From: To: "dhcwg@ietf.org" Date: Mon, 21 Jan 2013 17:23:49 +0100 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-03.txt Thread-Index: Ac338ushs5mZLotpS4WdVVtqwS7iEwAABCGg Message-ID: <94C682931C08B048B7A8645303FDC9F36EA71A6733@PUEXCB1B.nanterre.francetelecom.fr> References: <20130121161811.29426.67355.idtracker@ietfa.amsl.com> In-Reply-To: <20130121161811.29426.67355.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.21.152415 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 16:23:54 -0000 Dear all, This new version integrates all the comments received during the 2nd WGLC. = The main changes are:=20 * Add a new section for rate limiting considerations * Add an explicit response to ack the receipt of reconfigure-request * Add new text to explain the rationale for defining reconfigure-ack * Explicit the retransmission procedure and define the associated parameter= s. A link is provided below for a detailed diff.=20 I would like to thank Bernie for his careful review and suggestions. Cheers, Med >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de internet-drafts@ietf.org >Envoy=E9 : lundi 21 janvier 2013 17:18 >=C0 : i-d-announce@ietf.org >Cc : dhcwg@ietf.org >Objet : [dhcwg] I-D Action: draft-ietf-dhc-triggered-reconfigure-03.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration=20 >Working Group of the IETF. > > Title : RECONFIGURE Triggered by DHCPv6 Relay Agents > Author(s) : Mohamed Boucadair > Xavier Pougnard > Filename : draft-ietf-dhc-triggered-reconfigure-03.txt > Pages : 12 > Date : 2013-01-21 > >Abstract: > This document defines new DHCPv6 messages: Reconfigure-Request and > Reconfigure-Ack. Reconfigure-Request message is sent by a DHCPv6 > relay agent to notify a DHCPv6 server about a configuration > information change, so that the DHCPv6 server can send a Reconfigure > message accordingly. > > This document updates RFC 3315 and RFC 6422. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-triggered-recon >figure-03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From budmillwood@gmail.com Mon Jan 21 14:52:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59C021F8826 for ; Mon, 21 Jan 2013 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPIm-LydlSwc for ; Mon, 21 Jan 2013 14:52:28 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id B22C221F86EA for ; Mon, 21 Jan 2013 14:52:25 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id l10so6702274oag.36 for ; Mon, 21 Jan 2013 14:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sZ9Lc0SjSfoN9/Hl5AmDT8t59o8qAhVO7dhr0V1JAeM=; b=F8iBj0z0PrIeOmb5vSyQADZugFMSqP5i7IVF8RzV1U6VzRDPlZKZkOtRpqy6fM7WYT ufAwqV3K/pH6i9L9VPGFX56RBOL2/hKGgMVRqoNSKJ44iiPGnhfI/x/kIyKNB8OR3Tyk NUhF7ss3tPHbz6lUvvkeQZHYMKW5GRgdnDaw4Hfjt594rNBezV/LA666lNiDbk45geIj 2LlzVhHXpVoNKx3ZAC7O/WvupXTlI5hdeu6kvhhQThF1EnGTBJDHE9cdjL3c2H560gt/ YARAiQ2G++T9V1m49aa86FRWkpEsrejR1BwyXUyncI0CoTsDzJcVqODWmk6v3uNRf82w PSUg== MIME-Version: 1.0 X-Received: by 10.60.169.41 with SMTP id ab9mr14886878oec.58.1358808745275; Mon, 21 Jan 2013 14:52:25 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.60.80.166 with HTTP; Mon, 21 Jan 2013 14:52:25 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> Date: Mon, 21 Jan 2013 23:52:25 +0100 X-Google-Sender-Auth: pAq5FuoA-eBAMRI1syBiqpVIlLM Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 22:52:28 -0000 > Regarding 4.2, how is that? It always means no addresses available but ma= y mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but wi= thout any IAADDR/IAPREFIX options. (The server would not really create a re= cord of this binding since it has no leases.) Perhaps the text should be cl= arified regarding this. The original text says to return an IA_* with no addr/prefix and a status code "NoBinding". Now, if we cannot fulfill the binding, we do the same thing, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document for = the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the client = (but client implementers may prefer 2) -- it is also sending back what the = client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging the IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th whe= n WGLC ends). Usually the RFC-Editor also catches things like this, but bes= t to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddr= sAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support upd= ated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "bindi= ng" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding poi= nt (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully ther= e will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forwar= d. >> >> I do have some comments and it would be good if authors can consider the= m. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. I s= ee no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that this i= s just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM >> message for IA_PD. I think we should update the definition of CONFIRM >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix alloca= tion. A RFC 3315bis would definitely want to reword it as such (as I would = expect it to combine 3315 and 3633). This really falls into the changes to = RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope= ) to keep the RFC 3315 changes consistent with what RFC 3315 contained and = PD changes to RFC 3633. There might be more we could add to RFC 3633, but d= o we really think that is necessary? I guess we could replace "addresses" w= ith something more generic ("configuration information explicitly assigned = to the client", which comes from the definition of binding in RFC 3315), bu= t I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's b= een substantial discussion and comment already. This is pretty important = IPv6 deployment work, so more eyes are better. Please review the draft an= d indicate whether or not you feel it is ready to be published. We have b= een getting very anemic responses to working group messages recently. You= r response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Mon Jan 21 15:24:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F268B21F86D9 for ; Mon, 21 Jan 2013 15:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4PZpRGA3aXI for ; Mon, 21 Jan 2013 15:24:31 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDC421F84EA for ; Mon, 21 Jan 2013 15:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9680; q=dns/txt; s=iport; t=1358810671; x=1360020271; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HH3i5SNey1/wgabJVB/6O74tUfUZgv/1UdGcIfbG8JA=; b=Bo2Lmjvbp071HY0rbixBcX4Iiu2DMxgNgl6jlQJrdV2TVGhkg7JBmexy QxbaAd2scbsgGxUVQ5RrP71KI2g/cqlk/MaO+ZCkRxd3RL6kVXMK2sp9m M/RNA/t4Z0OdpvrohtlQ7/C74mdf5OBX6ZtSQAFwyd/EkWn3V0V5G5L2g A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALnN/VCtJV2a/2dsb2JhbABEvjEWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4d4Bgy8BwSOXYF7YQOmVYJoDYIk X-IronPort-AV: E=Sophos;i="4.84,510,1355097600"; d="scan'208";a="165602720" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jan 2013 23:24:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0LNOUnJ030603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jan 2013 23:24:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 17:24:30 -0600 From: "Bernie Volz (volz)" To: Bud Millwood Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: AQHN9+v1hlVR97tQwEWdQEw5vWHbDZhT66CwgADdE4D//5438A== Date: Mon, 21 Jan 2013 23:24:30 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 23:24:33 -0000 >The original text says to return an IA_* with no addr/prefix and a status = code "NoBinding". Now, if we cannot fulfill the binding, we do the same thi= ng, but we don't include a status code. Is that right? Hum ... perhaps it is best to follow the Request and return NoAddrsAvail st= atus in the IA_* option (of course we'd need to update RFC 3633 text then a= s well to return NoPrefixAvail). The choices now seem to be: 1. Just return the IA_* option (empty). 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following Req= uest logic. 3. Return IA_* option with NoBinding -- following existing Renew logic for = unknown bindings. 4. Don't return the IA_* option (I think this is not a good choice and beli= eve you don't either). Perhaps new #2 is the best as it matches the Request ... Renew and Request = are really very similar anyway - the main differences were: - We are telling the server the client is renewing (thus is using the lease= s) - No new bindings were 'allowed' -- this is now not true and what we are pr= oposing to change. We could do the same for the Rebind. BTW: The case for a Rebind where the server can't find the client entry for= the IA is not covered in RFC 3315 (it is if the addresses are no longer ap= propriate, but not otherwise). In some ways, this missing text leaves it up= to the server (which for some cases, may be good - for example, Failover m= ay trust the client and if there is no conflict, the server may want to res= pond -- that is what we do in V4). In other instances, the server might wan= t to drop the Rebind or respond with NoBindings to force client back to Sol= icit? Also, the Rebind is missing the text that allows the server to change= the addresses as appears in Renew.=20 Opinions? - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of B= ud Millwood Sent: Monday, January 21, 2013 5:52 PM To: Bernie Volz (volz) Cc: dhc WG; Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > Regarding 4.2, how is that? It always means no addresses available but ma= y mean prefixes available. Yes of course; I should have reviewed 3633. > Regarding 4.4, I would expect the server to return the IA_* option but wi= thout any IAADDR/IAPREFIX options. (The server would not really create a re= cord of this binding since it has no leases.) Perhaps the text should be cl= arified regarding this. The original text says to return an IA_* with no addr/prefix and a status c= ode "NoBinding". Now, if we cannot fulfill the binding, we do the same thin= g, but we don't include a status code. Is that right? > Note that perhaps a question exists as to which behavior to document for = the Reply in this case: > 1. Return the IA_* option, empty. > 2. Do not return the IA_* option. > Either approach would work. 1 may provide more information to the client = (but client implementers may prefer 2) -- it is also sending back what the = client sent (since it had no IAADDR/IAPREFIXes to include). (1) makes more sense to me because the server is explicitly acknowledging t= he IA_*. - Bud > Regarding 4.5, ok one of those edits can be done in a -04 (after 28th whe= n WGLC ends). Usually the RFC-Editor also catches things like this, but bes= t to give them a better document to start with. > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf=20 > Of Bud Millwood > Sent: Monday, January 21, 2013 10:28 AM > To: Gaurav Halwasia (ghalwasi) > Cc: dhc WG; Bernie Volz (volz); Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > > 4.2: Proposed solution: No change. For backwards compatibility, the > NoAddrsAvail Status Code option when no addresses are available will > be kept in the global scope for Advertise messages. > > Question: Does it need to be further clarified that in Advertise, "NoAddr= sAvail" now may mean "SomeAddrsAvail"? > > 4.4: Note that clients that communicate with servers that do not support > this updated Renew processing will receive the NoBinding status for > the IA which had no bindings. > > Question: isn't this also a valid response if the server does support upd= ated Renew processing, but cannot fulfill the binding for the IA? > > 4.5: It lets a server without a binding to reply to > the message, under the assumption that the server only needs > knowledge about the prefix(es) on the link, to inform the client that > the address is likely valid or not. > > - Change "lets" to "enables" or "allows", alt. remove "to" between "bindi= ng" and "reply". > > - Bud > > > On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >> Thanks for taking care of comments. I agree with you point regarding poi= nt (3). >> >> -Gaurav >> >> -----Original Message----- >> From: Bernie Volz (volz) >> Sent: Wednesday, January 16, 2013 2:38 AM >> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> Hi: >> >> Thanks for the comments, I've made some comments below (BV>). >> >> Let's wait until the 28th before I draft the -04 version. Hopefully ther= e will be more comments! >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Gaurav Halwasia (ghalwasi) >> Sent: Monday, January 14, 2013 10:47 PM >> To: Ted Lemon; dhc WG >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> I read/reviewed this document and I support this document to move forwar= d. >> >> I do have some comments and it would be good if authors can consider the= m. Even otherwise I support this document. >> >> 1.) In Abstract :- >> >> "Implementation experience of the CPE model >> described in has shown multiple issues" >> I think you wanted to specify RFC6204 after "described in" >> >> BV> Yes. >> >> 2.) Section 4.2 Placement of Status codes. >> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >> NoBinding) are encapsulated in the IA option. >> I think we should include "NoPrefixAvail" as well in the above line. I s= ee no reason why it should not be. >> >> BV> Yes. Might be best to use (i.e.) too so that it is clear that this i= s just a partial list. >> >> 3.) For Confirm message. As I understand, we are now allowing CONFIRM=20 >> message for IA_PD. I think we should update the definition of CONFIRM=20 >> message in RFC3315 which currently only talks about *address* >> >> >> CONFIRM (4) A client sends a Confirm message to any >> available server to determine whether the >> addresses it was assigned are still appropriate >> to the link to which the client is connected. >> >> >> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix alloca= tion. A RFC 3315bis would definitely want to reword it as such (as I would = expect it to combine 3315 and 3633). This really falls into the changes to = RFC 3633 that it would extend Confirm to include prefixes. We tried (I hope= ) to keep the RFC 3315 changes consistent with what RFC 3315 contained and = PD changes to RFC 3633. There might be more we could add to RFC 3633, but d= o we really think that is necessary? I guess we could replace "addresses" w= ith something more generic ("configuration information explicitly assigned = to the client", which comes from the definition of binding in RFC 3315), bu= t I think that doesn't really improve anything. >> >> BV> Thus, I will not make this change. >> >> >> Thanks, >> Gaurav >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 >> Behalf Of Ted Lemon >> Sent: Tuesday, January 15, 2013 1:04 AM >> To: dhc WG >> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>> A 2nd Query regarding this as I heard nothing since the first. >> >> Oops, sorry about that, Bernie. >> >> Folks, the authors of this draft feel it's ready for a WGLC. There's b= een substantial discussion and comment already. This is pretty important = IPv6 deployment work, so more eyes are better. Please review the draft an= d indicate whether or not you feel it is ready to be published. We have b= een getting very anemic responses to working group messages recently. You= r response matters, so please do respond. >> >> We will evaluate consensus after January 28. Thanks! >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From budmillwood@gmail.com Mon Jan 21 17:22:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4021F8726 for ; Mon, 21 Jan 2013 17:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKFpObQStIEj for ; Mon, 21 Jan 2013 17:22:19 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2FC21F871D for ; Mon, 21 Jan 2013 17:22:19 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id j1so6743372oag.15 for ; Mon, 21 Jan 2013 17:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=telhgab3nZBUzUdst28yHp8xm3DAzVtygkycCOTGzqI=; b=xYpCCdNea6FCXG9A0BviJrWqZ1DTIbr8T9b0kOlDa3UmT/B+zW2IRV1iUqHo5CgSLK /uhuYsf29qaA7dkmK0rHSVc0yJpIkZfRsjsaHE56NcEQ91e4L+CnsITlmHV/cd5eFdnm 7yj7M2uHYz78Ss2OSSXhiUQimhzg2ooF8Bi4vWr8RfvptNcqJlh806bVxrcIdPuVK2Ad pUkJ0re41BAUeVfzIO6dQilaDeTSIDiDhRUKHEfmffnTb8fPge4So4Y8uRtx53swFm1l JHfjR0dIqrdjMgqFlYOvuvui1YciuB3LaJ52FDMbutDVYZUNrMUFbYbI17e8VjKGMVJ9 C4Jg== MIME-Version: 1.0 X-Received: by 10.182.156.81 with SMTP id wc17mr15820916obb.21.1358817738711; Mon, 21 Jan 2013 17:22:18 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.60.80.166 with HTTP; Mon, 21 Jan 2013 17:22:18 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <90903C21C73202418A48BFBE80AEE5EB22DEB892@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843CA16@xmb-rcd-x04.cisco.com> <90903C21C73202418A48BFBE80AEE5EB22DEDE19@xmb-aln-x06.cisco.com> <489D13FBFA9B3E41812EA89F188F018E18442EC0@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E184431CF@xmb-rcd-x04.cisco.com> Date: Tue, 22 Jan 2013 02:22:18 +0100 X-Google-Sender-Auth: 7N80FC-GbRNa1dS3ye2EJMK6ZXU Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dhc WG , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 01:22:20 -0000 On Tue, Jan 22, 2013 at 12:24 AM, Bernie Volz (volz) wrote= : >>The original text says to return an IA_* with no addr/prefix and a status= code "NoBinding". Now, if we cannot fulfill the binding, we do the same th= ing, but we don't include a status code. Is that right? > > Hum ... perhaps it is best to follow the Request and return NoAddrsAvail = status in the IA_* option (of course we'd need to update RFC 3633 text then= as well to return NoPrefixAvail). > > The choices now seem to be: > 1. Just return the IA_* option (empty). > 2. Return IA_* option with NoAddrsAvail (or NoPrefixAvail) -- following R= equest logic. > 3. Return IA_* option with NoBinding -- following existing Renew logic fo= r unknown bindings. > 4. Don't return the IA_* option (I think this is not a good choice and be= lieve you don't either). > > Perhaps new #2 is the best as it matches the Request ... Renew and Reques= t are really very similar anyway - the main differences were: > - We are telling the server the client is renewing (thus is using the lea= ses) > - No new bindings were 'allowed' -- this is now not true and what we are = proposing to change. I think #2 is best approach. Since we can now create bindings in Renew, and a client should be prepared to obtain a new lease at this time, it's basically the same thing as Request from the standpoint of the protocol. And judging by the names of the error codes, NoAddrsAvail and NoPrefixAvail seem better because they reflect the server's inability to create a binding. "NoBinding" seems more like "No info, can't proceed" (which is more suited the previous behavior). > We could do the same for the Rebind. I suppose my argument in favor of this is the same as above. If the client must be prepared to accept a new lease at this time, it's like a "deferred Request". > BTW: The case for a Rebind where the server can't find the client entry f= or the IA is not covered in RFC 3315 (it is if the addresses are no longer = appropriate, but not otherwise). In some ways, this missing text leaves it = up to the server (which for some cases, may be good - for example, Failover= may trust the client and if there is no conflict, the server may want to r= espond -- that is what we do in V4). In other instances, the server might w= ant to drop the Rebind or respond with NoBindings to force client back to S= olicit? Also, the Rebind is missing the text that allows the server to chan= ge the addresses as appears in Renew. Maybe it's important to distinguish between not being able to create a new binding for a non-existent lease (NoAddrsAvail/NoPrefixAvail) and not being able to create a new binding for an existing lease? (Or for that matter, for the latter, not being able to rebind the addr/prefix in question due to lack of information). - Bud > > Opinions? > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Bud Millwood > Sent: Monday, January 21, 2013 5:52 PM > To: Bernie Volz (volz) > Cc: dhc WG; Ted Lemon > Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 > >> Regarding 4.2, how is that? It always means no addresses available but m= ay mean prefixes available. > > Yes of course; I should have reviewed 3633. > >> Regarding 4.4, I would expect the server to return the IA_* option but w= ithout any IAADDR/IAPREFIX options. (The server would not really create a r= ecord of this binding since it has no leases.) Perhaps the text should be c= larified regarding this. > > The original text says to return an IA_* with no addr/prefix and a status= code "NoBinding". Now, if we cannot fulfill the binding, we do the same th= ing, but we don't include a status code. Is that right? > >> Note that perhaps a question exists as to which behavior to document for= the Reply in this case: >> 1. Return the IA_* option, empty. >> 2. Do not return the IA_* option. >> Either approach would work. 1 may provide more information to the client= (but client implementers may prefer 2) -- it is also sending back what the= client sent (since it had no IAADDR/IAPREFIXes to include). > > (1) makes more sense to me because the server is explicitly acknowledging= the IA_*. > > - Bud > >> Regarding 4.5, ok one of those edits can be done in a -04 (after 28th wh= en WGLC ends). Usually the RFC-Editor also catches things like this, but be= st to give them a better document to start with. >> >> - Bernie >> >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf >> Of Bud Millwood >> Sent: Monday, January 21, 2013 10:28 AM >> To: Gaurav Halwasia (ghalwasi) >> Cc: dhc WG; Bernie Volz (volz); Ted Lemon >> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >> >> 4.2: Proposed solution: No change. For backwards compatibility, the >> NoAddrsAvail Status Code option when no addresses are available will >> be kept in the global scope for Advertise messages. >> >> Question: Does it need to be further clarified that in Advertise, "NoAdd= rsAvail" now may mean "SomeAddrsAvail"? >> >> 4.4: Note that clients that communicate with servers that do not support >> this updated Renew processing will receive the NoBinding status for >> the IA which had no bindings. >> >> Question: isn't this also a valid response if the server does support up= dated Renew processing, but cannot fulfill the binding for the IA? >> >> 4.5: It lets a server without a binding to reply to >> the message, under the assumption that the server only needs >> knowledge about the prefix(es) on the link, to inform the client that >> the address is likely valid or not. >> >> - Change "lets" to "enables" or "allows", alt. remove "to" between "bind= ing" and "reply". >> >> - Bud >> >> >> On Wed, Jan 16, 2013 at 5:43 AM, Gaurav Halwasia (ghalwasi) wrote: >>> Thanks for taking care of comments. I agree with you point regarding po= int (3). >>> >>> -Gaurav >>> >>> -----Original Message----- >>> From: Bernie Volz (volz) >>> Sent: Wednesday, January 16, 2013 2:38 AM >>> To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG >>> Subject: RE: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> Hi: >>> >>> Thanks for the comments, I've made some comments below (BV>). >>> >>> Let's wait until the 28th before I draft the -04 version. Hopefully the= re will be more comments! >>> >>> - Bernie >>> >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Gaurav Halwasia (ghalwasi) >>> Sent: Monday, January 14, 2013 10:47 PM >>> To: Ted Lemon; dhc WG >>> Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> I read/reviewed this document and I support this document to move forwa= rd. >>> >>> I do have some comments and it would be good if authors can consider th= em. Even otherwise I support this document. >>> >>> 1.) In Abstract :- >>> >>> "Implementation experience of the CPE model >>> described in has shown multiple issues" >>> I think you wanted to specify RFC6204 after "described in" >>> >>> BV> Yes. >>> >>> 2.) Section 4.2 Placement of Status codes. >>> In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink, >>> NoBinding) are encapsulated in the IA option. >>> I think we should include "NoPrefixAvail" as well in the above line. I = see no reason why it should not be. >>> >>> BV> Yes. Might be best to use (i.e.) too so that it is clear that this = is just a partial list. >>> >>> 3.) For Confirm message. As I understand, we are now allowing CONFIRM >>> message for IA_PD. I think we should update the definition of CONFIRM >>> message in RFC3315 which currently only talks about *address* >>> >>> >>> CONFIRM (4) A client sends a Confirm message to any >>> available server to determine whether the >>> addresses it was assigned are still appropriat= e >>> to the link to which the client is connected. >>> >>> >>> BV> Well this is a bit tricky as RFC 3315 knows nothing of prefix alloc= ation. A RFC 3315bis would definitely want to reword it as such (as I would= expect it to combine 3315 and 3633). This really falls into the changes to= RFC 3633 that it would extend Confirm to include prefixes. We tried (I hop= e) to keep the RFC 3315 changes consistent with what RFC 3315 contained and= PD changes to RFC 3633. There might be more we could add to RFC 3633, but = do we really think that is necessary? I guess we could replace "addresses" = with something more generic ("configuration information explicitly assigned= to the client", which comes from the definition of binding in RFC 3315), b= ut I think that doesn't really improve anything. >>> >>> BV> Thus, I will not make this change. >>> >>> >>> Thanks, >>> Gaurav >>> -----Original Message----- >>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On >>> Behalf Of Ted Lemon >>> Sent: Tuesday, January 15, 2013 1:04 AM >>> To: dhc WG >>> Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 >>> >>> On Jan 14, 2013, at 2:15 PM, Bernie Volz (volz) wrote: >>>> A 2nd Query regarding this as I heard nothing since the first. >>> >>> Oops, sorry about that, Bernie. >>> >>> Folks, the authors of this draft feel it's ready for a WGLC. There's = been substantial discussion and comment already. This is pretty important= IPv6 deployment work, so more eyes are better. Please review the draft a= nd indicate whether or not you feel it is ready to be published. We have = been getting very anemic responses to working group messages recently. Yo= ur response matters, so please do respond. >>> >>> We will evaluate consensus after January 28. Thanks! >>> >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From gvithal@gmail.com Tue Jan 22 20:35:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0834621F87C8 for ; Tue, 22 Jan 2013 20:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPdYZKwkz3K3 for ; Tue, 22 Jan 2013 20:35:38 -0800 (PST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB921F87AC for ; Tue, 22 Jan 2013 20:35:38 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id fw7so4620538vcb.20 for ; Tue, 22 Jan 2013 20:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=xkTbCSdySJF/lQRKSc2FnG8vn1txjvNHHuyj3lmHa5M=; b=uJYy6H5BnI+ujpW9y2TIcgVF4umlUNoQPbUQTJLb01RygTnJ/hFfg2SyRiHT7A20X/ gCfNAmpob66ncAdLlwZ1KTuvXtUAkVZyhaa5rZgcRyNuueb2laoEB+O2ImhPBYPV783Y rahIt0bGTo+sjb0yn85x6Sm2zHbbG15Y6zvjn5sq+D00Bwd1VVCtPxxmO5D+fv0TuiqD areeBdcStHbXDtCwKSeYRqkyXKK1lnXlbxLirxMWObt+MtmEqWykSZMt2t2HFCoFrn3K m2GxHPDtmMOxR3RkJvzj6ZZGjrI52QN4DdCVMNlyWGDKOOW8qoZgC5LMTOtlW0RniXKY 0WcA== MIME-Version: 1.0 X-Received: by 10.220.247.204 with SMTP id md12mr26453468vcb.27.1358915737519; Tue, 22 Jan 2013 20:35:37 -0800 (PST) Received: by 10.59.10.194 with HTTP; Tue, 22 Jan 2013 20:35:37 -0800 (PST) In-Reply-To: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2013 10:05:37 +0530 Message-ID: From: VithalPrasad Gaitonde To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=bcaec54eede8d0864e04d3ed3987 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 04:35:39 -0000 --bcaec54eede8d0864e04d3ed3987 Content-Type: text/plain; charset=ISO-8859-1 Hi Ralph, This draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour. Can you please clarify what is the expected behavior of the client with this - Is the client expected to send a SOLICIT every 1 hour and wait for a server response for the next hour (timeout). or is the client expected to send a SOLICIT every 1 hour but timeout after 2 minutes. My understanding is the former but need confirmation. Also, I expect that the proposal is that in the first hour when the client connects to the network, the retransmission during this first hour are as governed by section 14 of RFC 3315 i.e. the client does retransmissions with increasing timeout values (starting with min of 1 second) till a max timeout of 1 hour. Please confirm. Thanks, Prasad On Fri, Dec 14, 2012 at 7:59 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Dynamic Host Configuration Working Group > of the IETF. > > Title : Modification to Default Value of SOL_MAX_RT > Author(s) : Ralph Droms > Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt > Pages : 5 > Date : 2012-12-13 > > Abstract: > This document updates RFC 3315 by redefining the default value for > SOL_MAX_RT and defining an option through which a DHCPv6 server can > override the client's default value for SOL_MAX_RT with a new value. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --bcaec54eede8d0864e04d3ed3987 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ralph,
=A0
This draft proposes to increase SOL_= MAX_RT from 2 minutes to 1 hour.
Can you please clarify what is t= he expected behavior of the client with this -
Is the client expe= cted to send a SOLICIT every 1 hour and wait for a server response for the = next hour (timeout).
or is the client expected to send a SOLICIT every 1 hour but timeout a= fter 2 minutes.
=A0
My understanding is the former but = need confirmation.
=A0
Also, I expect that the proposal= is that in the first hour when the client connects to the network, the ret= ransmission during this first hour are as governed by section 14 of RFC 331= 5=A0i.e. the client does retransmissions with increasing timeout values (st= arting with min of 1 second) till a max timeout of 1 hour. Please confirm.<= /div>
=A0
Thanks,
Prasad

On Fri, Dec 14, 2012 at 7:59 AM, <internet-drafts@ietf.or= g> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Dynamic Host Configuration Working Grou= p of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Modification to Default Value o= f SOL_MAX_RT
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ralph Droms
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-dhcpv6-solmaxrt-up= date-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 5
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-12-13

Abstract:
=A0 =A0This document updates RFC 3315 by redefining the default value for =A0 =A0SOL_MAX_RT and defining an option through which a DHCPv6 server can<= br> =A0 =A0override the client's default value for SOL_MAX_RT with a new va= lue.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-d= hcpv6-solmaxrt-update

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-sol= maxrt-update-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--bcaec54eede8d0864e04d3ed3987-- From gvithal@gmail.com Fri Jan 25 08:35:05 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5C521F88E2 for ; Fri, 25 Jan 2013 08:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE2Dpp4fytrM for ; Fri, 25 Jan 2013 08:35:04 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1F21F88D6 for ; Fri, 25 Jan 2013 08:35:04 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so403448vbm.6 for ; Fri, 25 Jan 2013 08:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=qoSf3szgxJEnSy7CIJAy6ruYbdEEPc0fuw9ApgVx7A8=; b=Zv13rq1lCRyk5UFxerRG/iULQqapYBXRWpz8HvxhaVpps5mSl/WbU/d5n9848g+X94 OzxvYhOBvcYXzwJ+hqKOZmr1cMaVtpc+Ub6hmieLNctV+u3tEg1jw5GFHmZF/tcYqrQR EUAg71wghGh++B6LSCw14dpc0AvG7dsjewch6CvQSwNnfi+pRt+xyKIwgdFefp1QVk25 nQJYMaxYnJHhnqBGjCCSS9rKp1JWh+mOsi6qA6ogf8Z0BcDXD6IGRzjDFN5eSUfWYtut V0YyWMNH8bgkvjLD+VAqglu68h9lKDJZUFSVBA5dnx0xV6ovWlouUGX45Z2kGLU6/XCK OTUw== MIME-Version: 1.0 X-Received: by 10.52.72.194 with SMTP id f2mr5682521vdv.106.1359131703546; Fri, 25 Jan 2013 08:35:03 -0800 (PST) Received: by 10.59.10.194 with HTTP; Fri, 25 Jan 2013 08:35:03 -0800 (PST) In-Reply-To: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 22:05:03 +0530 Message-ID: From: VithalPrasad Gaitonde To: dhcwg@ietf.org Content-Type: multipart/alternative; boundary=bcaec50160c564946904d41f82c1 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:35:05 -0000 --bcaec50160c564946904d41f82c1 Content-Type: text/plain; charset=ISO-8859-1 Can someone please clarify on the below mentioned issues. On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde wrote: > Hi Ralph, > > This draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour. > Can you please clarify what is the expected behavior of the client with > this - > Is the client expected to send a SOLICIT every 1 hour and wait for a > server response for the next hour (timeout). > or is the client expected to send a SOLICIT every 1 hour but timeout after > 2 minutes. > > My understanding is the former but need confirmation. > > Also, I expect that the proposal is that in the first hour when the client > connects to the network, the retransmission during this first hour are as > governed by section 14 of RFC 3315 i.e. the client does retransmissions > with increasing timeout values (starting with min of 1 second) till a max > timeout of 1 hour. Please confirm. > > Thanks, > Prasad > > On Fri, Dec 14, 2012 at 7:59 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Dynamic Host Configuration Working >> Group of the IETF. >> >> Title : Modification to Default Value of SOL_MAX_RT >> Author(s) : Ralph Droms >> Filename : draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt >> Pages : 5 >> Date : 2012-12-13 >> >> Abstract: >> This document updates RFC 3315 by redefining the default value for >> SOL_MAX_RT and defining an option through which a DHCPv6 server can >> override the client's default value for SOL_MAX_RT with a new value. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-solmaxrt-update >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> > > --bcaec50160c564946904d41f82c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can someone please clarify on the below mentioned issues.

On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde <= gvithal@gmail.com> wrote:
Hi Ralph,
=A0
This = draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour.
C= an you please clarify what is the expected behavior of the client with this= -
Is the client expected to send a SOLICIT every 1 hour and wait for a s= erver response for the next hour (timeout).
or is the client expected to send a SOLICIT every 1 hour but timeout a= fter 2 minutes.
=A0
My understanding is the former but = need confirmation.
=A0
Also, I expect that the proposal= is that in the first hour when the client connects to the network, the ret= ransmission during this first hour are as governed by section 14 of RFC 331= 5=A0i.e. the client does retransmissions with increasing timeout values (st= arting with min of 1 second) till a max timeout of 1 hour. Please confirm.<= /div>
=A0
Thanks,
Prasad

On Fri, Dec 14, 2012 at 7:= 59 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Dynamic Host Configuration Working Grou= p of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Modification to Default Value o= f SOL_MAX_RT
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Ralph Droms
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dhc-dhcpv6-solmaxrt-up= date-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 5
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-12-13

Abstract:
=A0 =A0This document updates RFC 3315 by redefining the default value for =A0 =A0SOL_MAX_RT and defining an option through which a DHCPv6 server can<= br> =A0 =A0override the client's default value for SOL_MAX_RT with a new va= lue.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-d= hcpv6-solmaxrt-update

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-sol= maxrt-update-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg


--bcaec50160c564946904d41f82c1-- From akostur@incognito.com Fri Jan 25 08:48:28 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0134421F894D for ; Fri, 25 Jan 2013 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7jIb3RAPYAT for ; Fri, 25 Jan 2013 08:48:27 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id B11F321F8948 for ; Fri, 25 Jan 2013 08:48:26 -0800 (PST) Received: from mail-qa0-f71.google.com ([209.85.216.71]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUQK3WhWGkjxEmYhYFKbpEO5aN9dR7wq8@postini.com; Fri, 25 Jan 2013 08:48:26 PST Received: by mail-qa0-f71.google.com with SMTP id z4so753703qan.6 for ; Fri, 25 Jan 2013 08:48:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hnDV+NiIGVcBBSpeUrcxulbCQ70WAWh3pCFFMSGPfaQ=; b=RuBZB2HDjXzGCPGqTtfS/6ScYt1HpVudbuvx0d0KOCYqbpaYV/SUgjRQNeZ9R/KZE5 HrAmcJNw7xuQZjdS4E/usFnX/2xr9PYh1M35s3wNfJ22i5MuAy/mmG303HZZ/zzMvPJy rfiE0sI3tNQ4gElsLiGvBjwSYh3pPdRTj7SP9f304rj4YTaHfngnZhFqWqTx2ljKpyza iqDIvPCc0XoGfJ5wnCGb3Lo53RO7BkQnRdjRZLDjOBuO/c24UFA8D7WfAV5f2tXW896J gThbpGwFnOVQ/4sAwOB7dvGaZ/ZDl0BlyddksHXp1Nqvk3/rN0GUn08SIjBQSMOSxkpw RmRg== X-Received: by 10.52.75.105 with SMTP id b9mr5909104vdw.28.1359132505594; Fri, 25 Jan 2013 08:48:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.75.105 with SMTP id b9mr5909097vdw.28.1359132505494; Fri, 25 Jan 2013 08:48:25 -0800 (PST) Received: by 10.220.202.196 with HTTP; Fri, 25 Jan 2013 08:48:24 -0800 (PST) In-Reply-To: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 08:48:24 -0800 Message-ID: From: Andre Kostur To: VithalPrasad Gaitonde Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnCIYSV1h1Fk9lMKv4X/ieeO6GxiAzKrI74p2zL74TrRh4LEYtpPvQyDtkTc08AzKIYynuyYO1A91NTImpoQcyyooKzlJi1sTBdIvJNJsd3+bM+1VFSfruWgCrWELfP8w1fD2TQ9ExEuBiP/KPdsvhwNpmkXQ== Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:48:28 -0000 My interpretation of Sections 14 and 17.1.2 of RFC 3315 plus this draft suggests that the client does all of the stuff it used to do, but continues to extend the timeout out to 1 hour. So it retries at 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 3600, 3600... seconds (modified by the random calculation). The phrasing of RFC 3315 suggests that the client is valiantly waiting for an Advertise (or Reply for Rapid Commit) through the entire time. Of course, the 3600 may be modified by the server sending back the option which sets that time to a different value. On Fri, Jan 25, 2013 at 8:35 AM, VithalPrasad Gaitonde wrote: > Can someone please clarify on the below mentioned issues. > > > On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde > wrote: >> >> Hi Ralph, >> >> This draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour. >> Can you please clarify what is the expected behavior of the client with >> this - >> Is the client expected to send a SOLICIT every 1 hour and wait for a >> server response for the next hour (timeout). >> or is the client expected to send a SOLICIT every 1 hour but timeout after >> 2 minutes. >> >> My understanding is the former but need confirmation. >> >> Also, I expect that the proposal is that in the first hour when the client >> connects to the network, the retransmission during this first hour are as >> governed by section 14 of RFC 3315 i.e. the client does retransmissions with >> increasing timeout values (starting with min of 1 second) till a max timeout >> of 1 hour. Please confirm. -- Andre Kostur From Dmitry.Anipko@microsoft.com Sun Jan 27 23:35:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A5521F891D for ; Sun, 27 Jan 2013 23:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aki3oxJmMpQy for ; Sun, 27 Jan 2013 23:35:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3087221F8922 for ; Sun, 27 Jan 2013 23:35:40 -0800 (PST) Received: from BY2FFO11FD002.protection.gbl (10.1.15.204) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.596.13; Mon, 28 Jan 2013 07:35:39 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Mon, 28 Jan 2013 07:35:39 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Mon, 28 Jan 2013 07:35:37 +0000 From: Dmitry Anipko To: Andre Kostur , VithalPrasad Gaitonde Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nD Date: Mon, 28 Jan 2013 07:35:36 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(51704002)(24454001)(59766001)(56776001)(50986001)(77982001)(46102001)(54356001)(16406001)(74662001)(53806001)(20776003)(55846006)(74502001)(33656001)(23726001)(4396001)(44976002)(54316002)(31966008)(79102001)(47736001)(76482001)(550184003)(47776003)(56816002)(47446002)(5343655001)(63696002)(51856001)(47976001)(46406002)(5343635001)(49866001)(50466001)(57646009); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 074040B844 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 07:35:42 -0000 >>The phrasing of RFC 3315 suggests that the client is valiantly waiting for an Advertise (or Reply for Rapid Commit) through the entire time. While I agree this is one of the possible interpretations, is there a parti= cular language which explicitly specifies this behavior? Given that initially client retries with the interval of seconds, is it a r= easonable assumption that any server implementation would reply within seco= nds or immediately to a client request (or not reply to that particular req= uest at all), and hence if there was no reply - the client eventually re-tr= ansmits its message? Thanks. ________________________________________ From: dhcwg-bounces@ietf.org [dhcwg-bounces@ietf.org] on behalf of Andre Ko= stur [akostur@incognito.com] Sent: Friday, January 25, 2013 8:48 AM To: VithalPrasad Gaitonde Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt My interpretation of Sections 14 and 17.1.2 of RFC 3315 plus this draft suggests that the client does all of the stuff it used to do, but continues to extend the timeout out to 1 hour. So it retries at 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 3600, 3600... seconds (modified by the random calculation). The phrasing of RFC 3315 suggests that the client is valiantly waiting for an Advertise (or Reply for Rapid Commit) through the entire time. Of course, the 3600 may be modified by the server sending back the option which sets that time to a different value. On Fri, Jan 25, 2013 at 8:35 AM, VithalPrasad Gaitonde wrote: > Can someone please clarify on the below mentioned issues. > > > On Wed, Jan 23, 2013 at 10:05 AM, VithalPrasad Gaitonde > wrote: >> >> Hi Ralph, >> >> This draft proposes to increase SOL_MAX_RT from 2 minutes to 1 hour. >> Can you please clarify what is the expected behavior of the client with >> this - >> Is the client expected to send a SOLICIT every 1 hour and wait for a >> server response for the next hour (timeout). >> or is the client expected to send a SOLICIT every 1 hour but timeout aft= er >> 2 minutes. >> >> My understanding is the former but need confirmation. >> >> Also, I expect that the proposal is that in the first hour when the clie= nt >> connects to the network, the retransmission during this first hour are a= s >> governed by section 14 of RFC 3315 i.e. the client does retransmissions = with >> increasing timeout values (starting with min of 1 second) till a max tim= eout >> of 1 hour. Please confirm. -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg= From Ted.Lemon@nominum.com Wed Jan 30 03:57:39 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7072F21F8778 for ; Wed, 30 Jan 2013 03:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnQb2q6FwDuo for ; Wed, 30 Jan 2013 03:57:39 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id DBEF221F875A for ; Wed, 30 Jan 2013 03:57:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUQkKsSiSWo7l8dU8efTzXjAXfSYHldL4@postini.com; Wed, 30 Jan 2013 03:57:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4733AF8009 for ; Wed, 30 Jan 2013 03:57:37 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3C1AA190043; Wed, 30 Jan 2013 03:57:37 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 03:57:37 -0800 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLnWtwi1wyaSEqStm4niIO/zJhXGQSAgAPtrICAAAO7AIAEHIsAgANt2YA= Date: Wed, 30 Jan 2013 11:57:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <38100A3F8D3FBB4E9E805DF43BD6D2DB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:57:39 -0000 On Jan 28, 2013, at 2:35 AM, Dmitry Anipko wr= ote: > While I agree this is one of the possible interpretations, is there a par= ticular language which explicitly specifies this behavior? What Andre said is correct. Section 17.1.2 of RFC3315 describes this in d= etail. From Dmitry.Anipko@microsoft.com Wed Jan 30 11:17:50 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A621F87A4 for ; Wed, 30 Jan 2013 11:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC6S+9pmSBZQ for ; Wed, 30 Jan 2013 11:17:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45221F86F6 for ; Wed, 30 Jan 2013 11:17:46 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.203) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 30 Jan 2013 19:17:43 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 30 Jan 2013 19:17:43 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 19:17:20 +0000 From: Dmitry Anipko To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gA== Date: Wed, 30 Jan 2013 19:17:19 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(24454001)(13464002)(54316002)(77982001)(47736001)(74662001)(550184003)(47776003)(4396001)(63696002)(31966008)(23726001)(44976002)(46102001)(16406001)(59766001)(50466001)(20776003)(53806001)(51856001)(33656001)(46406002)(47976001)(76482001)(74502001)(49866001)(47446002)(55846006)(50986001)(79102001)(56816002)(5343635001)(56776001)(5343655001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0742443479 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 19:17:50 -0000 Thanks Ted. The text in section 17.1.2 was written when SOL_MAX_RT was set = at 120s. While this may be what the text says verbatim, it is not immediate= ly clear, whether it is reasonable to extrapolate the same exact meaning to= the case where SOL_MAX_RT is set to 1h. What scenario would be broken, if = the client waited for server reply only for e.g. 120s after each retransmis= sion every hour? -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, January 30, 2013 3:58 AM To: Dmitry Anipko Cc: Andre Kostur; VithalPrasad Gaitonde; dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt On Jan 28, 2013, at 2:35 AM, Dmitry Anipko wr= ote: > While I agree this is one of the possible interpretations, is there a par= ticular language which explicitly specifies this behavior? What Andre said is correct. Section 17.1.2 of RFC3315 describes this in d= etail. From Ted.Lemon@nominum.com Wed Jan 30 11:54:51 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9662021F88B9 for ; Wed, 30 Jan 2013 11:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrNtpq4Q6OND for ; Wed, 30 Jan 2013 11:54:51 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id E896221F88A9 for ; Wed, 30 Jan 2013 11:54:50 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUQl6isvzHj9I7cdBJgsHsIyVX/Jv2lJI@postini.com; Wed, 30 Jan 2013 11:54:50 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 240BD1B83A3 for ; Wed, 30 Jan 2013 11:54:50 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1A910190043; Wed, 30 Jan 2013 11:54:50 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 11:54:50 -0800 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLnWtwi1wyaSEqStm4niIO/zJhXGQSAgAPtrICAAAO7AIAEHIsAgANt2YCAAHrfgIAACnqA Date: Wed, 30 Jan 2013 19:54:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B9CBBED8120A749BE1DED2778066F3C@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 19:54:51 -0000 On Jan 30, 2013, at 2:17 PM, Dmitry Anipko wr= ote: > Thanks Ted. The text in section 17.1.2 was written when SOL_MAX_RT was se= t at 120s. While this may be what the text says verbatim, it is not immedia= tely clear, whether it is reasonable to extrapolate the same exact meaning = to the case where SOL_MAX_RT is set to 1h. What scenario would be broken, i= f the client waited for server reply only for e.g. 120s after each retransm= ission every hour? Ah, I see the question you are asking. The current answer is that in prin= ciple, you have to be listening the whole time, but I'm curious to hear you= explain why you think this is a problem. I think I can guess, but I'd li= ke you to tell us, because personal experience is more important than theor= y. From Dmitry.Anipko@microsoft.com Wed Jan 30 17:24:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2721F8794 for ; Wed, 30 Jan 2013 17:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrZpldUaonXf for ; Wed, 30 Jan 2013 17:24:20 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id DBBAE21F876E for ; Wed, 30 Jan 2013 17:24:19 -0800 (PST) Received: from BL2FFO11FD009.protection.gbl (10.173.161.202) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 31 Jan 2013 01:24:12 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 31 Jan 2013 01:24:12 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 01:24:02 +0000 From: Dmitry Anipko To: Ted Lemon Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPA= Date: Thu, 31 Jan 2013 01:24:02 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52314002)(24454001)(199002)(189002)(377454001)(13464002)(79102001)(76482001)(55846006)(47446002)(74662001)(50986001)(47736001)(74502001)(44976002)(47976001)(53806001)(54316002)(16406001)(33656001)(56816002)(56776001)(54356001)(77982001)(59766001)(4396001)(31966008)(550184003)(5343655001)(50466001)(23726001)(5343635001)(49866001)(51856001)(46102001)(46406002)(47776003)(20776003)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0743E8D0A6 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 01:24:20 -0000 For some devices, which are energy constrained, doing infinite wait on the = network given that they are going to retransmit anyway (and will get a resp= onse fast if the server is back online) doesn't seem like the best use of t= heir constrained resources. The actual cost depends on the device design - = for some devices/types of links it may be higher than for others. So, if practically all servers reply with responses (if they reply at all) = within seconds/minutes (e.g. current max RT fixed in the original 3315 - 12= 0s + random deviation), and given the client will eventually retry anyway, = I'm trying to understand whether there is indeed a strong reason for a clie= nt to wait for an hour. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Wednesday, January 30, 2013 11:55 AM To: Dmitry Anipko Cc: dhcwg@ietf.org; Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt On Jan 30, 2013, at 2:17 PM, Dmitry Anipko wr= ote: > Thanks Ted. The text in section 17.1.2 was written when SOL_MAX_RT was se= t at 120s. While this may be what the text says verbatim, it is not immedia= tely clear, whether it is reasonable to extrapolate the same exact meaning = to the case where SOL_MAX_RT is set to 1h. What scenario would be broken, i= f the client waited for server reply only for e.g. 120s after each retransm= ission every hour? Ah, I see the question you are asking. The current answer is that in prin= ciple, you have to be listening the whole time, but I'm curious to hear you= explain why you think this is a problem. I think I can guess, but I'd li= ke you to tell us, because personal experience is more important than theor= y. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Ted.Lemon@nominum.com Wed Jan 30 18:10:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA221F8794 for ; Wed, 30 Jan 2013 18:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBEvrabJW1cM for ; Wed, 30 Jan 2013 18:10:12 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5521F872E for ; Wed, 30 Jan 2013 18:10:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUQnSgoGxuEmQhhd1HQJr7Qm9C3bAhbXD@postini.com; Wed, 30 Jan 2013 18:10:12 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9C4621B8386 for ; Wed, 30 Jan 2013 18:10:10 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 936B7190043; Wed, 30 Jan 2013 18:10:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 18:10:10 -0800 From: Ted Lemon To: Dmitry Anipko Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLnWtwi1wyaSEqStm4niIO/zJhXGQSAgAPtrICAAAO7AIAEHIsAgANt2YCAAHrfgIAACnqAgABb/ACAAAzigA== Date: Thu, 31 Jan 2013 02:10:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> , <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <49DD0ADA64A40B4DBCC7A9A705A083B1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , Andre Kostur Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 02:10:19 -0000 On Jan 30, 2013, at 8:24 PM, Dmitry Anipko wr= ote: > So, if practically all servers reply with responses (if they reply at all= ) within seconds/minutes (e.g. current max RT fixed in the original 3315 - = 120s + random deviation), and given the client will eventually retry anyway= , I'm trying to understand whether there is indeed a strong reason for a cl= ient to wait for an hour. I suspected this was the issue you had in mind. I think it would make sen= se to add something to the draft that addresses this issue. From akostur@incognito.com Wed Jan 30 18:20:57 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01B121F8460 for ; Wed, 30 Jan 2013 18:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O11pbOF6B91 for ; Wed, 30 Jan 2013 18:20:55 -0800 (PST) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with SMTP id 7530D21F878F for ; Wed, 30 Jan 2013 18:20:54 -0800 (PST) Received: from mail-ve0-f200.google.com ([209.85.128.200]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUQnVBdWv6j4vqIlyBWTDNAdM15y8TENh@postini.com; Wed, 30 Jan 2013 18:20:54 PST Received: by mail-ve0-f200.google.com with SMTP id ox1so218161veb.11 for ; Wed, 30 Jan 2013 18:20:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=3Pzz5ao76luWEu1TSEdeuwpDx+lZZaNCsP3wwrb3mew=; b=PfEblFEHLQ2tb6JDmV+OyWsYRXwbbmDUUy96o3oGUi4BLOh5rollwCAmyCME1y5y7f GHp4nK8o8kdJfZojHq4r6QqM1Rt2U35iSghGmRw3puh2RE1GtOGIbb2w5iTbFG9bQGOL 5BIZYwSZ+DrpR4Gm3zuwLjF+fpqGCZOXh303/4glfqQOH7WsbHnTAqh/Ua9l46dUoWVF Ploj+4HZ5z6HtP4aOAA8mUlKtpHlz2Ahr6E+Wg7Lm14+b9MzpbWQzDabs9bU8UJb423W NtgnZ3HY7S42vSwFpgocULPzZHbZUEEHTe8WGpKwqfF/z0za5+PVNqr8XoFpaiyHx4IZ Bysg== X-Received: by 10.58.181.42 with SMTP id dt10mr2493695vec.34.1359598852939; Wed, 30 Jan 2013 18:20:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.58.181.42 with SMTP id dt10mr2493689vec.34.1359598852798; Wed, 30 Jan 2013 18:20:52 -0800 (PST) Received: by 10.220.0.212 with HTTP; Wed, 30 Jan 2013 18:20:52 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> Date: Wed, 30 Jan 2013 18:20:52 -0800 Message-ID: From: Andre Kostur To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlRrcTarWJx+X2X2W7l4XaQpIjFL+r13e7pPaTyxpS1fOfC4YqyXmAEfqGGGiQpeD/FCq/cViIrx8Qlw/dbE6Q+bi7k9MVdhlwTtNw66nhk3eqUKjPOOZMYAq7nnMUlis1b8tOBE5TURBd3a1TOISHnv+YlBA== Cc: "dhcwg@ietf.org" , Dmitry Anipko Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 02:20:57 -0000 Not directly related to this draft (as this is a consideration after the device obtains some addresses), but if one of these restricted-power devices wished to be able to do Reconfigure, how would that work? On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: > On Jan 30, 2013, at 8:24 PM, Dmitry Anipko = wrote: >> So, if practically all servers reply with responses (if they reply at al= l) within seconds/minutes (e.g. current max RT fixed in the original 3315 -= 120s + random deviation), and given the client will eventually retry anywa= y, I'm trying to understand whether there is indeed a strong reason for a c= lient to wait for an hour. > > I suspected this was the issue you had in mind. I think it would make s= ense to add something to the draft that addresses this issue. > --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From budmillwood@gmail.com Thu Jan 31 02:53:43 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA221F86A8 for ; Thu, 31 Jan 2013 02:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2Q7qQbgvUTd for ; Thu, 31 Jan 2013 02:53:40 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id 692C221F869B for ; Thu, 31 Jan 2013 02:53:40 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so2660648obb.25 for ; Thu, 31 Jan 2013 02:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PWVwipjL1/kwc8YvPNrWgc6+rXDt88CS9184YB6jYTA=; b=Ly9kN864cGYn1O5BL9CsNwcfQb2DwnRfjAWeuU96gAxW+xzGNyuhLDVLUPNeRrkp4O gZhMVtBgIs4tPzLUOFj6DQ92txu00A8hQXXw6agf+oihUwX9Hmuro5H0G4U5KdI9uvei 80VSrxiRQUcqLxdoN4ktLZNGfVkkFqn0qocayWsel3dN8R5Z0m+ealjA6rqyQb8MEsbz zGJbvakzcNd11vuTP5Vz6kEvj8uDGwDCT//alpEUdonZb/qNuFxHnKipq+EYtuIkDkfv tcdY4mFoVbtPx2QDEZqMHqrol2d8h9tZIcq/+jisKB3Xyosz1B0hZh1672nL6WeKuenc 6elg== MIME-Version: 1.0 X-Received: by 10.60.19.161 with SMTP id g1mr6358486oee.117.1359629619920; Thu, 31 Jan 2013 02:53:39 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.60.80.166 with HTTP; Thu, 31 Jan 2013 02:53:39 -0800 (PST) In-Reply-To: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> Date: Thu, 31 Jan 2013 11:53:39 +0100 X-Google-Sender-Auth: NDwW1PEnKRAhMvg2jjF2ssrQMDI Message-ID: From: Bud Millwood To: Andre Kostur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:53:44 -0000 On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wrote= : > Not directly related to this draft (as this is a consideration after > the device obtains some addresses), but if one of these > restricted-power devices wished to be able to do Reconfigure, how > would that work? For that matter, what about any other scenario where we could adjust the time spent using a socket in order to reduce energy? My question for Dmitry is: if you're not waiting on a socket, aren't you waiting on something? And is it actually likely that it costs more energy (CPU cycles) to wait on an unconnected socket than any other wait mechanism? I just want to make sure we don't go off solving a problem that doesn't actually exist. My understanding is that for long-term TCP socket use on a mobile device, the correct way to do it is to adjust the socket properties to minimize keepalive traffic. I believe that Google provides Push Notification for Android using TCP, with the socket settings tweaked to use almost no battery at all. And that's a connected socket. For UDP, I can't see how a wait on the socket would use any extra CPU cycles at all. But if you have some data, or even theoretical references to such a problem, I'd be interested in reading about it. - Bud > On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: >> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko = wrote: >>> So, if practically all servers reply with responses (if they reply at a= ll) within seconds/minutes (e.g. current max RT fixed in the original 3315 = - 120s + random deviation), and given the client will eventually retry anyw= ay, I'm trying to understand whether there is indeed a strong reason for a = client to wait for an hour. >> >> I suspected this was the issue you had in mind. I think it would make = sense to add something to the draft that addresses this issue. >> > > > > -- > Andre Kostur > Distinguished Software Architect & Engineer > P: 604-678-2864 > E: akostur@incognito.com > Toll-Free: 1-800-877-1856 > > > F: 604-678-2864 > VoIP: sip:864@sip.incognito.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Thu Jan 31 04:18:19 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7E621F8770 for ; Thu, 31 Jan 2013 04:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU3jeAvTev-Y for ; Thu, 31 Jan 2013 04:18:19 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 0663221F876E for ; Thu, 31 Jan 2013 04:18:18 -0800 (PST) Received: from mail-qa0-f72.google.com ([209.85.216.72]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUQphCjMmjqONx8LmKqeUBTE2G/b0VYOt@postini.com; Thu, 31 Jan 2013 04:18:19 PST Received: by mail-qa0-f72.google.com with SMTP id dx4so1879513qab.3 for ; Thu, 31 Jan 2013 04:18:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=+Qbr9lQMYMdlCDWk2suiudNH5mrrIPckxINY2Mk/kQo=; b=I6kybMDgFuRjDEwChbInuXH7ELhdT70GC6b84c+V+IFf5q+WDBVO3+T0+ZF40LmQSK tfuxxWV2fmMMc+Zc8AP0QKHd/+nIp/r+dHUMU846FlZELNJZ9FrbF7SgEAQqPKlOkeof ORA7yKCl81Fyde9cZgmiXdOnfFZA7xYLig1upGIByEA0qLMprZ5GJPPbQDrjgR04CGXV vnVtmTA7UJUXrLavwj5chAydA34LvgnQkUoLRd6jSTo1+OdfZtax9CjJKIu6njglp7Lx c3R0KXi+7vkudOVWPYdpWP8xdIr+IYRxhQBj4IoGdageKKj/X4+X+Efo+N5xJxujPQSm O0rA== X-Received: by 10.220.152.76 with SMTP id f12mr3567047vcw.51.1359634697360; Thu, 31 Jan 2013 04:18:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.152.76 with SMTP id f12mr3567034vcw.51.1359634697169; Thu, 31 Jan 2013 04:18:17 -0800 (PST) Received: by 10.220.0.212 with HTTP; Thu, 31 Jan 2013 04:18:16 -0800 (PST) In-Reply-To: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> Date: Thu, 31 Jan 2013 04:18:16 -0800 Message-ID: From: Andre Kostur To: Bud Millwood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnYfMoOjvIvxhixklnHsSt4T8PY6XRX7FQu37iOyduK2pZqyiLuKPllT6T733DqxVWMwxUyULTwJXXpiuzm40Slv+cCzmw3WesFY3GRMZ2iVBDxfU/5nCi1H84PF0OZnt4p+Qso5v68X7wN52lISsf73Z1BDQ== Cc: "dhcwg@ietf.org" , Ted Lemon , Dmitry Anipko Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:18:19 -0000 A second consideration is whether the energy-constrained device needs to keep a radio alive in order to listen for the incoming UDP? On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood wr= ote: > On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wro= te: >> Not directly related to this draft (as this is a consideration after >> the device obtains some addresses), but if one of these >> restricted-power devices wished to be able to do Reconfigure, how >> would that work? > > For that matter, what about any other scenario where we could adjust > the time spent using a socket in order to reduce energy? > > My question for Dmitry is: if you're not waiting on a socket, aren't > you waiting on something? And is it actually likely that it costs more > energy (CPU cycles) to wait on an unconnected socket than any other > wait mechanism? > > I just want to make sure we don't go off solving a problem that > doesn't actually exist. My understanding is that for long-term TCP > socket use on a mobile device, the correct way to do it is to adjust > the socket properties to minimize keepalive traffic. I believe that > Google provides Push Notification for Android using TCP, with the > socket settings tweaked to use almost no battery at all. And that's a > connected socket. > > For UDP, I can't see how a wait on the socket would use any extra CPU > cycles at all. But if you have some data, or even theoretical > references to such a problem, I'd be interested in reading about it. > > - Bud > >> On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote= : >>> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko wrote: >>>> So, if practically all servers reply with responses (if they reply at = all) within seconds/minutes (e.g. current max RT fixed in the original 3315= - 120s + random deviation), and given the client will eventually retry any= way, I'm trying to understand whether there is indeed a strong reason for a= client to wait for an hour. >>> >>> I suspected this was the issue you had in mind. I think it would make= sense to add something to the draft that addresses this issue. >>> >> >> >> >> -- >> Andre Kostur >> Distinguished Software Architect & Engineer >> P: 604-678-2864 >> E: akostur@incognito.com >> Toll-Free: 1-800-877-1856 >> >> >> F: 604-678-2864 >> VoIP: sip:864@sip.incognito.com >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From stenc@s-carlsen.dk Thu Jan 31 04:27:27 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD5321F845D for ; Thu, 31 Jan 2013 04:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik2PDgcSZP5H for ; Thu, 31 Jan 2013 04:27:26 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3781921F8436 for ; Thu, 31 Jan 2013 04:27:26 -0800 (PST) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 9B45CDADA; Thu, 31 Jan 2013 13:27:19 +0100 (CET) Message-ID: <510A6327.6050506@s-carlsen.dk> Date: Thu, 31 Jan 2013 13:27:19 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Kostur References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/alternative; boundary="------------080601060801090106050108" Cc: "dhcwg@ietf.org" , Dmitry Anipko , Ted Lemon , Bud Millwood Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:27:27 -0000 This is a multi-part message in MIME format. --------------080601060801090106050108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 31/01/13 13:18, Andre Kostur wrote: > A second consideration is whether the energy-constrained device needs > to keep a radio alive in order to listen for the incoming UDP? Usually there will be a strict timing so the power for the radio is minimized by only listening at specific times. The master example is GSM that can sleep for 2.12 seconds and then listen for 300µs. Other energy restricted devices must be designed likewise or burn far too much energy. Generally from this perspective fixed/predictable windows makes sense, synchronize events and save more energy. > > On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood wrote: >> On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wrote: >>> Not directly related to this draft (as this is a consideration after >>> the device obtains some addresses), but if one of these >>> restricted-power devices wished to be able to do Reconfigure, how >>> would that work? >> For that matter, what about any other scenario where we could adjust >> the time spent using a socket in order to reduce energy? >> >> My question for Dmitry is: if you're not waiting on a socket, aren't >> you waiting on something? And is it actually likely that it costs more >> energy (CPU cycles) to wait on an unconnected socket than any other >> wait mechanism? >> >> I just want to make sure we don't go off solving a problem that >> doesn't actually exist. My understanding is that for long-term TCP >> socket use on a mobile device, the correct way to do it is to adjust >> the socket properties to minimize keepalive traffic. I believe that >> Google provides Push Notification for Android using TCP, with the >> socket settings tweaked to use almost no battery at all. And that's a >> connected socket. >> >> For UDP, I can't see how a wait on the socket would use any extra CPU >> cycles at all. But if you have some data, or even theoretical >> references to such a problem, I'd be interested in reading about it. >> >> - Bud >> >>> On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: >>>> On Jan 30, 2013, at 8:24 PM, Dmitry Anipko wrote: >>>>> So, if practically all servers reply with responses (if they reply at all) within seconds/minutes (e.g. current max RT fixed in the original 3315 - 120s + random deviation), and given the client will eventually retry anyway, I'm trying to understand whether there is indeed a strong reason for a client to wait for an hour. >>>> I suspected this was the issue you had in mind. I think it would make sense to add something to the draft that addresses this issue. >>>> >>> >>> >>> -- >>> Andre Kostur >>> Distinguished Software Architect & Engineer >>> P: 604-678-2864 >>> E: akostur@incognito.com >>> Toll-Free: 1-800-877-1856 >>> >>> >>> F: 604-678-2864 >>> VoIP: sip:864@sip.incognito.com >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg > > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------080601060801090106050108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 31/01/13 13:18, Andre Kostur wrote:
A second consideration is whether the energy-constrained device needs
to keep a radio alive in order to listen for the incoming UDP?
Usually there will be a strict timing so the power for the radio is minimized by only listening at specific times. The master example is GSM that can sleep for 2.12 seconds and then listen for 300µs. Other energy restricted devices must be designed likewise or burn far too much energy.

Generally from this perspective fixed/predictable windows makes sense, synchronize events and save more energy.

On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood <budm@weird-solutions.com> wrote:

On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur <akostur@incognito.com> wrote:

Not directly related to this draft (as this is a consideration after
the device obtains some addresses), but if one of these
restricted-power devices wished to be able to do Reconfigure, how
would that work?

For that matter, what about any other scenario where we could adjust
the time spent using a socket in order to reduce energy?

My question for Dmitry is: if you're not waiting on a socket, aren't
you waiting on something? And is it actually likely that it costs more
energy (CPU cycles) to wait on an unconnected socket than any other
wait mechanism?

I just want to make sure we don't go off solving a problem that
doesn't actually exist. My understanding is that for long-term TCP
socket use on a mobile device, the correct way to do it is to adjust
the socket properties to minimize keepalive traffic. I believe that
Google provides Push Notification for Android using TCP, with the
socket settings tweaked to use almost no battery at all. And that's a
connected socket.

For UDP, I can't see how a wait on the socket would use any extra CPU
cycles at all. But if you have some data, or even theoretical
references to such a problem, I'd be interested in reading about it.

- Bud


On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Jan 30, 2013, at 8:24 PM, Dmitry Anipko <Dmitry.Anipko@microsoft.com> wrote:

So, if practically all servers reply with responses (if they reply at all) within seconds/minutes (e.g. current max RT fixed in the original 3315 - 120s + random deviation), and given the client will eventually retry anyway, I'm trying to understand whether there is indeed a strong reason for a client to wait for an hour.

I suspected this was the issue you had in mind.   I think it would make sense to add something to the draft that addresses this issue.




--
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: akostur@incognito.com
Toll-Free: 1-800-877-1856


F: 604-678-2864
VoIP: sip:864@sip.incognito.com
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg





-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------080601060801090106050108-- From Ted.Lemon@nominum.com Thu Jan 31 04:50:22 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32721F880B for ; Thu, 31 Jan 2013 04:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCibNGCDVsj0 for ; Thu, 31 Jan 2013 04:50:21 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 732FC21F85AD for ; Thu, 31 Jan 2013 04:50:21 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUQpohszyzGv/a/VnwgcPL2vnzOACBNfN@postini.com; Thu, 31 Jan 2013 04:50:21 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 36B2C1B83C1 for ; Thu, 31 Jan 2013 04:50:14 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2CBFF190043 for ; Thu, 31 Jan 2013 04:50:14 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 04:50:14 -0800 From: Ted Lemon To: "dhcwg@ietf.org WG" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLnWtwi1wyaSEqStm4niIO/zJhXGQSAgA0c1gA= Date: Thu, 31 Jan 2013 12:50:13 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074747658A@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <96128A169DC74040B20BF432EA7F20BE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:50:22 -0000 If you guys are interested in exploring this issue, why not write up a prob= lem statement? There's certainly no technical reason why a DHCP server ca= n't send reconfigures within a specified time window, but obviously the cur= rent spec doesn't say anything about this. From stenc@s-carlsen.dk Thu Jan 31 05:34:48 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED8E21F86B7 for ; Thu, 31 Jan 2013 05:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDPTt9ybEDrj for ; Thu, 31 Jan 2013 05:34:47 -0800 (PST) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 51F3E21F86B2 for ; Thu, 31 Jan 2013 05:34:47 -0800 (PST) Received: from silver3airport.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:5ab0:35ff:fe78:122b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 822D9DF0B for ; Thu, 31 Jan 2013 14:34:43 +0100 (CET) Message-ID: <510A72F2.1060406@s-carlsen.dk> Date: Thu, 31 Jan 2013 14:34:42 +0100 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747658A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074747658A@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5 Content-Type: multipart/alternative; boundary="------------000201030607050200080702" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:34:48 -0000 This is a multi-part message in MIME format. --------------000201030607050200080702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am not sure it is worth the effort, every system will have its own timings and idiosyncrasies, making something general that will fit most is unlikely. I just mentioned this to clarify the discussion a bit. On 31/01/13 13:50, Ted Lemon wrote: > If you guys are interested in exploring this issue, why not write up a problem statement? There's certainly no technical reason why a DHCP server can't send reconfigures within a specified time window, but obviously the current spec doesn't say anything about this. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------000201030607050200080702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am not sure it is worth the effort, every system will have its own timings and idiosyncrasies, making something general that will fit most is unlikely.
I just mentioned this to clarify the discussion a bit.

On 31/01/13 13:50, Ted Lemon wrote:
If you guys are interested in exploring this issue, why not write up a problem statement?   There's certainly no technical reason why a DHCP server can't send reconfigures within a specified time window, but obviously the current spec doesn't say anything about this.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"
--------------000201030607050200080702-- From Ted.Lemon@nominum.com Thu Jan 31 05:43:10 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D887921F866F for ; Thu, 31 Jan 2013 05:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVEf6nZ+bbOO for ; Thu, 31 Jan 2013 05:43:10 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 483B121F862E for ; Thu, 31 Jan 2013 05:43:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUQp07tmoZiD85nDNQE0d7avP8h22Usn5@postini.com; Thu, 31 Jan 2013 05:43:10 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E26771B8404 for ; Thu, 31 Jan 2013 05:43:09 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DC0BB190043; Thu, 31 Jan 2013 05:43:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 05:43:09 -0800 From: Ted Lemon To: Sten Carlsen Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLnWtwi1wyaSEqStm4niIO/zJhXGQSAgA0c1gCAAAxvAIAAAlyA Date: Thu, 31 Jan 2013 13:43:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747476845@mbx-01.win.nominum.com> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747658A@mbx-01.win.nominum.com> <510A72F2.1060406@s-carlsen.dk> In-Reply-To: <510A72F2.1060406@s-carlsen.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:43:11 -0000 On Jan 31, 2013, at 8:34 AM, Sten Carlsen wrote: > I am not sure it is worth the effort, every system will have its own timi= ngs and idiosyncrasies, making something general that will fit most is unli= kely. > I just mentioned this to clarify the discussion a bit. I don't know if it's worth the effort either; perhaps we can simply say tha= t mobile devices do not support Reconfigure unless they have really big bat= teries. But if there is some desire to support reconfigure on mobile devi= ces, it might be worth doing this. Mobile devices typically have very acc= urate clocks; there is no particular reason why a solution can't be specifi= ed. From budmillwood@gmail.com Thu Jan 31 06:21:16 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47221F8633 for ; Thu, 31 Jan 2013 06:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ky-SyfV4AJ1 for ; Thu, 31 Jan 2013 06:21:15 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4FB21F85AD for ; Thu, 31 Jan 2013 06:21:15 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so3033975oag.33 for ; Thu, 31 Jan 2013 06:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M8qoNdWh+3rZve0sz3y9ZP0deqqEvW0g6fjzz67hFtI=; b=zSDLdoCj8uzRXWgjUFDGPaHWyX6+vaIpMaq07hcRk+IBmlPEBJUYyq1Hog7aFulhJN LotrqZ87yTzemOp3oDCXoIDFnTdNTyUlkciyWnKtdGy/4P6F/M7rECLmNPshmu2/Qhn2 tbj9jIQU5VZ/dbbDpdJzhy2/MLeYOXozNB17xa33XbDzduIIRmH3co4tKpGLwcytOihr 1Lf/UEx15W+mOIZkuDwRgNglSATxsvCURn/81SlaF5GZ3HDVoZr1mpWR0+h9WK/M4gUN IrPtV6M4CeJPUxXyGacerqjwwFLHsiXKIviYX/Wc0aJM7J0Yc0joEHFDYb4S1U43Ssd+ ZqXw== MIME-Version: 1.0 X-Received: by 10.60.6.227 with SMTP id e3mr6836894oea.66.1359642074861; Thu, 31 Jan 2013 06:21:14 -0800 (PST) Sender: budmillwood@gmail.com Received: by 10.60.80.166 with HTTP; Thu, 31 Jan 2013 06:21:14 -0800 (PST) In-Reply-To: <510A6327.6050506@s-carlsen.dk> References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> Date: Thu, 31 Jan 2013 15:21:14 +0100 X-Google-Sender-Auth: zR7nYMaS2a9csK9EVjQnUUcPFeU Message-ID: From: Bud Millwood To: Sten Carlsen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , Ted Lemon , Andre Kostur , Dmitry Anipko Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:21:16 -0000 Sten, thanks for that real-world example, I've learned something. - Bud On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen wrote: > > On 31/01/13 13:18, Andre Kostur wrote: > > A second consideration is whether the energy-constrained device needs > to keep a radio alive in order to listen for the incoming UDP? > > Usually there will be a strict timing so the power for the radio is > minimized by only listening at specific times. The master example is GSM > that can sleep for 2.12 seconds and then listen for 300=B5s. Other energy > restricted devices must be designed likewise or burn far too much energy. > > Generally from this perspective fixed/predictable windows makes sense, > synchronize events and save more energy. > > > On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood > wrote: > > On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wro= te: > > Not directly related to this draft (as this is a consideration after > the device obtains some addresses), but if one of these > restricted-power devices wished to be able to do Reconfigure, how > would that work? > > For that matter, what about any other scenario where we could adjust > the time spent using a socket in order to reduce energy? > > My question for Dmitry is: if you're not waiting on a socket, aren't > you waiting on something? And is it actually likely that it costs more > energy (CPU cycles) to wait on an unconnected socket than any other > wait mechanism? > > I just want to make sure we don't go off solving a problem that > doesn't actually exist. My understanding is that for long-term TCP > socket use on a mobile device, the correct way to do it is to adjust > the socket properties to minimize keepalive traffic. I believe that > Google provides Push Notification for Android using TCP, with the > socket settings tweaked to use almost no battery at all. And that's a > connected socket. > > For UDP, I can't see how a wait on the socket would use any extra CPU > cycles at all. But if you have some data, or even theoretical > references to such a problem, I'd be interested in reading about it. > > - Bud > > On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: > > On Jan 30, 2013, at 8:24 PM, Dmitry Anipko > wrote: > > So, if practically all servers reply with responses (if they reply at all= ) > within seconds/minutes (e.g. current max RT fixed in the original 3315 - > 120s + random deviation), and given the client will eventually retry anyw= ay, > I'm trying to understand whether there is indeed a strong reason for a > client to wait for an hour. > > I suspected this was the issue you had in mind. I think it would make > sense to add something to the draft that addresses this issue. > > > > -- > Andre Kostur > Distinguished Software Architect & Engineer > P: 604-678-2864 > E: akostur@incognito.com > Toll-Free: 1-800-877-1856 > > > F: 604-678-2864 > VoIP: sip:864@sip.incognito.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > "MALE BOVINE MANURE!!!" > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Dmitry.Anipko@microsoft.com Thu Jan 31 11:23:38 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70C21F8574 for ; Thu, 31 Jan 2013 11:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF6r7dyu79ha for ; Thu, 31 Jan 2013 11:23:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC4A21F8536 for ; Thu, 31 Jan 2013 11:23:37 -0800 (PST) Received: from BL2FFO11FD015.protection.gbl (10.173.161.200) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 31 Jan 2013 19:23:35 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 31 Jan 2013 19:23:34 +0000 Received: from TK5EX14MBXC253.redmond.corp.microsoft.com ([169.254.3.95]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 19:22:38 +0000 From: Dmitry Anipko To: Bud Millwood , Sten Carlsen Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt Thread-Index: AQHN2aLtf97Q/V2yEUWdCx2wJ5mS4phWkuiAgAPtq4CAAAO7AIAEG3nDgANu8ACAAHd7gIAADdqAgABaxPCAAA4bAIAAAv0AgACPRYCAABelAIAAAoeAgAAf1ACAAFAk8A== Date: Thu, 31 Jan 2013 19:22:37 +0000 Message-ID: References: <20121214022919.19971.21882.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63074747458F@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474754C3@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630747475B92@mbx-01.win.nominum.com> <510A6327.6050506@s-carlsen.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(377454001)(24454001)(199002)(189002)(51704002)(52314002)(13464002)(63696002)(5343635001)(50466001)(16406001)(77982001)(59766001)(74502001)(23756002)(51856001)(47776003)(54356001)(50986001)(4396001)(53806001)(47976001)(56816002)(55846006)(47446002)(54316002)(44976002)(74662001)(46102001)(33656001)(47736001)(20776003)(79102001)(5343655001)(49866001)(76482001)(56776001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0743E8D0A6 Cc: "dhcwg@ietf.org" , Andre Kostur , Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:23:38 -0000 To Bud's question: I meant the type of energy cost Andre & Sten referred to= . From my observations, network adapters which require significantly more e= nergy when they listen, are not uncommon. So if there is a "low hanging fruit", which is to simply add one phrase to = the solmaxrt-update that in reality doesn't require behavior change of any = servers today, but allows some client devices to save energy, why not take = it. Are there any objections? Along the same lines, I'd suggest changing default for INF_MAX_RT similarly= to SOL_MAX_RT (or at least say the host MAY choose to do so), with the sam= e rationale - DHCP server is not replying after several frequent retransmis= sions, so what's the point of trying as frequently.=20 To Ted's point, I think a larger overhaul of DHCP to make it more power fri= endly is an interesting idea to explore, though it will probably take notic= eably more time and ignite passionate debates (which are good, but again, t= ake more time to reach consensus :)). -----Original Message----- From: budmillwood@gmail.com [mailto:budmillwood@gmail.com] On Behalf Of Bud= Millwood Sent: Thursday, January 31, 2013 6:21 AM To: Sten Carlsen Cc: Andre Kostur; dhcwg@ietf.org; Dmitry Anipko; Ted Lemon Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.t= xt Sten, thanks for that real-world example, I've learned something. - Bud On Thu, Jan 31, 2013 at 1:27 PM, Sten Carlsen wrote: > > On 31/01/13 13:18, Andre Kostur wrote: > > A second consideration is whether the energy-constrained device needs=20 > to keep a radio alive in order to listen for the incoming UDP? > > Usually there will be a strict timing so the power for the radio is=20 > minimized by only listening at specific times. The master example is=20 > GSM that can sleep for 2.12 seconds and then listen for 300=B5s. Other=20 > energy restricted devices must be designed likewise or burn far too much = energy. > > Generally from this perspective fixed/predictable windows makes sense,=20 > synchronize events and save more energy. > > > On Thu, Jan 31, 2013 at 2:53 AM, Bud Millwood=20 > > wrote: > > On Thu, Jan 31, 2013 at 3:20 AM, Andre Kostur wro= te: > > Not directly related to this draft (as this is a consideration after=20 > the device obtains some addresses), but if one of these=20 > restricted-power devices wished to be able to do Reconfigure, how=20 > would that work? > > For that matter, what about any other scenario where we could adjust=20 > the time spent using a socket in order to reduce energy? > > My question for Dmitry is: if you're not waiting on a socket, aren't=20 > you waiting on something? And is it actually likely that it costs more=20 > energy (CPU cycles) to wait on an unconnected socket than any other=20 > wait mechanism? > > I just want to make sure we don't go off solving a problem that=20 > doesn't actually exist. My understanding is that for long-term TCP=20 > socket use on a mobile device, the correct way to do it is to adjust=20 > the socket properties to minimize keepalive traffic. I believe that=20 > Google provides Push Notification for Android using TCP, with the=20 > socket settings tweaked to use almost no battery at all. And that's a=20 > connected socket. > > For UDP, I can't see how a wait on the socket would use any extra CPU=20 > cycles at all. But if you have some data, or even theoretical=20 > references to such a problem, I'd be interested in reading about it. > > - Bud > > On Wed, Jan 30, 2013 at 6:10 PM, Ted Lemon wrote: > > On Jan 30, 2013, at 8:24 PM, Dmitry Anipko=20 > > wrote: > > So, if practically all servers reply with responses (if they reply at=20 > all) within seconds/minutes (e.g. current max RT fixed in the original=20 > 3315 - 120s + random deviation), and given the client will eventually=20 > retry anyway, I'm trying to understand whether there is indeed a=20 > strong reason for a client to wait for an hour. > > I suspected this was the issue you had in mind. I think it would make > sense to add something to the draft that addresses this issue. > > > > -- > Andre Kostur > Distinguished Software Architect & Engineer > P: 604-678-2864 > E: akostur@incognito.com > Toll-Free: 1-800-877-1856 > > > F: 604-678-2864 > VoIP: sip:864@sip.incognito.com > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > "MALE BOVINE MANURE!!!" > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Ted.Lemon@nominum.com Thu Jan 31 19:51:20 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1621F88DB for ; Thu, 31 Jan 2013 19:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrSJd0-gxqf5 for ; Thu, 31 Jan 2013 19:51:19 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2621F88EF for ; Thu, 31 Jan 2013 19:51:17 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUQs7rc6Iy5uej8Q8/bA5aantGA2/F7+v@postini.com; Thu, 31 Jan 2013 19:51:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8B6A21B835B for ; Thu, 31 Jan 2013 19:51:09 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 82ED9190043 for ; Thu, 31 Jan 2013 19:51:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 19:51:09 -0800 From: Ted Lemon To: " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOAC9e6WOKq1UT9UyI5dVQpbv8Hg== Date: Fri, 1 Feb 2013 03:51:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E546F75E6787349ADD6571D02C5882B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 03:51:20 -0000 This document got significant attention during the call for adoption. The= author feels it is ready to publish and have asked for a last call. The = document describes a load balancing algorithm for DHCPv6, similar to the on= e described in RFC3074 for DHCPv4. Please review the document if you haven't already. If you are in favor of= publishing the document, please say so on the mailing list. If you oppos= e publication of the document, please also say so. If you have comments, = please raise them on the mailing list. We will evaluate consensus on February 14. From Ted.Lemon@nominum.com Thu Jan 31 19:56:32 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04A421F892A for ; Thu, 31 Jan 2013 19:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCSjy84HHeMM for ; Thu, 31 Jan 2013 19:56:31 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4E21F891D for ; Thu, 31 Jan 2013 19:56:31 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUQs876UdLI4r/TfabP4N059arTJ/5Q45@postini.com; Thu, 31 Jan 2013 19:56:31 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D91231B835B for ; Thu, 31 Jan 2013 19:56:30 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D308E190043 for ; Thu, 31 Jan 2013 19:56:30 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 19:56:31 -0800 From: Ted Lemon To: dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soADaH5GgA== Date: Fri, 1 Feb 2013 03:56:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 03:56:32 -0000 On Jan 14, 2013, at 2:34 PM, Ted Lemon wrote: > Folks, the authors of this draft feel it's ready for a WGLC. There's be= en substantial discussion and comment already. This is pretty important I= Pv6 deployment work, so more eyes are better. Please review the draft and= indicate whether or not you feel it is ready to be published. We have be= en getting very anemic responses to working group messages recently. Your= response matters, so please do respond. >=20 > We will evaluate consensus after January 28. Thanks! Bud offered some comment. Aside from that, nobody said they wanted the dr= aft to advance, and nobody objected. By default this means it fails the l= ast call and will not advance. Is that really the outcome that people wan= t, or was everybody just asleep when the WGLC went out? From ghalwasi@cisco.com Thu Jan 31 20:03:08 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657521F86C5 for ; Thu, 31 Jan 2013 20:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCZwzJJyY0TZ for ; Thu, 31 Jan 2013 20:03:07 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BB09821F84BA for ; Thu, 31 Jan 2013 20:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1461; q=dns/txt; s=iport; t=1359691388; x=1360900988; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yE+VLXtZWmP9uGhOcrHUzTSZbZpkwLI0k2n0YYNU1T4=; b=eUlJmrCWu0kCXurBfzXYUEKzRMFYpown8kQtZERgsumIbZ4INXLwC0Es h9Bs45cw/GCvDrXH6na0PT+L/059quxVQBO39/PAOveuCgERYbo/DW2gk QeGLyiSovh/6gij6R0kPOsayAn5LSagB1O2CsPOA3VijWK8pdSlcf7mM+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANQ8C1GtJXHB/2dsb2JhbABFvycWc4IeAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAEBBAESCIgJDMIJBJArYQOmYoJ7giQ X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171525764" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 01 Feb 2013 04:03:07 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r11437BL020832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 04:03:07 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.58]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 22:03:07 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , dhc WG Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 Thread-Index: Ac3Q9Rt2+8Dix9CVTYmAMJDRC/+QkghlkQXAABF0soADaH5GgAAQmmQQ Date: Fri, 1 Feb 2013 04:03:07 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E26D0D@xmb-aln-x06.cisco.com> References: <30813AC8-4595-4AE7-9135-F2AEEB62D8DB@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1843B8C2@xmb-rcd-x04.cisco.com> <8D23D4052ABE7A4490E77B1A012B630747467CA7@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782DB@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 04:03:08 -0000 Just in case it got missed, I replied saying that I want this document to m= ove forward (I also had some comments and Bernie replies to that as well). As it stands today, I am in favor of advancing this draft. -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, February 01, 2013 9:27 AM To: dhc WG Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-03 On Jan 14, 2013, at 2:34 PM, Ted Lemon wrote: > Folks, the authors of this draft feel it's ready for a WGLC. There's be= en substantial discussion and comment already. This is pretty important I= Pv6 deployment work, so more eyes are better. Please review the draft and= indicate whether or not you feel it is ready to be published. We have be= en getting very anemic responses to working group messages recently. Your= response matters, so please do respond. >=20 > We will evaluate consensus after January 28. Thanks! Bud offered some comment. Aside from that, nobody said they wanted the dr= aft to advance, and nobody objected. By default this means it fails the l= ast call and will not advance. Is that really the outcome that people wan= t, or was everybody just asleep when the WGLC went out? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From akostur@incognito.com Thu Jan 31 20:44:18 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76921F88FB for ; Thu, 31 Jan 2013 20:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz+Q0IbWyfY1 for ; Thu, 31 Jan 2013 20:44:17 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 0001521F881E for ; Thu, 31 Jan 2013 20:44:16 -0800 (PST) Received: from mail-vc0-f200.google.com ([209.85.220.200]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUQtIIGeNCz/5z34auKHbCx+hLIGOZHN6@postini.com; Thu, 31 Jan 2013 20:44:17 PST Received: by mail-vc0-f200.google.com with SMTP id p1so4865288vcq.7 for ; Thu, 31 Jan 2013 20:44:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=mHURODS+rWiRU3uDa++ScYZC2xDGO2lxVi+pbLJRlNs=; b=k2HXcsDBjUaEkxOuO9gcLgw8OF5IBBf2QMvq8TR5iMyiayfHMfGPX/SyjxjXcC+XZF q1BiLnms/6+5dDBX/7ZldFr5cTFObU4HqUOhPMKtsGOzdfhdOjvRfsgHItZyP38ikFvs zpqy8j9MLwkYaNkhUju/v/Ata1mo6pBuIvkIPr1nM+vr25fItJQW4PbePuBtprxaocKN 5ZSpSPYZFZn4z5FDhmhSGjJam7pOEjQsiGPHXBFWlueGVaFMZUk6v9LhRvuQDwb0TfIN F8DRhjwQsnymAysyBpTodETUFso7d1TvOZbsDGYH70GOPcKoRzhQ0OxBUZVcRRFRwpDZ vrpQ== X-Received: by 10.220.239.73 with SMTP id kv9mr10295396vcb.50.1359693855903; Thu, 31 Jan 2013 20:44:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.239.73 with SMTP id kv9mr10295390vcb.50.1359693855687; Thu, 31 Jan 2013 20:44:15 -0800 (PST) Received: by 10.220.0.212 with HTTP; Thu, 31 Jan 2013 20:44:15 -0800 (PST) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> Date: Thu, 31 Jan 2013 20:44:15 -0800 Message-ID: From: Andre Kostur To: " WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnVvdGaasdEblASXzvV3PMtGN8b8bIcd2h1nDb1TcQs/o9YymYV5OmA0YaIB7RoYnZAb4UmDuSkfGQGE5KEPR0nAZL9ojKPTBvgxZDdhXt4aPWeF0Tg6jrTflIUA4c/db8yKGDHViVo2SQLE5fitI6LSSgb4g== Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 04:44:18 -0000 I'm the author, and I favour publishing this draft. On Thu, Jan 31, 2013 at 7:51 PM, Ted Lemon wrote: > This document got significant attention during the call for adoption. T= he author feels it is ready to publish and have asked for a last call. Th= e document describes a load balancing algorithm for DHCPv6, similar to the = one described in RFC3074 for DHCPv4. > > Please review the document if you haven't already. If you are in favor = of publishing the document, please say so on the mailing list. If you opp= ose publication of the document, please also say so. If you have comments= , please raise them on the mailing list. > > We will evaluate consensus on February 14. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From ghalwasi@cisco.com Thu Jan 31 20:46:42 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAEE21F88B5 for ; Thu, 31 Jan 2013 20:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtoziEtJvrdt for ; Thu, 31 Jan 2013 20:46:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4A21F881E for ; Thu, 31 Jan 2013 20:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=989; q=dns/txt; s=iport; t=1359694002; x=1360903602; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KDh0gTfZMAhGnJ5/havUusNiupiasOF8KpiqXQMiOqE=; b=Rnnyjcm0YTJwC6cLbOtsO5IkvfG2N32ozdODgXdcMoMTlaOm7reZc5s7 r7xckB8WrmON3G9szYBKblst2SF/GviViFQK9WollVTQu8zqcwXCBd9Ix TWY9Z2nsYjZsZ1SX//j4e8XZc0B4dcud8BTPNxhdhwTf1TuSGgnyZvDYf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFADBHC1GtJV2c/2dsb2JhbABFhgG5JhZzgh4BAQEEAQEBGh00FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiICQzCCwSQK2EDpmKCe4Ik X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171534868" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 01 Feb 2013 04:46:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r114kfC6024484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 04:46:41 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.58]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 22:46:41 -0600 From: "Gaurav Halwasia (ghalwasi)" To: Ted Lemon , " WG" Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOAC9e6WOKq1UT9UyI5dVQpbv8Hphkbdbg Date: Fri, 1 Feb 2013 04:46:40 +0000 Message-ID: <90903C21C73202418A48BFBE80AEE5EB22E2736C@xmb-aln-x06.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 04:46:42 -0000 +1 -Gaurav -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Friday, February 01, 2013 9:21 AM To: WG Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 This document got significant attention during the call for adoption. The= author feels it is ready to publish and have asked for a last call. The = document describes a load balancing algorithm for DHCPv6, similar to the on= e described in RFC3074 for DHCPv4. Please review the document if you haven't already. If you are in favor of= publishing the document, please say so on the mailing list. If you oppos= e publication of the document, please also say so. If you have comments, = please raise them on the mailing list. We will evaluate consensus on February 14. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From Tina.Tsou.Zouting@huawei.com Thu Jan 31 21:02:25 2013 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC821F86AB for ; Thu, 31 Jan 2013 21:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1qkXr+JVEHV for ; Thu, 31 Jan 2013 21:02:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F721F86A2 for ; Thu, 31 Jan 2013 21:02:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id API03021; Fri, 01 Feb 2013 05:02:22 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 05:01:41 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Feb 2013 05:02:20 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.4]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Thu, 31 Jan 2013 21:02:12 -0800 From: Tina TSOU To: "Gaurav Halwasia (ghalwasi)" Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 Thread-Index: AQHOADlKF7umvjuOvUGufQBlyTj3NQ== Date: Fri, 1 Feb 2013 05:02:10 +0000 Message-ID: <00FA0CBB-EECA-46F0-AFDE-65539CA25C35@huawei.com> References: <8D23D4052ABE7A4490E77B1A012B6307474782A7@mbx-01.win.nominum.com>, <90903C21C73202418A48BFBE80AEE5EB22E2736C@xmb-aln-x06.cisco.com> In-Reply-To: <90903C21C73202418A48BFBE80AEE5EB22E2736C@xmb-aln-x06.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: " WG" , Ted Lemon Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 05:02:25 -0000 Dear all, +1 Thank you, Tina On Jan 31, 2013, at 8:46 PM, "Gaurav Halwasia (ghalwasi)" wrote: > +1 >=20 > -Gaurav >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ted Lemon > Sent: Friday, February 01, 2013 9:21 AM > To: WG > Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-load-balancing-00 >=20 > This document got significant attention during the call for adoption. T= he author feels it is ready to publish and have asked for a last call. Th= e document describes a load balancing algorithm for DHCPv6, similar to the = one described in RFC3074 for DHCPv4. >=20 > Please review the document if you haven't already. If you are in favor = of publishing the document, please say so on the mailing list. If you opp= ose publication of the document, please also say so. If you have comments= , please raise them on the mailing list. >=20 > We will evaluate consensus on February 14. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg